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

[Jie, Yang]

Usually I use one of below 2 methods to debug this kind of issues:
1. use trigger mode of scope with probing the SDO pin of the SSP port.
2. use LBM of the SSP port, run capture first and then playback, check the captured .wav file.

Thanks,
~Keyon

>-----Original Message-----
>From: Sound-open-firmware <sound-open-firmware-bounces at alsa-project.org>
>On Behalf Of Paul Olaru
>Sent: Thursday, December 5, 2019 7:00 PM
>To: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>; sound-open-
>firmware at alsa-project.org
>Subject: Re: [Sound-open-firmware] [EXT] Re: How to check first frames on
>playback
>
>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.co
>m%2Fthesofproject%2Fsof%2Fissues%2F1215&data=02%7C01%7Cpaul.olar
>u%40nxp.com%7Ce14bf677d2ef4c25b0d408d778f4c15a%7C686ea1d3bc2b4c6fa
>92cd99c5c301635%7C0%7C0%7C637110864919842504&sdata=A8flz5y7DX
>uT914qkQCkhYJdk03wEpJiYIP1ojuN%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.
>_______________________________________________
>Sound-open-firmware mailing list
>Sound-open-firmware at alsa-project.org
>https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware