I’m having an issue on my Raspberry Pi 4b with a pisound-micro hat where I cannot change the blocksize. It seems stuck at 64, which I believe is causing cpu spikes and audio dropouts even with simple Sine oscillators.
And I’ve tried forcing it in SuperCollider: `s.options.hardwareBufferSize = 128; s.options.blockSize = 128;
In both cases, SuperCollider either produces no sound or the logs show it has reverted to 64. When I check the jack status, the buffer size is always 64.
Is there any solution to this?
Also, that might be another question, is it better running supercollider without jack? is it really needed? If so, how would that work. Everything i tried disabling it didn’t work
Or is there anything else i should do to optimize supercollider for raspberry pi 4b and pisound-micro?
To my knowledge, this option has no effect in Linux. JACK buffer size has to be configured using JACK tools. SC cannot override JACK’s settings. (Edit: I’m not sure if this setting does or doesn’t apply when scsynth boots the JACK server. I never quite trusted scsynth starting JACK, so I always set up JACK outside of SC.)
Block size is SC-internal. It should be a divisor of the hardware buffer size but won’t have an effect on JACK configuration.
Dang, that doesn’t sound good. So I basically can’t change the block size
Any other options I can try to reduce audio dropouts or spikes?
In average my cpu usage is not even that high, on the pi its about 20% but in supercollider it always spikes shortly after couple of seconds even with the simplest script.
You can change the block size using JACK tools. What I wrote was “JACK buffer size has to be configured using JACK tools” and “I always set up JACK outside of SC.” This doesn’t mean that it’s impossible to configure the block size – only that you can’t use SC commands to do it, and that it can be done using non-SC tools.
If you have qjackctl, the hardware buffer size can be set there. If using Pipewire, the buffer size is part of the “Pipewire quantum.”
I really appreciate your help on this, but pipewire seems to be crazy stubborn. whatever I try. I am not able to either overwrite the blocksize of 64 nor can I actually kill pipewire.
One weak point of Pipewire is the lack of a simple configuration tool… so yeah, it’s not really surprising to hear this.
I’m using Ubuntu Studio, which ships a configuration utility. You run the utility, choose the first option (“configure current audio configuration”), and then type in the hardware block size and sample rate you want, separated by a space (e.g. “1024 44100”). This exists as an apt package but I have no idea if this will be compatible with your pi’s Linux distro.
Alternately, a clever linuxmusicians user came up with a shell script. This script doesn’t set the sample rate, but see below.
Basically what the script is doing is creating a user level configuration file and then restarting the Pipewire service. It’s creating the file ~/.config/pipewire/pipewire.conf.d/quantumsetting.conf with contents (I’ve modified it from the original post to include sample rate):
However I cannot confirm that this approach works on my system. Apparently the Ubuntu Studio configuration tool puts the configuration in some place that cannot be overridden this way. Since I guess you don’t have Ubuntu Studio taking control over this setting, maybe the script would work for you (but maybe it wouldn’t).
In other words, after saying in another thread that Pipewire is fantastic, I now have to admit that there’s one common requirement (setting sr and blocksize) that is more difficult than it needs to be (I remain impressed with it in most other respects though).
Thank you both for your help. I think I finally got it working.
I couldn’t get the PipeWire script working, or at least it didn’t seem to do anything for me.
First, I disabled the internal Raspberry Pi audio sources by editing config.txt
dtparam=audio=off
dtoverlay=vc4-kms-v3d,noaudio (I believe this handles HDMI audio)
This stopped PipeWire from getting confused by multiple sources. However, even after setting SuperCollider to a block size of 512, I noticed in “pw-top” that PipeWire was still internally using 1024.
I think PipeWire wasn’t treating my card as a “Pro” (whatever that means) and was limiting the block size, so I still got cpu spikes, even it was a bit better overall.
The final step that fixed it was forcing PipeWire to stop completely and switching back to jack.
This solved all my issues; the spikes are gone and I couldn’t be happier.
(I think I tried that even before, but I guess it got confused somehow with the internal raspberry pi audio hardware)
I have pretty much no experience with Linux, so I am not 100% sure it all makes sense what I am talking about, but I hope this helps anyone else who runs into this. This issue gave me a headache for days
If you don’t need Pipewire, this is a perfectly fine way to go! I personally am enjoying Pipewire on my lappy but that doesn’t mean it’s best for every case.
FWIW I’ve asked on the Ubuntu Studio mailing list what exactly their configuration tool is doing which blocks other configuration approaches. I think I’ll also follow up on linuxmusicians for ideas why that script failed. (This isn’t intended to push you toward Pipewire – more for my own curiosity, and to be able to offer better help when this question arises again [and it will…]).
Oh yea, that sounds great. Thank you for asking. I am very curious as well.
I was basically just sharing the steps I took, with my very limited linux knowledge.
If there’s an even better way to do this with Pipewire, I’d love to know.
The downside is probably also that I had to shut out all other audio on my Pi.
It doesn’t bother me since it’s entirely used for my groovebox project, but it’s probably not a good solution for everyone
For me, the biggest advantage of Pipewire is better integration across different types of audio applications: the ability to patch between JACK, PulseAudio and ALSA apps freely (this also supports Bluetooth audio devices for JACK applications, which I never had before), and for online meetings, a true “monitor” audio device for sharing desktop audio. Also, with JACK, to change to a different audio device, I had to shut down the JACK server (which required shutting down all audio applications), reboot JACK, and then reload all the applications. This was quite disruptive. With Pipewire, it usually works to just plug in the other audio device, and either choose that device in the PulseAudio menu or perhaps repatch in a session manager. It’s much more flexible.
On a pi, running just one specific audio environment, you might not need that flexibility, so if it’s working now to your satisfaction, I’d say, “If it ain’t broke, don’t fix it.” Totally up to you – just because I’m having a good experience with Pipewire doesn’t mean that it’s right for your pi.
(I remain impressed with it in most other respects though).
I think I finally got it working.
