|
|
[[_TOC_]]
|
|
|
|
|
|
### Is PipeWire Ready Yet?
|
|
|
|
|
|
It is getting ready for broader testing.
|
... | ... | @@ -173,6 +175,28 @@ There is some more about this here: |
|
|
* [Push vs Pull in SDL](https://discourse.libsdl.org/t/sdl-audio-push-vs-pull-model/3923)
|
|
|
* [Linux Audio Systems](https://blog.linuxplumbersconf.org/2009/slides/Paul-Davis-lpc2009.pdf)
|
|
|
|
|
|
### PipeWire Buffering Explained
|
|
|
|
|
|
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).
|
|
|
|
|
|
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.
|
|
|
|
|
|
This does not include extra buffering in the resamplers (\~50 samples). There is a resampler in each stream and sink/source. There is not yet an option to remove the resampler latency while inactive.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
With `default.clock.max-quantum` you should be able to configure 128 samples for a 2.6ms server latency. If you use `pw-top` you can see the selected latency between app/device. I would suggest to see what it says there after adjusting the max-quantum.
|
|
|
|
|
|
For PulseAudio clients, it is the `pipewire-pulse` server that is woken up every quantum and it has an internal buffer based on what the client negotiated. Clients in general set buffering requirements based on configuration options in the application or you can use `PULSE_LATENCY_MSEC` env variable to configure things. Other than that it should work pretty much the same way as PulseAudio.
|
|
|
|
|
|
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.
|
|
|
|
|
|
### User Questions
|
|
|
|
|
|
### Does Desktop Audio Interfere With Pro-Audio Using PipeWire?
|
... | ... | |