Re: handling of underrunning snd_pcm_writei

[Takashi Iwai <tiwai@suse.de>]

At Thu, 12 Nov 2009 15:01:15 +0100,
Mads Kiilerich wrote:
> 
> 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.

Hm, not now, as I've been too busy for other things.
Will take a look at this issue later.


thanks,

Takashi