Hello. Sorry for the week of delay, deadlines came and went. This may also be easier to do if I was closer to the timezones in Europe.
On Sun, Feb 28, 2010 at 11:57 PM, Frank Mehnert <[email protected]> wrote: > 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. > > > 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). The easy way to fix the loss of brief sounds is to make the requested prebuffer size small (smaller than the buffer_attr->tlength target buffer length value) as that would lessen the probability that data written would be smaller than the prebuffer, stalling playback start. That said, the prebuffer size is only requested and ultimately decided by the server and can change over the connection's lifetime. Such a fix would return to corking and flushing on device close. Also note that it is more correct to cork then flush than the other way around. This is the most correct way IMHO. The other way is not to use a prebuffer, which is close to what normal hardware does, playing silence when the buffer underflows. I can write a patch with that behavior for testing purposes, but I've experienced out-of-sync server side buffers with that code before and crashes with older server versions. The method of trying to trigger the playback after 50ms sounds a bit difficult as pulse's api doesn't provide facility for it, requiring something custom. Cheers -Art -- Arthur Taylor [email protected] [email protected] _______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
