What is the meaning of fragments and fragment_size in PulseAudio ALSA modules?

Question

Following advice on a blog post called Pulseaudio And Latency, I tried loading module-alsa-sink with special fragments and fragment_size parameters to ensure low latency. However, I'm not sure what exactly these are doing. The latency reported by pactl list sinks doesn't have an obvious correspondence to the values I put in these parameters. Here's a short script I wrote to test various settings:

pulseaudio &

# unload all sinks
pactl list sinks | grep "Owner Module" | \
    cut -d : -f 2 | \
    while read i; do
        pactl unload-module $i;
    done

# try different settings
patest () {
    pactl load-module module-alsa-sink device=$DEV \
          tsched=no \
          fixed_latency_range=yes \
          fragments=$F fragment_size=$FS > /tmp/modnum.out;
    pactl list sinks | grep Latency;
    pactl unload-module $(cat /tmp/modnum.out)
}
patest_nofix () {
    pactl load-module module-alsa-sink device=$DEV > /tmp/modnum.out;
    pactl list sinks | grep Latency;
    pactl unload-module $(cat /tmp/modnum.out)
}

Now I can try various settings of fragments (F) and fragment_size (FS). For the hardware device "hw:0" the latency is low but I can't see how it corresponds to the two parameters:

F=1; FS=15; DEV=hw:0; patest
#        Latency: 2516 usec, configured 1451 usec
F=1; FS=30; DEV=hw:0; patest
#        Latency: 2484 usec, configured 1451 usec
F=5; FS=15; DEV=hw:0; patest
#        Latency: 2475 usec, configured 1451 usec
F=50; FS=200; DEV=hw:0; patest
#        Latency: 57628 usec, configured 56689 usec

# (default minimum latency:)
DEV=hw:0; patest_nofix 
#        Latency: 1983968 usec, configured 2000000 usec

For the "dmix" ALSA device it is a bit higher, not sure why:

F=1; FS=15; DEV=dmix; patest
#        Latency: 42752 usec, configured 42666 usec

# (default:)
DEV=dmix; patest_nofix
#        Latency: 326596 usec, configured 341333 usec

However, when I create my own "dmix" device to output to hw:0,

$ cat ~/.asoundrc
...
pcm.hw0mix {
    type dmix
    ipc_key 2498 # unique random number
    slave {
        pcm "hw:0,0"
        channels 2
        rate 48000
    }
}

then I can see that the latency is much higher and seems fixed at 0.25 seconds:

F=1; FS=15; DEV=hw0mix; patest
#        Latency: 251132 usec, configured 250000 usec
F=50; FS=200; DEV=hw0mix; patest
#        Latency: 251126 usec, configured 250000 usec

# (default:)
DEV=hw0mix; patest_nofix
#        Latency: 356292 usec, configured 375000 usec

What is the relationship between the parameters fragments and fragment_size, and the "configured latency", and how do I change the configured minimum latency to be lower even for non-hardware ALSA devices?

Answer 1

For an explanation of fragments/periods please see https://www.alsa-project.org/wiki/FramesPeriods and see also https://juho.tykkala.fi/Pulseaudio-and-latency for Pulseaudio tuning tips.

Pulseaudio also does mixing, so you might have some duplication in your setup by using it in conjunction with dmix.

dmix uses the ALSA plugin layer, so it will always add some latency. For the lowest possible latency, you can use hw: devices directly and mix sources on the analogue side.

However, with the right system configuration it should be possible to use dmix as an alternative to pulseaudio and keep latency unnoticeable for most purposes. 251ms is excessive, it should be possible to get much, much lower than that with dmix.

The tool https://github.com/raboof/realtimeconfigquickscan might be useful to identify any aspects of your system configuration causing excessive latency.