[alsa-devel] handling of underrunning snd_pcm_writei
Mads Kiilerich
mads at kiilerich.com
Thu Nov 12 15:01:15 CET 2009
On 11/12/2009 01:10 PM, Mads Kiilerich wrote:
> On 11/12/2009 08:12 AM, Takashi Iwai wrote:
>> Yes, snd_pcm_recover() is *recommended*. You can write the recovery
>> routine by yourself. The function isn't referred here just because
>> it's relatively new. Better to be documented, indeed.
>
> Thanks a lot for you answer, Takashi. That was very helpful.
>
> But when I hack pcm_min.c to log the state at the beginning of the loop
> and then enforces an underrun by pausing the program then it sometimes
> locks up:
>
> $ ./pcm_min
> state 2 SND_PCM_STATE_PREPARED
> state 2 SND_PCM_STATE_PREPARED
> Short write (expected 16384, wrote 7616)
> state 3 SND_PCM_STATE_RUNNING
> state 3 SND_PCM_STATE_RUNNING
> state 3 SND_PCM_STATE_RUNNING
> state 3 SND_PCM_STATE_RUNNING
> [ctrl-s ... waiting for silence ... ctrl q]
> ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured
> state 2 SND_PCM_STATE_PREPARED
> state 2 SND_PCM_STATE_PREPARED
> state 3 SND_PCM_STATE_RUNNING
> [hanging in snd_pcm_writei]
>
> It seems like pcm_min.cs use of snd_pcm_recover isn't enough to recover
> fully? The playback never gets started again, so the async writes in
> PREPARED succeeds, but the first blocking write hangs waiting forever?
> What is missing?
It seems like the lockup always happens in SND_PCM_STATE_RUNNING after
snd_pcm_avail_update has reported values > 9000. Usually it returns < 8000.
Any idea?
/Mads
More information about the Alsa-devel
mailing list