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 ALSA, the kernel-level audio system everything else builds on. The buffer is the shock absorber between the application's irregular delivery of audio and the hardware's demand for a perfectly steady stream. Too small and any system hiccup starves the hardware; too large and you get laggy volume response and sluggish transport control. Tuning it is straightforward once you know which knobs matter.
Periods, buffers, and what they mean
ALSA moves audio in periods: chunks of frames that the application delivers and the hardware consumes. The buffer holds several periods, and the hardware raises an interrupt each time it finishes one, prompting the application to refill. Two numbers define the setup: period size (frames per chunk) and the number of periods in the buffer. Multiply them for the total buffer size, which divided by the sample rate gives the buffer's duration in seconds.
The trade is direct. A larger buffer tolerates longer scheduling delays without underrun, at the cost of latency: the time between the application producing audio and the speakers emitting it. For music and video playback, latency barely matters, so generous buffers are free insurance. For interactive uses like gaming or live monitoring, latency matters and buffers stay small.
Where ALSA sits in the Linux audio stack
ALSA is the kernel layer, but most desktop audio does not talk to it directly. PulseAudio (older systems) or PipeWire (most current distros) sits on top, mixing application streams and handing a single stream to ALSA. For a Kodi or LibreELEC media center, the application often opens ALSA directly, bypassing the middleman. If you are troubleshooting dropouts, know which layer you are tuning: buffer settings in Kodi's audio menu affect its ALSA stream, while system-wide stutter across all apps points at the PulseAudio or PipeWire layer above. JACK is the third option, built for pro-audio low latency, and overkill for a playback-only media box.
Diagnosing underruns
An underrun, also called an xrun, happens when the hardware consumes the buffer faster than the application refills it. ALSA logs these, and most media applications report them in verbose output. If you hear dropouts, first confirm they are xruns rather than a decoding or network problem: play a local uncompressed file and watch for xrun messages. If local playback is clean, the buffer is innocent and the problem lies upstream.
To see what ALSA actually negotiated (as opposed to what the application requested), check the hardware parameters while audio is playing:
cat /proc/asound/card0/pcm0p/sub0/hw_params
This shows the real period_size and buffer_size in frames. If the numbers do not match what you configured, the driver or an intermediate layer overrode them, and that mismatch is worth investigating before changing anything else.
Common xrun causes on a Pi-based media center include CPU frequency scaling delaying the audio thread, USB bus contention when the DAC shares a bus with storage, and background processes stealing realtime priority. Fixing the cause beats enlarging the buffer, though a larger buffer masks mild cases effectively.
Setting buffer parameters
Most applications let you set buffer time or period configuration through their audio settings or configuration files. A good starting point for playback on a media center is a total buffer around 100 to 200 milliseconds: enough to ride out scheduling jitter on a busy Pi, short enough that transport controls still feel responsive. If xruns persist, double the buffer and re-test; if they vanish, you can try trimming back to find the edge.
Period count matters too. More, smaller periods give the application finer-grained wakeups and smoother refill behavior; typical values are 2 to 4 periods. Very large single periods can interact badly with some drivers. One subtlety worth knowing: some applications define "buffer size" as the whole ring and derive the period from it (a 256-frame buffer with 4 periods means 64-frame wakeups), while others set period size directly. If your configured numbers are not behaving as expected, check which convention your application uses. When in doubt, keep period size moderate and scale total buffer time with period count.
System-level tuning that helps
Buffer tuning works best on a system that is not fighting itself. Give the audio thread realtime priority if the application supports it, so the kernel schedules refills ahead of background work. Disable CPU frequency scaling governors that park cores at low speed, or at least set a floor that keeps the audio path responsive; the powersave governor is a classic xrun factory on media Pis.
If the DAC is USB, isolate it from heavy USB traffic where possible, and prefer a direct port over a hub shared with drives. For HDMI audio, ensure the display's audio path is not resampling or delaying unexpectedly; some displays add their own buffering that interacts with ALSA settings. Match the ALSA sample rate to the source material to avoid a resampling stage that adds CPU load and potential artifacts.
Verifying the result
Test with demanding material: high sample-rate files, gapless albums where any dropout is obvious, and video with dialogue where lip sync reveals latency problems. Listen for a full session, not just a minute, since thermal throttling and background tasks cause dropouts that appear only after the system warms up.
Log xrun counts over a day of normal use. Zero xruns across varied playback means the tuning holds; occasional xruns correlated with specific events, like library scans or network bursts, point at system scheduling rather than buffer size, and are better fixed at the source.
The takeaway
ALSA buffer tuning is shock-absorber engineering: size the buffer to the system's real jitter, not to a theoretical ideal. Confirm xruns are the actual problem, verify what the hardware really negotiated, start generous on buffer time, calm the system's scheduling, and verify over real listening sessions. The clicks and pops disappear, and the media center fades into the background where it belongs.
Related Guides
- Configuring PulseAudio Buffer Latency for Streamers: 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 between action and audience. Tune it tight or your viewers will notice.
- 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 how much it buffers and when it starts.
- 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 handling the video stream instead of leaving it to the CPU.
- 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 its capabilities, and without one the GPU may refuse to output anything at all.