[17:31] <bhechinger> OvenWerks/Eickmeyer : I got it working but it's setup more like it was before on JACK. null sinks that connect to Ardour and everything else connects to the sinks. It's not ideal, but it works. I really want to write a dynamic router for wireplumber now.
[17:33] <Eickmeyer> bhechinger: In Ubuntu Studio 24.04, I wrote a piece for Ubuntu Studio Audio Configuration that creates a null sink via graphical interface.
[17:33] <Eickmeyer> Also lets you have it on login if you want.
[17:35] <bhechinger> I was hoping to avoid that because technically you should be able to route directly between apps, but there isn't currently a good way to control what goes where. Using  qpwgraph keeps most connections up to date but the very dynamic nature of stuff like every firefox tab getting its own node made that not great.
[17:36] <bhechinger> So I had to create the sink so that I could set it as the default device in wireplumber
[17:36] <bhechinger> and the other sinks so I could use pav to control what goes where.
[17:40] <Eickmeyer> Unfortunately, applications that still rely on the old PulseAudio API still look for the default sink, so even if a session manager such as RaySession is running, they'll connect automatically to whatever RaySession has them connect to AND the default sink, so best to have them go to a null sink (or Dummy Audio device as I've labeled it) while
[17:40] <Eickmeyer> connecting to the DAW.
[17:53] <bhechinger> I should be able to circumvent that with a dynamic router module for wireplumber. It'll only go to the default sink if there are no routing rules for the input (which is my plan, assuming I ever write it)
[17:58] <Eickmeyer> I mean, theoretically that's a great idea, but PulseAudio applications don't recognize PipeWire's native API, so they just go to whatever the default sink is according to the PulseAudio API, so they'll never follow wireplumber. Or if they do, they'll follow wireplumber and whatever default sink is set in the PulseAudio API.
[18:19] <bhechinger> I don't think I've really messed with a pure pulseaudio client yet so I'd need to see how that behaves. In theory pipewire/wireplumber can (does?) control  the Pulse API since it's all emulated anyway.
[18:20] <OvenWerks> A dummy device has more advantages than just providing a default device.
[18:20] <OvenWerks> Though, that in itself is very usefull.
[18:20] <bhechinger> What the hell Spotify, why won't you start your audio?
[18:21] <bhechinger> Oh, PEBKAC.
[18:21] <bhechinger> There wasn't a song selected so the mini player at the bottom was grayed out. Oops. :-D
[18:24] <OvenWerks> With multi-io devices, many apploications when presented with 12 outputs will send audio to all of them, possibly with wierd processing on some of them. A dummy device also allows limiting an applications choice to two outputs only (or more for surround) and lets you define which output goes where. So rather than routing L&R to outputs 1&2 they can be routed to 6&7 if thats where your amplifier 
[18:24] <OvenWerks> happens to reside.
[18:25] <OvenWerks> Many audio devices use the last two outputs as there "monitor" outs rather then the first.
[18:26] <bhechinger> Speaking of which, is there a way to tell pipewire applications only have 2 outputs by default? I'm not ever going to do 5.1 here.
[18:27] <OvenWerks> Really, this is much the same as what we did before with pulse/jack bridging but with a better bridge. This bridge does not need to do it's own buffering.
[18:28] <bhechinger> Yeah, it took a while to figure out how to accomplish what I wanted but so far I'm really impressed with pipewire.
[18:28] <OvenWerks> Yes, set up a dummy device with two outputs the application can see. Or use pavucontrol to tell PW you want to use this device as a stereo device.
[18:28] <bhechinger> if pw-top is to be believed I'm getting way better latency than I ever got under jack
[18:29] <OvenWerks> The only way to know is to use a tool that measures the delay
[18:31] <OvenWerks> If you tell pulse/pw a device is stereo, you will loose access to the rest of the i/o, at least if it is an HDA type device. External devices I am not sure.
[18:31] <bhechinger> I don't like qpwgraph. I miss RaySession. :(
[18:32] <OvenWerks> I feel the same. I don't like qpwgraph either.... or at least I didn't last I used it ;)
[18:32] <OvenWerks>  I haven't done enough audio for a while to know.
[18:33] <bhechinger> So far none of the session managers come even close to RaySession's canvas
[18:34] <bhechinger> Hmmm, Ardour keeps crashing. :(
[18:35] <OvenWerks> use ardour with ALSA.
[18:36] <OvenWerks> There are still known issues with ardour and pw's jack graph... some of which may be fixed upstream but have not made it to debian/ubuntu.
[18:38] <bhechinger> How do I do that? I lose all my inputs
[18:40] <bhechinger> and output. Like it doesn't show up at all in qpwgraph
[18:41] <bhechinger> Maybe I won't start my midi thing I wrote, maybe I'm making this happen.
[18:42] <bhechinger> Guess I'll re-write that to support pipewire directly instead of through the jack emulation. :-D
[18:42] <bhechinger> (I write it before I converted)
[18:44] <bhechinger> I write it? I can totally English.
[18:44] <bhechinger> Ok, ardour just crashed again. Not my fault. :-D
[18:44] <bhechinger> OvenWerks: upstream for which, ardour or pipewire?
[18:55] <bhechinger> Hmm, Spotify seems to be the culprit.
[18:55] <bhechinger> Watching youtube and zero issues.
[19:09] <OvenWerks> Speaking of Ardour, I am finding that my version of studio's Guitarix plugins will crash Ardour if I use them in more than one channel.
[19:09] <OvenWerks> Pipewire upstream
[19:10] <OvenWerks> Paul wrote jack and Ardour is therefore completely compatable with jack. It is up to the PW dev to make sure pw is fully compatable with jack.
[19:13] <OvenWerks> I think Guitarix is still using gtk as gui.... so expected. Record one track, freeze, then record another.... or use outboard gear  ;)
[19:19] <bhechinger> Ah, the joys of linux. :-D
[19:20] <bhechinger> Looks like I'm on pipewire 0.3.85, not sure what ubuntu/debian is on
[19:21] <bhechinger> I could in theory move to 1.0.0
[19:21] <bhechinger> as that's what in unstable nixpkgs
[20:48] <Eickmeyer> bhechinger: That's why. 0.3.85 is for sure not even an RC.
[20:48] <Eickmeyer> bhechinger: Also, NixOS is *entirely* offtopic here.