[LAD] Re: Status of Pipewire
On 3/18/23 19:34, Len Ovens wrote: On Sat, 18 Mar 2023, Rui Nuno Capela wrote: On 2/8/23 17:06, Rui Nuno Capela wrote: pipewire is simply a disaster under a PREEMPT_RT kernel, while jack excels with flying colors :) have to retract the above: recent 6.3-rcX-rtY (preempt_rt) kernel patches are doing quite well here on both accounts, pipewire-jack and genuine jackd(bus)... ... > Having said that, PipeWire does work well for most people (I have not had freewheel work for me yet) and I think it is much better than pulse or pulse/jack. For most of my work, I can run PW for everything just fine but using my computer as an effects box/softsynth still needs jack. two things: 1. jack-freewheeling is working fine here (pipewire-jack 0.3.67 though used to work right before,since .54 I think) 2. what remains not quite on par to good ol'jack is jack-transport/timebase sync'ing... ie. some jack-clients, which aren't currently timebase master, may botch the BBT timeline now and then, randomly... besides that nitpick--for what jack-transport wasn't and never will a stellar performer anyway--I think pipewire is going for the gold in the coming championships ;) well, just saying, it actually depends on whether 6.3-rt keeps the figures up as seen until now ;) cheers -- 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 Sat, 18 Mar 2023, Rui Nuno Capela wrote: On 2/8/23 17:06, Rui Nuno Capela wrote: pipewire is simply a disaster under a PREEMPT_RT kernel, while jack excels with flying colors :) have to retract the above: recent 6.3-rcX-rtY (preempt_rt) kernel patches are doing quite well here on both accounts, pipewire-jack and genuine jackd(bus)... if things keep this way, hopefully the switch to pipewire-jack might just happen permanently one of these coming months ;) Not for me, the ALSA firewire module limits me to at least 256/2 latency as compaired to 16/2 with jack (3 days straight no xruns). PipeWire will never support jack backends like ffado. It does not seem ALSA FW will ever be better than just barely working. Buying a USB box to replace what I have, aside from being more than I can afford right now, aside from being a waste of a perfectly good unit, Just irks me that I should spend good money for something that would work less well than what I already have. Having said that, PipeWire does work well for most people (I have not had freewheel work for me yet) and I think it is much better than pulse or pulse/jack. For most of my work, I can run PW for everything just fine but using my computer as an effects box/softsynth still needs jack. -- 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 2/8/23 17:06, Rui Nuno Capela wrote: pipewire is simply a disaster under a PREEMPT_RT kernel, while jack excels with flying colors :) have to retract the above: recent 6.3-rcX-rtY (preempt_rt) kernel patches are doing quite well here on both accounts, pipewire-jack and genuine jackd(bus)... if things keep this way, hopefully the switch to pipewire-jack might just happen permanently one of these coming months ;) cheers -- 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 Tue, Feb 14, 2023 at 04:55:00PM +0100, Wim Taymans wrote: > > BTW, what about the 'signed differences' issue I pointed > > out earlier ? > > Should be fixed with this: > https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/274b63e9723ec00dd413bb64b6650d2004f7e4c2 I don't think this is correct. But it may be a long time before this becomes apparent. Frame times are 32 bit. The required result of the subtraction is the difference modulo 2^32 and interpreted as an int32_t i.e. including the wraparound resulting from the 'exact' value being out of range for an int32_t. The wraparound won't happen when frametimes are cast to 64 bit. 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
Hi Win, Le 2023-02-14 à 10 h 55, Wim Taymans a écrit : On Tue, 14 Feb 2023 at 16:32, Fons Adriaensen wrote: BTW, what about the 'signed differences' issue I pointed out earlier ? Should be fixed with this: https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/274b63e9723ec00dd413bb64b6650d2004f7e4c2 Wim I wonder if it would fix an issue I experienced: 3 months ago I installed Pipewire with Debian 11 on an old laptop, to use ALSA and Jack software together (jack software connected to ALSA software); I suspended the laptop for the night and when I opened it the next morning the audio software froze for 3 or 4 minutes, as if it was trying to process samples collected overnight... Trying to "fix" this problem I later installed a realtime kernel and activated the PipeWire Rt module; it was working better, but maybe it'd work even better with your new commit? Marc ___ 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 Tue, 14 Feb 2023 at 16:32, Fons Adriaensen wrote: > > On Tue, Feb 14, 2023 at 03:57:05PM +0100, Wim Taymans wrote: > > > > The real difference between the two methods is 'sample count' > > > versus 'time' as the source of the event that starts a period. > > > > > > I always wondered why one would use a timer, it just amounts > > > to polling. Suppose you look every 1 ms to check if there > > > > You don't need to use polling with timerfd, just set the timeout > > according to some clock, > > add the timerfd to some poll loop and it wakes up on time. > > It's of course not 'active polling' (spending all CPU time on > testing a condition), but it is still polling in the sense > that it is NOT the event you wait for (having enough samples > to start a Jack cycle) that wakes you up. When using a timer > you just test for that condition periodically, which means > you can be up to that period late. The idea is to use a DLL to tweak the timeout and wake up exactly when you have the desired number of samples in the device. > > To avoid loss of period processing time, the timer period > must a very small fraction of the Jack period time. And > then I wonder what is the advantage. > If you want to implement dynamic latency changes with the IRQ based wakeup you need to do the opposite, use small ALSA periods and then accumulate a few until you have the desired period for the graph. It would be possible to implement something like this as an alternative for timers. > > Very much like how ALSA wakes you up when a period expires. > > AFAIK, ALSA doesn't use timers for that. > For a sound card on e.g. a PCI bus the start of cycle would > be the indirect result of an hardware interrupt. For USB > or firewire cards, it would be triggered by an event from > the lower (USB/firewire) layers. > > BTW, what about the 'signed differences' issue I pointed > out earlier ? Should be fixed with this: https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/274b63e9723ec00dd413bb64b6650d2004f7e4c2 Wim > > 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
On Tue, Feb 14, 2023 at 03:57:05PM +0100, Wim Taymans wrote: > > The real difference between the two methods is 'sample count' > > versus 'time' as the source of the event that starts a period. > > > > I always wondered why one would use a timer, it just amounts > > to polling. Suppose you look every 1 ms to check if there > > You don't need to use polling with timerfd, just set the timeout > according to some clock, > add the timerfd to some poll loop and it wakes up on time. It's of course not 'active polling' (spending all CPU time on testing a condition), but it is still polling in the sense that it is NOT the event you wait for (having enough samples to start a Jack cycle) that wakes you up. When using a timer you just test for that condition periodically, which means you can be up to that period late. To avoid loss of period processing time, the timer period must a very small fraction of the Jack period time. And then I wonder what is the advantage. > Very much like how ALSA wakes you up when a period expires. AFAIK, ALSA doesn't use timers for that. For a sound card on e.g. a PCI bus the start of cycle would be the indirect result of an hardware interrupt. For USB or firewire cards, it would be triggered by an event from the lower (USB/firewire) layers. BTW, what about the 'signed differences' issue I pointed out earlier ? 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
On Fri, 10 Feb 2023 at 23:46, Fons Adriaensen wrote: > > On Thu, Feb 09, 2023 at 01:34:52PM +0100, Wim Taymans wrote: > > > real JACK is more mature and does things differently (mostly device > > wakeup with IRQ instead of timers) > > The real difference between the two methods is 'sample count' > versus 'time' as the source of the event that starts a period. > > I always wondered why one would use a timer, it just amounts > to polling. Suppose you look every 1 ms to check if there You don't need to use polling with timerfd, just set the timeout according to some clock, add the timerfd to some poll loop and it wakes up on time. Very much like how ALSA wakes you up when a period expires. Wim > are enough samples for a period. That means you can be up > to 1 ms late. Compare that to the period time of 1.33 ms > when using 64 samples / 48 kHz. Up to 3/4 of the available > time to compute a period could be lost... > > Or am I missing something ? > > 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
On Thu, Feb 09, 2023 at 01:34:52PM +0100, Wim Taymans wrote: > real JACK is more mature and does things differently (mostly device > wakeup with IRQ instead of timers) The real difference between the two methods is 'sample count' versus 'time' as the source of the event that starts a period. I always wondered why one would use a timer, it just amounts to polling. Suppose you look every 1 ms to check if there are enough samples for a period. That means you can be up to 1 ms late. Compare that to the period time of 1.33 ms when using 64 samples / 48 kHz. Up to 3/4 of the available time to compute a period could be lost... Or am I missing something ? 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 - Ryzen 5
On Fri, Feb 10, 2023 at 06:32:36PM +, Will Godfrey wrote: > On Thu, 9 Feb 2023 20:18:59 + > John Rigg wrote: > >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. > > > OK. That works thanks. Strange it wasn't needed for kernel 5.10. The scheduler was modified to allow dynamic preemption (preemption can be turned on and off with kernel command line), starting with 5.12 kernel. 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
I think it is too bad that pipewire does not just use the system libjack and allow setting server name. Then both could run as separate jack servers. Building a Jack->jack bridge with SRC would not be too hard either. For many people, leaving pw server to default would just work but for others setting the server name to pipewire would allow jackd to start as normal, no comflict. I suppose it would be possible to leave the system libjack active and start a zita-j2n instance with pw-jack and a zita-n2j without as a bridge. Clunky for sure but maybe a purpose built zita-pjbridge could work better. (peanut butter and jam?) -- 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 - Ryzen 5
On Thu, 9 Feb 2023 20:18:59 +
John Rigg wrote:
>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
OK. That works thanks. Strange it wasn't needed for kernel 5.10.
--
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 2023-02-08 04:03, Lorenzo Sutton wrote: I recently reinstalled my uses Manjaro (Arch-based) and I see I _do_ have a 'pipewire' package installed, but it looks like I'm actually running pulseaudio (?) and am able to run jack and use my jack-pulseaudio sink _if_ needed - as I have usually done since years. Yes, however, the packaging is ever changing so what I have to say may be true for some people and not for others. At some point (ubuntu 22.04 here but already different in for 23.04) both pulse and pipewire are installed and set up in systemd so that if pulse is enabled, it takes the resources first and pipewire fails to start. So disabling pulse with systemctl (as a user not root) will switch to pipewire at least for desktop use. If the right (wrong?) pipewire-jack (not sure the right package name and it is changing anyway) package is installed, a file is created in /etc/ld.so.conf.d/ that basically tells the system that libjack is located in /usr/lib/*/pipewire*/jack/. This means that any jack client will use this lib and connect to pw instead of jack. This includes jackd(bus), jack_control, etc. To start jackd(bus) one must first remove /etc/ld.so.conf.d/*pipewire* and do an ldcoonfig (both as root of course). Then there is a pw configuration change that should make pw bridge to jackd... I haven't got so far as seeing how that works. I can (via script) change between a system that runs pulse/jack and a system that runs pipewire so far. However life has been busy and I have not played with it enough to say more. pactl load-module module-jack-sink pactl load-module module-jack-source This does not seem possible. There is some sort of pw/jack bridge but there can only ever be one (that I can tell) and it will only ever have a number of ports automatically determined by PW rather than the very flexible modules listed above. Hopefully that changes. It is supposed to be possible to either: use pw for desktop with a bridge to jack for deterministic audio or use pw as jack and use jackd as a device. The second would require running jackd(bus) from a script that points jackd(bus) at the right libjack. so far PW has been reasonably good for desktop and jack functions for me except for Ardour exports where freerun is required. I am running it at 1024 buffer size only though because... the ALSA FW stack seems limited compared to ffado. ALSA fw seems limited to 256/2 and above where ffado will run reliably at 16/2. When I say limited to 256/2 I mean that jackd using the alsa fw stack with crash if the latency is set lower. As such, I have an interest in being able to use jackd in a PW environment, not so I can run at 16/2 but at least low enough to use my computer as a guitar effect in real time which pw does not allow. -- 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 - 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
[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
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, 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
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
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
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
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 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/8/23 16:48, ycollette.nos...@free.fr wrote: On fedora, you can switch easily between jack and jack-pipewire: $ dnf swap pipewire-jack-audio-connection-kit --allowerasing $ dnf swap jack-audio-connection-kit --allowerasing note that I don't (always) want to "swap" jack for pipewire-jack... 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 for instance, and for crying out loud, pipewire is simply a disaster under a PREEMPT_RT kernel, while jack excels with flying colors :) nuff said -- 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
Quite honestly, the more I see, the more this looks like a train wreck!
I'll wait for the dust to settle (then still probably stick with Jack).
--
Will J Godfrey {apparently now an 'elderly'}
___
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 fedora, you can switch easily between jack and jack-pipewire:
$ dnf swap pipewire-jack-audio-connection-kit --allowerasing
$ dnf swap jack-audio-connection-kit --allowerasing
- Mail original -
De: "Dominique Michel"
À: linux-audio-dev@lists.linuxaudio.org
Envoyé: Mercredi 8 Février 2023 17:42:29
Objet: [LAD] Re: Status of Pipewire
Le Wed, 8 Feb 2023 13:03:37 +0100,
Lorenzo Sutton a écrit :
> Hi Fons,
>
> On 08/02/2023 12:09, Fons Adriaensen wrote:
> > Hello all,
Hello,
If I take a look at the gentoo pipewire ebuild, it is 2 jack related
USE flags: jack-client and jack-sdk
Their dependencies are as follow:
jack-client? ( >=media-sound/jack2-1.9.10:2[dbus] )
jack-sdk? ( !media-sound/jack-audio-connection-kit
!media-sound/jack2 )
Jack-client need jack2, but jack-sdk is blocking jack(2) because it
provide a replacement.
It is also a post install warning:
if ! use jack-sdk; then echo \
"JACK emulation is incomplete and not all programs will work.
PipeWire's alternative libraries have been installed to a
non-default location. To use them, put pw-jack before
every JACK application. When using pw-jack, do not run jackd/jackdbus.
However, a virtual/jack provider is still needed to compile the JACK
applications themselves."
And on the gentoo wiki https://wiki.gentoo.org/wiki/PipeWire
"Warning
As of mid 2022, PipeWire is still in active development. Some things
may still not be fully integrated, tested, or implemented, and there
may be large changes. It can work well for some, though the experience
is not guaranteed to be perfect, free of issues, or bugs."
Which mean that even with USE="jack-sdk", some use cases can get in
troubles.
> As said, this (at least logically), sounds really similar to the
> pulsaudio-jack sink concept... For instance what I now have in a
> script is something along the lines of:
>
> pactl load-module module-jack-sink
> pactl load-module module-jack-source
>
> and get pulseaudio as an in/out jack client.
Into my system, I don't use gnome or kde, so I never get the
point to use pulseaudio (it is not even installed), when we can do the
same using alsa and jack only. The default alsa card is defined
into /etc/modprobe.d/alsa.conf with a line
alias snd-card-0 snd-aloop
This also need a custom ~/.asoundrc file with something like
pcm.!default {
type plug
slave.pcm "jack";
}
ctl.!default {
type hw card 0
}
pcm.jack {
type jack
playback_ports {
0 system:playback_1
1 system:playback_2
}
capture_ports {
0 system:capture_1
1 system:capture_2
}
}
That way, the alsa only software will use by default the alsa default
card, and the clients of that aloop card will be rooted to jackd via
the jack ALSA plugin. They will even appear into the jack graph. jackd
is configured to use the real sound card.
That setting works fine for me with both qjackctl and cadence. It was
working with jackd and it works now with jack-dbus from years, that on
several computers.
Cheers,
Dominique
>
> >
> >
> > [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,
> >
>
> Lorenzo
>
> [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK
> ___
> 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
___
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
Le Wed, 8 Feb 2023 13:03:37 +0100,
Lorenzo Sutton a écrit :
> Hi Fons,
>
> On 08/02/2023 12:09, Fons Adriaensen wrote:
> > Hello all,
Hello,
If I take a look at the gentoo pipewire ebuild, it is 2 jack related
USE flags: jack-client and jack-sdk
Their dependencies are as follow:
jack-client? ( >=media-sound/jack2-1.9.10:2[dbus] )
jack-sdk? ( !media-sound/jack-audio-connection-kit
!media-sound/jack2 )
Jack-client need jack2, but jack-sdk is blocking jack(2) because it
provide a replacement.
It is also a post install warning:
if ! use jack-sdk; then echo \
"JACK emulation is incomplete and not all programs will work.
PipeWire's alternative libraries have been installed to a
non-default location. To use them, put pw-jack before
every JACK application. When using pw-jack, do not run jackd/jackdbus.
However, a virtual/jack provider is still needed to compile the JACK
applications themselves."
And on the gentoo wiki https://wiki.gentoo.org/wiki/PipeWire
"Warning
As of mid 2022, PipeWire is still in active development. Some things
may still not be fully integrated, tested, or implemented, and there
may be large changes. It can work well for some, though the experience
is not guaranteed to be perfect, free of issues, or bugs."
Which mean that even with USE="jack-sdk", some use cases can get in
troubles.
> As said, this (at least logically), sounds really similar to the
> pulsaudio-jack sink concept... For instance what I now have in a
> script is something along the lines of:
>
> pactl load-module module-jack-sink
> pactl load-module module-jack-source
>
> and get pulseaudio as an in/out jack client.
Into my system, I don't use gnome or kde, so I never get the
point to use pulseaudio (it is not even installed), when we can do the
same using alsa and jack only. The default alsa card is defined
into /etc/modprobe.d/alsa.conf with a line
alias snd-card-0 snd-aloop
This also need a custom ~/.asoundrc file with something like
pcm.!default {
type plug
slave.pcm "jack";
}
ctl.!default {
type hw card 0
}
pcm.jack {
type jack
playback_ports {
0 system:playback_1
1 system:playback_2
}
capture_ports {
0 system:capture_1
1 system:capture_2
}
}
That way, the alsa only software will use by default the alsa default
card, and the clients of that aloop card will be rooted to jackd via
the jack ALSA plugin. They will even appear into the jack graph. jackd
is configured to use the real sound card.
That setting works fine for me with both qjackctl and cadence. It was
working with jackd and it works now with jack-dbus from years, that on
several computers.
Cheers,
Dominique
>
> >
> >
> > [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,
> >
>
> Lorenzo
>
> [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK
> ___
> 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
On 2023-02-08 12:51, Yann Collette wrote: Was it Unfa ? I remember that in the Pipewire video he made he told that ardour needed some patches because of varying buffers of pipewire ... Most likely Unfa. I remember watching that episode when he couldn't use pipewire for all the x-runs and crashes. He started using pipewire again later. Here is the video about it. It's a sort of trial and error pipewire ju-jitsu. https://www.youtube.com/watch?v=q7XrrBXIzfg Fons, Unfa has his own Rocket.Chat server. Think he's on irc somewhere too but don't remember what nick or network. Rocket.Chat https://chat.unfa.xyz/home Cheers, /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/8/23 11:09, Fons Adriaensen wrote: Hello all, I've been contemplating trying out Pipewire as a replacement for Jack. What is holding me back is a what seems to be a serious lack of information. I'm not prepared to spend a lot of time and risk breaking a perfectly working system just to find out that it was a bad idea from the start. So I have a lot of questions which maybe some of you reading this can answer. Thanks in advance for all useful information. A first thing to consider is that I actually *like* the separation of the 'desktop' and 'pro audio' worlds that using Jack provides. I don't want the former to interfere (or just be able to do so) with the latter. Even so, it may be useful in some cases to route e.g. browser audio or a video conference to the Jack world. 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 ? 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 ? Q3. What overhead (memory, CPU) is incurred for such large systems, compared to plain old Jack ? 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) Q4. Where is the DLL and what does it lock to when Pipewire is emulating Jack ? Q5. Do all Jack clients see the same (and correct) info regarding the state of the DLL in all cases ? 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. [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. TL;DR (IMHO) pipewire is a dang good replacement to pulseaudio (and possibly jack) for *consumer*/*desktop* scenarios; though, not so good for the pro-audio scene, as far as "deterministic" and "stable" low-latency goes, at least as far as good ol'jack. a proverbial YMMV ensues... the biggest problem I've come around is that most distros package managers will command you to ditch genuine jack altogether, whenever you try to install pipewire-jack (ie. the so called "jack replacement" libraries); this is simply outrageous for us (me included) good old jack folks; however I've been dwelling with this on my own premises, whenever a new pipewire version comes along (openSUSE Tumbleweed here). again, YMMV just my 2c. -- 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
Hi Fons, On 08/02/2023 12:09, Fons Adriaensen wrote: Hello all, I've been contemplating trying out Pipewire as a replacement for Jack. What is holding me back is a what seems to be a serious lack of information. I'm not prepared to spend a lot of time and risk breaking a perfectly working system just to find out that it was a bad idea from the start. So I have a lot of questions which maybe some of you reading this can answer. Thanks in advance for all useful information. I'm really glad you raise the questions... I feel in the same situation (more as a user) and still find Pipewire quite confusing. I recently reinstalled my uses Manjaro (Arch-based) and I see I _do_ have a 'pipewire' package installed, but it looks like I'm actually running pulseaudio (?) and am able to run jack and use my jack-pulseaudio sink _if_ needed - as I have usually done since years. That's confusing enough, my intuition is that pipewire (at least on Arch and Arch-based distros) is some sort of 'metapackage' (the upstream points to pipewire.org) and then the actual functionality is in the myriad of pipewire-* packages such as pipewire-audio, pipewire-alsa, pipewire-jack. Then I see that pipewire-jack conflicts with both jack and jack2 which makes me very very reluctant to install them as a replacement (I use jack2): on my older machine I gave it a go and Ardour wouldn't even start. I don't want to sound over-critical, just as you (and maybe other users) I'm simply pretty confused. The documentation, at least for me, also seems a bit confusing when it comes to JACK [1]. It might just be a matter of time, meaning Pipewire is still a relatively new project and quite ambitious I'd say. I'd also imagine that (understandable) it's mostly focusing on desktop audio (/video) and not on pro audio. A first thing to consider is that I actually *like* the separation of the 'desktop' and 'pro audio' worlds that using Jack provides. I don't want the former to interfere (or just be able to do so) with the latter. Even so, it may be useful in some cases to route e.g. browser audio or a video conference to the Jack world. I agree. For me pulseaudio is 'everyday' non-pro-audio, jack for pro-audio and then if needed use a sink. Quick and easy and good to have two distinct approaches. If I'm recording or making audio I'm (typically) not watching youtube videos et. al. So, I'm also really interested in the questions you pose (and possible answers). 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 ? I think the final aim of Pipewire is to _replace_ JACK. It's not clear for me if the option to run JACK 'natively on demand' is considered a kind of transitionary phase or will remain. If the latter maybe one could consider (and use) Pipewiere eventually as Pulseaudio is used today? 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 ? Q3. What overhead (memory, CPU) is incurred for such large systems, compared to plain old Jack ? 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) Q4. Where is the DLL and what does it lock to when Pipewire is emulating Jack ? Q5. Do all Jack clients see the same (and correct) info regarding the state of the DLL in all cases ? 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. As said, this (at least logically), sounds really similar to the pulsaudio-jack sink concept... For instance what I now have in a script is something along the lines of: pactl load-module module-jack-sink pactl load-module module-jack-source and get pulseaudio as an in/out jack client. [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, Lorenzo [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK ___ 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
Was it Unfa ? I remember that in the Pipewire video he made he told that ardour needed some patches because of varying buffers of pipewire ... To be confirmed. Le 08/02/2023 à 12:33, Will Godfrey a écrit : I can't remember who it was, but someone over on https://linuxmusicians.com/ was very keen on Pipewire until he discovered that it was varying the latency depending on what sources were active, so switched back to Jack. Sorry, I don't know anything more than that. ___ 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
I can't remember who it was, but someone over on https://linuxmusicians.com/
was very keen on Pipewire until he discovered that it was varying the latency
depending on what sources were active, so switched back to Jack.
Sorry, I don't know anything more than that.
--
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
