The Dec 2020 update to the Raspberry Pi OS now uses pulseaudio and it broke my setup. Reading around, all sounds a bit complicated and I don’t understand it, yet. But a little trial and error got a workaround, using a USB soundcard.
First, switch to the USB Sound Card from the GUI top bar, as usual.
Then this commands lists the cards, result on mine below. My USB card is called Device
cat /proc/asound/cards
0 [b1 ]: bcm2835_hdmi - bcm2835 HDMI 1
bcm2835 HDMI 1
1 [Headphones ]: bcm2835_headphonbcm2835 Headphones - bcm2835 Headphones
bcm2835 Headphones
2 [Device ]: USB-Audio - USB Audio Device
GeneralPlus USB Audio Device at usb-0000:01:00.0-1.3, full speed
Then run this to start Jack with the USB card. Has to be before you start Sonic Pi. I’m guessing but it seems that SPi starts it’s own Jack server on startup? So this one gets in first (sorry for the technical language)
jackd -d alsa --device hw:Device &
Then let there be sound! (Fiat Sonus?) OK, I use a USB soundcard on my Windows machines to avoid all the typical onboard sound/driver problems. So if this is robust workaround, I’ve no problem with it. Be nice if I could tweak some SPi code to run it for me.
To clarify your thoughts Sonic Pi is designed to check for a running jackd when it starts, and if so to make use of that. If not it launches jackd itself.
Sonic Pi 3.2.2 utilises the .asoundrc file to check which sound card to use, and if it doesn’t find one it defaults to connecting to sound card 0 which is usually HDMI so if you don’t have speakers in your monitor you wont hear anything. The foundation supplied Sonic Pi 3.1 (still in the new OS) didn’t have sound card selection implemented, and so also uses HDMI sound.
The new OS no longer uses or updates .asoundrc so it doesn’t work for sound card selection. The OS does I think let you use this even if there is a pulseaudio proram using it too. This will not be the cause at present if you select another sound card using jackd.
It is probably best not to select the same card with the new audio selector on the menu bar in that case.
For greater flexibility in specifying different sample rates or connecting audio inputs to SP you may wnat to enable QjackCtl in the Main Menu editor (in Preferences on the Pi Main Menu ). It is in the Sound & Video Section.
You can then use this to configure and start jackd before starting Sonic Pi.
In either case, if you are using an external jackd dont forget to kill it when you finish, or you wont be able to use that card with pulseaudio (until you reboot).
Work is going on to try and improve the sound selection, but things are still changing in the pulseaudio setup (for example not all outputs seem to support stereo at present, and the 3.5mm jack output can’t be used when HDMI2 is active. (see discussions here) Some work has also gone on to see if a pulseaudio driver could be added to SuperCollider, which seems to work in early trials, but requires further work and may take some time to be adopted, especially as problems with SuperCollider and the latest MacOS Big Sur will demand a higher priority for solution. Neither of these is fully under Sonic Pi’s control.
Thanks for that. That explains the jackd startup. I had read about the .asoundrc file (one of the many things recommended), tried it but it seemed to have no effect.
Am I right in thinking that having a USB soundcard sidesteps some of the problems there seem to be around the AV Jack and HDMI outputs? At one level I’d like to understand how to set these things up. But at another level I’d just like it to work.
QjackCtl does make it simpler I agree, handling both the Jack startup and the MIDI connection, thanks. I’ve now left the audio selector on the menu bar on AV jack, and the QjackCtl profile to use ‘Device’ the USB card.
I tried playing at YT vid, and that comes through the headphone socket at the same time as SPi/PD coming through the USB card. Which is a good - what I might hope for but not expect
Do you think this a robust setup?
EDIT - having moved to a USB soundcard, that opens the door to use the new RPi 400 which looked like a good idea, apart from there being no headphone jack. Self contained, with a big passive heatsink.
That’s what I’m thinking. I found the after-market cases for the RPi to be…ah…variable. I had to try a couple, and gave up trying after one I got turned out to have a lid that doesn’t even screw on…so it’s now held on with an elastic band. On one hand that appeals, on the other other, meh.
But aside from that, can I press you on whether you think using a USB soundcard (or nice external interface) is going to be robust against changes out of the blue from the RPI people like this pulseaudio one? Speaking as you do from a position of understanding it, rather than my trial and error approach?
A quote from that Rpi update blog goes “PulseAudio is effectively a layer that sits on top of ALSA; it still uses ALSA to communicate with some devices. So ALSA is not removed from your system when you install PulseAudio; indeed PulseAudio wouldn’t work if it was…”
Well I’ve used a range of usb cards with raspberry pi and sonic pi for several years including cheapy USB dongles like techrise usb sound card from Amazon for about £9 or a more expensive interace like Steinberg UR22MkII. Others here use FocusRite interfaces which work well, so yes I think they are fine. They will work with both pulseaudio and jack outputs.
If, and ONLY if, you are using a Raspberry Pi with the latest Raspberry Pi OS (released on 2020-12-02) you might like to try this experimental solution to enable Sonic Pi 3.2.2 to utilise the new pulseaudio environment used in that version of the OS. Please read the READMEFIRST.md file for details of how to install the one file that needs to be changed, and remember to install the pulseaudio-module-jack package using sudo apt install pulseaudio-module-jack
I would appreciate feedback on how this works out for you. I have tested the change fairly throughly and it seems to work.
It worked! Following your advise, I managed to get sound out of Sonic Pi on my Raspberry Pi 4B.
Thanks for your help. Your work is incredibly wonderful.
@robin.newman thank you for this, I will give it a go hopefully this week. Attempting to learn a bit about the background I read this https://jackaudio.org/faq/pulseaudio_and_jack.html which I’ll share maybe for the benefit of others. One snippet I guess explains why the RPi people want to use Pulseaudio - as they seem everywhere to be promoting the RPi as a valid desktop-PC option, away from it’s roots as a DIY toolkit kind of thing…
PulseAudio is focused on desktop and mobile audio needs. It doesn’t try to address low latency usage, but does provide seamless device switching, network routing, global per-application volume control and lots more great stuff.
JACK is focused on the needs of pro-audio and music creation users. It offers the lowest possible latency, complete routing flexibility between applications and audio hardware, and all audio is always sample synchronized - apps don’t run ahead or behind of others. It doesn’t provide the smooth desktop experience that PulseAudio is aiming at."
Reminds me of the WASAPI vs ASIO choice on Windows, is that a valid comparison? I don’t understand the guts of those either, but the user experience is as above.
The article lists the various ways you can use them on the same system, including the ‘separate sound card’ approach.
I guess the issue with SPi is that it’s aimed at both camps - ‘music creation users’ who are prepared to put up with some setup fuss, and more casual/education users who want it work out of the box.
The pulseaudio solution is fine as you say if latency is not a critical issue, and it allows other sound sources to be heard simultaneously. The good thing is that if it is, you will still be able to launch jack from say QjackCtl and configure it directly for a sound card, to be used in such situations. For most people who need this, that should be a feasible option, whereas, just to play some code on SP will be simpler using pulse, so you get the best of both worlds.
Although I can now connect an Anker bluetooth speaker to Raspberry Pi easily, I have not yet managed to get this to cooperate with SP.
I think that’s going to be my mode. I’m slightly wary of deviating from the vanilla RPi OS - not that I can’t do it but I don’ want to have to when they make some arbirtary change in the future. Then a music session can turn into an IT session.
I’ve heard that an RPI can be bricked if the power is lost. I’m surprised, but defo read that, and it’s easy to lose power. Reinstalling isn’t a major drama, but if there’s too many mods to remember it’s a pain.
I’ve just managed to get my SP 3.2.2 running on a Pi400 with the latest OS and patched with the new scsynthexternal.rb detailed above running with my BT speaker which is great.
A glimpse into the future: Pipewire might be the solution to the Linux audio confusion.
Nevertheless I think you will always have to put some more energy into your system configuration as soon as you need professional audio features (I assume that this is also the case on Windows and Mac OSX - allthough it might be easier and more unified).
Hum hum the project is not new, 2017, and the official website is not very well documented. The scheme on the github can fear . Have you played with it ?
to install myself later thanks to your .deb (
. Have you played with it ?
Aaah, now I see 
