[LAD] Status of Pipewire
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. 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: Text editor with new views in separate windows (not tabs or split views)
Coming back to this I've discovered kwrite is a self-contained program and will
run quite happily in user space, so I grabbed an older copy and run 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
[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
[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
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
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
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
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 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
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 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
