According to the article, PA works in two modes, with tsched=0 it's the old IRQ-driven mode as ALSA does and it heavily relies to the fragments number and size. Hence it gets ALSA underruns if the app is too slow to fill the buffer. It happens to my work PC sometime because it isn't too fast (model name: Intel(R) Pentium(R) CPU G620 @ 2.60GHz) and I mostly listen to music in Chrome (HTML5 audio). Chrome has the latency of ~65 ms now. It's quite feasible that some program would occupy the CPU for this much time so I'd have a skip/underrun. In case of tsched=0 there's nothing we can do as period/buffer size is set up on startup and basically can't be changed in runtime.
When tsched=1 or not specified (defaults to 1) PA sets up an ALSA buffer of 2 seconds long with two periods of 1 second each. This way it doesn't underrun in ALSA but rather underruns in PA itself. This code is responsible for tweaking the watermark and latency: https://github.com/pulseaudio/pulseaudio/blob/master/src/modules/alsa/alsa-sink.c#L326
The problem here is that watermark can go in both directions, up and down, while latency can only grow until the sink is reset (recreated). This actually means that if some particular program has chosen too little latency and had several underruns because of that, THE WHOLE LOT OF OTHER PROGRAMS now will suffer bad latency as well! And there's no other way to lower it back other than restarting PA itself together with all its clients or when PA gets unsuspended ( https://github.com/pulseaudio/pulseaudio/blob/master/src/modules/alsa/alsa-sink.c#L1021 ).
And also, I repeat, launching pavucontrol for the first time and sometimes pacmd list-sinks causes stuttering on my work system (works ok at home but there I have i7-2600 and PCI SB Live 7.1). I don't know how and why but they seem to block PA somewhere so that Chrome can't sink its audio to it in time and hence we get an underrun, latency increase and the bad mood. I dunno, maybe I have to file this pavucontrol bug separately.
So I've done some research. This article describes the timer model and how ALSA works in regards of periods/fragments and software/hardware buffers: http:// 0pointer. de/blog/ projects/ pulse-glitch- free.html
According to the article, PA works in two modes, with tsched=0 it's the old IRQ-driven mode as ALSA does and it heavily relies to the fragments number and size. Hence it gets ALSA underruns if the app is too slow to fill the buffer. It happens to my work PC sometime because it isn't too fast (model name: Intel(R) Pentium(R) CPU G620 @ 2.60GHz) and I mostly listen to music in Chrome (HTML5 audio). Chrome has the latency of ~65 ms now. It's quite feasible that some program would occupy the CPU for this much time so I'd have a skip/underrun. In case of tsched=0 there's nothing we can do as period/buffer size is set up on startup and basically can't be changed in runtime.
When tsched=1 or not specified (defaults to 1) PA sets up an ALSA buffer of 2 seconds long with two periods of 1 second each. This way it doesn't underrun in ALSA but rather underruns in PA itself. This code is responsible for tweaking the watermark and latency: https:/ /github. com/pulseaudio/ pulseaudio/ blob/master/ src/modules/ alsa/alsa- sink.c# L326
The problem here is that watermark can go in both directions, up and down, while latency can only grow until the sink is reset (recreated). This actually means that if some particular program has chosen too little latency and had several underruns because of that, THE WHOLE LOT OF OTHER PROGRAMS now will suffer bad latency as well! And there's no other way to lower it back other than restarting PA itself together with all its clients or when PA gets unsuspended ( https:/ /github. com/pulseaudio/ pulseaudio/ blob/master/ src/modules/ alsa/alsa- sink.c# L1021 ).
I haven't found a way to setup a default minimal latency so that if I know that my system isn't capable to deliver 4 ms, I can set it to 16 instead of having 0.5 ms and several underruns just to let PA get to that latency by itself. It seems to me that this minimal latency is just hardcoded ( https:/ /github. com/pulseaudio/ pulseaudio/ blob/master/ src/pulsecore/ sink.c# L54 ) and there are no tools to call pa_sink_ set_latency_ range ( https:/ /github. com/pulseaudio/ pulseaudio/ blob/master/ src/pulsecore/ sink.c# L3091 )
And also, I repeat, launching pavucontrol for the first time and sometimes pacmd list-sinks causes stuttering on my work system (works ok at home but there I have i7-2600 and PCI SB Live 7.1). I don't know how and why but they seem to block PA somewhere so that Chrome can't sink its audio to it in time and hence we get an underrun, latency increase and the bad mood. I dunno, maybe I have to file this pavucontrol bug separately.