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

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

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 <j...@signalogic.com> 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

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 <j...@signalogic.com> 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

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 <j...@signalogic.com> 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

   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.

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<blksize; 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 <j...@signalogic.com> 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

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 <j...@signalogic.com> 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

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 <j...@signalogic.com> 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.

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 <j...@signalogic.com> 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

Megha-

> There is one more thing. I ran the following program:
> i=1;
>  while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>                cfir(bufferrcv, bufferxmt, BUFFSIZE);
>
> and in cfir():
>
>  FilterBufferBySamplesIIR(data, blksize);
>
>  //  for (i = 0; i < blksize; i++)
>  i=1;
>   results[i] = data[i];
> if I remove filterbufferbysamples I get proper output for single samples
> (i=1), but if i add filterbufferbysamples I am not getting output but
> just noise.

This is because you are waiting too long to output to the codec.  Try it
this way:

  /* wait for input sample to be ready */
  while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));

  /* output last filtered sample */
  PEP5416_AIC23_write16(hCodec, @out_sample);

  /* filter one sample */
  cfir(bufferrcv[i], @out_sample, 1);

  i++;

  /* end of loop; repeat and wait for next sample */

The idea is that when the codec is ready, you need to do both input and
output without waiting.  Otherwise the codec will output some junk.

If you can get this to work, then you can try buffering samples, instead
of single sample processing.  One step at a time.

-Jeff
> My data is not changing in filterbufferbysamples. Its the same. I
> am just using it once inside that function that to get its value. i am
> not changing its value. Can you think of any reson why thats happening.
> kindly reply.
> thanking you
> megha
>
> Jeff Brower <j...@signalogic.com> wrote: Megha-
>
>> Yeah thats what I was asking about. Currently I am using just a single
>> buffer in my program which is making my data lost. Hence I need to use
>> dual buffers.
>> Now what I had in mind:
>> to use dual buffer I will have to use McBSP and DMA. I am not sure how
>> to
>> use dual buffer without those and I dont want to use DMA right now.
>> Can you help me in how to use them. Or can you give some links, where
>> their description can be found.
>
> If your loop is processing each sample, which would explain why you get
> some noise on the output if you wait too long to supply the output value
> (i.e. result from the filter), then for now you can just use a single
> sample delay, then worry about ping-pong buffer later.
>
> For example, if your processing loop is based either on a sample interrupt
> or polling (waiting) for each sample, then you can do something like this:
>
>   cur_sample = fltoq(flacoustic[i]);
>   PEP5416_AIC23_write16(hCodec, last_sample);
>   last_sample = cur_sample;
>
> Note this causes a 1-sample delay in the output.
>
> Only when your filter and other processing gets to be enough it cannot be
> accomplished in one sample period do you need to worry about using
> ping-pong buffers.  What is your sampling rate?
>
> -Jeff
>> Jeff Brower  wrote: 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

Megha-

> You suggested:
>   /* wait for input sample to be ready */
>   while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>
>   /* output last filtered sample */
>   PEP5416_AIC23_write16(hCodec, @out_sample);
>
>   /* filter one sample */
>   cfir(bufferrcv[i], @out_sample, 1);
>
>   i++;
>
> The above case is not real time. In the above case when the processor is
> processing write() and after that cfir(), nothing is getting read into
> bufferecv[] and hence that amount of data is lost.

It is real-time, but you don't understand signal processing well enough to
realize it.   The above code waits for the codec sample period, does input
and output, then has 22.6 usec of time to filter one sample before the
next sample period.  For sure your IIR filter can process one sample in
22.6 usec -- if not, then you will not be in real-time and no amount of
DMA or any other technique is going to fix that.  Do you understand the
significance of 22.6 usec?  If you cannot answer that, I cannot help you
any longer.

> What I want is real time and thats why I was thinking of PIP, HST, McBSP,
> DMA...

DSP students have to learn to crawl before they can walk.  Your current
level of DSP coding experience does not allow you to try advanced
techniques.  If you can get single-sample processing working, then you can
advance one step at a time:  enable McBSP interrupts (i.e. don't poll for
sample period), then add buffering instead of single-sample, etc.

-Jeff

