We have developed a device based on the iMX.28 evk with some modifications, which includes TAS5760 audio codec.
We also based on the L2.6.35_1.1.0_130130 BSP, where ltib tool is used to build the image.
On top of that we run our application which uses audio device on top of the alsa-lib 1.0.14 (included in the BSP).
After some long audio tests (hours), the audio stalls. Irrecoverably. We tried to avoid the stall using alsa-lib API in different ways(see below), closing and opening the sound device (snd_pcm_close/snd_pcm_open) and even killing the application and starting it over. The only way to recover sound is restarting the whole system.
This is the sound configuration dump(from alsa-lib) in one of our latest tests.
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 16384
period_size : 2048
period_time : 42666
tstamp_mode : NONE
period_step : 1
avail_min : 2048
period_event : 0
start_threshold : 16384
stop_threshold : 16384
silence_size : 0
boundary : 1073741824
state : PREPARED
tstamp : 30989.487253764
delay : 0
avail : 16384
avail_max : 0
Our audio routine is called every 100ms approximately. When there's audio to play we check (snd_pcm_avail) if there's room in the audio ring buffer to inject samples, if not we wait for next call. We write sample chunks while there's room enough in the audio ring buffer. We do some basic error checking to handle underrun or audio readiness (snd_pcm_state). Also, it's usual that audio needs to be stopped, in that case we call snd_pcm_drop.
Once we started the test, unpredictably, audio stalls. It may take from 30 minutes to 10 hours. When audio stalls, what we see is that snd_pcm_avail always returns 0 (or a very low value), snd_pcm_state returns 3 SND_PCM_STATE_RUNNING but no audio can be heard. At this point we can see through /proc/interrupts that MXS PCM DMA channel interrupt count also stalls, it doesn't increase.
Shortly before this point, when audio still worked, we had an empty audio ringbuffer, audio routine filled the audio ring buffer till there was no more room for a new audio chunk. When the audio behaved correctly, the ring buffer space increased when audio routine was called again, meaning that audio was send to the codec.
In case it helps, rarely kernel throws a message like:
klogd: [ 5129.800000] mxs_pcm_dma_irq: DMA audio channel 20 (mxs-saif-0) error
From the userspace point of view, we tried using SND_PCM_ACCESS_MMAP_INTERLEAVED and SND_PCM_ACCESS_RW_INTERLEAVED modes. We also tried using snd_pcm_avail_update as oposed to snd_pcm_avail. None of these tests changed audio behaviour.
We would appreciate some directions to solve the issue.
Original Attachment has been moved to: xrun.zip
Original Attachment has been moved to: hw_ptr-skip_lost-interrupt.zip
Original Attachment has been moved to: appcrash_reboot.zip
Original Attachment has been moved to: lost-interrupt.zip