On 12/4/19 8:25 AM, Paul Olaru wrote:
What is a good way to check that the first frames when starting playback with a file are correct and not reordered or repeated? I have tried to modify my host DMA driver to dump the frames as it transfers them and I see that the data transferred is the same as in the file but the first two frames are reordered and repeated, at least when I set the buffer size to be very small in aplay (--buffer-size=96). My test is to attempt to play a 768-byte raw file (2 channels, S16_LE) and dump all the data transferred by my host DMA driver. From the dumps (within the limits of etrace; I don't have DMA trace working as I didn't focus on that) I notice that several of the frames within the first period (first 384 bytes) end up being repeated and in the wrong ordering.
The issue is unimportant with uncompressed playback as that would just be a small, 2ms glitch which is hardly audible, especially if you also have a volume ramp or the file is silent or mostly silent in the beginning. However, I want to implement support for compressed playback at some point which requires such glitches to not happen with the data before it even enters the pipeline (any bit change will cause corruption which is definitely audible or even failure of the decoding algorithm).
So how should I check that the first few frames during playback are actually the correct ones?
For this kind of issues where the DMA takes the wrong buffer, I found it very efficient to create a custom PCM file with a sawtooth pattern on one channel, looping between e.g. 0 and 1023. You can then use an analyzer (I use Logic Pro) to capture the SAI data, export to excel and run a filter to highlight any discontinuities.
see e.g. https://github.com/thesofproject/sof/issues/1215
If you want to be smarter you can also use a PRBS generator with a well-known polynomial, e.g. the AES3S/SoundWire one. The drawback is that you lose 8 samples at the beginning while the detector catches up and fills its history buffer.