[vbox-dev] PulseAudio support rewrite [Patch]

[Arthur Taylor]

On Fri, Feb 26, 2010 at 1:05 AM, Frank Mehnert <Frank.Mehnert at sun.com> wrote:
> The order of sequences is normally like this:
>
>  1. the guest user application wants to play a short sound
>     and calls the proper guest sound system function
>  2. the guest sound system unpauses the sound card
>  3. the guest sound system plays the short sound sequence
>  4. now the guest sound system waits for a short amount of time
>     for more audio date (for instance WinXP waits for about 2-3
>     seconds)
>  5. the guest sound system pauses the sound card

I've done some more investigating into this issue. The log of events
you list above is most certainly correct, however there are some
nuances to the way the pulse backed behaves. The only form of
synchronization with the guest is how much space is available to
write. When a short sound is played while nothing else is played, if
it can fit in the pulse buffer's target length pulse will eat all the
sound data at once. To the guest this appears like the hardware has
played target length of data in 0ms. Happy that all of it's short clip
has been played (when really it is buffered and playback hasn't
started) the guest stops the device. Assuming this operation to be
brief the Windows explorer ui appears to block on it. This is what
creates the bug people were reporting. The normal wait for audio to
play guest routine runs instantly while the close the device routine
blocks until the buffer is drained.

I do however have a fix for consideration. Once again this returns to
triggering and draining before corking on the close, but this time the
drain and cork doesn't block the device close routine.

Cheers
-Art

-- 
Arthur Taylor
art at ified.ca
theycallhimart at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pulseaudio-drain-2.patch
Type: application/octet-stream
Size: 5617 bytes
Desc: not available
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20100226/268e9659/attachment.obj>