> > Hmm, in my case the upper bound in this range is 1837,50 ms. May be this > > explains huge pauses. Though I'd expect that command-line option > > --latency-msec=50 should change the used latency. > > The reason why that doesn't work is probably that when the last byte of > the stream buffer is copied to the sink buffer, the sink latency is set > back to about 2 seconds, but the stream is not considered yet finished, > because the data is still in the sink buffer, not yet out of the > speakers. Thus, there will be roughly 2 seconds before the sink requests > more data, and this is the event that triggers the notification that the > stream has now definitely finished. Does this mean pulse client did not send a drain signal for the server to end the playback stream ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20130213/13763106/attachment.html>
