ALSA/Audio overrun errors on with 8168/Linux (EZSDK 5.02/5.03).

Hello everyone,

We've noticed that there has been some on and off activity on the topic of 'ALSA/Audio overrun errors'
in the forums but no definitive solution or workaround that we've seen. We are using the TI8168 on our product
to do video and audio capture and we're getting audio overruns reported at the high level application layer.

We've already cross-posted this DM816x, C6A806x, and AM389x Processors Forum but there's been no
traction there so far. (See http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/194561.aspx ).

Our questions are:

  Question 1) What's causing this?

  Question 2) How can we fix it or work around it?

We've recently had a chance to start looking into this problem with the audio capture
application which is loosely based on the audio_encode application delivered with earlier
SDKs for the TI8168 EVM (initially with EZSDK 5.02/5.03).

In particular, the problem is coming from the the A8-side capture of audio via the ALSA subsystem
and is not related to the DSP or the encoding of the audio samples.

We've managed to track the location to the linux kernel file:

    $KERNEL/sound/core/pcm_lib.c (at approximately line #437).

Specifically, when the problem occurs, the check for:

    if (delta > runtime->period_size + runtime->period_size / 2) { /*** ... ***/ }

is being flagged in the function snd_pcm_update_hw_ptr0(...).

Since there's an actual check for this in the kernel [note the "Lost interrupts?" hw_ptr_error()
condition] it seems like someone must have noticed this too and at least tried to detect it.

Things we've tried but that didn't work:

We've tried getting rid of the video capture to see if it was a CPU loading issue
on the A8 (i.e.: removed the OpenMax video components execution from the A8 side)
with no change in the symptoms. Switching to an audio capture sample rate of 16kHz helps but
we'd like to understand why we're not getting the data we're expecting reliably, not even at 16kHz.

We've tried bumping up the priority of the audio capture task which also helps but we
still get the overruns.

We've tried running the audio data transfer with a different asp_chan_q
(EVENTQ_0 vs EVENTQ_1 vs EVENTQ_2) to see if it makes any difference. (It didn't.)

The forum traffic seems to implicate McASP/DMA interrupt issues. Since we've "peeled-off" most of
everything else and we still see this it is becoming a concern for the project. We would really
like to have our audio capture sampling frequency at 48kHz if we can get it to work reliably.

   Question 3) Is there any tweaking/tuning that we may be missing?

Thanks for reading and we would appreciate any insights anyone may have.

Juan Solis