[vbox-dev] PulseAudio support rewrite [Patch]

Frank Mehnert Frank.Mehnert at Sun.COM
Sun Feb 28 23:57:22 PST 2010


On Friday 26 February 2010, Arthur Taylor wrote:
> On Fri, Feb 26, 2010 at 1:05 AM, Frank Mehnert <Frank.Mehnert at sun.com> 
> > 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.

Note that I've debuggged the sequence and the guest will certainly
wait for 2-3 before it pauses the audio device! You are right that
the guest assumes that the pausing is very brief -- actually the
guest writes to an I/O port and the I/O operation wouldn't return
until the operation is done.

> 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.

That fix goes into the right direction but again, note that we have
to drain the buffer earlier -- _before_ the guest pauses the sound device
because otherwise, short sound sequences will be delayed for the time
the guest waits until the sound device is paused. So I think we really
need to introduce a timer which triggers a drain after a short amount of
time (perhaps 50-100ms).

Kind regards,

Dr.-Ing. Frank Mehnert

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels
Vorsitzender des Aufsichtsrates: Martin Häring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://www.virtualbox.org/pipermail/vbox-dev/attachments/20100301/83a22c41/attachment-0001.bin 

More information about the vbox-dev mailing list