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

[Paul Olaru]

It's hard to check for this because the data is transferred correctly after the beginning,
the problem only occurs at the very beginning. I will see what I can do with that.

Will look into the linked situation. However I'd guess that I'll only see discontinuities
at the very beginning (first few ms) and when the ARM core lags and causes underruns.
The latter is of course normal.

I'll see what I can do. If I indeed find an issue, I will post it (even if it comes from my own
drivers, I will still probably need help investigating).

-----Original Message-----
From: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com> 
Sent: Wednesday, December 4, 2019 10:01 PM
To: Paul Olaru <paul.olaru at nxp.com>; sound-open-firmware at alsa-project.org
Subject: [EXT] Re: [Sound-open-firmware] How to check first frames on playback

Caution: EXT Email

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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fthesofproject%2Fsof%2Fissues%2F1215&data=02%7C01%7Cpaul.olaru%40nxp.com%7Ce14bf677d2ef4c25b0d408d778f4c15a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637110864919842504&sdata=A8flz5y7DXuT914qkQCkhYJdk03wEpJiYIP1ojuN%2FaY%3D&reserved=0

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.