For a streamer, audio latency is not an abstract number. It is the delay between your mouth moving and your voice reaching the broadcast, the gap that makes game audio feel disconnected from the action, and the offset that turns a live instrument into an unplayable echo of itself. PulseAudio, the sound server still common on many Linux streaming boxes, adds latency through its buffering: chunks of audio held in memory to smooth over scheduling hiccups. Bigger buffers mean fewer dropouts but more delay. Smaller buffers mean tighter sync but a higher risk of crackles when the system gets busy. Tuning those buffers is the difference between a stream that feels live and one that feels dubbed.
Where the latency actually lives
Every hop in the audio path holds some audio in a buffer: the application, the sound server, and the hardware driver each keep a queue. PulseAudio's contribution is governed by two settings that work as a pair. The fragment count sets how many chunks the buffer is divided into, and the fragment size sets how long each chunk is in milliseconds. Total server-side latency is roughly the product of the two. The defaults lean conservative, prioritizing dropout-free playback on unknown hardware over tight timing, which is exactly backwards for a streamer monitoring their own voice or mixing live sources. Knowing that the delay is a configured choice rather than a fixed property of your hardware is the first step, because it means you can trade stability margin for speed deliberately instead of suffering the default.
Setting server-wide buffer defaults
The global buffer behavior is configured in the PulseAudio daemon configuration, where you set the default fragment count and fragment size for all streams. For streaming work, a reasonable starting point is in the neighborhood of four fragments of around ten milliseconds each, giving roughly forty milliseconds of server buffering. That is tight enough to keep voice monitoring usable while leaving enough cushion for a system that is also encoding video. Edit the configuration, restart the daemon, and then measure rather than guess. If you hear periodic crackles or see underrun messages in the logs, the buffers are too small for what the machine is doing, and the fix is to grow the fragment size a little, not to abandon the tuning. Change one variable at a time and listen for a full streaming session before changing it again, because buffer problems often show up only under sustained load.
Per-application latency overrides
You do not have to give every application the same latency budget. PulseAudio lets individual applications request their own latency, and the environment variable for it lets you tune a single program without touching the global defaults. This is useful when one source needs tight timing, like a microphone you monitor live, while another is perfectly happy with deep buffering, like background music playback. Launch the latency-sensitive application with a modest requested latency, in the tens of milliseconds, and leave everything else on the defaults. The sound server negotiates the actual value with the hardware, so treat your request as a target and verify what was actually granted. Applications that ignore the hint entirely will simply run at the server default, which is fine as long as you know which of your sources those are.
The timer-based scheduling toggle
PulseAudio can drive audio with timer-based scheduling, where it wakes up on a timer to feed the hardware, or with the older interrupt-driven model. Timer-based scheduling generally allows lower latency with fewer wakeups, which is why it is the default, but on some hardware and driver combinations it interacts badly and produces the exact glitches you are trying to eliminate. If your tuned buffers still crackle despite generous sizing, disabling timer-based scheduling for the problematic device is a legitimate diagnostic step. When the crackles vanish, you have learned something specific about your hardware rather than something vague about latency. Document which devices need the exception, because this is exactly the kind of setting that gets lost in a reinstall and then costs you an evening of confused re-tuning a year later.
Measuring instead of guessing
Ears are good detectors but bad measuring instruments, and latency tuning without measurement drifts into superstition. PulseAudio ships with simple tools that report the actual latency of a stream, and there are loopback techniques where you play a click out of one device and record it on another to measure the round trip through the whole chain. Measure the baseline before you change anything, then measure after each change. You are looking for two numbers: the steady-state latency during a realistic streaming load, and whether any underruns occurred during the session. A configuration that measures well for five minutes and crackles at minute forty under thermal throttling is not a good configuration. Run your tests at the load you actually stream at, with the encoder running and the game or instruments live.
When the tradeoff will not balance
Sometimes no buffer setting gives you both clean audio and low latency, and that is information, not failure. It usually means something else in the system is stealing the CPU time that audio needs: a software encoder running on too few cores, a USB device sharing a congested bus, or a power management policy that parks cores aggressively. Buffers can hide scheduling jitter but they cannot fix a system that fundamentally cannot deliver audio on time. Before concluding that your latency target is unreachable, check system load during a stream, try a different USB port or bus for the audio interface, and consider whether the encoding workload belongs on hardware acceleration. The buffer settings are the last mile of latency tuning. The first miles are making sure the machine has the headroom to do the work at all.
Tune PulseAudio buffers as a deliberate tradeoff: fragments and fragment sizes set the delay, per-application overrides protect the sources that need speed, and measurement keeps you honest. Start near forty milliseconds of server buffering, verify with real streaming load, and grow the buffers only as far as the crackles demand. Your viewers will never know the numbers. They will just feel that the stream is live.
Related Guides
- ALSA Audio Buffer Tuning on Linux Centers: Audio dropouts on a Linux media center, the tiny clicks, pops, and gaps that ruin music and dialogue, almost always trace back to buffer sizing in
- Configuring Kodi AdvancedSettings for Linux Buffers: Kodi on Linux buffers video ahead of playback to smooth over network hiccups and slow storage, and the advancedsettings.xml file is where you control
- Hardware Video Decoding Buffers in Libreelec: LibreELEC turns a Raspberry Pi into a dedicated Kodi media center, and smooth playback depends on hardware video decoding: the Pi's GPU decoding the
- HDMI EDID Handshake Overrides on Headless Servers: A headless server has no monitor, but its GPU does not know that: the graphics hardware expects an EDID handshake, the display's self-description of