[04:01] <arraybolt3[m]> Wow, git and quilt turned out to be a bigger battle than I thought, so I still have more to do tomorrow before helping with PipeWire, but I still intend to do stuff with PipeWire.
[04:05] <Eickmeyer> arraybolt3[m]: We appreciate it. I'm heading to bed myself after doing a bunch of package backporting to the backports PPA.
[05:43] <arraybolt3[m]> For whenever anyone sees this, is disabling, masking, and enabling systemd units an acceptable way of turning sound subsystems on and off? If so, I have learned how to stop PulseAudio and start PipeWire without a reboot, and I'm pretty sure I can do the reverse, too.
[05:44] <arraybolt3[m]> Yep, I can do the reverse.
[05:54] <OvenWerks> arraybolt3[m]: That will probably work for pulse, for jack things are different because there are two libs to switch out.
[05:56] <arraybolt3[m]> OK. Well that's at least 25% of the list done (I can disable PulseAudio and plug in PipeWire and have audio work in an Ubuntu Studio Kinetic VM).
[05:57] <arraybolt3[m]> While you're right here, what benefit is there to running PipeWire without also running the PulseAudio component? Do you, like, run Pulseaudio to do your audio, and then use PipeWire as a backend for JACK to do stuff that it then runs through PulseAudio? (Random shot in the dark here, I've used Pulse, I know some about PipeWire, and I've used JACK quite a bit, but I have no idea if what I just said is correct.)
[05:59] <arraybolt3[m]> Oh, I see that PipeWire works kinda like JACK.
[15:34] <OvenWerks> arraybolt3[m]: pw is like a combination of pulse and jack (similar to what we do with controls)
[15:35] <OvenWerks> for most people, just using PW as both pulse and jack as it comes out of the box might work just fine.
[15:36] <OvenWerks> However, the ALSA firewire implementation is unstable and high latency.
[15:39] <OvenWerks> So it is pretty much useless for anyone having a FW device. The problem being that there seems to be (as yet) no newer devices that work as well as these older devices ( the new batch of USB 2 boxes are not as good as most fw boxes) making difficult for people to just downgrade to newer interfaces.
[15:41] <OvenWerks> Of course many of us have refused to marry churn and so it is painful to spend money on a new product when the old one works very well.
[15:44] <OvenWerks> arraybolt3[m]: The perfect end result, would be to run PW to replace most of what studio-controls does with bridging and to have a ffado backend in PW. That will not happen.
[15:45] <OvenWerks> arraybolt3[m]: the second best would be to use PW to replace everything but be able to use jack as a device for PW. This is supposed to work already, at least for ALSA devices in jack.
[15:47] <OvenWerks> arraybolt3[m]: when jack requests a device from PW, PW will release that device and automatically set up a PW-jack bridge with the same number of i/o as the device it released.
[15:49] <OvenWerks> The problem is, the only reason to use this feature would be when jack is started with a non-ALSA device and so PW would not be aware it needed to make a bridge. The documentation does not tell us how to make a PW-jack bridge manually and the author considers such a thing not required because it is already automated.
[15:50] <OvenWerks> arraybolt3[m]: some of these things may have changed since I last talked to Wim so I don't know.
[15:51] <OvenWerks> arraybolt3[m]: I also don't know what PW does with MIDI.... because I haven't got that far  :)
[17:22] <OvenWerks> arraybolt3[m]: probably at this point I should just live with my ICE1712 based device while I work it out. It is a bit noisier than the Audiofire 12 and has only 4 i/o but really, I only us 1/2 i/o anyway.