On Fri, Feb 26, 2010 at 1:05 AM, Frank Mehnert <[email protected]> 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 [email protected] [email protected]
pulseaudio-drain-2.patch
Description: Binary data
_______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
