[alsa-devel] iMX233 audio capture: glitches on task switch?

[Gilles Grégoire]

Dear alsa developers,

I need help debugging a driver for the builtin codec of Freescale's iMX233 SoC.

I am facing an issue when capturing audio: garbage data (glitches)
appears periodically in the recorded audio data. Audio playback looks
fine, as far as I can tell.

I am using kernel 3.13.6. A driver by Freescale exists for a 2.6.35
kernel but it was never submitted to mainline. Therefore, the driver I
use is a port of Freescale's driver to kernel 3.13.6 by Michal
Ulianko. You can find it in the attached patch+dts. Please note that
this is still a work in progress.

The driver is actually quite simple: it simply sets up the codec/cpu
DAI and uses the generic dma engine through
snd_dmaengine_pcm_register() to make the audio run.

I am using arecord to capture the audio from the default input (the
mic), which is _not_ connected in my setup. The command line I am
using is the following:
$ arecord --disable-format --disable-resample --fatal-errors
--disable-channels --buffer-size=32768 --period-size=4096 -r 22050 -f
S16_LE -c 2 -d 1 /tmp/test.wav

What happens: the recorded audio data contains glitches at periodic
intervals which contain garbage data. No underrun/overrun occurs
during capture.

I suspect that the problem is not in the driver's code itself, but
could be the symptom of a bug somewhere else (possibly in mxs dma
code), because of the following observations I did:
 * there are 2 kind of glitches: short (~3 samples) and long (~25
samples) depending on the kernel configuration. Both kinds may exists
on the same capture.
 * short glitches exist only with CONFIG_HZ_PERIODIC=y. The period of
those glitches is _exactly_ 4ms, which corresponds to the HZ value in
my kernel config (250Hz).
 * long glitches are always there. The period of those glitches is
directly related to the --period-bytes parameter of arecord: halving
the --period-bytes parameter halves the period of the glitches.

You can find attached a screenshot showing the glitches for the
"dynticks" case (where only long glitches exist) and for the "periodic
timer" case (where both kinds are visible).

These observations lead me to believe that the glitches are related to
task switching. Here is my best guess:
 * the short glitches come from the HZ tick invoking the scheduler.
 * the long glitches come from the kernel code waking up the arecord
process when enough audio data was received.

I spent a long time trying to narrow down the problem with no success.
My main problem is that I have no idea what kind of bug could cause
these symptoms.
This is where I need help: I would welcome any advice on what to look for.

Best regards,

-- Gilles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-01-audio.patch
Type: text/x-patch
Size: 94162 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140412/efef58ad/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imx233-audio.dts
Type: application/octet-stream
Size: 3291 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140412/efef58ad/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imx233-short-long-glitches.png
Type: image/png
Size: 47476 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140412/efef58ad/attachment-0001.png>