> I tried one of the sample examples by TI for PIP (copy.pjt copies
> data from i/p to o/p). But thats not working on my device. I am not
> getting the reason. I have just added the device initialization part to
> that code. I am attaching that code, if possible have a look at that.
> What I think is if I can read data from PIP (continous real time). I can
> read it in form of 3/4 frames. Then I can pass 1 frame at a time to the
> filter process and then that frame to o/p. Then again I will take 2 frame
> and so on. this way I wont loose data. I will have to use interrupts.
> Thats what in my mind.
> Kindly provide your suggestion.
> Thanks
> Megha
>
> Jeff Brower <j...@signalogic.com> wrote: Megha-
>
>> There is one more thing. I ran the following program:
>> i=1;
>>  while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>>                cfir(bufferrcv, bufferxmt, BUFFSIZE);
>>
>> and in cfir():
>>
>>  FilterBufferBySamplesIIR(data, blksize);
>>
>>  //  for (i = 0; i < blksize; i++)
>>  i=1;
>>   results[i] = data[i];
>> if I remove filterbufferbysamples I get proper output for single samples
>> (i=1), but if i add filterbufferbysamples I am not getting output but
>> just noise.
>
> This is because you are waiting too long to output to the codec.  Try it
> this way:
>
>   /* wait for input sample to be ready */
>   while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>
>   /* output last filtered sample */
>   PEP5416_AIC23_write16(hCodec, @out_sample);
>
>   /* filter one sample */
>   cfir(bufferrcv[i], @out_sample, 1);
>
>   i++;
>
>   /* end of loop; repeat and wait for next sample */
>
> The idea is that when the codec is ready, you need to do both input and
> output without waiting.  Otherwise the codec will output some junk.
>
> If you can get this to work, then you can try buffering samples, instead
> of single sample processing.  One step at a time.
>
> -Jeff
>> My data is not changing in filterbufferbysamples. Its the same. I
>> am just using it once inside that function that to get its value. i am
>> not changing its value. Can you think of any reson why thats happening.
>> kindly reply.
>> thanking you
>> megha
>>
>> Jeff Brower  wrote: Megha-
>>
>>> Yeah thats what I was asking about. Currently I am using just a single
>>> buffer in my program which is making my data lost. Hence I need to use
>>> dual buffers.
>>> Now what I had in mind:
>>> to use dual buffer I will have to use McBSP and DMA. I am not sure how
>>> to
>>> use dual buffer without those and I dont want to use DMA right now.
>>> Can you help me in how to use them. Or can you give some links, where
>>> their description can be found.
>>
>> If your loop is processing each sample, which would explain why you get
>> some noise on the output if you wait too long to supply the output value
>> (i.e. result from the filter), then for now you can just use a single
>> sample delay, then worry about ping-pong buffer later.
>>
>> For example, if your processing loop is based either on a sample
>> interrupt
>> or polling (waiting) for each sample, then you can do something like
>> this:
>>
>>   cur_sample = fltoq(flacoustic[i]);
>>   PEP5416_AIC23_write16(hCodec, last_sample);
>>   last_sample = cur_sample;
>>
>> Note this causes a 1-sample delay in the output.
>>
>> Only when your filter and other processing gets to be enough it cannot
>> be
>> accomplished in one sample period do you need to worry about using
>> ping-pong buffers.  What is your sampling rate?
>>
>> -Jeff
>>> Jeff Brower  wrote: 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

Dear Jeff
There is one more thing. I ran the following program:
i=1;
 while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
               cfir(bufferrcv, bufferxmt, BUFFSIZE);

and in cfir():
   
 FilterBufferBySamplesIIR(data, blksize);
   
 //  for (i = 0; i < blksize; i++)
 i=1;
  results[i] = data[i];
if I remove filterbufferbysamples I get proper output for single samples (i=1), but if i add
filterbufferbysamples I am not getting output but just noise. My data is not changing in
filterbufferbysamples. Its the same. I am just using it once inside that function that to get
its value. i am not changing its value. Can you think of any reson why thats happening.
kindly reply.
thanking you
megha

Jeff Brower <j...@signalogic.com> wrote: Megha-

