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