I am using the dm816x with the 5.04.00.11 EZSDK. We have a McASP stream that contains 16 32-bit time slots of 48kHz audio feeding into McASP2. An application on the DSP has the EDMA pulling the audio data from the McASP and placing it into two buffers created in shared memory. The two buffers are being used in a ping-pong scenario where upon filling the ping buffer the DSP will send a notification to the HOST, and then start filling the pong buffer. After the pong buffer is filled, DSP notifies HOST, and the cycle repeats. The HOST application will empty the appropriate buffer when notified, passing the appropriate channels to their destinations. When I test the DSP code alone, no HOST side app running, ping pong buffers are filled as I expect, no matter how long I let the test run. Running a simple HOST side application, capturing a small number of frames from the DSP, and all of the data looks good. When we run our application on the HOST side that is processing video, and capturing this audio data from the DSP, we start getting what appears to be channel skipping in the data coming from the DSP. We have been able to verify that this is what is happening by putting fixed data into the 16 McASP channels and capturing the output data to a file on the HOST side. We can find in the output files where it will start writing the data for a channel and after the first sample, it is writing the data from some other channel. The timing for when this happens is not periodic, in fact it varies depending on whether we are passing video or not. The channel that it skips to is also not fixed. We use VPSS, OMX, etc. for processing the video, and the frequency at which this channel skipping happens is dramatically higher than when we shut our video chains down. As I said, it appears to be skipping channels, as we never get any kind of garbage data in the output. The data is always valid channel data, just not on the channel it should be on. The only fact that we have found that is consistent, is that when it skips channels, it always does it after the first sample. Are we pushing the limits on the part. Any suggestions or pointers would be appreciated.
Thanks,
Duncan