8 Feb
2023
8 Feb
'23
12:09 p.m.
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
8 Feb
8 Feb
12:33 p.m.
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.
12:51 p.m.
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.
3:43 p.m.
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
1:03 p.m.
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
5:42 p.m.
Le Wed, 8 Feb 2023 13:03:37 +0100,
Lorenzo Sutton <lorenzofsutton(a)gmail.com> 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 <application> 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(a)lists.linuxaudio.org
To unsubscribe send an email to
linux-audio-dev-leave(a)lists.linuxaudio.org
5:48 p.m.
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" <dominique.c.michel(a)gmail.com>
À: linux-audio-dev(a)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 <lorenzofsutton(a)gmail.com> a écrit :
_______________________________________________
Linux-audio-dev mailing list -- linux-audio-dev(a)lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-leave(a)lists.linuxaudio.org
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 <application> 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(a)lists.linuxaudio.org
To unsubscribe send an email to
linux-audio-dev-leave(a)lists.linuxaudio.org
6:06 p.m.
On 2/8/23 16:48, ycollette.nospam(a)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
rncbc(a)rncbc.org
9 Feb
9 Feb
9:31 a.m.
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
10:55 a.m.
On 2/9/23 08:31, Bengt Gördén wrote:
On 2023-02-08 18:04, Will Godfrey wrote:
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
rncbc(a)rncbc.org
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.
5:50 p.m.
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
9:50 a.m.
On Wed, Feb 08, 2023 at 05:06:45PM +0000, 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
5:44 p.m.
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
6:28 p.m.
On Wed, Feb 08, 2023 at 05:06:45PM +0000, 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
18 Mar
18 Mar
6:46 p.m.
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
rncbc(a)rncbc.org
8:34 p.m.
On Sat, 18 Mar 2023, Rui Nuno Capela wrote:
On 2/8/23 17:06, Rui Nuno Capela wrote:
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
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 ;)
20 Mar
20 Mar
5:44 p.m.
On 3/18/23 19:34, Len Ovens wrote:
On Sat, 18 Mar 2023, Rui Nuno Capela wrote:
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
rncbc(a)rncbc.org
On 2/8/23 17:06, Rui Nuno Capela wrote:
...
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.
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)...
8 Feb
8 Feb
6:04 p.m.
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'}
10 Feb
10 Feb
6:20 p.m.
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
8:38 p.m.
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
8 Feb
8 Feb
3:36 p.m.
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
rncbc(a)rncbc.org
9 Feb
9 Feb
3:33 p.m.
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.
9:18 p.m.
New subject: Status of Pipewire - Ryzen 5
On Thu, Feb 09, 2023 at 02:33:18PM +0000, 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
10 Feb
10 Feb
7:32 p.m.
New subject: Status of Pipewire - Ryzen 5
On Thu, 9 Feb 2023 20:18:59 +0000
John Rigg <ladev9(a)jrigg.co.uk> wrote:
On Thu, Feb 09, 2023 at 02:33:18PM +0000, Will Godfrey
wrote:
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.
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
9:43 p.m.
New subject: Status of Pipewire - Ryzen 5
On Fri, Feb 10, 2023 at 06:32:36PM +0000, Will Godfrey wrote:
On Thu, 9 Feb 2023 20:18:59 +0000
John Rigg <ladev9(a)jrigg.co.uk> wrote:
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
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. 
9 Feb
9 Feb
1:34 p.m.
On Wed, 8 Feb 2023 at 12:09, Fons Adriaensen <fons(a)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(a)lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-leave(a)lists.linuxaudio.org
3:13 p.m.
Hello Wim,
Thanks for the info.
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
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.
10 Feb
10 Feb
11:46 p.m.
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
14 Feb
14 Feb
3:57 p.m.
On Fri, 10 Feb 2023 at 23:46, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Thu, Feb 09, 2023 at 01:34:52PM +0100, Wim Taymans wrote:
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
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
4:32 p.m.
On Tue, Feb 14, 2023 at 03:57:05PM +0100, Wim Taymans wrote:
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.
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.
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
4:55 p.m.
On Tue, 14 Feb 2023 at 16:32, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
Should be fixed with this:
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/274b63e9723ec00dd…
Wim
On Tue, Feb 14, 2023 at 03:57:05PM +0100, Wim Taymans wrote:
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.
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.
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 ?
Ciao,
--
FA
7:28 p.m.
Hi Win,
Le 2023-02-14 à 10 h 55, Wim Taymans a écrit :
On Tue, 14 Feb 2023 at 16:32, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
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
BTW, what about the 'signed differences'
issue I pointed
out earlier ?
Should be fixed with this:
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/274b63e9723ec00dd…
Wim
15 Feb
15 Feb
12:29 p.m.
On Tue, Feb 14, 2023 at 04:55:00PM +0100, Wim Taymans wrote:
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
BTW, what
about the 'signed differences' issue I pointed
out earlier ?
Should be fixed with this:
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/274b63e9723ec00dd…
642
days inactive
682
days old
linux-audio-dev@lists.linuxaudio.org
32 comments
12 participants
participants (12)
-
Bengt Gördén -
Dominique Michel -
Fons Adriaensen -
John Rigg -
Len Ovens -
Lorenzo Sutton -
Marc Lavallée -
Rui Nuno Capela -
Will Godfrey -
Wim Taymans -
Yann Collette -
ycollette.nospam＠free.fr