> Yeah thats what I was asking about. Currently I am using just a single
> buffer in my program which is making my data lost. Hence I need to use
> dual buffers.
> Now what I had in mind:
> to use dual buffer I will have to use McBSP and DMA. I am not sure how to
> use dual buffer without those and I dont want to use DMA right now.
> Can you help me in how to use them. Or can you give some links, where
> their description can be found.

If your loop is processing each sample, which would explain why you get
some noise on the output if you wait too long to supply the output value
(i.e. result from the filter), then for now you can just use a single
sample delay, then worry about ping-pong buffer later.

For example, if your processing loop is based either on a sample interrupt
or polling (waiting) for each sample, then you can do something like this:

  cur_sample = fltoq(flacoustic[i]);
  PEP5416_AIC23_write16(hCodec, last_sample);
  last_sample = cur_sample;

Note this causes a 1-sample delay in the output.

Only when your filter and other processing gets to be enough it cannot be
accomplished in one sample period do you need to worry about using
ping-pong buffers.  What is your sampling rate?

-Jeff
> Jeff Brower  wrote: 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

Dear Jeff
my problem is I am not taking continous input and give continous output. What I am doing is:
PEPread() and PEPwrite()
These two function write data from the codec into a buffer and write from buffer to codec. Its
not taking continous input. For continous input I have to use PIP or DA or something like that.
I am not getting how to use that to avoid delay or data loss. Do you know any example I can
refer to in 5416 for continous input data. Kinldy suggest.
Secondly I wrote in my prev mail:
I ran the following program:
i=1;
 while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
               cfir(bufferrcv, bufferxmt, BUFFSIZE);

and in cfir():
   
 FilterBufferBySamplesIIR(data, blksize);
   
 //  for (i = 0; i < blksize; i++)
 i=1;
  results[i] =  data[i];
if I remove filterbufferbysamples I get proper output for single samples (i=1), but if i add
filterbufferbysamples I am not getting output but just noise. My data is not changing in
filterbufferbysamples. Its the same. I am just using it once inside that function that to get
its value. i am not changing its value. Can you think of any reson why thats happening.
kindly reply.
thanking you
megha

Jeff Brower <j...@signalogic.com> wrote: Megha-

> Yeah thats what I was asking about. Currently I am using just a single
> buffer in my program which is making my data lost. Hence I need to use
> dual buffers.
> Now what I had in mind:
> to use dual buffer I will have to use McBSP and DMA. I am not sure how to
> use dual buffer without those and I dont want to use DMA right now.
> Can you help me in how to use them. Or can you give some links, where
> their description can be found.

If your loop is processing each sample, which would explain why you get
some noise on the output if you wait too long to supply the output value
(i.e. result from the filter), then for now you can just use a single
sample delay, then worry about ping-pong buffer later.

For example, if your processing loop is based either on a sample interrupt
or polling (waiting) for each sample, then you can do something like this:

  cur_sample = fltoq(flacoustic[i]);
  PEP5416_AIC23_write16(hCodec, last_sample);
  last_sample = cur_sample;

Note this causes a 1-sample delay in the output.

Only when your filter and other processing gets to be enough it cannot be
accomplished in one sample period do you need to worry about using
ping-pong buffers.  What is your sampling rate?

-Jeff
> Jeff Brower  wrote: 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

 Dear Jeff
What I understand is you got 22.6usec from the audio sampling rate of 44.1KHz. Well but I think
I dont understand the theory behind codec waiting for next 22.6usec to take another data. See I
understand it takes input data and writes at output but I dont understand why wont it loose
data when its waiting for those 22.6usec. As the data is continous and i wont be reading
anything in that 22.6usec interval, wont that data get lost? Kindly clear this confusion of
mine. 
As per as single sample processing is concerned, its not working. As I wrote in previous mail,
I did try your suggestion, but I am still getting noise. there is contious output but output is
noise. I did the following:
In main:
while(1)
    {
    i=0;
       // for (i = 0; i < 2048; i++)
        {
            while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
    
            while (!PEP5416_AIC23_write16(hCodec, bufferxmt));
                cfir(bufferrcv, &bufferxmt, 1);
        }
//        counter++;
    }
