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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
