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