| OvenWerks | arraybolt3[m]: your experience is "expected" as I recall. | 00:54 |
|---|---|---|
| OvenWerks | once pw-jack (or whatever the package is called) is installed it becomes jackd in the same way that it becomes pulse. | 00:55 |
| OvenWerks | pw renames the real jackd libs (libjack-jackd2) to something else and renames it's libs to that | 00:56 |
| OvenWerks | It uses a script or some manual edit to do and undo it. | 00:56 |
| OvenWerks | That was the part I was talking about when I said I wanted to be able to turn pw-jack off and on at will :) | 00:57 |
| OvenWerks | arraybolt3[m]: I expect there is a pwctl (or similar) CLI utility command for starting a jack-jack bridge (or pw-jack bridge however it is called) and allows that bridge to make the real jackd master device for SR/framesize/framecount/jacktransport. Actaully I don't know if pw even supports jack transport | 00:59 |
| OvenWerks | WirePlumber is a separate project from PipeWire and as such has it's own design parameters and goals. Bridging to a real jack is likely outside anything they have even thought of as they are mostly interested in media playback for user entertainment and not audio production (from any of the stuff I have read on it) | 01:02 |
| OvenWerks | arraybolt3[m]: To be honest, my end goal would be to run either pw as pulse/jack, pw as pulse/jack with jackd as a device or pw as pulse with pw bridged to jack as pulse style ports. | 01:14 |
| arraybolt3[m] | OvenWerks: Actually, in Kinetic, there's no problem having PipeWire and jackd installed side-by-side - the packaging keeps them from conflicting. It was a PPA that threw a wrench in the works. With the default package, everything defaults to jackd, but if you run it with the "pw-jack" command, it plops a snippet of code in $LD_LIBRARY_PATH to point to the PipeWire JACK libraries, so you can switch between them at will. | 01:16 |
| OvenWerks | arraybolt3[m]: yes... but | 01:17 |
| arraybolt3[m] | OvenWerks: Your "pwctl" idea sounds good, I'll look into it. | 01:17 |
| OvenWerks | there is another way where the pw jack lib takes over too. It is listed in the PW docs | 01:18 |
| arraybolt3[m] | Also, as far as my bit about WirePlumber, there's an interesting setting in a PipeWire session manager called "alsa.jack-device", who | 01:18 |
| arraybolt3[m] | which I believe does exactly what we want. | 01:18 |
| OvenWerks | possibly | 01:18 |
| arraybolt3[m] | It's present in both pipewire-session-manager and WirePlumber, but the WirePlumber version seems to error out and do nothing. | 01:18 |
| OvenWerks | I have not met with it yet :) | 01:18 |
| OvenWerks | AS I mentioned, it has been some time since I played with PW and most of what I know is from that time. | 01:19 |
| arraybolt3[m] | I'll look into the jackd takeover you're talking about, that's probably why the PPA failed. But I do know I can run jackd and PipeWire (from the Kinetic repositories) side-by-side, run carla all by itself and see the JACK patchbay, then run "pw-jack carla" and see the PipeWire patchbay. | 01:19 |
| OvenWerks | Yes I was able to do that with one of my setups | 01:20 |
| OvenWerks | The thing is, it was supposed to work that if jackd started with a device that pw knew about, then pw would automatically bridge jackd to pw with the exact number of ports to satisfy system:play* and system:capt* | 01:22 |
| arraybolt3[m] | OvenWerks: But then that doesn't happen when you do jackd with FFADO, thus why we need the PW-to-jackd bridge. | 01:24 |
| OvenWerks | I was not able to get that to work and it is not what I wanted anyway because the only devices pw sees are alsa devices and pw already handles alsa devices just fine | 01:24 |
| OvenWerks | right, it is jackd with other backends other than alsa I want to deal with | 01:24 |
| OvenWerks | ffado, jacknet, dummy, etc. | 01:25 |
| arraybolt3[m] | Oh. I thought we were trying to make it so that jackd consumed FFADO, fed it into a "JACK Device" bridge within its patchbay, then the PW patchbay would have a "JACK Device" device in it, allowing you to connect FFADO to PipeWire. | 01:25 |
| OvenWerks | That would be great. | 01:25 |
| OvenWerks | That would allow studio-controls to move forward from pulse to pw | 01:26 |
| arraybolt3[m] | That's what one guy pulled off with Fedora in that one link, using the "alsa.jack-device" setting. https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1196#note_923472 | 01:26 |
| ubottu | Issue 1196 in pipewire/pipewire "Replacement for pulseaudio-module-jack" [Opened] | 01:26 |
| arraybolt3[m] | Actually, he's not on Fedora, he's on openSUSE Tumbleweed. | 01:27 |
| arraybolt3[m] | Since this "jackd-to-PW bridge" works using pipewire-media-session for this person, this is where I'm thinking our solution most likely lies. Sadly, I couldn't get audio to come out of my VM at all when using pipewire-media-session... | 01:28 |
| OvenWerks | which distro he is on should not matter as the configuration is uniform across usage | 01:28 |
| OvenWerks | :) | 01:28 |
| arraybolt3[m] | Well, the package versions can still be different, but we're in pre-feature-freeze, so we have a fighting chance at getting a good version in there. | 01:29 |
| arraybolt3[m] | Hey, made some progress! I still can't get audio out of the VM with pipewire-media-session, but I just got a bit of a JACK patchbay! | 01:44 |
| arraybolt3[m] | Possibly silly question, but are libraries located in the same directory as an application given higher priority than other libraries in the system? I may have just figured out why this isn't working. | 01:47 |
| OvenWerks | yes of course there is a LD_LIBRARY_PATH | 02:00 |
| arraybolt3[m] | Bah, it didn't work. The fancy "alsa.jack-device" option has a disclaimer that the session manager must be using the non-PipeWire JACK libraries for it to work, but no amount of fiddling with LD_LIBRARY_PATH and LD_PRELOAD is doing the trick. | 02:00 |
| OvenWerks | but it is not in the environment it is only fed to ld.so | 02:01 |
| OvenWerks | Yeah I kind of got the idea it was one of those things where one does a set/reboot/work kind of workfow | 02:02 |
| arraybolt3[m] | Oh. So maybe that's what I'm messing up? I'm trying stuff like "LD_LIBRARY_PATH=/lib wireplumber". | 02:02 |
| arraybolt3[m] | Every time I set the alsa.jack-device option to true, WirePlumber spits out this unhelpful error: "script/create-item create-item.lua:80:chunk: <WpSiAudioAdapter:0x556f19df5050> failed to activate item: Object activation aborted: proxy destroyed". | 02:03 |
| OvenWerks | You are starting to understand why I put pw integration back burner | 02:04 |
| arraybolt3[m] | LOL | 02:04 |
| OvenWerks | However, PW _is_ the future of desktop audio and not very far into the future. So, finding a way to bridge things is important. | 02:07 |
| OvenWerks | I would be happy to leave things in the must run pwjack using pw_jack application, if I can create as many pw/jack bridges as I like or even if I can create a pw/jack bridge with any number of ports I feel like and name them as I like (I think I can set names already) | 02:10 |
| arraybolt3[m] | Sounds good. Hey, you know your pw-cli thing you were talking about? I think I just found the command, maybe that will give me a more useful error message. | 02:10 |
| OvenWerks | I am not oposed to using pw as jack so long as I can use jackd as a device. | 02:11 |
| arraybolt3[m] | OvenWerks: Exactly. In fact, I think that's the end goal. | 02:11 |
| arraybolt3[m] | (Typing furiously in a Ubuntu Studio VM while we chat, I think I'm >< this close to it working) | 02:12 |
| OvenWerks | arraybolt3[m]: for most people (99%?) just using PW with no jack will take care of all their needs. | 02:13 |
| OvenWerks | FW devices are a very small number anymore. | 02:13 |
| OvenWerks | for an even smaller number of people, jackd1 is all they are interested in ever using | 02:14 |
| arraybolt3[m] | OvenWerks: Given the fit everyone threw when Windows 11 deprecated a bunch of old CPUs, I think deprecating FW devices is probably not in our best interest, thus why this is a good idea. | 02:14 |
| OvenWerks | There are (in my opinion) no good replacements for FW devices running on jackd using the ffado backend | 02:15 |
| OvenWerks | There are a few PCIe devices such as AudioScience devices and other broadcast oriented devices. networked devices (Dante, AES67, AVB) that are setting themselves up to take over the audio world too. | 02:17 |
| arraybolt3[m] | Random possibly insane idea for in the event I can't get this to work - What if we made our own custom application that had two components - a jackd-connecting component and a PipeWire JACK-connecting component. Each one would expose input and output stereo audio channels, and would look like any other audio application. The two components would then talk to each other via a UNIX socket, sharing the audio data between the | 02:19 |
| arraybolt3[m] | two, and BAM, jackd bridged to PipeWire. | 02:19 |
| OvenWerks | unix socket not required, libzita, however would be required | 02:20 |
| OvenWerks | The problem with that kind of bridging is that pw would not be forced to sync to the bridge which is what we want. | 02:21 |
| arraybolt3[m] | OvenWerks: OK. Just whatever would allow the JACK end to shove audio into the PipeWire end and vice-versa. | 02:21 |
| arraybolt3[m] | Sorry if this is an ignorant question, but by "sync to the bridge", do you mean something like JACK Transport? | 02:21 |
| OvenWerks | so libzita would be needed for SRC | 02:21 |
| OvenWerks | no not jack transport but audio media clock | 02:22 |
| arraybolt3[m] | OvenWerks: Oh, I get it. Kinda like the "48KHz In" port in the back of my keyboard? | 02:22 |
| arraybolt3[m] | OvenWerks: I can make that thing make so many weird noises if I tell it to use the external clock input but don't connect anything to the clock port. | 02:22 |
| arraybolt3[m] | I'm assuming that's the kind of thing we're trying to avoid. | 02:23 |
| OvenWerks | Studio-controls does all this behind the scenes right now. The master jack device is system sync but all "extra" devices even if they are running at the "same" clock rate need to be synced to the same clock via src to avoid pops and clicks | 02:24 |
| OvenWerks | yeah, that kind of thing. But our main audio device is the clock we want to use for (semi)pro audio | 02:25 |
| arraybolt3[m] | So the problem is that my idea would result in everything PipeWire being synced together, and everything JACK synced together, but then PipeWire and JACK would be out of sync with each other? | 02:25 |
| arraybolt3[m] | But you're saying that libzita would solve the problem, right? | 02:25 |
| OvenWerks | In general we want to have one device only and just use it's sync or word clock to all devices | 02:25 |
| OvenWerks | no libzita would make things work but not allow jack's master device to provide system clock. | 02:26 |
| OvenWerks | with pulse/jack bridged, jack actually forces pulse to run at jack's SR and latency. you can watch this by looking at pulse's cpu usage with different farme sizes in jackd. | 02:27 |
| arraybolt3[m] | OK, another silly idea, but what if JACK was synced to the master device, and PipeWire was synced to the custom application? Would that pipe the clock sync through, too? | 02:28 |
| OvenWerks | in fact this is why controls tells pulse _not_ to look at any alsa device | 02:28 |
| OvenWerks | That is what the pw/jack bridge is supposed to do. | 02:28 |
| OvenWerks | it is just a matter of learning to use it and start it manually from the command line | 02:29 |
| arraybolt3[m] | OK. Well, I guess I'll keep fiddling with it then. If one guy can get it to work once, surely someone else should be able to get it to work too. | 02:30 |
| OvenWerks | or learning to have it run automatically when jack is available | 02:30 |
| * OvenWerks wants bridges on demand ;) | 02:34 | |
| arraybolt3[m] | Bah, I went to open a bug report against WirePlumber and my new GitLab FreeDesktop account requires manual approval... | 02:39 |
| OvenWerks | oh, that is part of the "lets encourage people to send bug reports" program | 02:40 |
| arraybolt3[m] | LOL oh well. | 02:40 |
| arraybolt3[m] | OvenWerks: I think this is probably a PipeWire regression. It was working a year ago, but no amount of fighting with it is working for me now. I think the next step is probably a git bisect, but I'm far too brainfried to do that at this point. | 02:52 |
| arraybolt3[m] | Good news, finally got a GitLab FreeDesktop account. Turns out it needed me to confirm with an email, and it was slow sending the email so I missed it... But now if this inability to create a JACK device is a bug (which I suspect), we'll be able to report it! | 19:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!