On Wed, 8 Feb 2023 at 12:09, Fons Adriaensen <f...@linuxaudio.org> wrote: > > Hello all, > [snip] > So the ideal solution > for me would be the have Pipewire as a Jack client. > So first question: > > Q1. Is that still possible ? If not, why not ?
It is possible although I have not tried this in a while. The way it works is a little bit like pulseaudio. There is a JACK device that you can activate and then it creates a jack client with N inputs and M outputs. > > If the answer is no, then all of the following become > relevant. > > Q2. Does Pipewire as a Jack replacement work, in a reliable > way [1], in real-life conditions, with tens of clients, > each maybe having up to a hundred ports ? I believe so. > > Q3. What overhead (memory, CPU) is incurred for such large > systems, compared to plain old Jack ? I have some performance measurements here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance TLDR; it's comparable, I would say maybe slightly more CPU usage than JACK when you do simple things. Probably more memory usage, didn't test that. > > A key feature of Jack is that all clients share a common idea > of what a 'period' is, including its timing. In particular > the information provided by jack_get_cycle_times(), which is > basically the state of the DLL and identical for all clients > in any particular period. Now if Pipewire allows (non-Jack) > clients with arbitrary periods (and even sample rates) PipeWire at the core uses the same period and samplerate for all clients attached to a driver, just like JACK. It can change dynamically but then it changes for everyone. When a JACK client is started, the automatic buffer size and samplerate switch is disabled but you can still force it (with settings metadata). You *can* have jack clients with different buffer size and samplerate when they are running on different drivers and when they are in no way related, it would be like starting 2 JACK servers on different cards. In the layer above (pipewire-pulse and ALSA plugin), each client gets a different ring buffer and resampler that is used to read and write to the clients with the latency and samplerate that they want. > > Q4. Where is the DLL and what does it lock to when Pipewire > is emulating Jack ? There is one DLL per driver in the graph, clients join a driver either explicitly or by linking to it directly or indirectly. If multiple drivers are joined, based on priority, one becomes master and the other uses an adaptive resampler to keep in sync (if not already sharing the same clock on the device or word clock). So normally you would have all clients look at the timings of one driver and so they share the same time. It's pretty similar to what JACK does. > > Q5. Do all Jack clients see the same (and correct) info > regarding the state of the DLL in all cases ? Yes, if they are using the same driver. > > The only way I can see this being OK would be that the Jack > emulation is not just a collection of Pipewire clients which > happen to have compatible parameters, but actually a dedicated > subsystem that operates almost independently of what the rest > of Pipewire is up to. Which in turn means that having Pipewire > as a Jack client would be the simpler (and hence preferred) > solution. PipeWire at the core is a JACK server with some more dynamic behaviour. You can in fact make a minimal server that just does what JACK does (without a session manager and pipewire-pulse server). The dynamic stuff and device detection and automatic routing (for pulse and ALSA apps) is implemented in the session manager. The adaption layer for pulseaudio clients is implemented in pipewire-pulse. The JACK emulation is a small wrapper to map the JACK methods to PipeWire IPC and methods. The only reason to run JACK clients on top of JACK instead of PipeWire is because real JACK is more mature and does things differently (mostly device wakeup with IRQ instead of timers) that makes it work better for some cases. Otherwise, there should be no difference. In any case, I should test the PipeWire as a JACK client code again and make it work well... Wim > > > [1] which means I won't fall flat on my face in front of > a customer or a concert audience because of some software > hickup. > > Ciao, > > -- > FA > > > > > _______________________________________________ > Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org > To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org _______________________________________________ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
