Humm. The reason there was a call to pa_stream_drain there is that windows likes to open the device, play a very short sound (like the click noise when you enter directories) and the close the device right away again. This causes a stream uncork, stream write, stream cork and then stream flush. The problem with this is that pulseaudio waits for at lease buffer_attr->prebuf bytes to be written before starting playback^1. If less than prebuf data was written, playback never starts and the buffer gets flushed. In the close routine causing a trigger and a drain solved this as it ensure that if playback wasn't started that any written data would still be played before corking again. The bug that this fixed was that without it the directory click noises and other very short sounds disappeared. Note that how short is too short is up to the prebuf length the pulse server gives us. Virtualbox uses Pulse's asynchronous API and there is a second thread, therefore it may be possible to retain the drain while not blocking. I'll look into this more this evening.
Cheers -Art Footnote: 1 - Setting the requested prebuf to 0 results in no prebuffering mode where pulse plays silence on underrun. This sounds desirable but in my experience it never works as expected, as it can result in larger latencies if you feed too slowly. Also, on old versions of pulseaudio, switching from silence to data back to silence often caused server crashes. On Thu, Feb 25, 2010 at 3:52 AM, Frank Mehnert <[email protected]> wrote: > One followup here: It turns out that this rewrite caused a regression: > There were some reports that especially Windows guests freeze for a > short amount especially when doing some Explorer operations (e.g. click > into a subfolder). The reason is that Windows guests pause the sound > device after a short amount of time. The PulseAudio backend drained the > pending frames to the sound device in this case. The problem should be > fixed in r26783. > -- Arthur Taylor [email protected] [email protected] _______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
