Hello,I'm developing an audio application for the ADSP-SC573 processor and I'm using the SC573-EZLITE kit as development hardware. I'm trying to use the ADC DAC Audio Playback (SC573 SHARC) example as a starting point and have created my own test project based on that. I'm experiencing some data corruption when the audio should come through as unchanged. It seems that there is some synchronization issue somewhere, but I have not been able to entirely pinpoint the problem. I'm able to reproduce some of the problems on the original example code when it is suspended and then resumed. The example code seems to start reliably, and the output audio is correct, but after a suspend and resume, parts of the audio stream are shifted:
ch1: input, ch2: output
In my altered code where I'm running the processing on core0 (arm) only, the situation is worse. When starting as debugged the output is rarely correct, and the shifted part length changes from single sample to a short block of data. When doing a suspend-resume cycle the situation may be corrected or it can get worse. I also tried to load the software to the external flash using cldp.exe to see if cold starting makes and difference but result was the same.I'm not sure what happens but it seems that the buffer halves of the ping pong buffer get mixed and the DMA starts writing or reading the half that is manipulated by the ProcessBuffers function. If I understand correctly the callback functions should always receive addresses to the buffer position that are ready to be read or written? How could this go wrong?The initializations on the two software should be the same. Is there anything that can be done to ensure the DMAs and buffers are synchronized at start up?Best regardsPauli
Moving to CrossCore Embedded Studio and Add-ins
We have tried to simulate the issue which you are facing using adc_dac_playback example code in ADSP-SC573 Ez-kit. But we are not able to simulate the issue. Can you please share us the modified code to reproduce the issue.
Also we recommend you to avoid placing breakpoint in the audio code. If you put a breakpoint in the audio code it is actually causing delay(halting) and which will cause into a Receiver overflow.
Thank you for your response.I verified that I am able to reproduce the previously described problem with the unmodified ADC DAC Audio Playback example code. Single suspend-resume cycle for the core1 might not bring up the problem, but a few eventually will.I understand that halting the code will cause corruption since the DMAs seem to continue running but the data in the buffers is not updated. More interesting question is, why doesn't the system correct itself when resumed?I've made an example project for you where I have taken the ADC DAC Audio Playback example and with small changes modified it to run on the ARM core. The buffer alignment is declared differently. I hope it is correct. When run, this example produces an output that has glitches at about 2,66ms interval. Again it seems plausible that the first corrupted sample belongs to the next glitch position and so on. This leads me to think that the buffer reads/writes are somehow not in sync with the DMAs and this way part of the data is written or read to the wrong place.I hope the zip file contains everything you need.
ch1 = input at IP1, ch2 = output at OP1I'm trying to understand how the DMAs and the ADC/DAC drivers work and I have hard time figuring out how the ping pong buffers are used in the DMAs. At initialization phase both the ping and pong buffers are submitted to the driver. Are they stored in some kind of list that the DMA then cycles? How are these functions supposed to be used?Then at callback when the buffers are re-submitted, only the currently free one is submitted, right? Should this mechanism ensure that the DMAs and ping pong buffers are synchronized?Are there any explanation or usage guide for the ADAU1979 and ADAU1962 drivers or the SPORT driver underneath them? I can find the API Reference Manual from the help files, but it doesn't provide much information about the usage of the driver in my opinion.Best regardsPauli
Here are some additional captures of the glitch with some GPIO timings.in the following images:ch1 = output signal (OP1)ch2 = GPIO toggle in AdcCallback functionch3 = GPIO toggle in DacCallback functionch4 = GPIO Set while in ProcessBuffers when pGetADC != NULL, pGetDAC != NULL or (pDAC != NULL) && (pADC != NULL)At first the short glitch is present:
DacCallback comes first, AdcCallback comes second and immediately a longer pulse on ch4 marks the copying of the buffers.
Sometimes when suspending and resuming the short glitch changes to a longer one:Now AdcCallback comes first, DacCallback comes second.
Sometimes suspending and resuming fixes the problem entirely:Now AdcCallBack comes first and DacCallback comes after.
Does the order of the callbacks or it changing play some role in this?
I have still not being able to solve this problem and I'm running out of ideas. It's impossible for us to continue development if we don't have a solid base to build from.
I was suspecting that moving the example from the sharc core to the arm core was messing some things or something was initialized incorrectly. I now found that in the examples there is a ASRC Playback SC573 (Cortex) example that is specifically for the arm core only.
I have tried this example and without any modification it also consistently shows the same one sample glitch output as shown in the first scope image in the previous message. I tested this example by loading it with the debugger and also as a flashed (with cldp.exe) standalone version to ensure that the debugger is not involved in the startup.
We have a second Ez-kit and I believe it behaves similarly so I don't suspect the HW. Could there be something else in my environment setup maybe? Any ideas are welcome. Please advice.