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