PulseAudio
PulseAudio provides a sound-server interface that routes, mixes, buffers, and converts application streams for selected output sinks.
PulseAudio provides a sound-server model in which applications create audio streams and the server routes them to sinks. A sink is a playback destination; an application's playback stream is represented on the server as a sink input.
The server can combine streams, adjust levels and convert formats for the output. The physical device may be reached through ALSA, Bluetooth or another supported backend.
| Term | Playback meaning |
|---|---|
| Client | Application connected to the server |
| Stream / sink input | One application's submitted audio |
| Sink | Destination that consumes playback audio |
| Source | Capture or monitor destination that supplies audio |
| Sample specification | The stream's rate, channels and sample representation |
A monitor source can expose a sink's mixed audio for capture. That is a server-side signal observation, not necessarily a capture of the final analog output.
Buffer requests are expressed in bytes
PulseAudio's asynchronous stream interface uses playback buffer attributes. The requested target length, tlength, establishes a buffering goal; maxlength, prebuf and minreq serve other purposes.
For 48 kHz stereo float32, one sample frame contains eight bytes. A target length of 19,200 bytes represents:
19,200 / 8 = 2,400 sample frames
2,400 / 48,000 = 0.050 s = 50 ms
That calculation needs the actual sample specification. The same byte count in stereo 16-bit PCM would describe twice as many frames and twice the duration.
| Attribute | Role |
|---|---|
tlength |
Target playback buffering amount |
maxlength |
Maximum buffer length |
prebuf |
Amount required before automatic playback starts or resumes |
minreq |
Minimum amount requested from the client at once |
Without PA_STREAM_ADJUST_LATENCY, the target length concerns the stream's server-side playback buffer. With that flag, the request instead asks the server to configure the combined sink and stream buffering toward that latency. The accepted configuration and measured delay need to be checked; a requested 50 ms is not proof of exactly 50 ms at the speaker.
The server can satisfy several clients with different buffering needs. A request also cannot eliminate delay inherent in a separate wireless receiver.
Routing and conversion happen after the app's format
An application can submit 44.1 kHz audio while the destination uses 48 kHz. The server's output route can perform the necessary conversion. Per-stream gain, sink gain and supported processing can affect what reaches the device.
Moving a stream to another sink changes its destination and may change its format or timing requirements. A stored preference, the current default sink and an already-running stream's actual destination are different observations.
For an Emby Linux client, inspect the app's stream and the sink it is using. Changing a server setting on the machine hosting the media library does not select the speakers on a separate client.
The protocol does not identify the implementation
A program using libpulse speaks the PulseAudio client protocol. It can connect to the PulseAudio daemon or to PipeWire's pipewire-pulse compatibility server.
The names shown to a PulseAudio client may therefore describe a compatible view of a PipeWire graph. That helps existing applications continue to work; it also means “PulseAudio output” in a player log is not enough to identify the running daemon.