[alsa-devel] Hang in snd_pcm_writei with alsa-pulse plugin

[Raymond Yau]

2010/11/1 Matthew Gregan <kinetik at flim.org>

> Hi,
>
> I think I'm seeing a bug in the alsa-pulse plugin where the buffer
> management ends up corrupt and results in a deadlock waiting for free
> buffer
> space.  This occurs when resuming from pause using snd_pcm_pause.  After
> resuming, my application tries to write a fixed block of data, expecting
> snd_pcm_writei to block if the data is larger than the available buffer
> size
> (the result of snd_pcm_avail_update).
>
> I originally observed this in the wild in Firefox, which pauses and resumes
> the sound device whenever network buffering occurs.  I'm planning to
> include
> the workaround mentioned below in the next Firefox release (Mozilla bug
> 573924).
>
> What happens is that, after resuming with snd_pcm_pause, a call to
> snd_pcm_writei never returns.  This happens on the write call that would
> have exceeded the available buffer size, which I would expect to block only
> until sufficient buffer space became available.
>

It depend on whether pulse_write wait until all requested frames are played
or just put to the playback ring buffer

especailly when your program write audio more than the available free buffer
space

http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.htm

If the blocking behaviour is selected and it is running, then routine waits
until all requested frames are played or put to the playback ring buffer.
The returned number of frames can be less only if a signal or underrun
occurred.

If the non-blocking behaviour is selected, then routine doesn't wait at all.







>
> It's possible to get into a similar situation using SND_PCM_NONBLOCK and
> waiting on the sound device if it returns EAGAIN, except that
> snd_pcm_writei
> always returns EAGAIN and snd_pcm_wait returns 1 immediately, resulting in
> a
> tight loop in the calling code.
>
> I discovered that I can reliably workaround the problem by ensuring the
> first writes after resuming from pause are never larger than what
> snd_pcm_avail_update returns.  After writing enough to fill (but not
> exceed)
> the available buffer size, the code returns to the fixed buffer size per
> write strategy and continues as normal.
>
> The problem occurs with the following stack:
>
> #0  __poll (fds=<value optimized out>,
>    nfds=<value optimized out>, timeout=<value optimized out>)
>    at ../sysdeps/unix/sysv/linux/poll.c:87
> #1  snd1_pcm_wait_nocheck (pcm=0x1b9a780, timeout=-1)
>    at pcm.c:2367
> #2  snd1_pcm_write_areas (pcm=0x1b9a780,
>    areas=0x7fff4ce9b890, offset=<value optimized out>, size=30000,
>    func=0x339ba91d10 <ioplug_priv_transfer_areas>) at pcm.c:6655
> #3  snd_pcm_ioplug_writei (pcm=0x1b9a780,
>    buffer=<value optimized out>, size=30000) at pcm_ioplug.c:561
> #4  bwrite (pcm=0x1b9a780, towrite=30000) at
>    atest2.c:29
> #5  main (argc=1, argv=0x7fff4ce9ba68) at atest2.c:86
>
> I'm Fedora 13 x86_64 with all updates from updates-testing.  ALSA is
> 1.0.22-1, PulseAudio is 0.9.21-6, and the kernel is 2.6.34.7-61.  I've also
> tested against the current git versions of alsa-libs and alsa-plugins and
> can still reproduce the problem.
>
> I've attached a simple test program that reproduces this problem reliably
> on
> my machine.  It writes a period sized buffer in a loop, waiting half a
> period until the next attempt.  Every few iterations, it pauses the sound
> device for half a period and then resumes it.  It usually hangs within 2-3
> pause/resume cycles.  Running the test with "-r" enables the recovery code
> I
> mentioned above.  It never hangs when tested using the hardware ALSA
> backend
> with alsa-pulse disabled, but my sound hardware doesn't seem to support
> snd_pcm_pause.
>
> Cheers,
> -mjg
> --
> Matthew Gregan
>
>