sonic-pi-net / sonic-pi

Code. Music. Live.
https://sonic-pi.net
Other
10.84k stars 922 forks source link

Boot error on rpi when jack is pre-started #3191

Closed wolfwolfswinkel closed 2 years ago

wolfwolfswinkel commented 2 years ago

Hi,

Testing 4.0.3 on rpi.

When starting without jackd running up-front, all is well.

However, when I pre-start jack, boot fails with the attached error.

(Not entirely sure, but I think I used to be able to start with jackd already running with the older sonic-pi version on buster)

Regards,

Wolf

sonic-pi-boot-error.txt

rbnpi commented 2 years ago

Hi there, It should work OK pre-starting Jack before you run SP. You only need to do this if you want to get very low latency, and for most cases running via pulse audio can be more convenient as it is easier to route your audio, and also to use other sound apps at the same time. However if you want low latency you may prefer to configure jack to run directly with supercollider. In this case you do need to configure it to recognise your audio interface, which looks like it is a presonus audiobox i2. It looks like jack is starting OK according to the log. You have quite a low latency figure 2.7ms, but I am running a similar setup using a steinberg UR22mkII interface currently running with latency of 5.33ms. It could be that yours is too low to run effectively: maybe try something higher to start with. (double the buffer size). The problem in your logs was that the spiderserver couldn't connect but I'm not sure why. Could you detail the settings you put in your qjackctl configuration and also list the contents of .jackdrc (in your home folder) and also the Qjackctl status window Also was there anything untoward in the messages window. I notice that you haven't configured audio input (input channels set to 0), but of course this is set by a switch in the prefs window once you get SP running. Worth trying a reboot of your computer and then trying to launch sp again. Let me know how you get on. I've just successfully run my setup starting jack first. One final point are you running the 64bit or the 32bit version, and on what model of Pi?

wolfwolfswinkel commented 2 years ago

Hello,

Thanks for your response.

What I am trying to do is sending SP audio into jamulus. The latter requires jack to be running before it starts, has opinions about the sample rate and likes low latency.

Running 32-bit on a Pi 4.

In the configuration that produced the boot errors, I was running jack with sample rate=48000, frames/period=64 and periods/buffer=2. Quite a bit of nastiness in the messages, see attached qjackctl_messages.log

However, following your suggestion, I changed to frames/period=128 and then SP boots fine. Managed to route audio to jamulus as well. So issue fixed, at least for now.

I am going to experiment with mixing live playing into the same jamulus session, and f/p=64 would be beneficial for the overall latency. But that could simply be pushing things to hard. I am not familiar with the subtleties of linux audio, so any suggestions on how to best do things like this are welcome.

Thanks,

Wolf

rbnpi commented 2 years ago

Glad you've got it going. It can get quite critical if you make the latency too low. You get lots of Xruns in the log as you show. You may run with the odd one occasionally, but generally best to adjust the setup so that they are avoided. Not come across jamulus, but had a brief look and I might give it a twirl and see if it gives me any ideas.. I am generally just using external synth like yoshimi driven by midi from SP and feeding the audio back into SP.

rbnpi commented 2 years ago

would you like to close this for the moment? You can always reopen if necessary. I think you'rw sailing fairly close to the wind as far as the latency settings are concerned on a pi. If you have very complex sounds you may find you start to get dropouts. I don't think there is otherwise a problem with the code. EDIT if you are only using jamulus with a simple mic input and NOT sp the demands will be less and you can get away with a lower latency.