Art, On Friday 26 February 2010, Arthur Taylor wrote: > 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.
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, Frank -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
