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

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

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

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

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 wrote: Megha-

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

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

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

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

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

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

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

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

while (!PEP5416_AIC23_write16(hCodec, bufferxmt));
cfir(bufferrcv, &bufferxmt, 1);
}
// counter++;
}
and in cfir()
{
Preemphasis(data,blksize);

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

FilterBufferBySamplesIIR(data, blksize);

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

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

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

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

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

-Jeff

> I tried one of the sample examples by TI for PIP (copy.pjt copies
> data from i/p to o/p). But thats not working on my device. I am not
> getting the reason. I have just added the device initialization part to
> that code. I am attaching that code, if possible have a look at that.
> What I think is if I can read data from PIP (continous real time). I can
> read it in form of 3/4 frames. Then I can pass 1 frame at a time to the
> filter process and then that frame to o/p. Then again I will take 2 frame
> and so on. this way I wont loose data. I will have to use interrupts.
> Thats what in my mind.
> Kindly provide your suggestion.
> Thanks
> Megha
>
> Jeff Brower wrote: Megha-
>
>> There is one more thing. I ran the following program:
>> i=1;
>> while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>> cfir(bufferrcv, bufferxmt, BUFFSIZE);
>>
>> and in cfir():
>>
>> FilterBufferBySamplesIIR(data, blksize);
>>
>> // for (i = 0; i < blksize; i++)
>> i=1;
>> results[i] = data[i];
>> if I remove filterbufferbysamples I get proper output for single samples
>> (i=1), but if i add filterbufferbysamples I am not getting output but
>> just noise.
>
> This is because you are waiting too long to output to the codec. Try it
> this way:
>
> /* wait for input sample to be ready */
> while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>
> /* output last filtered sample */
> PEP5416_AIC23_write16(hCodec, @out_sample);
>
> /* filter one sample */
> cfir(bufferrcv[i], @out_sample, 1);
>
> i++;
>
> /* end of loop; repeat and wait for next sample */
>
> The idea is that when the codec is ready, you need to do both input and
> output without waiting. Otherwise the codec will output some junk.
>
> If you can get this to work, then you can try buffering samples, instead
> of single sample processing. One step at a time.
>
> -Jeff
>> My data is not changing in filterbufferbysamples. Its the same. I
>> am just using it once inside that function that to get its value. i am
>> not changing its value. Can you think of any reson why thats happening.
>> kindly reply.
>> thanking you
>> megha
>>
>> Jeff Brower wrote: Megha-
>>
>>> Yeah thats what I was asking about. Currently I am using just a single
>>> buffer in my program which is making my data lost. Hence I need to use
>>> dual buffers.
>>> Now what I had in mind:
>>> to use dual buffer I will have to use McBSP and DMA. I am not sure how
>>> to
>>> use dual buffer without those and I dont want to use DMA right now.
>>> Can you help me in how to use them. Or can you give some links, where
>>> their description can be found.
>>
>> If your loop is processing each sample, which would explain why you get
>> some noise on the output if you wait too long to supply the output value
>> (i.e. result from the filter), then for now you can just use a single
>> sample delay, then worry about ping-pong buffer later.
>>
>> For example, if your processing loop is based either on a sample
>> interrupt
>> or polling (waiting) for each sample, then you can do something like
>> this:
>>
>> cur_sample = fltoq(flacoustic[i]);
>> PEP5416_AIC23_write16(hCodec, last_sample);
>> last_sample = cur_sample;
>>
>> Note this causes a 1-sample delay in the output.
>>
>> Only when your filter and other processing gets to be enough it cannot
>> be
>> accomplished in one sample period do you need to worry about using
>> ping-pong buffers. What is your sampling rate?
>>
>> -Jeff
>>> Jeff Brower wrote: Megha-
>>>
>>>> I am not using that in recurrsion and hence I took your advice.
>>>> Actually
>>>> there is one more function in DSP called fltoq(). it converts float to
>>>> Q15 (short). i read about it and it does nothing but multiplication by
>>>> 32768 :)
>>>> Well actually I dont know how this scaling is affecting my output.
>>>> Right
>>>> now I am not getting the whole output. Actually as I am using a single
>>>> buffer, my data is getting lost when the previous data is getting
>>>> processed and hence I am just getting beeps right now instead of
>>>> continous data. I think I will have to use two buffers now, ex ping
>>>> pong
>>>> buffering. But I think I will have to use it with DMA and McBSP. Do
>>>> you
>>>> have any suggestions on that?
>>>
>>> Ping pong (dual) buffers are needed for real-time, continuous output:
>>> in
>>> your case, one buffer is going out to DAC while other buffer is being
>>> filled by your filter output + fltoq().
>>>
>>> My suggestion is to get that working first, then worry about DMA. Your
>>> sampling rates are not high enough to cause DMA to be required for real
>>> time operation, so save the DMA for last step.
>>>
>>> -Jeff
>>>
>>>> Jeff Brower wrote: Megha-
>>>>
>>>>> I thought of converting like that. I thought of multiplying my
>>>>> filtered
>>> output and giving that to result. But you see like this I will disturb
>>> the filtered value. It wont be same as it was. So thats a problem I
>>> think.
>>>>
>>>> It's just scaling. As long as you don't feed results[] back into the
>>> filter, then no problem. If results[] must be used as recursive input
>>> to the filter, then keep 2 arrays:
>>>>
>>>> results[i] = flacoustic[i];
>>>> dac_out[i] = (short int)(32767.0*flacoustic[i]);
>>>>
>>>> where results[] is float, and dac_out[] is short int.
>>>>
>>>> -Jeff
>>>>
>>>>> Jeff Brower wrote: Megha-
>>>>>
>>>>>> As I told in my last mail, there is some problem in my filter
>>> function. cause its running properly but the filtered output is not
>>> coming. I got the reason why. Well the last lines are:
>>>>>> for(i=0; i
>>>>>> results[i] = flacoustic[i];
>>>>>> Well flacoustic is the filtered output from filter function and
>>> results is the array which is written back on the output port of the
>>> device. Now
>>>>>> the problem is flacoustic is float and result is Int16(typedefined
>>>>>> as
>>> short).the filetered function is returning all values between 1 and -1
>>> and hence when they go into results (defined short), the value becomes
>>> 0, and hence no output. I hope you got my point.
>>>>>
>>>>> Try like this:
>>>>>
>>>>> results[i] = floor(32767.0*flacoustic[i]);
>>>>>
>>>>> I don't know if you floor() function is available or not; if not find
>>>>> a
>>> function that converts float to int. Also just this might work:
>>>>>
>>>>> results[i] = (short int)(32767.0*flacoustic[i]);
>>>>>
>>>>> but I'm not sure because 54xx floating-point library support in CCS
>>>>> may
>>> not be that complete.
>>>>>
>>>>> In any case, once you have values between -32768 and 32767 in
>>> results[], then you can send those out to D/A converter; i.e. using
>>>>> PEP5416_AIC23_write16() function.
>>>>>
>>>>> -Jeff
>>>>>
>>>>>
>>>>>> Now there were two choices either I convert all Int16 to float or
>>> float to
>>>>>> Int16. if I convert float to Int16, I will get 0 in flacoustic
>>>>>> itself
>>> (cause filtered value is between 1 and -1 and will become 0 if
>>> flacoustic
>>>>>> is short). So the only option remains is converting Int16 to float.
>>> Now the problem is in the device inbuilt functions, when i read data,
>>> its
>>>>>> read in Int16 format. the statement is decalred like following in
>>>>>> the
>>> header file of teh device (pep5416_aic23.h):
>>>>>> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle hCodec, Int16
>>> *val);
>>>>>> and write is defined in following manner:
>>>>>> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle hCodec,
>>>>>> Int16
>>> val);
>>>>>> So as you see the val is Int16 and now if I convert Int16 into
>>>>>> float,
>>> I will have to convert it here too. But if I convert it to float,
>>> there is
>>>>>> lot of noise and I am not getting proper output. i tried it without
>>> filter
>>>>>> function, on my first code (simple audio in and same audio out). I
>>>>>> am
>>>>>> not
>>>>>> getting proper output if I change this function; which I was getting
>>>>>> when
>>>>>> it was Int16. I hope I am able to explain everything clearly.
>>>>>> Hence my problem remains. I am not able to think of a solution to
>>> this. If you have any idea kindly help me.
>>>>>> Thanks
>>>>>> Megha
>>>>>>
>>>>>> Jeff Brower wrote: Megha-
>>>>>>
>>>>>>> As I wrote in my last mail, its problem with InitBuffer function.
>>>>>>> Well
>>>>>>> I debugged it further and there is no problem in that. The problem
>>>>>>> is
>>> when data goes into the filter function "cfir()'. I just tried with a
>>> loop inside the cfir. The loop did following:
>>>>>>> rcv = xmt;
>>>>>>> And the code is running (rest all is same).
>>>>>>> So something is going wrong in the filter function.
>>>>>>
>>>>>> This could be different types of problems:
>>>>>>
>>>>>> 1) The cfir() code has some basic problem, for example goes beyond
>>>>>> array
>>>>>> boundary,
>>>>>> bad pointer, etc.
>>>>>>
>>>>>> 2) The code is Ok, but filter coefficients are not good, so your
>>> output eventually
>>>>>> becomes zero or saturated value, and you hear no sound.
>>>>>>
>>>>>>> I have to debug it further. Actually I am not getting how to debug
>>>>>>> that. I am gonna follow your advice of adding parts one by one. But
>>>>>>> that
>>>>>>> too is difficult to decide what to and what not to.
>>>>>>
>>>>>> One thing to try is let filter code run, but at very end of function
>>> (just
>>>>>> before
>>>>>> return) put:
>>>>>>
>>>>>> rcv = xmt;
>>>>>>
>>>>>> as you did above. Then if you can still hear the output, then
>>> probably filter code
>>>>>> is Ok, but coefficients are a problem.
>>>>>>
>>>>>> -Jeff
>>>>>>
>>>>>>
>>>>>>> Jeff Brower wrote: Megha-
>>>>>>>
>>>>>>> > I am working on a PEP5416 device and am using a TI C5416
>>>>>>> simulator.
>>>>>>> I
>>>>>>> am
>>>>>>> > implementing an acoustic model which takes the sound input from
>>>>>>> the
>>> microphone, process it (filters) and provide the filtered output at
>>>>>>> headphone.
>>>>>>> > My code is working on the simulator, its not giving any errors
>>>>>>> and
>>>>>>> I
>>>>>>> have
>>>>>>> > debugged it step by step, its nowhere getting stuck. But when I
>>>>>>> try
>>>>>>> to
>>>>>>> run
>>>>>>> > the code on the device, its not running. I can hear no output,
>>>>>>> not
>>>>>>> a
>>>>>>> simple
>>>>>>> > buzz. I have ran a simple code on that device, in which I just
>>>>>>> take
>>>>>>> the
>>>>>>> > input and pass it onto the output. And its running.
>>>>>>>
>>>>>>> Since you can run simple loopback that's a good starting point for
>>>>>>> debug
>>>>>>> -- we call
>>>>>>> that "known good". From that point, try adding your code (the
>>>>>>> unknown,
>>>>>>> haha), step
>>>>>>> by step. For example, just call the functions, but don't take the
>>> output, continue
>>>>>>> to use the original loopback. The idea is to find which piece of
>>> your code does
>>>>>>> something bad, like "step on" other code or other memory data, mess
>>> up the stack,
>>>>>>> etc.
>>>>>>>
>>>>>>> -Jeff

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