... | ... | @@ -179,13 +179,13 @@ There is some more about this here: |
|
|
|
|
|
PipeWire has two 'buffers':
|
|
|
|
|
|
1. One it keeps in the hardware device by keeping one period (quantum) of data in the sink. If there is < quantum of data if runs the graph to ask all nodes to provide one new quantum of data. Presumably that can happen before the sink finishes playing the remaining data (if not: xrun). Batch devices (alsa devices that report themselves as batch) keep an extra period of data in the device as headroom.
|
|
|
1. One it keeps in the hardware device by keeping one period (quantum) of data in the sink. If there is < quantum of data if runs the graph to ask all nodes to provide one new quantum of data. Presumably that can happen before the sink finishes playing the remaining data (if not: xrun). Batch devices (alsa devices that report themselves as batch) enable IRQs at period-size/2 (by default 1024/2) and keep an extra period-size/2 of data in the device as headroom. So, normal device introduce a latency of `quantum`, batch devices run at a latency of `quantum + period-size/2`.
|
|
|
|
|
|
2. Buffers in the application. This can be anything you would want it to be. jack clients use 0 buffering and react to the graph wakeup immediately. stream based clients can do the same thing but usually do some sort of extra buffering.
|
|
|
2. Buffers in the application. This can be anything you would want it to be. jack clients use 0 buffering and react to the graph wake-up immediately. stream based clients can do the same thing but usually do some sort of extra buffering.
|
|
|
|
|
|
This does not include extra buffering in the resamplers (\~50 samples). There is a resampler in each stream and sink/source. The resampler latency is 0 when the resampler is not used.
|
|
|
|
|
|
This does also not include latency introduced by the USB subsystem or other hardware latencies. These are generally also lower with JACK and PulseAudio when doing IRQ based scheduling. This is something that PipeWire can't do yet.
|
|
|
This does also not include latency introduced by the USB subsystem or other hardware latencies. These are generally the same as with JACK and PulseAudio when the IRQ period-size is set to a sufficiently low value for batch devices.
|
|
|
|
|
|
The quantum on the server is controlled by the clients node.latency property. It it always set to the lowest requested latency. If you start a PipeWire app with PIPEWIRE_LATENCY=128/48000 it will use a 2.6ms quantum and the latency between a client waking up and the sink read pointer will be 2.6ms.
|
|
|
|
... | ... | @@ -195,7 +195,7 @@ For PulseAudio clients, it is the `pipewire-pulse` server that is woken up every |
|
|
|
|
|
Note that `PIPEWIRE_LATENCY=` does nothing for PulseAudio clients.
|
|
|
|
|
|
So, first use max-quantum to limit server latency, then use client config or env variable to set client latency.
|
|
|
So, first use max-quantum to limit server latency, use the alsa-monitor.conf file to set batch period size (for batch devices), then use client config or env variable to set client latency.
|
|
|
|
|
|
### User Questions
|
|
|
|
... | ... | |