5409 | 5416 | AD5 | ADC | BIOS | Boot | Booting | Bootloader | C540 | C5402 | C5409 | C5416 | CCS | Codec | DMA | Dmad | DSK | DSKPlus | Dsplib | EVM | FFT | FIR | Flash | GPIO | HPI | Initialization | Interrupt | JTAG | LOG_printf | MCBSP | RFFT | RTDX | Sampling | STLM | UART | VC540

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

   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.

(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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.

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

 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

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

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 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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

Dear Jeff
Thanks. Well as I told I did debug the code and saw step by step, the value is
getting transferred as it is and it is coming into results as required, but
somehow o/p is not coming. It can be due to length of the code. If its long can
you suggest some thing.
Thanking You
Megha Daga

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

> 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.

There is no "continuous" in "digital signal processing (dsp)
system.  With
your sampling rate, each time the codec samples the audio data, there is
22.6 usec until the next sample.  That is the time available to process
one sample.  All filtering -- or whatever processing needed -- for each
sample must fit within that time.  Otherwise, the system is not in
real-time.

> As per as single sample processing is concerned, its not working.

In the code I suggested previously:

   /* 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);

what happens if you replace cfir() line with:

  out_sample = bufferrcv[i];

do you get continuous output?  Sure.  So then you look into cfir()
routine, find out what's wrong?  Maybe it has a bug, takes too long...

Whatever is wrong with cfir(), I don't know -- that's your code and you
have to debug it.  I can't help you with this any further until you get
the single-sample step working.  When you get that far, write the group
again.

-Jeff
> 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).  I am
> attaching the respective code. Kindly tell me the reason behind this.
> Kindly reply.
> Thanking You
> Megha Daga
>
> Jeff Brower  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
>

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

Megha-

> Yes its an IIR filter and yes everything inside that is in floating point
> representation. I understand that 54xx will take long due to the floating
> point, but can anything be done to reduce that like optimization or
> something...(as I think that will make it work)

First question is whether cfir() is really taking too long, which I doubt, or
you
have some other problem(s).  Does cfir() expect floating-point or fixed-point
arguments?   If floating-point, then the code I gave you should look like:

  /* 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 */

  flt_input = bufferrcv[i]/32767.0;
  cfir(&flt_input, &flt_output, 1);

  out_sample = fltoq(flt_output);

where flt_xxx are floats.

Also, are you sure that "blksize" inside cfir() = 1?  If you do more
than one, it
won't work since you're only processing one sample at a time.

-Jeff
> Jeff Brower <j...@signalogic.com> wrote:
>
>      Megha-
>
>      > Thanks. Well as I told I did debug the code and saw step by step,
the
>      > value is getting transferred as it is and it is coming into
results as
>      > required, but somehow o/p is not coming. It can be due to length
of the
>
>      > code. If its long can you suggest some thing.
>
>      If it's IIR filter, and you call it with len = 1 (filter one sample),
>      then
>      it should not take long.
>
>      If cfir() is all in floating-point, then that may be taking a long
time
>      to
>      process. Floating-point on C54xx has to be done with software
routines,
>      since C54xx is fixed-point processor.
>
>      Well, you will have to figure this out.
>
>      -Jeff
>
>      > Jeff Brower wrote: Megha-
>      >
>      >> 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.
>      >
>      > There is no "continuous" in "digital signal
processing (dsp) system.
>      With
>      > your sampling rate, each time the codec samples the audio data,
there
>      is
>      > 22.6 usec until the next sample. That is the time available to
process
>      > one sample. All filtering -- or whatever processing needed -- for
each
>      > sample must fit within that time. Otherwise, the system is not
in
>      > real-time.
>      >
>      >> As per as single sample processing is concerned, its not
working.
>      >
>      > In the code I suggested previously:
>      >
>      > /* 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);
>      >
>      > what happens if you replace cfir() line with:
>      >
>      > out_sample = bufferrcv[i];
>      >
>      > do you get continuous output? Sure. So then you look into cfir()
>      > routine, find out what's wrong? Maybe it has a bug, takes too
long...
>      >
>      > Whatever is wrong with cfir(), I don't know -- that's your code
and you
>
>      > have to debug it. I can't help you with this any further until
you get
>      > the single-sample step working. When you get that far, write the
group
>      > again.
>      >
>      > -Jeff
>      >
>      >
>      >> 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). I am
>
>      >> attaching the respective code. Kindly tell me the reason
behind this.
>      >> Kindly reply.
>      >> Thanking You
>      >> Megha Daga
>      >>
>      >>
>      >>
>      >> Jeff Brower 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
>      >>
>      >>
>      >

(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

Dear Jeff
  Yes its an IIR filter and yes everything inside that is in floating point
representation. I understand that 54xx will take long due to the floating point,
but can anything be done to reduce that like optimization or something...(as I
think that will make it work)
  Kindly reply
  Thanking You
  Megha Daga

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

> Thanks. Well as I told I did debug the code and saw step by step, the
> value is getting transferred as it is and it is coming into results as
> required, but somehow o/p is not coming. It can be due to length of the
> code. If its long can you suggest some thing.

If it's IIR filter, and you call it with len = 1 (filter one sample), then
it should not take long.

If cfir() is all in floating-point, then that may be taking a long time to
process. Floating-point on C54xx has to be done with software routines,
since C54xx is fixed-point processor.

Well, you will have to figure this out.

-Jeff

> Jeff Brower wrote: Megha-
>
>> 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.
>
> There is no "continuous" in "digital signal processing (dsp)
system. With
> your sampling rate, each time the codec samples the audio data, there is
> 22.6 usec until the next sample. That is the time available to process
> one sample. All filtering -- or whatever processing needed -- for each
> sample must fit within that time. Otherwise, the system is not in
> real-time.
>
>> As per as single sample processing is concerned, its not working.
>
> In the code I suggested previously:
>
> /* 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);
>
> what happens if you replace cfir() line with:
>
> out_sample = bufferrcv[i];
>
> do you get continuous output? Sure. So then you look into cfir()
> routine, find out what's wrong? Maybe it has a bug, takes too long...
>
> Whatever is wrong with cfir(), I don't know -- that's your code and you
> have to debug it. I can't help you with this any further until you get
> the single-sample step working. When you get that far, write the group
> again.
>
> -Jeff
>> 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). I am
>> attaching the respective code. Kindly tell me the reason behind this.
>> Kindly reply.
>> Thanking You
>> Megha Daga
>>
>> Jeff Brower 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

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

Dear Jeff
cfir() is not taking too long. cfir is not taking floating point data. This is
because 54xx is reading just fixed point data and I am passing fixed point data
to the cfir. So it is like following:
Int16 bufferrcv[2048];
Int16 bufferxmt;
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);
        }
    }

void cfir(Int16 *data,Int16 *results,Int16 blksize)
{
    Preemphasis(data,blksize);

    FilterBufferBySamplesIIR(data, blksize);

    *results = data[0];
     //  *results = 32768*flacoustic[0];
}
So you see data, results is fixed point an dblksize is 1. Now inside the
FilterBufferBySamplesIIR we are passing fixed point, but all the calculations
(with coefficients) is in float. In the end the output is stored in flacoustic
(defined extern float) in FilterBufferBySamplesIIR(). This float output is
multiplied by 32768 in cfir() and the int equivalent of that gets srored in
results. But in the above case I am not even using flacoustic. I am just copy
pasting the data to results. Just running the Filter function is disturbing the
output.  And as I said before, the filter function is not changing the data[0].
I can see that in the watch window. I will try optimizing the filter function
today. That might help.
Kinldy reply.
Thanking You
Megha Daga

Jeff Brower <j...@signalogic.com> wrote:   Megha- > Yes its an IIR
filter and yes everything inside that is in floating point 
> representation. I understand that 54xx will take long due to the floating 
> point, but can anything be done to reduce that like optimization or 
> something...(as I think that will make it work) 
First question is whether cfir() is really taking too long, which I doubt, or
you have some other problem(s).  Does cfir() expect floating-point or
fixed-point arguments?   If floating-point, then the code I gave you should look
like: 
  /* 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 */ 
  flt_input = bufferrcv[i]/32767.0; 
  cfir(&flt_input, &flt_output, 1); 
  out_sample = fltoq(flt_output); 
where flt_xxx are floats. 
Also, are you sure that "blksize" inside cfir() = 1?  If you do more
than one, it won't work since you're only processing one sample at a time. 
-Jeff 
  
Jeff Brower <j...@signalogic.com> wrote: Megha- > Thanks. Well as I
told I did debug the code and saw step by step, the 
> value is getting transferred as it is and it is coming into results as 
> required, but somehow o/p is not coming. It can be due to length of the 
> code. If its long can you suggest some thing. 
If it's IIR filter, and you call it with len = 1 (filter one sample), then 
it should not take long. 
If cfir() is all in floating-point, then that may be taking a long time to 
process. Floating-point on C54xx has to be done with software routines, 
since C54xx is fixed-point processor. 
Well, you will have to figure this out. 
-Jeff 
> Jeff Brower wrote: Megha- 
> 
>> 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. 
> 
> There is no "continuous" in "digital signal processing (dsp)
system. With 
> your sampling rate, each time the codec samples the audio data, there is 
> 22.6 usec until the next sample. That is the time available to process 
> one sample. All filtering -- or whatever processing needed -- for each 
> sample must fit within that time. Otherwise, the system is not in 
> real-time. 
> 
>> As per as single sample processing is concerned, its not working. 
> 
> In the code I suggested previously: 
> 
> /* 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); 
> 
> what happens if you replace cfir() line with: 
> 
> out_sample = bufferrcv[i]; 
> 
> do you get continuous output? Sure. So then you look into cfir() 
> routine, find out what's wrong? Maybe it has a bug, takes too long... 
> 
> Whatever is wrong with cfir(), I don't know -- that's your code and you 
> have to debug it. I can't help you with this any further until you get 
> the single-sample step working. When you get that far, write the group 
> again. 
> 
> -Jeff 
>> 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). I am

>> attaching the respective code. Kindly tell me the reason behind this. 
>> Kindly reply. 
>> Thanking You 
>> Megha Daga 
>> 
>> Jeff Brower 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 
>>

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

Hy i am a student an i"m working at a project with a
dsk5416. I am trying to design an iir filter using
fdatool from matlab but i can't use those filter
coeffincints because they have a diffrent structure.
the dsplib functios usualy use biquads sections.
 i tried to use iir5 function from dsplib  ...
can  anybody help me? is there any way to export or to
convert parameters from matlab in order to use them
whith dsplib functions or is thhere any other program
that i can use to design the filter with a proper
parameter structure?

_________________________

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

Hi
I understand your problem is matlab gives u in float and u need in fixed for
dsk. Well there is a function for float to Q15 convert. Q15 is nothing but
representation of signed int. You can read abt it in one of the documnets
spru518. The function is described in the same doc.
megha

john doe <z...@yahoo.com> wrote: Hy i am a student an i"m working at
a project with a
dsk5416. I am trying to design an iir filter using
fdatool from matlab but i can't use those filter
coeffincints because they have a diffrent structure.
the dsplib functios usualy use biquads sections.
 i tried to use iir5 function from dsplib  ...
can  anybody help me? is there any way to export or to
convert parameters from matlab in order to use them
whith dsplib functions or is thhere any other program
that i can use to design the filter with a proper
parameter structure?

_________________________

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )

Zadrig-

> Hy i am a student an i"m working at a project with a
> dsk5416. I am trying to design an iir filter using
> fdatool from matlab but i can't use those filter
> coeffincints because they have a diffrent structure.
> the dsplib functios usualy use biquads sections.
>  i tried to use iir5 function from dsplib  ...
> can  anybody help me? is there any way to export or to
> convert parameters from matlab in order to use them
> whith dsplib functions or is thhere any other program
> that i can use to design the filter with a proper
> parameter structure?

Suggest to try this MATLAB function:

  [bcas,acas,g] = tocas(b,a)

which converts direct-form to a series of biquad (2nd order) filter
sections.  This is often known as "biquad cascade" form.

Then, as Megha pointed out, you will need to make the floating-point
coefficients into Q-n format for efficient implementation on C54x
processor.

-Jeff

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )