Hi, working on a L137 from several weeks. Currently I'm using only the C6747 and not planning to use the ARM core.
After working a bit with my project I discovered a huge problem, that could be either a serious bug of the audio driver or a problem of mine in using it.
The driver I'm using is the example you find in psp013001\packages\ti\pspiom\examples\evmOMAPL137\audio called audioSample. I'm using DSP/BIOS 5.41 (bios_5_41_03_17)
The driver works frame-by-frame, you obtain a frame, it is a 16-bit signed integer Left-Right interleaved AFAIK. You unpack it and use it however you want. Then issue back a frame with the output.
THE PROBLEM:
sometimes (let's say 60% of the times) two consecutive audio frames are scrambled. What I mean:
- I take the frame and store it in a temp array, then use it.
- Next cycle I have a new frame and the old one I stored in the temp array. I plot them side by side and see that 60% of the times they are not correctly joined, there's a step. 40% of the times they join correctly, i.e. putting them side by side, it looks clear they come from the same signal.
So you would say: maybe the driver is missing some samples, but that's not the case, because MAGICALLY: if you plot the newest first and the oldest after, they join perfectly! So the driver gives me two consecutive buffers that are reverse-ordered!
What's more: the AUDIO WORKS flawlessly. I send a sinewave to the input and I record the same exact sine on output. So why the audio works fine if the data should not be fine? Normally I input some signal and throw it out without processing it, just copying the buffers but I also tried to use a Lo-pass filter and it worked fine.
Maybe it's the debugger that's not working ok? But I'm quite sure it is working fine because FIR filters have their output corrupted by the fact from a frame to the other, the previous states are not correctly joining the new ones. This problem affects all the processing and I can see bad results at the end.
I'll post you two images to make it clearer:
The first image shows two buffers concatenated. The green line shows where the step is. The second image show the concatenated version of the two buffers in reverse order: they join perfectly (green line).
Just to make it clear, the signal fed into the DSP is the one below (played in loop), so every smaller sine follows bigger sine.
It is shaped this way so I can debug better.
Some pseudocode used for the debugging:
SIO_reclaim(rcv,...) // reclaim a buffer
buffer_unpack(rcv, f_in_L, f_in_R); //unpack the buffer into L and R channels f_in_L and f_in_R
my_processing(f_in_L, f_in_R, f_out_L, f_out_R);
storing_the_buffer(f_in_L, temp_f_in_L);
SIO_issue(...); // issue the processed buffer
I obtain the plots putting a breakpoint between buffer unpacking and before storing_the_buffer. This way I have the old buffer temp_f_in_L from the previous cycle of the audio task and I have the new frame f_in_L to be used for this cycle of the processing.
Some of you may ask me if my unpacking procedure is faulty: it is not. The same problem happens on the original rcv buffer (you just have to plot it using the correct options, displaying one 16-bit int data every 2).
Maybe I should start reading the whole code of the driver, but I have no time, I have to focus on the algorithm.
Just a question: is there a sample-by-sample driver for C6747 that is ready to use? I have a tutorial book from Chassaing on coding for TI processors but it's all sample-by-sample.
I hope I've been clear, ask me further questions if you wish.