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@alsa-project.org On Behalf Of Paul Olaru Sent: Thursday, December 5, 2019 7:00 PM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; sound-open- firmware@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@linux.intel.com Sent: Wednesday, December 4, 2019 10:01 PM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@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@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware