Hi Harshit,
Thanks for your reply.
Harshit.Gaharwar wrote:
- 1) Is it realistic to assume that the 21489 is running out of processing power for the 2048-tap stereo filters, or am I doing something wrong?
>> Can you please first try writing a simple code to check if the fir function works fine and you receive the correct output data corresponding to 1024, 2048 and 4096 tap stereo filters or not?
Once this is confirmed then we can look into why the problem is observed when you try to implement it inside the real time talk-through example codes.
May be you can try by sending a simple sinusoidal wave as an input and then checking the output for it, which will give more information regarding what kind of error is happening, like is the function not getting enough time to do the processing by the time another set of data is received or is the output data from the fir function is getting corrupted for different tap filter lengths.
It might be interesting to verify the FIR function first for the offline case as you suggest, but I already do know that it works well in the real-time case at least for 1024 taps (mono or stereo) and 2048 taps (mono). (I perform the stereo FIR just by evaluating two consecutive mono FIR calls with different coefficients.) I tested this by making a simple 5 kHz bandpass filter, and feeding noise to the system. The output shows a nice peak at 5 kHz when running one or two 1024-tap FIRs in the process_audio.c -routine, or when running one 2048-tap FIR. However, if I try to run two 2048-tap FIRs, I get only a peak at 2.5 kHz (=5/2 kHz) at the output. Trying to run one 4096-tap FIR gives me a peak around 5/3 kHz.
I also did another test by performing the real-time FIR calculations, but just feeding the signal directly through from input to output. Using a 5 kHz sine as an input, I should expect the same signal at the output (regardless of the FIR-coefficients, since even though the FIR is evaluated, the result is not used). With one or two 1024-tap FIRs, the output is a clean 5kHz sine as it should be. This is also the case when I evaluate one call to the FIR-function using a 2048-tap coefficient vector. However, when I evaluate two FIR-calls using 2048 taps, the output signal is corrupted, consisting of the 5kHz tone, added with a 19.2 kHz tone. Hence, this makes me suspect that the computational burden of the two 2048-tap (dummy) FIR-calls prior to feeding the signal straight from input to output is too much and the audio interrupt doesn't have time to finish before the next sample should be processed. Does this seem like a reasonable interpretation?
Harshit.Gaharwar wrote:
I would suggest you to first isolate the issue and try to find out, if the problem is there in fir function as standalone code or the problem happens only when you try to implement it inside the talk-through code. Also as you can see in the talk-through code, before processing any data, the received data is first getting converted from fixed to float format and once the processing is done, the processed data is changed back from float to fixed and is sent out through the DAC.
So you may have to check if the code you are implementing takes care of the data format support for the FIR function or not, which could also result in wrong output.
In the light what I described above, it seems that the FIR-function is indeed operating correctly, and there should not be an issue with fixed/float format case either. Would there be an easy way of estimating the actual computational load of the two 2048-tap FIR calls, multiply this by the Fs = 48000 kHz and see if it exceeds the 21489's specs?
Thanks,
Jykke