and in cfir()
{
    Preemphasis(data,blksize);

    if(doagcdrc)
    {
        //Now call the front end functions that are desired
        AGCDRC(data,blksize);
    }

    FilterBufferBySamplesIIR(data, blksize);
   
   //for (i = 0; i < blksize; i++)
  //i=0;
   *results = data[0];
      // *results = 32768*flacoustic[0];      
}
In above case I am just trying to copy paste again ( *results = data[0]). The change is I am
running the FilterBufferBySamplesIIR(). If I remove FilterBufferBySamplesIIR() and try the
above copy paste thing, it works. But with that filter function inside, I am not getting the
proper output. The filter function is not changing the data anywhere. I dont get why this thing
is happening. I even checked the values in watch window and it is fine, but still its not fine
at headphone. Sampling rate is 44KHz for filters and device is runnning at 48MHz (96/2, divide
by 2 mode).  Kindly tell me the reason behind this.
Kindly reply.
Thanking You
Megha Daga
Jeff Brower <j...@signalogic.com> wrote: Megha-

> You suggested:
>   /*  wait for input sample to be ready */
>   while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>
>   /* output last filtered sample */
>   PEP5416_AIC23_write16(hCodec, @out_sample);
>
>   /* filter one sample */
>   cfir(bufferrcv[i], @out_sample, 1);
>
>   i++;
>
> The above case is not real time. In the above case when the processor is
> processing write() and after that cfir(), nothing is getting read into
> bufferecv[] and hence that amount of data is lost.

It is real-time, but you don't understand signal processing well enough to
realize it.   The above code waits for the codec sample period, does input
and output, then has 22.6 usec of time to filter one sample before the
next sample period.  For sure your IIR filter can process one sample in
22.6 usec -- if not, then you will not be in real-time and no amount of
DMA or any other technique is going to fix that.   Do you understand the
significance of 22.6 usec?  If you cannot answer that, I cannot help you
any longer.

> What I want is real time and thats why I was thinking of PIP, HST, McBSP,
> DMA...

DSP students have to learn to crawl before they can walk.  Your current
level of DSP coding experience does not allow you to try advanced
techniques.  If you can get single-sample processing working, then you can
advance one step at a time:  enable McBSP interrupts (i.e. don't poll for
sample period), then add buffering instead of single-sample, etc.

-Jeff

> I tried one of the sample examples by TI for PIP (copy.pjt copies
> data from i/p to o/p). But thats not working on my device. I am not
> getting the reason. I have just added the device initialization part to
> that code. I am attaching that code, if possible have a look at that.
> What I think is if I can read data from PIP (continous real time). I  can
> read it in form of 3/4 frames. Then I can pass 1 frame at a time to the
> filter process and then that frame to o/p. Then again I will take 2 frame
> and so on. this way I wont loose data. I will have to use interrupts.
> Thats what in my mind.
> Kindly provide your suggestion.
> Thanks
> Megha
>
> Jeff Brower  wrote: Megha-
>
>> There is one more thing. I ran the following program:
>> i=1;
>>  while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>>                cfir(bufferrcv, bufferxmt, BUFFSIZE);
>>
>> and in cfir():
>>
>>  FilterBufferBySamplesIIR(data, blksize);
>>
>>  //  for (i = 0; i < blksize; i++)
>>  i=1;
>>   results[i] = data[i];
>> if I remove filterbufferbysamples I get proper output for single samples
>> (i=1), but if i add  filterbufferbysamples I am not getting output but
>> just noise.
>
> This is because you are waiting too long to output to the codec.  Try it
> this way:
>
>   /* wait for input sample to be ready */
>   while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>
>   /* output last filtered sample */
>   PEP5416_AIC23_write16(hCodec, @out_sample);
>
>   /* filter one sample */
>   cfir(bufferrcv[i], @out_sample, 1);
>
>   i++;
>
>   /* end of loop; repeat and wait for next sample */
>
> The idea is that when the codec is ready, you need to do both input and
> output without waiting.  Otherwise the codec will output some junk.
>
> If you can get this to work, then you can try buffering samples, instead
> of single sample processing.  One step at a time.
>
> -Jeff
>> My data is not changing in  filterbufferbysamples. Its the same. I
>> am just using it once inside that function that to get its value. i am
>> not changing its value. Can you think of any reson why thats happening.
>> kindly reply.
>> thanking you
>> megha
>>
>> Jeff Brower  wrote: Megha-
>>
>>> Yeah thats what I was asking about. Currently I am using just a single
>>> buffer in my program which is making my data lost. Hence I need to use
>>> dual buffers.
>>> Now what I had in mind:
>>> to use dual buffer I will have to use McBSP and DMA. I am not sure how
>>> to
>>> use dual buffer without those and I dont want to use DMA right now.
>>> Can you help me in how to use them. Or can you give some links, where
>>> their description can be found.
>>
>> If your loop is processing each  sample, which would explain why you get
>> some noise on the output if you wait too long to supply the output value
>> (i.e. result from the filter), then for now you can just use a single
>> sample delay, then worry about ping-pong buffer later.
>>
>> For example, if your processing loop is based either on a sample
>> interrupt
>> or polling (waiting) for each sample, then you can do something like
>> this:
>>
>>   cur_sample = fltoq(flacoustic[i]);
>>   PEP5416_AIC23_write16(hCodec, last_sample);
>>   last_sample = cur_sample;
>>
>> Note this causes a 1-sample delay in the output.
>>
>> Only when your filter and other processing gets to be enough it cannot
>> be
>> accomplished in one sample period do you need to worry about using
>> ping-pong buffers.  What is your sampling  rate?
>>
>> -Jeff
>>> Jeff Brower  wrote: 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

