[pulseaudio-discuss] Playback pauses

[Dmitri Paduchikh]

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