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.
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 audio capture
overrun errors being reported from our application which is loosely based on
the audio_encode application delivered with earlier SDKs.
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.
We've tried running the audio data transfer with a different asp_chan_q
(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.
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
