It's not supported.
Continuing the jack/pipewire debate...
Moderators: raboof, MattKingUSA, khz
-
- Established Member
- Posts: 2083
- Joined: Mon Sep 28, 2015 8:06 pm
- Location: Here, of course!
- Has thanked: 232 times
- Been thanked: 400 times
- Contact:
Re: Continuing the jack/pipewire debate...
Thanks for letting me know. It doesn't affect me (my setup doesn't need any session management) but I know a few people who will be very disappointed
- Largos
- Established Member
- Posts: 639
- Joined: Mon Oct 05, 2020 12:21 pm
- Has thanked: 72 times
- Been thanked: 186 times
Re: Continuing the jack/pipewire debate...
Audiojunkie wrote: ↑Mon Oct 09, 2023 3:47 pmMon, Oct 9, 2023, 09:14:41 - sercanbrack: Is it still beneficial to use the /preempt=full and /threadirqs kernel parameters with a generic kernel to make the kernel run as a realtime kernel?
Mon, Oct 9, 2023, 09:15:05 - wtay: probably, I don't know
Mon, Oct 9, 2023, 09:15:24 - wtay: whatever works for jack will probably still work
I had a problem where my live audio monitoring through my firewire device was having an : annoying latency delay. Adding threadirqs to the kernel parameter has fixed this. So I would say it can still be beneficial. I haven't used prempt=full though
- rncbc
- Established Member
- Posts: 1071
- Joined: Mon Apr 19, 2010 12:20 pm
- Has thanked: 45 times
- Been thanked: 279 times
- Contact:
Re: Continuing the jack/pipewire debate...
if I am not mistaken, jack_session is a prerogative of jack clients that adopt and support it.
although it would be plain simple to add support to pipewire(-lib)jack (aka pw-jack API replacement) it's (probably) a choice of the pw upstream devs (quite literally they have read the "deprecated" writing-on-the-wall and chose to just not bother with it, go figure...; any thoughts @wtay?)
but still
in my thinking, if you, after all those years of bashing, still rely on jack_session, you may still have a friend on qjackctl as a jack_session manager, maybe forever... that said, it is going to stay always there, as long I keep the maintainer's helm
cheers
-
- Established Member
- Posts: 2083
- Joined: Mon Sep 28, 2015 8:06 pm
- Location: Here, of course!
- Has thanked: 232 times
- Been thanked: 400 times
- Contact:
Re: Continuing the jack/pipewire debate...
Thanks for this, very reassuring, and I'll pass the info on.
Just to add, I don't use this myself. In fact I don't use any session manager, but there are a number of Yoshimi users that do, and if some of our small band use it, then there are likely to be a lot of others that do!
Re: Continuing the jack/pipewire debate...
rncbc wrote: ↑Mon Feb 26, 2024 3:11 pmif I am not mistaken, jack_session is a prerogative of jack clients that adopt and support it.
although it would be plain simple to add support to pipewire(-lib)jack (aka pw-jack API replacement) it's (probably) a choice of the pw upstream devs (quite literally they have read the "deprecated" writing-on-the-wall and chose to just not bother with it, go figure...; any thoughts @wtay?)
Supporting deprecated API was not really a top priority.. but now that there is not much else to do, I guess I can give it a try.
Wim
-
- Established Member
- Posts: 47
- Joined: Fri Jun 09, 2023 9:55 am
- Has thanked: 61 times
- Been thanked: 15 times
- Contact:
Re: Continuing the jack/pipewire debate...
@wtay Is there any way to put MIDI ports on separate nodes? I currently have a single big block with Midi Through & friends.