[LAD] Re: Status of Pipewire
On 2023-02-08 18:04, Will Godfrey wrote: Quite honestly, the more I see, the more this looks like a train wreck! On 2023-02-08 18:06, Rui Nuno Capela wrote: for instance, and for crying out loud, pipewire is simply a disaster under a PREEMPT_RT kernel, while jack excels with flying colors :) You are probably both right, I don't know but I would like to know a little more how you came to this conclusion. I myself use Ubuntustudio nowadays in my studio. I am not prepared to tinker with it as long as it works well. My reasoning for that is that it's too much fuss if it goes wrong and I want to focus on music and not admin there. On my laptop (OpenSUSE TW) I've tried Pipewire and it messed up my bluetooth so bad I couldn't fix it without rolling back with snapper (cli for filesystem snapshot management on btrfs and ext4 (deprecated)). Bluetooth is needed for work. Bluetooth and Pipewire might be fine now. Should try it again. -- /bengan ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] Re: Status of Pipewire
On 2/9/23 08:31, Bengt Gördén wrote: On 2023-02-08 18:04, Will Godfrey wrote: Quite honestly, the more I see, the more this looks like a train wreck! On 2023-02-08 18:06, Rui Nuno Capela wrote: for instance, and for crying out loud, pipewire is simply a disaster under a PREEMPT_RT kernel, while jack excels with flying colors :) You are probably both right, I don't know but I would like to know a little more how you came to this conclusion. been testing it a lot, over every kernel-rt patch and pipewire release, currently on 6.2-rc7-rt1 and pipewire 0.3.65. pipewire's scheduling is allegedly based on s/w timers and not on h/w irqs like jack/alsa; it's just more prone to xruns when under a preempt_rt kernel and buffer-sizes (or quantum) lower than 1024 frames/period. overall, vanilla preempt aka low-latency kernels, seem to work better in this regard; byee -- rncbc aka. Rui Nuno Capela rn...@rncbc.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
[LAD] Re: Status of Pipewire
On Wed, 8 Feb 2023 at 12:09, Fons Adriaensen 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
[LAD] Re: Status of Pipewire
Hello Wim, Thanks for the info. > > 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. I have not yet looked at the actual DLL, but some of the related functions seem to be wrong. In pipewire-jack.c: jack_time_t jack_frames_to_time(): df = (frames - pos->clock.position) * ... jack_nframes_t jack_time_to_frames(): du = (usecs - pos->clock.nsec/SPA_NSEC_PER_USEC) * ... In both cases, the value computed inside the () should be signed. But since both arguments are unsigned, so will be their difference. See the original jack sources for how to handle this. Similar considerations apply in all related functions, so I do expect some other bugs. 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
[LAD] Re: Status of Pipewire
Something that may (or may not be related)
There seems to be something odd with Linux image 6.1 preempt
On a Ryzen 5, Rosegarden keeps randomly losing the transport timer
sometimes freezing for nearly a second (then blasts poor yoshimi with bunches
of notes on all 16 channels). This doesn't happen with the 'normal' 6.1 kernel,
nor does it happen with 5.10 preempt.
However the exact same setup on an older Intel Pentium has no problems at all.
This from devuan testing.
--
Will J Godfrey {apparently now an 'elderly'}
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] Re: Status of Pipewire
On Wed, 8 Feb 2023, Rui Nuno Capela wrote: note that I don't (always) want to "swap" jack for pipewire-jack... I don't blain you. There are a few simple commands that do not require install remove steps. Basically remove the pointer at PW's version of libjack and ldconfig. Not sure what that does for "pulse"/jack bridging but that is supposed to be able to happen still. pactl info should tell you who is being pulseaudio. Look for: Server Name: PulseAudio (on PipeWire 0.3.63) I want both to be installed and co-exist in the system and have the option to run wither one, genuine jackd(bus) or pipewire-jack substitution on a whim, anytime Can be done-ish for instance, and for crying out loud, pipewire is simply a disaster under a PREEMPT_RT kernel, while jack excels with flying colors :) - No ffado back end either so second class ALSA firewire drivers. - While there are reports otherwise, free wheel still fails for me. Ardour exports still need to be done in RT or I have to reboot. nuff said indeed. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] Re: Status of Pipewire
On Thu, 9 Feb 2023, Bengt Gördén wrote: I myself use Ubuntustudio nowadays in my studio. I am not prepared to tinker with it as long as it works well. My reasoning for that is that it's too much Skip 23.04 I think. stick with the LTS. Ubuntu has decided PW is the replacement for pulse and studio-controls has not caught up yet. It should be possible get jack and pw to play well together. I can switch between pulse/jack and pw right now but more work is needed. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] Re: Status of Pipewire
On Wed, Feb 08, 2023 at 05:06:45PM +, Rui Nuno Capela wrote: > for instance, and for crying out loud, pipewire is simply a disaster under a > PREEMPT_RT kernel, while jack excels with flying colors :) This is a concern. I've noticed some pro audio package maintainers are starting to replace jack dependencies with pipewire-jack (eg. in lsp-plugins package in Alpine edge). This is quite worrying, considerimg pipewire doesn't appear to be suitable (yet) for pro audio work. John ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] Re: Status of Pipewire
On Wed, Feb 08, 2023 at 05:06:45PM +, Rui Nuno Capela wrote: > for instance, and for crying out loud, pipewire is simply a disaster under a > PREEMPT_RT kernel, while jack excels with flying colors :) This is a concern. I've noticed some pro audio package maintainers are starting to replace jack dependencies with pipewire-jack (eg. in lsp-plugins package in Alpine edge). This is quite worrying, considerimg pipewire doesn't appear to be suitable (yet) for pro audio work. John ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] Re: Status of Pipewire - Ryzen 5
On Thu, Feb 09, 2023 at 02:33:18PM +, Will Godfrey wrote: > > Something that may (or may not be related) > There seems to be something odd with Linux image 6.1 preempt > > On a Ryzen 5, Rosegarden keeps randomly losing the transport timer > sometimes freezing for nearly a second (then blasts poor yoshimi with bunches > of notes on all 16 channels). This doesn't happen with the 'normal' 6.1 > kernel, > nor does it happen with 5.10 preempt. > > However the exact same setup on an older Intel Pentium has no problems at all. Have you turned off hyperthreading on the Ryzen system (usually called SMT in BIOS settings on AMD)? I keep SMT turned off on my Ryzen systems to avoid possible scheduling problems. So far no problems with 6.x kernels with dynamic preempt enabled. John ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
