[Sound-open-firmware] How to check first frames on playback

[Pierre-Louis Bossart]

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.