Dear Jeff
Kindly reply. You asked for the sampling rate: It is 44.1Ksamples per second. It can go down
till 24Ksamples per second. Following is the summary of current situation:
My filter process is filtering one sample at a time. What i did was read 2048 samples in rcv
buffer passed it on to filter function. Filter function filtered it sample by sample and then
when all 2048 was sampled, it wrote it them to xmt buffer.
Now in above case when filter function is running rcv buffer is not reading any data from the
codec and all that data is lost. So for that what is required is: The data is read continously
without getting interrupted from the filter function. When a certain amount of data is read
(suppose 256), that much data should be passed to another buffer (temp buffer) which will go to
filter function. while filtering of this data the rcv buffer is still reading data (its not
stopping). When filtering is done it write filtered data to xmt buffer and reads next 256
samples from rcv buffer into the temp buffer which is passed to filter function. This way i can
avoid losses.
I assume this is not impossible and this is how it should be done. But my problem is I am not
able to read data continously and take 256 samples and pass it on (the first step). I think I
can do it using PIP or HST. So I tried running simple example programs by TI on PIP and HST
like copy.pjt I ran this program on my device and I am not getting any output. It is not
calling any interrupts. I am not getting where I am getting wrong. I sent you that copy file in
my previous mail, if you get time kindly have a look at it.
Kindly provide suggestions. Waiting for your reply
thanking You
Megha Daga
Jeff Brower <j...@signalogic.com> wrote: Megha-

> Yeah thats what I was asking about. Currently I am using just a single
> buffer in my program which is making my data lost. Hence I need to use
> dual buffers.
> Now what I had in mind:
> to use dual buffer I will have to use McBSP and DMA. I am not sure how to
> use dual buffer without those and I dont want to use DMA right now.
> Can you help me in how to use them. Or can you give some links, where
> their description can be found.

If your loop is processing each sample, which would explain why you get
some noise on the output if you wait too long to supply the output value
(i.e. result from the filter), then for now you can just use a single
sample delay, then worry about ping-pong buffer later.

For example, if your processing loop is based either on a sample interrupt
or polling (waiting) for each sample, then you can do something like this:

  cur_sample = fltoq(flacoustic[i]);
  PEP5416_AIC23_write16(hCodec, last_sample);
  last_sample = cur_sample;

Note this causes a 1-sample delay in the output.

Only when your filter and other processing gets to be enough it cannot be
accomplished in one sample period do you need to worry about using
ping-pong buffers.  What is your sampling rate?

-Jeff
> Jeff Brower  wrote: 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