Hi everyone
I am working on a PEP5416 device and am using a TI C5416 simulator. I am
implementing an acoustic model which takes the sound input from the microphone,
process it (filters) and provide the filtered output at headphone.
My code is working on the simulator, its not giving any errors and I have
debugged it step by step, its nowhere getting stuck. But when I try to run the
code on the device, its not running. I can hear no output, not a simple buzz. I
have ran a simple code on that device, in which I just take the input and pass
it onto the output. And its running.
What I am doing is:
I have created two buffers: input and output of size 2048.
I first fill the input buffer, pass it to the filter function and then I pass
the output of the filter function to the output buffer.
I have just added a processing function/filter function to my first code (of
simple copy, input to output).
I am not understanding why such an error can occur. If anyone of you have any
idea, kindly reply. I am attaching my code for reference. Its originally in .zip
format. Kindly convert .abc to .zip to view it.
Waiting for reply.
Thanking You
Megha Daga
code working on simulator but not on device?
Started by ●May 1, 2006
Reply by ●May 2, 20062006-05-02
Megha-
> I am working on a PEP5416 device and am using a TI C5416 simulator. I am
> implementing an acoustic model which takes the sound input from the
> microphone, process it (filters) and provide the filtered output at headphone.
> My code is working on the simulator, its not giving any errors and I have
> debugged it step by step, its nowhere getting stuck. But when I try to run
> the code on the device, its not running. I can hear no output, not a simple
> buzz. I have ran a simple code on that device, in which I just take the
> input and pass it onto the output. And its running.
Since you can run simple loopback that's a good starting point for debug -- we call
that "known good". From that point, try adding your code (the unknown, haha), step
by step. For example, just call the functions, but don't take the output, continue
to use the original loopback. The idea is to find which piece of your code does
something bad, like "step on" other code or other memory data, mess up the stack,
etc.
-Jeff
> I am working on a PEP5416 device and am using a TI C5416 simulator. I am
> implementing an acoustic model which takes the sound input from the
> microphone, process it (filters) and provide the filtered output at headphone.
> My code is working on the simulator, its not giving any errors and I have
> debugged it step by step, its nowhere getting stuck. But when I try to run
> the code on the device, its not running. I can hear no output, not a simple
> buzz. I have ran a simple code on that device, in which I just take the
> input and pass it onto the output. And its running.
Since you can run simple loopback that's a good starting point for debug -- we call
that "known good". From that point, try adding your code (the unknown, haha), step
by step. For example, just call the functions, but don't take the output, continue
to use the original loopback. The idea is to find which piece of your code does
something bad, like "step on" other code or other memory data, mess up the stack,
etc.
-Jeff
Reply by ●May 3, 20062006-05-03
Dear Jeff
As I wrote in my last mail, its problem with InitBuffer function. Well I debugged it further and there is no problem in that. The problem is when data goes into the filter function "cfir()'. I just tried with a loop inside the cfir. The loop did following:
rcv = xmt;
And the code is running (rest all is same).
So something is going wrong in the filter function.
I have to debug it further. Actually I am not getting how to debug that. I am gonna follow your advice of adding parts one by one. But that too is difficult to decide what to and what not to.
thanks
megha
Jeff Brower wrote: Megha-
> I am working on a PEP5416 device and am using a TI C5416 simulator. I am
> implementing an acoustic model which takes the sound input from the
> microphone, process it (filters) and provide the filtered output at headphone.
> My code is working on the simulator, its not giving any errors and I have
> debugged it step by step, its nowhere getting stuck. But when I try to run
> the code on the device, its not running. I can hear no output, not a simple
> buzz. I have ran a simple code on that device, in which I just take the
> input and pass it onto the output. And its running.
Since you can run simple loopback that's a good starting point for debug -- we call
that "known good". From that point, try adding your code (the unknown, haha), step
by step. For example, just call the functions, but don't take the output, continue
to use the original loopback. The idea is to find which piece of your code does
something bad, like "step on" other code or other memory data, mess up the stack,
etc.
-Jeff
As I wrote in my last mail, its problem with InitBuffer function. Well I debugged it further and there is no problem in that. The problem is when data goes into the filter function "cfir()'. I just tried with a loop inside the cfir. The loop did following:
rcv = xmt;
And the code is running (rest all is same).
So something is going wrong in the filter function.
I have to debug it further. Actually I am not getting how to debug that. I am gonna follow your advice of adding parts one by one. But that too is difficult to decide what to and what not to.
thanks
megha
Jeff Brower wrote: Megha-
> I am working on a PEP5416 device and am using a TI C5416 simulator. I am
> implementing an acoustic model which takes the sound input from the
> microphone, process it (filters) and provide the filtered output at headphone.
> My code is working on the simulator, its not giving any errors and I have
> debugged it step by step, its nowhere getting stuck. But when I try to run
> the code on the device, its not running. I can hear no output, not a simple
> buzz. I have ran a simple code on that device, in which I just take the
> input and pass it onto the output. And its running.
Since you can run simple loopback that's a good starting point for debug -- we call
that "known good". From that point, try adding your code (the unknown, haha), step
by step. For example, just call the functions, but don't take the output, continue
to use the original loopback. The idea is to find which piece of your code does
something bad, like "step on" other code or other memory data, mess up the stack,
etc.
-Jeff
Reply by ●May 3, 20062006-05-03
Thanks Jeff
Yeah I think there is some problem in the buffer initialization function (which initialises all the buffers for the coefficient data and the type of stimulation and many other things). I call it before taking in the audio data. I noticed that before that function my hCodec has some value, but after that it becomes 0 and there the problem lies. So there is something in that function which makes hCodec zero. But basically in that function I am just allocating memory to all variables and getting data from a file (for type of stimulation to be done). I will be debugging it further now, step by step, but if you have any idea abt why it might be happening, kindly tell me.
Thanking You
Megha Daga
Jeff Brower wrote:
Megha-
> I am working on a PEP5416 device and am using a TI C5416 simulator. I am
> implementing an acoustic model which takes the sound input from the
> microphone, process it (filters) and provide the filtered output at headphone.
> My code is working on the simulator, its not giving any errors and I have
> debugged it step by step, its nowhere getting stuck. But when I try to run
> the code on the device, its not running. I can hear no output, not a simple
> buzz. I have ran a simple code on that device, in which I just take the
> input and pass it onto the output. And its running.
Since you can run simple loopback that's a good starting point for debug -- we call
that "known good". From that point, try adding your code (the unknown, haha), step
by step. For example, just call the functions, but don't take the output, continue
to use the original loopback. The idea is to find which piece of your code does
something bad, like "step on" other code or other memory data, mess up the stack,
etc.
-Jeff
Yeah I think there is some problem in the buffer initialization function (which initialises all the buffers for the coefficient data and the type of stimulation and many other things). I call it before taking in the audio data. I noticed that before that function my hCodec has some value, but after that it becomes 0 and there the problem lies. So there is something in that function which makes hCodec zero. But basically in that function I am just allocating memory to all variables and getting data from a file (for type of stimulation to be done). I will be debugging it further now, step by step, but if you have any idea abt why it might be happening, kindly tell me.
Thanking You
Megha Daga
Jeff Brower wrote:
Megha-
> I am working on a PEP5416 device and am using a TI C5416 simulator. I am
> implementing an acoustic model which takes the sound input from the
> microphone, process it (filters) and provide the filtered output at headphone.
> My code is working on the simulator, its not giving any errors and I have
> debugged it step by step, its nowhere getting stuck. But when I try to run
> the code on the device, its not running. I can hear no output, not a simple
> buzz. I have ran a simple code on that device, in which I just take the
> input and pass it onto the output. And its running.
Since you can run simple loopback that's a good starting point for debug -- we call
that "known good". From that point, try adding your code (the unknown, haha), step
by step. For example, just call the functions, but don't take the output, continue
to use the original loopback. The idea is to find which piece of your code does
something bad, like "step on" other code or other memory data, mess up the stack,
etc.
-Jeff
Reply by ●May 3, 20062006-05-03
Megha-
> As I wrote in my last mail, its problem with InitBuffer function. Well
> I debugged it further and there is no problem in that. The problem is
> when data goes into the filter function "cfir()'. I just tried with a
> loop inside the cfir. The loop did following:
> rcv = xmt;
> And the code is running (rest all is same).
> So something is going wrong in the filter function.
This could be different types of problems:
1) The cfir() code has some basic problem, for example goes beyond array boundary,
bad pointer, etc.
2) The code is Ok, but filter coefficients are not good, so your output eventually
becomes zero or saturated value, and you hear no sound.
> I have to debug it further. Actually I am not getting how to debug
> that. I am gonna follow your advice of adding parts one by one. But that
> too is difficult to decide what to and what not to.
One thing to try is let filter code run, but at very end of function (just before
return) put:
rcv = xmt;
as you did above. Then if you can still hear the output, then probably filter code
is Ok, but coefficients are a problem.
-Jeff
> Jeff Brower wrote: Megha-
>
> > I am working on a PEP5416 device and am using a TI C5416 simulator. I am
> > implementing an acoustic model which takes the sound input from the
> > microphone, process it (filters) and provide the filtered output at headphone.
> > My code is working on the simulator, its not giving any errors and I have
> > debugged it step by step, its nowhere getting stuck. But when I try to run
> > the code on the device, its not running. I can hear no output, not a simple
> > buzz. I have ran a simple code on that device, in which I just take the
> > input and pass it onto the output. And its running.
>
> Since you can run simple loopback that's a good starting point for debug -- we call
> that "known good". From that point, try adding your code (the unknown, haha), step
> by step. For example, just call the functions, but don't take the output, continue
> to use the original loopback. The idea is to find which piece of your code does
> something bad, like "step on" other code or other memory data, mess up the stack,
> etc.
>
> -Jeff
> As I wrote in my last mail, its problem with InitBuffer function. Well
> I debugged it further and there is no problem in that. The problem is
> when data goes into the filter function "cfir()'. I just tried with a
> loop inside the cfir. The loop did following:
> rcv = xmt;
> And the code is running (rest all is same).
> So something is going wrong in the filter function.
This could be different types of problems:
1) The cfir() code has some basic problem, for example goes beyond array boundary,
bad pointer, etc.
2) The code is Ok, but filter coefficients are not good, so your output eventually
becomes zero or saturated value, and you hear no sound.
> I have to debug it further. Actually I am not getting how to debug
> that. I am gonna follow your advice of adding parts one by one. But that
> too is difficult to decide what to and what not to.
One thing to try is let filter code run, but at very end of function (just before
return) put:
rcv = xmt;
as you did above. Then if you can still hear the output, then probably filter code
is Ok, but coefficients are a problem.
-Jeff
> Jeff Brower wrote: Megha-
>
> > I am working on a PEP5416 device and am using a TI C5416 simulator. I am
> > implementing an acoustic model which takes the sound input from the
> > microphone, process it (filters) and provide the filtered output at headphone.
> > My code is working on the simulator, its not giving any errors and I have
> > debugged it step by step, its nowhere getting stuck. But when I try to run
> > the code on the device, its not running. I can hear no output, not a simple
> > buzz. I have ran a simple code on that device, in which I just take the
> > input and pass it onto the output. And its running.
>
> Since you can run simple loopback that's a good starting point for debug -- we call
> that "known good". From that point, try adding your code (the unknown, haha), step
> by step. For example, just call the functions, but don't take the output, continue
> to use the original loopback. The idea is to find which piece of your code does
> something bad, like "step on" other code or other memory data, mess up the stack,
> etc.
>
> -Jeff
Reply by ●May 3, 20062006-05-03
Dear Jeff
Thanks that helped. I did put simple rcv = xmt at end in my main prog, after running the filter function; and I am getting output. there is some delay but there is something and with filter function there is nothing. I tried with single sample and delay was gone. But the problem remains same (with filter not working).
But the thing is this filter has already worked on PC before. I am implementing same code on PEP5416 now and its not running. But what I understand is if it ran on PC it should run on this board too.
If you have any suggestions kindly provide.
Thanks
Megha
---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
Thanks that helped. I did put simple rcv = xmt at end in my main prog, after running the filter function; and I am getting output. there is some delay but there is something and with filter function there is nothing. I tried with single sample and delay was gone. But the problem remains same (with filter not working).
But the thing is this filter has already worked on PC before. I am implementing same code on PEP5416 now and its not running. But what I understand is if it ran on PC it should run on this board too.
If you have any suggestions kindly provide.
Thanks
Megha
---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
Reply by ●May 4, 20062006-05-04
Megha-
> As I told in my last mail, there is some problem in my filter function.
> cause its running properly but the filtered output is not coming. I got
> the reason why. Well the last lines are:
> for(i=0; i > results[i] = flacoustic[i];
> Well flacoustic is the filtered output from filter function and results
> is the array which is written back on the output port of the device. Now
> the problem is flacoustic is float and result is Int16(typedefined as
> short).the filetered function is returning all values between 1 and -1
> and hence when they go into results (defined short), the value becomes
> 0, and hence no output. I hope you got my point.
Try like this:
results[i] = floor(32767.0*flacoustic[i]);
I don't know if you floor() function is available or not; if not find a
function that converts float to int. Also just this might work:
results[i] = (short int)(32767.0*flacoustic[i]);
but I'm not sure because 54xx floating-point library support in CCS may
not be that complete.
In any case, once you have values between -32768 and 32767 in results[],
then you can send those out to D/A converter; i.e. using
PEP5416_AIC23_write16() function.
-Jeff
> Now there were two choices either I convert all Int16 to float or float
> to
> Int16. if I convert float to Int16, I will get 0 in flacoustic itself
> (cause filtered value is between 1 and -1 and will become 0 if flacoustic
> is short). So the only option remains is converting Int16 to float.
> Now the problem is in the device inbuilt functions, when i read data, its
> read in Int16 format. the statement is decalred like following in the
> header file of teh device (pep5416_aic23.h):
> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle hCodec, Int16
> *val);
> and write is defined in following manner:
> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle hCodec, Int16
> val);
> So as you see the val is Int16 and now if I convert Int16 into float, I
> will have to convert it here too. But if I convert it to float, there is
> lot of noise and I am not getting proper output. i tried it without
> filter
> function, on my first code (simple audio in and same audio out). I am not
> getting proper output if I change this function; which I was getting when
> it was Int16. I hope I am able to explain everything clearly.
> Hence my problem remains. I am not able to think of a solution to this.
> If you have any idea kindly help me.
> Thanks
> Megha
>
> Jeff Brower wrote: Megha-
>
>> As I wrote in my last mail, its problem with InitBuffer function. Well
>> I debugged it further and there is no problem in that. The problem is
>> when data goes into the filter function "cfir()'. I just tried with a
>> loop inside the cfir. The loop did following:
>> rcv = xmt;
>> And the code is running (rest all is same).
>> So something is going wrong in the filter function.
>
> This could be different types of problems:
>
> 1) The cfir() code has some basic problem, for example goes beyond array
> boundary,
> bad pointer, etc.
>
> 2) The code is Ok, but filter coefficients are not good, so your output
> eventually
> becomes zero or saturated value, and you hear no sound.
>
>> I have to debug it further. Actually I am not getting how to debug
>> that. I am gonna follow your advice of adding parts one by one. But that
>> too is difficult to decide what to and what not to.
>
> One thing to try is let filter code run, but at very end of function (just
> before
> return) put:
>
> rcv = xmt;
>
> as you did above. Then if you can still hear the output, then probably
> filter code
> is Ok, but coefficients are a problem.
>
> -Jeff
>> Jeff Brower wrote: Megha-
>>
>> > I am working on a PEP5416 device and am using a TI C5416 simulator. I
>> am
>> > implementing an acoustic model which takes the sound input from the
>> > microphone, process it (filters) and provide the filtered output at
>> headphone.
>> > My code is working on the simulator, its not giving any errors and I
>> have
>> > debugged it step by step, its nowhere getting stuck. But when I try to
>> run
>> > the code on the device, its not running. I can hear no output, not a
>> simple
>> > buzz. I have ran a simple code on that device, in which I just take
>> the
>> > input and pass it onto the output. And its running.
>>
>> Since you can run simple loopback that's a good starting point for debug
>> -- we call
>> that "known good". From that point, try adding your code (the unknown,
>> haha), step
>> by step. For example, just call the functions, but don't take the
>> output, continue
>> to use the original loopback. The idea is to find which piece of your
>> code does
>> something bad, like "step on" other code or other memory data, mess up
>> the stack,
>> etc.
>>
>> -Jeff
> As I told in my last mail, there is some problem in my filter function.
> cause its running properly but the filtered output is not coming. I got
> the reason why. Well the last lines are:
> for(i=0; i > results[i] = flacoustic[i];
> Well flacoustic is the filtered output from filter function and results
> is the array which is written back on the output port of the device. Now
> the problem is flacoustic is float and result is Int16(typedefined as
> short).the filetered function is returning all values between 1 and -1
> and hence when they go into results (defined short), the value becomes
> 0, and hence no output. I hope you got my point.
Try like this:
results[i] = floor(32767.0*flacoustic[i]);
I don't know if you floor() function is available or not; if not find a
function that converts float to int. Also just this might work:
results[i] = (short int)(32767.0*flacoustic[i]);
but I'm not sure because 54xx floating-point library support in CCS may
not be that complete.
In any case, once you have values between -32768 and 32767 in results[],
then you can send those out to D/A converter; i.e. using
PEP5416_AIC23_write16() function.
-Jeff
> Now there were two choices either I convert all Int16 to float or float
> to
> Int16. if I convert float to Int16, I will get 0 in flacoustic itself
> (cause filtered value is between 1 and -1 and will become 0 if flacoustic
> is short). So the only option remains is converting Int16 to float.
> Now the problem is in the device inbuilt functions, when i read data, its
> read in Int16 format. the statement is decalred like following in the
> header file of teh device (pep5416_aic23.h):
> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle hCodec, Int16
> *val);
> and write is defined in following manner:
> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle hCodec, Int16
> val);
> So as you see the val is Int16 and now if I convert Int16 into float, I
> will have to convert it here too. But if I convert it to float, there is
> lot of noise and I am not getting proper output. i tried it without
> filter
> function, on my first code (simple audio in and same audio out). I am not
> getting proper output if I change this function; which I was getting when
> it was Int16. I hope I am able to explain everything clearly.
> Hence my problem remains. I am not able to think of a solution to this.
> If you have any idea kindly help me.
> Thanks
> Megha
>
> Jeff Brower wrote: Megha-
>
>> As I wrote in my last mail, its problem with InitBuffer function. Well
>> I debugged it further and there is no problem in that. The problem is
>> when data goes into the filter function "cfir()'. I just tried with a
>> loop inside the cfir. The loop did following:
>> rcv = xmt;
>> And the code is running (rest all is same).
>> So something is going wrong in the filter function.
>
> This could be different types of problems:
>
> 1) The cfir() code has some basic problem, for example goes beyond array
> boundary,
> bad pointer, etc.
>
> 2) The code is Ok, but filter coefficients are not good, so your output
> eventually
> becomes zero or saturated value, and you hear no sound.
>
>> I have to debug it further. Actually I am not getting how to debug
>> that. I am gonna follow your advice of adding parts one by one. But that
>> too is difficult to decide what to and what not to.
>
> One thing to try is let filter code run, but at very end of function (just
> before
> return) put:
>
> rcv = xmt;
>
> as you did above. Then if you can still hear the output, then probably
> filter code
> is Ok, but coefficients are a problem.
>
> -Jeff
>> Jeff Brower wrote: Megha-
>>
>> > I am working on a PEP5416 device and am using a TI C5416 simulator. I
>> am
>> > implementing an acoustic model which takes the sound input from the
>> > microphone, process it (filters) and provide the filtered output at
>> headphone.
>> > My code is working on the simulator, its not giving any errors and I
>> have
>> > debugged it step by step, its nowhere getting stuck. But when I try to
>> run
>> > the code on the device, its not running. I can hear no output, not a
>> simple
>> > buzz. I have ran a simple code on that device, in which I just take
>> the
>> > input and pass it onto the output. And its running.
>>
>> Since you can run simple loopback that's a good starting point for debug
>> -- we call
>> that "known good". From that point, try adding your code (the unknown,
>> haha), step
>> by step. For example, just call the functions, but don't take the
>> output, continue
>> to use the original loopback. The idea is to find which piece of your
>> code does
>> something bad, like "step on" other code or other memory data, mess up
>> the stack,
>> etc.
>>
>> -Jeff
Reply by ●May 4, 20062006-05-04
Megha-
> I thought of converting like that. I thought of multiplying my filtered
> output and giving that to result. But you see like this I will disturb
> the filtered value. It wont be same as it was. So thats a problem I
> think.
It's just scaling. As long as you don't feed results[] back into the
filter, then no problem. If results[] must be used as recursive input to
the filter, then keep 2 arrays:
results[i] = flacoustic[i];
dac_out[i] = (short int)(32767.0*flacoustic[i]);
where results[] is float, and dac_out[] is short int.
-Jeff
> Jeff Brower wrote: Megha-
>
>> As I told in my last mail, there is some problem in my filter function.
>> cause its running properly but the filtered output is not coming. I got
>> the reason why. Well the last lines are:
>> for(i=0; i
>> results[i] = flacoustic[i];
>> Well flacoustic is the filtered output from filter function and results
>> is the array which is written back on the output port of the device. Now
>> the problem is flacoustic is float and result is Int16(typedefined as
>> short).the filetered function is returning all values between 1 and -1
>> and hence when they go into results (defined short), the value becomes
>> 0, and hence no output. I hope you got my point.
>
> Try like this:
>
> results[i] = floor(32767.0*flacoustic[i]);
>
> I don't know if you floor() function is available or not; if not find a
> function that converts float to int. Also just this might work:
>
> results[i] = (short int)(32767.0*flacoustic[i]);
>
> but I'm not sure because 54xx floating-point library support in CCS may
> not be that complete.
>
> In any case, once you have values between -32768 and 32767 in results[],
> then you can send those out to D/A converter; i.e. using
> PEP5416_AIC23_write16() function.
>
> -Jeff
>> Now there were two choices either I convert all Int16 to float or float
>> to
>> Int16. if I convert float to Int16, I will get 0 in flacoustic itself
>> (cause filtered value is between 1 and -1 and will become 0 if
>> flacoustic
>> is short). So the only option remains is converting Int16 to float.
>> Now the problem is in the device inbuilt functions, when i read data,
>> its
>> read in Int16 format. the statement is decalred like following in the
>> header file of teh device (pep5416_aic23.h):
>> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle hCodec, Int16
>> *val);
>> and write is defined in following manner:
>> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle hCodec, Int16
>> val);
>> So as you see the val is Int16 and now if I convert Int16 into float, I
>> will have to convert it here too. But if I convert it to float, there is
>> lot of noise and I am not getting proper output. i tried it without
>> filter
>> function, on my first code (simple audio in and same audio out). I am
>> not
>> getting proper output if I change this function; which I was getting
>> when
>> it was Int16. I hope I am able to explain everything clearly.
>> Hence my problem remains. I am not able to think of a solution to this.
>> If you have any idea kindly help me.
>> Thanks
>> Megha
>>
>> Jeff Brower wrote: Megha-
>>
>>> As I wrote in my last mail, its problem with InitBuffer function. Well
>>> I debugged it further and there is no problem in that. The problem is
>>> when data goes into the filter function "cfir()'. I just tried with a
>>> loop inside the cfir. The loop did following:
>>> rcv = xmt;
>>> And the code is running (rest all is same).
>>> So something is going wrong in the filter function.
>>
>> This could be different types of problems:
>>
>> 1) The cfir() code has some basic problem, for example goes beyond array
>> boundary,
>> bad pointer, etc.
>>
>> 2) The code is Ok, but filter coefficients are not good, so your output
>> eventually
>> becomes zero or saturated value, and you hear no sound.
>>
>>> I have to debug it further. Actually I am not getting how to debug
>>> that. I am gonna follow your advice of adding parts one by one. But
>>> that
>>> too is difficult to decide what to and what not to.
>>
>> One thing to try is let filter code run, but at very end of function
>> (just
>> before
>> return) put:
>>
>> rcv = xmt;
>>
>> as you did above. Then if you can still hear the output, then probably
>> filter code
>> is Ok, but coefficients are a problem.
>>
>> -Jeff
>>> Jeff Brower wrote: Megha-
>>>
>>> > I am working on a PEP5416 device and am using a TI C5416 simulator. I
>>> am
>>> > implementing an acoustic model which takes the sound input from the
>>> > microphone, process it (filters) and provide the filtered output at
>>> headphone.
>>> > My code is working on the simulator, its not giving any errors and I
>>> have
>>> > debugged it step by step, its nowhere getting stuck. But when I try
>>> to
>>> run
>>> > the code on the device, its not running. I can hear no output, not a
>>> simple
>>> > buzz. I have ran a simple code on that device, in which I just take
>>> the
>>> > input and pass it onto the output. And its running.
>>>
>>> Since you can run simple loopback that's a good starting point for
>>> debug
>>> -- we call
>>> that "known good". From that point, try adding your code (the unknown,
>>> haha), step
>>> by step. For example, just call the functions, but don't take the
>>> output, continue
>>> to use the original loopback. The idea is to find which piece of your
>>> code does
>>> something bad, like "step on" other code or other memory data, mess up
>>> the stack,
>>> etc.
>>>
>>> -Jeff
> I thought of converting like that. I thought of multiplying my filtered
> output and giving that to result. But you see like this I will disturb
> the filtered value. It wont be same as it was. So thats a problem I
> think.
It's just scaling. As long as you don't feed results[] back into the
filter, then no problem. If results[] must be used as recursive input to
the filter, then keep 2 arrays:
results[i] = flacoustic[i];
dac_out[i] = (short int)(32767.0*flacoustic[i]);
where results[] is float, and dac_out[] is short int.
-Jeff
> Jeff Brower wrote: Megha-
>
>> As I told in my last mail, there is some problem in my filter function.
>> cause its running properly but the filtered output is not coming. I got
>> the reason why. Well the last lines are:
>> for(i=0; i
>> results[i] = flacoustic[i];
>> Well flacoustic is the filtered output from filter function and results
>> is the array which is written back on the output port of the device. Now
>> the problem is flacoustic is float and result is Int16(typedefined as
>> short).the filetered function is returning all values between 1 and -1
>> and hence when they go into results (defined short), the value becomes
>> 0, and hence no output. I hope you got my point.
>
> Try like this:
>
> results[i] = floor(32767.0*flacoustic[i]);
>
> I don't know if you floor() function is available or not; if not find a
> function that converts float to int. Also just this might work:
>
> results[i] = (short int)(32767.0*flacoustic[i]);
>
> but I'm not sure because 54xx floating-point library support in CCS may
> not be that complete.
>
> In any case, once you have values between -32768 and 32767 in results[],
> then you can send those out to D/A converter; i.e. using
> PEP5416_AIC23_write16() function.
>
> -Jeff
>> Now there were two choices either I convert all Int16 to float or float
>> to
>> Int16. if I convert float to Int16, I will get 0 in flacoustic itself
>> (cause filtered value is between 1 and -1 and will become 0 if
>> flacoustic
>> is short). So the only option remains is converting Int16 to float.
>> Now the problem is in the device inbuilt functions, when i read data,
>> its
>> read in Int16 format. the statement is decalred like following in the
>> header file of teh device (pep5416_aic23.h):
>> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle hCodec, Int16
>> *val);
>> and write is defined in following manner:
>> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle hCodec, Int16
>> val);
>> So as you see the val is Int16 and now if I convert Int16 into float, I
>> will have to convert it here too. But if I convert it to float, there is
>> lot of noise and I am not getting proper output. i tried it without
>> filter
>> function, on my first code (simple audio in and same audio out). I am
>> not
>> getting proper output if I change this function; which I was getting
>> when
>> it was Int16. I hope I am able to explain everything clearly.
>> Hence my problem remains. I am not able to think of a solution to this.
>> If you have any idea kindly help me.
>> Thanks
>> Megha
>>
>> Jeff Brower wrote: Megha-
>>
>>> As I wrote in my last mail, its problem with InitBuffer function. Well
>>> I debugged it further and there is no problem in that. The problem is
>>> when data goes into the filter function "cfir()'. I just tried with a
>>> loop inside the cfir. The loop did following:
>>> rcv = xmt;
>>> And the code is running (rest all is same).
>>> So something is going wrong in the filter function.
>>
>> This could be different types of problems:
>>
>> 1) The cfir() code has some basic problem, for example goes beyond array
>> boundary,
>> bad pointer, etc.
>>
>> 2) The code is Ok, but filter coefficients are not good, so your output
>> eventually
>> becomes zero or saturated value, and you hear no sound.
>>
>>> I have to debug it further. Actually I am not getting how to debug
>>> that. I am gonna follow your advice of adding parts one by one. But
>>> that
>>> too is difficult to decide what to and what not to.
>>
>> One thing to try is let filter code run, but at very end of function
>> (just
>> before
>> return) put:
>>
>> rcv = xmt;
>>
>> as you did above. Then if you can still hear the output, then probably
>> filter code
>> is Ok, but coefficients are a problem.
>>
>> -Jeff
>>> Jeff Brower wrote: Megha-
>>>
>>> > I am working on a PEP5416 device and am using a TI C5416 simulator. I
>>> am
>>> > implementing an acoustic model which takes the sound input from the
>>> > microphone, process it (filters) and provide the filtered output at
>>> headphone.
>>> > My code is working on the simulator, its not giving any errors and I
>>> have
>>> > debugged it step by step, its nowhere getting stuck. But when I try
>>> to
>>> run
>>> > the code on the device, its not running. I can hear no output, not a
>>> simple
>>> > buzz. I have ran a simple code on that device, in which I just take
>>> the
>>> > input and pass it onto the output. And its running.
>>>
>>> Since you can run simple loopback that's a good starting point for
>>> debug
>>> -- we call
>>> that "known good". From that point, try adding your code (the unknown,
>>> haha), step
>>> by step. For example, just call the functions, but don't take the
>>> output, continue
>>> to use the original loopback. The idea is to find which piece of your
>>> code does
>>> something bad, like "step on" other code or other memory data, mess up
>>> the stack,
>>> etc.
>>>
>>> -Jeff
Reply by ●May 4, 20062006-05-04
Dear Jeff
I thought of converting like that. I thought of multiplying my filtered output and giving that to result. But you see like this I will disturb the filtered value. It wont be same as it was. So thats a problem I think.
Thanks
Megha
Jeff Brower wrote: Megha-
> As I told in my last mail, there is some problem in my filter function.
> cause its running properly but the filtered output is not coming. I got
> the reason why. Well the last lines are:
> for(i=0; i
> results[i] = flacoustic[i];
> Well flacoustic is the filtered output from filter function and results
> is the array which is written back on the output port of the device. Now
> the problem is flacoustic is float and result is Int16(typedefined as
> short).the filetered function is returning all values between 1 and -1
> and hence when they go into results (defined short), the value becomes
> 0, and hence no output. I hope you got my point.
Try like this:
results[i] = floor(32767.0*flacoustic[i]);
I don't know if you floor() function is available or not; if not find a
function that converts float to int. Also just this might work:
results[i] = (short int)(32767.0*flacoustic[i]);
but I'm not sure because 54xx floating-point library support in CCS may
not be that complete.
In any case, once you have values between -32768 and 32767 in results[],
then you can send those out to D/A converter; i.e. using
PEP5416_AIC23_write16() function.
-Jeff
> Now there were two choices either I convert all Int16 to float or float
> to
> Int16. if I convert float to Int16, I will get 0 in flacoustic itself
> (cause filtered value is between 1 and -1 and will become 0 if flacoustic
> is short). So the only option remains is converting Int16 to float.
> Now the problem is in the device inbuilt functions, when i read data, its
> read in Int16 format. the statement is decalred like following in the
> header file of teh device (pep5416_aic23.h):
> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle hCodec, Int16
> *val);
> and write is defined in following manner:
> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle hCodec, Int16
> val);
> So as you see the val is Int16 and now if I convert Int16 into float, I
> will have to convert it here too. But if I convert it to float, there is
> lot of noise and I am not getting proper output. i tried it without
> filter
> function, on my first code (simple audio in and same audio out). I am not
> getting proper output if I change this function; which I was getting when
> it was Int16. I hope I am able to explain everything clearly.
> Hence my problem remains. I am not able to think of a solution to this.
> If you have any idea kindly help me.
> Thanks
> Megha
>
> Jeff Brower wrote: Megha-
>
>> As I wrote in my last mail, its problem with InitBuffer function. Well
>> I debugged it further and there is no problem in that. The problem is
>> when data goes into the filter function "cfir()'. I just tried with a
>> loop inside the cfir. The loop did following:
>> rcv = xmt;
>> And the code is running (rest all is same).
>> So something is going wrong in the filter function.
>
> This could be different types of problems:
>
> 1) The cfir() code has some basic problem, for example goes beyond array
> boundary,
> bad pointer, etc.
>
> 2) The code is Ok, but filter coefficients are not good, so your output
> eventually
> becomes zero or saturated value, and you hear no sound.
>
>> I have to debug it further. Actually I am not getting how to debug
>> that. I am gonna follow your advice of adding parts one by one. But that
>> too is difficult to decide what to and what not to.
>
> One thing to try is let filter code run, but at very end of function (just
> before
> return) put:
>
> rcv = xmt;
>
> as you did above. Then if you can still hear the output, then probably
> filter code
> is Ok, but coefficients are a problem.
>
> -Jeff
>> Jeff Brower wrote: Megha-
>>
>> > I am working on a PEP5416 device and am using a TI C5416 simulator. I
>> am
>> > implementing an acoustic model which takes the sound input from the
>> > microphone, process it (filters) and provide the filtered output at
>> headphone.
>> > My code is working on the simulator, its not giving any errors and I
>> have
>> > debugged it step by step, its nowhere getting stuck. But when I try to
>> run
>> > the code on the device, its not running. I can hear no output, not a
>> simple
>> > buzz. I have ran a simple code on that device, in which I just take
>> the
>> > input and pass it onto the output. And its running.
>>
>> Since you can run simple loopback that's a good starting point for debug
>> -- we call
>> that "known good". From that point, try adding your code (the unknown,
>> haha), step
>> by step. For example, just call the functions, but don't take the
>> output, continue
>> to use the original loopback. The idea is to find which piece of your
>> code does
>> something bad, like "step on" other code or other memory data, mess up
>> the stack,
>> etc.
>>
>> -Jeff
---------------------------------
Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2/min with Yahoo! Messenger with Voice.
I thought of converting like that. I thought of multiplying my filtered output and giving that to result. But you see like this I will disturb the filtered value. It wont be same as it was. So thats a problem I think.
Thanks
Megha
Jeff Brower wrote: Megha-
> As I told in my last mail, there is some problem in my filter function.
> cause its running properly but the filtered output is not coming. I got
> the reason why. Well the last lines are:
> for(i=0; i
> results[i] = flacoustic[i];
> Well flacoustic is the filtered output from filter function and results
> is the array which is written back on the output port of the device. Now
> the problem is flacoustic is float and result is Int16(typedefined as
> short).the filetered function is returning all values between 1 and -1
> and hence when they go into results (defined short), the value becomes
> 0, and hence no output. I hope you got my point.
Try like this:
results[i] = floor(32767.0*flacoustic[i]);
I don't know if you floor() function is available or not; if not find a
function that converts float to int. Also just this might work:
results[i] = (short int)(32767.0*flacoustic[i]);
but I'm not sure because 54xx floating-point library support in CCS may
not be that complete.
In any case, once you have values between -32768 and 32767 in results[],
then you can send those out to D/A converter; i.e. using
PEP5416_AIC23_write16() function.
-Jeff
> Now there were two choices either I convert all Int16 to float or float
> to
> Int16. if I convert float to Int16, I will get 0 in flacoustic itself
> (cause filtered value is between 1 and -1 and will become 0 if flacoustic
> is short). So the only option remains is converting Int16 to float.
> Now the problem is in the device inbuilt functions, when i read data, its
> read in Int16 format. the statement is decalred like following in the
> header file of teh device (pep5416_aic23.h):
> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle hCodec, Int16
> *val);
> and write is defined in following manner:
> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle hCodec, Int16
> val);
> So as you see the val is Int16 and now if I convert Int16 into float, I
> will have to convert it here too. But if I convert it to float, there is
> lot of noise and I am not getting proper output. i tried it without
> filter
> function, on my first code (simple audio in and same audio out). I am not
> getting proper output if I change this function; which I was getting when
> it was Int16. I hope I am able to explain everything clearly.
> Hence my problem remains. I am not able to think of a solution to this.
> If you have any idea kindly help me.
> Thanks
> Megha
>
> Jeff Brower wrote: Megha-
>
>> As I wrote in my last mail, its problem with InitBuffer function. Well
>> I debugged it further and there is no problem in that. The problem is
>> when data goes into the filter function "cfir()'. I just tried with a
>> loop inside the cfir. The loop did following:
>> rcv = xmt;
>> And the code is running (rest all is same).
>> So something is going wrong in the filter function.
>
> This could be different types of problems:
>
> 1) The cfir() code has some basic problem, for example goes beyond array
> boundary,
> bad pointer, etc.
>
> 2) The code is Ok, but filter coefficients are not good, so your output
> eventually
> becomes zero or saturated value, and you hear no sound.
>
>> I have to debug it further. Actually I am not getting how to debug
>> that. I am gonna follow your advice of adding parts one by one. But that
>> too is difficult to decide what to and what not to.
>
> One thing to try is let filter code run, but at very end of function (just
> before
> return) put:
>
> rcv = xmt;
>
> as you did above. Then if you can still hear the output, then probably
> filter code
> is Ok, but coefficients are a problem.
>
> -Jeff
>> Jeff Brower wrote: Megha-
>>
>> > I am working on a PEP5416 device and am using a TI C5416 simulator. I
>> am
>> > implementing an acoustic model which takes the sound input from the
>> > microphone, process it (filters) and provide the filtered output at
>> headphone.
>> > My code is working on the simulator, its not giving any errors and I
>> have
>> > debugged it step by step, its nowhere getting stuck. But when I try to
>> run
>> > the code on the device, its not running. I can hear no output, not a
>> simple
>> > buzz. I have ran a simple code on that device, in which I just take
>> the
>> > input and pass it onto the output. And its running.
>>
>> Since you can run simple loopback that's a good starting point for debug
>> -- we call
>> that "known good". From that point, try adding your code (the unknown,
>> haha), step
>> by step. For example, just call the functions, but don't take the
>> output, continue
>> to use the original loopback. The idea is to find which piece of your
>> code does
>> something bad, like "step on" other code or other memory data, mess up
>> the stack,
>> etc.
>>
>> -Jeff
---------------------------------
Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2/min with Yahoo! Messenger with Voice.
Reply by ●May 5, 20062006-05-05
Megha-
> I am not using that in recurrsion and hence I took your advice. Actually
> there is one more function in DSP called fltoq(). it converts float to
> Q15 (short). i read about it and it does nothing but multiplication by
> 32768 :)
> Well actually I dont know how this scaling is affecting my output. Right
> now I am not getting the whole output. Actually as I am using a single
> buffer, my data is getting lost when the previous data is getting
> processed and hence I am just getting beeps right now instead of
> continous data. I think I will have to use two buffers now, ex ping pong
> buffering. But I think I will have to use it with DMA and McBSP. Do you
> have any suggestions on that?
Ping pong (dual) buffers are needed for real-time, continuous output: in
your case, one buffer is going out to DAC while other buffer is being
filled by your filter output + fltoq().
My suggestion is to get that working first, then worry about DMA. Your
sampling rates are not high enough to cause DMA to be required for real
time operation, so save the DMA for last step.
-Jeff
> Jeff Brower wrote: Megha-
>
>> I thought of converting like that. I thought of multiplying my filtered
output and giving that to result. But you see like this I will disturb
the filtered value. It wont be same as it was. So thats a problem I
think.
>
> It's just scaling. As long as you don't feed results[] back into the
filter, then no problem. If results[] must be used as recursive input
to the filter, then keep 2 arrays:
>
> results[i] = flacoustic[i];
> dac_out[i] = (short int)(32767.0*flacoustic[i]);
>
> where results[] is float, and dac_out[] is short int.
>
> -Jeff
>
>> Jeff Brower wrote: Megha-
>>
>>> As I told in my last mail, there is some problem in my filter
function. cause its running properly but the filtered output is not
coming. I got the reason why. Well the last lines are:
>>> for(i=0; i
>>> results[i] = flacoustic[i];
>>> Well flacoustic is the filtered output from filter function and
results is the array which is written back on the output port of the
device. Now
>>> the problem is flacoustic is float and result is Int16(typedefined as
short).the filetered function is returning all values between 1 and -1
and hence when they go into results (defined short), the value becomes
0, and hence no output. I hope you got my point.
>>
>> Try like this:
>>
>> results[i] = floor(32767.0*flacoustic[i]);
>>
>> I don't know if you floor() function is available or not; if not find a
function that converts float to int. Also just this might work:
>>
>> results[i] = (short int)(32767.0*flacoustic[i]);
>>
>> but I'm not sure because 54xx floating-point library support in CCS may
not be that complete.
>>
>> In any case, once you have values between -32768 and 32767 in
results[], then you can send those out to D/A converter; i.e. using
>> PEP5416_AIC23_write16() function.
>>
>> -Jeff
>>> Now there were two choices either I convert all Int16 to float or
float to
>>> Int16. if I convert float to Int16, I will get 0 in flacoustic itself
(cause filtered value is between 1 and -1 and will become 0 if
flacoustic
>>> is short). So the only option remains is converting Int16 to float.
Now the problem is in the device inbuilt functions, when i read data,
its
>>> read in Int16 format. the statement is decalred like following in the
header file of teh device (pep5416_aic23.h):
>>> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle hCodec, Int16
*val);
>>> and write is defined in following manner:
>>> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle hCodec, Int16
val);
>>> So as you see the val is Int16 and now if I convert Int16 into float,
I will have to convert it here too. But if I convert it to float,
there is
>>> lot of noise and I am not getting proper output. i tried it without
filter
>>> function, on my first code (simple audio in and same audio out). I am not
>>> getting proper output if I change this function; which I was getting when
>>> it was Int16. I hope I am able to explain everything clearly.
>>> Hence my problem remains. I am not able to think of a solution to
this. If you have any idea kindly help me.
>>> Thanks
>>> Megha
>>>
>>> Jeff Brower wrote: Megha-
>>>
>>>> As I wrote in my last mail, its problem with InitBuffer function.
>>>> Well
>>>> I debugged it further and there is no problem in that. The problem is
when data goes into the filter function "cfir()'. I just tried with a
loop inside the cfir. The loop did following:
>>>> rcv = xmt;
>>>> And the code is running (rest all is same).
>>>> So something is going wrong in the filter function.
>>>
>>> This could be different types of problems:
>>>
>>> 1) The cfir() code has some basic problem, for example goes beyond array
>>> boundary,
>>> bad pointer, etc.
>>>
>>> 2) The code is Ok, but filter coefficients are not good, so your
output eventually
>>> becomes zero or saturated value, and you hear no sound.
>>>
>>>> I have to debug it further. Actually I am not getting how to debug
>>>> that. I am gonna follow your advice of adding parts one by one. But that
>>>> too is difficult to decide what to and what not to.
>>>
>>> One thing to try is let filter code run, but at very end of function
(just
>>> before
>>> return) put:
>>>
>>> rcv = xmt;
>>>
>>> as you did above. Then if you can still hear the output, then
probably filter code
>>> is Ok, but coefficients are a problem.
>>>
>>> -Jeff
>>>
>>>
>>>> Jeff Brower wrote: Megha-
>>>>
>>>> > I am working on a PEP5416 device and am using a TI C5416 simulator.
>>>> I
>>>> am
>>>> > implementing an acoustic model which takes the sound input from the
microphone, process it (filters) and provide the filtered output at
>>>> headphone.
>>>> > My code is working on the simulator, its not giving any errors and I
>>>> have
>>>> > debugged it step by step, its nowhere getting stuck. But when I try
>>>> to
>>>> run
>>>> > the code on the device, its not running. I can hear no output, not a
>>>> simple
>>>> > buzz. I have ran a simple code on that device, in which I just take
>>>> the
>>>> > input and pass it onto the output. And its running.
>>>>
>>>> Since you can run simple loopback that's a good starting point for debug
>>>> -- we call
>>>> that "known good". From that point, try adding your code (the unknown,
>>>> haha), step
>>>> by step. For example, just call the functions, but don't take the
output, continue
>>>> to use the original loopback. The idea is to find which piece of
your code does
>>>> something bad, like "step on" other code or other memory data, mess
up the stack,
>>>> etc.
>>>>
>>>> -Jeff
> I am not using that in recurrsion and hence I took your advice. Actually
> there is one more function in DSP called fltoq(). it converts float to
> Q15 (short). i read about it and it does nothing but multiplication by
> 32768 :)
> Well actually I dont know how this scaling is affecting my output. Right
> now I am not getting the whole output. Actually as I am using a single
> buffer, my data is getting lost when the previous data is getting
> processed and hence I am just getting beeps right now instead of
> continous data. I think I will have to use two buffers now, ex ping pong
> buffering. But I think I will have to use it with DMA and McBSP. Do you
> have any suggestions on that?
Ping pong (dual) buffers are needed for real-time, continuous output: in
your case, one buffer is going out to DAC while other buffer is being
filled by your filter output + fltoq().
My suggestion is to get that working first, then worry about DMA. Your
sampling rates are not high enough to cause DMA to be required for real
time operation, so save the DMA for last step.
-Jeff
> Jeff Brower wrote: Megha-
>
>> I thought of converting like that. I thought of multiplying my filtered
output and giving that to result. But you see like this I will disturb
the filtered value. It wont be same as it was. So thats a problem I
think.
>
> It's just scaling. As long as you don't feed results[] back into the
filter, then no problem. If results[] must be used as recursive input
to the filter, then keep 2 arrays:
>
> results[i] = flacoustic[i];
> dac_out[i] = (short int)(32767.0*flacoustic[i]);
>
> where results[] is float, and dac_out[] is short int.
>
> -Jeff
>
>> Jeff Brower wrote: Megha-
>>
>>> As I told in my last mail, there is some problem in my filter
function. cause its running properly but the filtered output is not
coming. I got the reason why. Well the last lines are:
>>> for(i=0; i
>>> results[i] = flacoustic[i];
>>> Well flacoustic is the filtered output from filter function and
results is the array which is written back on the output port of the
device. Now
>>> the problem is flacoustic is float and result is Int16(typedefined as
short).the filetered function is returning all values between 1 and -1
and hence when they go into results (defined short), the value becomes
0, and hence no output. I hope you got my point.
>>
>> Try like this:
>>
>> results[i] = floor(32767.0*flacoustic[i]);
>>
>> I don't know if you floor() function is available or not; if not find a
function that converts float to int. Also just this might work:
>>
>> results[i] = (short int)(32767.0*flacoustic[i]);
>>
>> but I'm not sure because 54xx floating-point library support in CCS may
not be that complete.
>>
>> In any case, once you have values between -32768 and 32767 in
results[], then you can send those out to D/A converter; i.e. using
>> PEP5416_AIC23_write16() function.
>>
>> -Jeff
>>> Now there were two choices either I convert all Int16 to float or
float to
>>> Int16. if I convert float to Int16, I will get 0 in flacoustic itself
(cause filtered value is between 1 and -1 and will become 0 if
flacoustic
>>> is short). So the only option remains is converting Int16 to float.
Now the problem is in the device inbuilt functions, when i read data,
its
>>> read in Int16 format. the statement is decalred like following in the
header file of teh device (pep5416_aic23.h):
>>> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle hCodec, Int16
*val);
>>> and write is defined in following manner:
>>> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle hCodec, Int16
val);
>>> So as you see the val is Int16 and now if I convert Int16 into float,
I will have to convert it here too. But if I convert it to float,
there is
>>> lot of noise and I am not getting proper output. i tried it without
filter
>>> function, on my first code (simple audio in and same audio out). I am not
>>> getting proper output if I change this function; which I was getting when
>>> it was Int16. I hope I am able to explain everything clearly.
>>> Hence my problem remains. I am not able to think of a solution to
this. If you have any idea kindly help me.
>>> Thanks
>>> Megha
>>>
>>> Jeff Brower wrote: Megha-
>>>
>>>> As I wrote in my last mail, its problem with InitBuffer function.
>>>> Well
>>>> I debugged it further and there is no problem in that. The problem is
when data goes into the filter function "cfir()'. I just tried with a
loop inside the cfir. The loop did following:
>>>> rcv = xmt;
>>>> And the code is running (rest all is same).
>>>> So something is going wrong in the filter function.
>>>
>>> This could be different types of problems:
>>>
>>> 1) The cfir() code has some basic problem, for example goes beyond array
>>> boundary,
>>> bad pointer, etc.
>>>
>>> 2) The code is Ok, but filter coefficients are not good, so your
output eventually
>>> becomes zero or saturated value, and you hear no sound.
>>>
>>>> I have to debug it further. Actually I am not getting how to debug
>>>> that. I am gonna follow your advice of adding parts one by one. But that
>>>> too is difficult to decide what to and what not to.
>>>
>>> One thing to try is let filter code run, but at very end of function
(just
>>> before
>>> return) put:
>>>
>>> rcv = xmt;
>>>
>>> as you did above. Then if you can still hear the output, then
probably filter code
>>> is Ok, but coefficients are a problem.
>>>
>>> -Jeff
>>>
>>>
>>>> Jeff Brower wrote: Megha-
>>>>
>>>> > I am working on a PEP5416 device and am using a TI C5416 simulator.
>>>> I
>>>> am
>>>> > implementing an acoustic model which takes the sound input from the
microphone, process it (filters) and provide the filtered output at
>>>> headphone.
>>>> > My code is working on the simulator, its not giving any errors and I
>>>> have
>>>> > debugged it step by step, its nowhere getting stuck. But when I try
>>>> to
>>>> run
>>>> > the code on the device, its not running. I can hear no output, not a
>>>> simple
>>>> > buzz. I have ran a simple code on that device, in which I just take
>>>> the
>>>> > input and pass it onto the output. And its running.
>>>>
>>>> Since you can run simple loopback that's a good starting point for debug
>>>> -- we call
>>>> that "known good". From that point, try adding your code (the unknown,
>>>> haha), step
>>>> by step. For example, just call the functions, but don't take the
output, continue
>>>> to use the original loopback. The idea is to find which piece of
your code does
>>>> something bad, like "step on" other code or other memory data, mess
up the stack,
>>>> etc.
>>>>
>>>> -Jeff
