Tanu Kaskinen wrote: > 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. Well, it's still not clear why it is implemented to follow this logic but I think I can do without full understanding for now since your suggestion below helped to solve my problem. Thank you! >> 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 Yes, this helps! Thanks! > 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. I guess that even if the upper bound is determined by the kernel configuration, it is not CONFIG_SND_HDA_PREALLOC_SIZE, since that is set to 4096 in my system whereas device.buffering.buffer_size was 352800. -- With best regards Dmitri Paduchikh
