Config - use pipewire by default on linux/Raspberry Pi

[samaaron]

add new audio-settings config "linux_use_pipewire" which if set to false will revert the audio back to pulse audio.

[samaaron]

@rbnpi - if you think this approach is worth taking, this code definitely needs testing :-)

[porras]

I just logged in to PR something very similar 😂 dev...porras:sonic-pi:pipewire

I did a couple of things differently (for your consideration):

• I did go "autodetect" route instead of configuration because it's the simplest I could think of. Less flexible though
• Searching for hdmi seems to be the right thing for raspberry but I don't think it is in (all?) linux desktops. In those I could check (including flatpak, which is my guess for what most people would use outside of raspberry) it is alsa_output. I wrote a check for those two things, but maybe it's better to ignore that part and search for the first playback_FL and playback_FR. I don't know if that could fail in some setups (with multiple sound cards or something)
• [This one is important, I think it won't work otherwise] The regular expression for SC output 1 needs a $ sign at the end. In Linux SC is started with 16 outputs, so not only out_1 will match but also out_10, out_11, etc.
• I did the pw-link output processing in Ruby for cleanness. Of course this is a matter of style/taste, so feel free to ignore it. I had done it in a separate commit for you to be easier not to take :)

Sorry for the confusion, I started hacking on this some days ago (when I added it to the flatpak as a patch, without the raspberry or backwards compatibility part) but was only ready to PR it today, and missed this PR 🙃

[samaaron]

@porras this looks good to me. I have no attachment to my PR - I just think that we need to move to pipe wire by default on Linux/pi.

@rbnpi do you have any thoughts on this? I'd be happy to merge this if it already improves the flatpak situation and will work on the Pi too.

[rbnpi]

Hi Sam
Apologies for not spotting this. I have tried it out and it works fine. Fine to add it.
It is still a bit of a rigmarole to change over, in that it requires the Following steps.
1 Run Sp under pipewire (using the "start_sonic-pi_with_pw-jack" script) to setup the config toml file in .sonic-pi/config
2 quit, and edit the settings file to set linux_use_pipewire=false
3 run sudo raspi-config and in the advanced settings change the default audio to pulse
4 reboot and then restart sonic pi using the original "sonic-pi" script in sonic-pi/bin/

I need to add pulseaudio-module-jack back to the distribution as I had dropped it.

To go back reverse the process. resetting the config flag, then using raspi-config to set the audio to pipewire then rebooting.
One problem is starting up SP for the wrong configuration. eg using start for pipewire when the audio is set to pluse, or using the sonic pi script to start when it is set to pipewire. Sonic Pi will start up, but you wont be able to connect any sound.

Starting under Pulse has the advantage that the volume control will switch sonic pi to the audio device it selects. One bug is that it will NOT control the volume of connected bluetooth devices. You need to use the SP volume control or the control on the bluetooth device. Other connected devices eg sound from a web browser has the same problem, so its not Sonic PI.

It is probably best to install pavucontrol for pulse operation. This then lets you control output volume OK, and to switch Sonic Pi on other apps to independent outputs if you want to.

All of this needs mechanisms to impart the information to users. I foresee the needs of a video or two and or detailed instructions for each scenario. For the basic user the pipewire default will be pretty good, apart from the situation where they don't have an hdmi speaker. One good improvement would be to incorporate code like the output switcher script I have detailed into SP and maybe have a panel to allow switching. The script is essentially similar to the run_post_start_commands, but allowing you to choose different possibilities for connections by allowing you to change the 'hdmi' to 'usb' or 'audio' or 'bluez_output'

I can add a bit to the Build instructions describing how to run under pulse rather than pipewire. I also have to add the startup script mentioned above to the distro, and also a change to pi-build_gui.sh adding an environmental variable QT_INSTALL_LOCATION=/usr/lib/qt6 just before it calls gthe linux_build_gui.sh script. to set the location of the installed qt6 packages. This is fine for Rpi but may be more problematic for different linux distros to add as the location may vary, Would you prefer a separate Using Sonic Pi on Raspberry Pi document rather than having everything in the build documentation as I have done so far?

EDIT I did try to load the old 3.2.2 deb file which is on debian, but it screwed up my OS. Not sure why, and I'll try again, but once I have another SD card set up to experiment. I will examine the contents to see what packages it tries to install.

[samaaron]

Hi @rbnpi,

Why would someone want to change to pulse audio anyway? If you have to change the settings in raspy-config then that's already pretty involved, so editing the audio settings toml file isn't too much further of an ask.

Also, perhaps dev...porras:sonic-pi:pipewire is a better approach by @porras? This autodetects things rather than having to manually edit toml files.

With respect to patching v3.2.2 - could we get away with something like dev...porras:sonic-pi:pipewire there too?

I personally think we should just focus on one audio system going forwards - pipe wire. Trying to support multiple systems feels like too much of a headache.

[samaaron]

Also, and perhaps most importantly, shouldn't we be using pipewire-jack instead of jackd in Jackbooter?

@porras, @rbnpi have either of you already tried this?

[rbnpi]

Yes I have. Wrote comments on the PR you asked me to review. Robin

…

On 29 Oct 2023, at 21:09, Sam Aaron ***@***.***> wrote: Also, and perhaps most importantly, shouldn't we be using pipewire-jack instead of jackd in Jackbooter? @porras <https://github.com/porras>, @rbnpi <https://github.com/rbnpi> have either of you already tried this? — Reply to this email directly, view it on GitHub <#3345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKUHCI473ZUT5UXB7IBTFLYB2ZYFAVCNFSM6AAAAAA6SX4OXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGIZDKOBUGM>. You are receiving this because you were mentioned.

[samaaron]

Yes I have. Wrote comments on the PR you asked me to review. Robin

Could you share a link to that here - I can't seem to find it.

[rbnpi]

Oops my mistake. I only looked quickly at your previous comment and thought it was referring to your changes to daemon.rb I have tried the @porras version now and it seems to work, I take his point about allowing for out_10 possible connedctions and changing the match condition. I think his code is a bit neater than mine.
I'm distracted at the moment by bluetooth connection issues again. I don't think it is due to SP,although as pipewire is a bit of an addition it may be related to that, but I'm finding it difficult to resolve. Devices which have connected and worked OK suddenly will pair, but not connect to audio. Iv'e tried all sorts including restarts but teh problme persists. I think there must be some corrupted connection info stored somewhere which is causing this. I have both mono and stereo bluetooth speakers and maybe they don't mix well.

[porras]

Also, and perhaps most importantly, shouldn't we be using pipewire-jack instead of jackd in Jackbooter?

If I'm not mistaken, it is not necessary to boot anything when using pipewire. Pipeware itself will be running since system startup, and that's enough for jack clients to connect, as long as they use pipewire's ABI compatible libjack instead of jack's. That's what the pw-jack wrapper does, tuning the load path to make sure that any executable uses pipewire's libjack. That's why on my branch I added an explicit check to skip calling jackbooter. This works on linux flatpak at least, and I think it should be the same in raspberry.

So imo jackbooter can stay as it is for "legacy" users in absence of pipewire (and be removed entirely if in the future that compatibility is dropped).

BTW, would it help if I actually create a PR for my branch or would it add more noise?

[samaaron]

BTW, would it help if I actually create a PR for my branch or would it add more noise?

Please do! I think it would also make sense to explicitly skip JackBooter on Raspberry Pi OS too.

If necessary I could add the toml config stuff on top to allow explicit choice during boot in the future - but let's see how far this gets us. I'm all in favour of reducing the surface area on Linux, so going pipe wire only feels like a very sensible move.