[00:44] Eickmeyer: "autojack expects pulseaudio" Thats coming to an end... but not sure I'll be there in time. [00:48] OvenWerks: Right, that's causing problems for people who merely install "ubuntustudio-installer" as it depends on studio-controls which installs autojack which tries to restart pulseaudio which causes havoc on pipewire. Pipewire is default on Ubuntu Desktop already as of 22.10 [00:50] Basically, the change I uploaded to Lunar needs to be SRU'd to Kinetic for that compatibility. [00:51] Ah, ok. [00:54] OvenWerks: If you can't get the changes done to studio-controls, I might have to make some default config changes in lunar that allow for a pipewire-jack configuration that conflicts with studio-controls. Still hashing that out. [18:59] OvenWerks: Got some fairly unfortunate news. Apparently, pulseaudio and pipewire-pulse are not coinstallable since they functionally overlap. Therefore, a simple switch between the two with studio-controls will not work and must be done with packaging. Still working on this. [18:59] Eickmeyer: that is not true [19:00] I have both installed right now [19:00] Right, but what is the DE using? [19:00] right now PW [19:00] How do you switch to pulse? [19:00] systemctl enable/disable works [19:01] Oh, that's cool. [19:01] Basically, if both are installed, pulse will grab the socket first and pw will drop out [19:01] disable pulse and pw will grab things and go. [19:02] I have even been able to do it without reboot. [19:02] Ok, then that leaves me worried from a seeding perspective if we want both installed by default but PW enabled by default. [19:04] one of two things, the meta can do a preinstall to disable or to remove the symbolic link [19:04] (same thing really) [19:04] Except one problem: .iso images aren't built with metas, they're built with tasks. [19:05] do those tasks include installing packages? [19:06] Yes, but I'm not sure how that all works. It's quite a bit different than installing the metas as defined by the ubuntustudio-meta since it grabs directly from the seed itself. [19:07] It's partially why packages on the .iso aren't necessarily marked as "auto". [19:08] Additionally, the metas don't have a pre/postinst script. [19:08] Couls we include this in ubuntustudio-default-settings? [19:08] Germinate doesn't have a facility for it. [19:09] We can, and that's one thing I'm working on in ubuntustudio-default-settings. I already have a "ubuntustudio-pipewire-config" package I've been working on. I can probably do a "systemctl disable pipewire" or something to that effect inside its postinst. [19:09] autojack, while not set to do this as yet could set the switch one way or the other [19:10] Actually you might to disable pulse [19:10] Better yet, mask pulse altogether and unmask it when removing the package. [19:11] controls/autojack can (do) check for what is actually installed and running on first run. [19:11] There we go. I think we have a solution. [19:12] For most people I think pw mode will just work for them [19:12] Those who have a good idea what they are doing might want something else. [19:13] Perhaps to finish a project [19:13] Right. [19:13] (though they will have to deal with a different version of DAW possibly anyway) [19:13] The config I've been making installs a file to /etc/profile.d/ubuntustudio-pwjack.sh which sets the environment variables necessary for pipewire-jack. [19:14] It removes that upon uninstallation. [19:14] Also includes a script to change the buffer size. [19:15] Defaults to 1024 [19:16] Though, I've found, each JACK client can set its own buffer size and that the buffer isn't global. [19:16] is that all? pwjack installs a file in /etc/ld.so.conf.d to set the libpath already so don't add that to the environment [19:17] Actually, it doesn't. At least not in lunar. [19:17] (controls adds/removes that file for switching purposes) [19:18] I tried it and all JACK clients would scream that JACK wasn't running until I added the necessary environment variables. [19:19] the contents of that file: /etc/ld.so.conf.d/pipewire-jack.conf should be: ls -d /usr/lib/*/pipewire*/jack/ > /etc/ld.so.conf.d/pipewire-jack.conf [19:20] I guess it makes more sense to say I create that file with the line: ls -d /usr/lib/*/pipewire*/jack/ > /etc/ld.so.conf.d/pipewire-jack.conf [19:21] It has to be run as sudo of course [19:21] In controls case it is run with pkexec [19:23] This is the manner that upstream does things [19:23] Unfortunately, that file doesn't exist in lunar. [19:23] with pipewire-jack installed. [19:24] I understand but a preinstall that creates the file you are creating could just as easily create this one. [19:25] one of the packages in: https://launchpad.net/~pipewire-debian/+archive/ubuntu/pipewire-upstream must put that line in. [19:26] Well, we have to do this using the Ubuntu packages, not that. [19:27] yes but that is not the point. Adding an environment variable is not the right way to make the pw libjack active [19:28] It is according to every single document I found. The pw-jack executable is merely a wrapper that sets the environment variables so that JACk applications can connect to JACK. This sets them system-wide. [19:29] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-JACK [19:29] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-JACK#installation to be exact [19:30] "You also need to to create a file /etc/ld.so.conf.d/pipewire-jack-x86_64.conf containing a link to the JACK modules:" [19:30] Like I said upstream pw recommends this way [19:30] Yes. PIPEWIRE_QUANTUM and LD_LIBRARY_PATH are the two environment variables that PIPEWIRE THEMSELVES SET in pw-jack. [19:31] export PIPEWIRE_QUANTUM="1024/48000" [19:31] export LD_LIBRARY_PATH='/usr/${LIB}/pipewire-0.3/jack' [19:31] yes but that is just for running a jack application when the lib is not set up [19:31] This sets the lib up. [19:31] I have looked at that file as well. [19:31] It works. Trust me. I've tested it ad-nauseum. [19:32] but that is not needed to make things work if the installation procedure laid out in the pw documentation is followed [19:32] The installation procedure also works [19:33] Ok, then why isn't the Ubuntu package installing it correctly then? [19:33] Good question [19:33] My point is we need to work with what we've got until that is fixed. It's in main, so I can't fix it. [19:33] if you are going to install a file install the correct one [19:34] What does that file contain then? [19:35] the file can be created with this line: ls -d /usr/lib/*/pipewire*/jack/ > /etc/ld.so.conf.d/pipewire-jack.conf [19:35] the documentation says the line in the file is /usr/lib64/pipewire-0.3/jack/ [19:35] but... I figure the line I use will still work if the version specific line they use changes [19:36] ]That is for pw-jack 0.4 or something [19:38] which version of pw (or pw jack) does ubuntu use in main? The documentation says "This configuration issue should be fixed in later versions but as of 0.3.21+ it is still an issue." [19:39] it may be the package I am using is newer? [19:39] Let me see. [19:41] No, your package is older. Lunar has 0.3.63 in proposed already. [19:41] Yup [19:41] so different packaging [19:42] Yep. The packaging is straight from Debian, synced. [19:42] And it's in main, so I'm not allowed to touch it. [19:43] Thats ok [19:45] Figured it out: Debian interprets the ld.so.conf.d stuff as examples, not "the way to do it." Basically, there's more than one way to skin a cat. [19:45] They install it, but to /usr/share/doc/pipewire/examples/ld.so.conf.d [19:46] by not putting it in /etc/ they leave jackd working [19:46] Correct. What's nice about the way I'm doing it is it's a simple package install/uninstall. [19:46] this means that by not installing pulse, pw works for all desktop applications while jack users still use jack [19:47] the way you are doing it breaks controls [19:47] The way I'm doing it helps people who might not want controls. [19:47] i.e. users of other flavors. [19:48] yes but using the upstream method works for them as well [19:48] And it has the benefit that all distros can work the same [19:49] Right, except Arch's documentation about pipewire-jack don't even mention the upstream method and mention setting an environment variable. [19:49] wonderful... [19:50] The package I'm using comes from a arch user :P [19:50] life is complicated [19:51] I think we're in a situation of scope creep here. [19:51] I guess I can search for that file and -x it? [19:51] Well, anything in profile.d gets executed regardless of executable bit as long as the extension is .sh, so it could be renamed from .sh. [19:52] In any case, I would ask that the installation method speced by upstream developers would be the way to go. [19:53] You're not wrong, but, in order for controls to work with it, distros have to agree on that as well. Right now, there seems to be confusion. [19:53] Debian sees it as optional, and Arch has the "Arch Way". [19:54] That is ok, someone sends me an issue/bugreport I can at least point at the upstream installation and say if your distro doesn't do it that way, I can't help you. [19:57] I guess controls will have to do a breaks/replaces for that package [19:58] There is not really any difference between rename and nuke [19:59] either one will mess with upgrades I would imagine [20:00] OvenWerks: I'm already on it. Right now, that package is definitely on Breaks: studio-controls [20:01] As far as upgrades, still working on that. I might be able to maneuver around that. [20:01] If the file is installed as part of postinstall it is probably ok [20:01] It is, and removed as part of prerm. [20:02] In fact, it's dynamically generated by a new command: ubuntustudio-pwjack which lets the user set the default buffer size. [20:02] Upon installation, it sets it to 1024. [20:02] So the only problem for me would be to look for it and nuke it if found [20:03] (if switching to jack) [20:04] Honestly, it would need to be renamed to remove the .sh extension and then the user would have to relog. That's it. [20:10] yes but the upgrade would not see the renamed file and just create a new file. [20:12] As a sw dev creating something for the whole of the ecosystem, I have to use what upstream uses, not some kludge in some directory other than that. If using the upstream method doesn't work I have to point the user at their distro to submit a bug. [20:15] Right, which is precisely why I'm setting a Breaks: line in the packaging. [22:06] OvenWerks: The biggest problem I have with installing anything directly into /etc (as opposed to dynamically writing it) is that it requires a purge to remove it or if a newer version gets installed it requires user intervention. [22:06] So, believe me, I'm trying to figure out how to work ld.so.conf.d in. [22:07] I just can't guarantee full ownership of it. [22:07] It's a namespace issue and the archive admins are going to stomp all over me. [22:33] OvenWerks: I figured it out. I can symlink pipewire-jack.conf -> /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*-linux-gnu.conf (to keep it ok for all archs) and it'll just work. I'll have to keep the other file for the PIPEWIRE_QUANTUM variable, but this one does the LD_LIBRARY stuff. [22:50] OvenWerks: Bad news, the symlink doesn't work. It still wants the environment variable set somehow. [22:52] I can make the variable LD_LIBRARY_PATH=$(cat /etc/ld.so.conf.d/pipewire-jack.conf) and have it export that, but it has to have something in that variable otherwise it's completely broken. [22:58] Actually, it'll be LD_LIBRARY_PATH=$(cat /etc/ld.so.conf.d/pipewire-jack.conf || true), that way it retuns empty if studio-controls removes the pipewire-jack.conf file. [23:25] OvenWerks: Nevermind. Got the symlink to work. I forgot to put ldconfig in the postinst. [23:25] I can remove the Breaks: line now. [23:25] Ladies and gentlemen, we have a Pipewire configuration that doesn't break anything.