On Tue, 2013-02-12 at 22:52 +0600, Dmitri Paduchikh 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. > Is the maximal value > configurable or is only calculated from the buffer size in kernel? It's configurable, to some extent. By default, the alsa modules are loaded by module-udev-detect. You can't configure the maximum latency if you use module-udev-detect (there's no reason why it couldn't be configurable also in that case, but there just hasn't been need for implementing that). If you don't use sound card hotplugging, module-udev-detect is not necessary. You can comment out module-udev-detect loading in /etc/pulse/default.pa, and replace it with this command (or several similar ones, if you have multiple sound cards): load-module module-alsa-card device_id=0 tsched_buffer_size=65536 The device_id parameter is the sound card index, as listed in /proc/asound/cards. The tsched_buffer_size parameter is the sink buffer size in bytes, which determines the maximum latency, and which you can choose freely. The kernel configuration determines the upper bound. 65536 matches the default kernel configuration of 64 kilobytes. -- Tanu
