On Wed, 2013-02-13 at 09:49 +0800, Raymond Yau wrote: > > > 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 ? No. The problem that we're talking about is that the client sends a drain request, but a reply to that arrives later than expected. -- Tanu
