I’d like to sometimes run PureData without starting it through patchbox-config. I’ve got QJackCtl configured for real time, running from the ‘patch’ user not root, and it appears to start up OK. But when I run PureData from I get an error. Is there an easy fix? Any help gratefully received.
BTW I can get it to run with realtime mode OFF in QJackCtl, but with obvious downsides.
Here’s what PureData says (invoked with either ‘pd’ or ‘pd -rt’)…
Here’s the JACK status - it says Realtime Mode: Yes
Hi, see here: https://jackaudio.org/faq/linux_rt_config.html
You may have to edit the security limits file. I think patch user is already a member of audio group, so additional changes there shouldn’t be necessary.
Thanks, I’ve done all that. OK I’ll investigate further and report back if successful.
Point is that when jack is started by your script (running as root) it works and is running with the realtime flag
usr/bin/jackd -t 2000 -R -P 95 -d alsa -d hw:pisound -r 48000 -p 128 -n 2 -X seq -s -S
It actually runs as user ‘jack’, see https://github.com/BlokasLabs/patchbox-os-debs/blob/master/blokas-jack/src/jack.service
Btw, it is configured to be shared with other users on the system, thanks to JACK_PROMISCUOUS_SERVER=jack environment variable. It’s set to the same value for user patch too, so processes started by it should be able to reach the shared Jack backend.
I’d recommend to just use the Jack service as is, and if you need to change the command line manually, edit /etc/jackdrc file.
Yes, my mistake, ‘jack’ user. I would go with the jack service as-is, except that when I run Pd from the ‘patch’ user I get this error. However if there’s not a simple fix, let’s drop this and I’ll use patchbox-config to start them. Thanks for the info though.
I don’t get this error when starting PD, regardless if the kernel is RT or regular one. What changes did you make to your system?
Is the environment variable mentioned before set in /etc/environment file?
I’ve installed Sonic Pi, xrdp, QJackCtl - that’s all.
Here’s the environment file
Here is the kernel info, from patchbox-config, if that’s relevant
To bring this to topic an end…
There’s talk on the web of jack’s promiscuous mode not working. Certainly on my box, puredata only connects to the pisound-started jack server when puredata runs under root.
I can write a script to do that, but the simplest workaround is to have one of my puredata patches using ‘main.pd’. Then with the 1-click button assigned to ‘start puredata’, it finds that patch and starts it. I guess this is the mechanism to load from a usb drive, but it helpfully looks in the puredata-patches folder too. From there I can close that patch and open another from the Pd console/log window (or whatever that window is called).
Why my jack server started under the ‘patch’ user can’t do real time? That remains a mystery for another day.
Because I like to understand how things are working rather than just do workarounds, I did prep another sd-card with patchbox OS from scratch. Same result.
We made sure to include the right version of Jack backend, built it from source ourselves, it works. 
patch@patchbox:~ $ jackd --version
jackdmp version 1.9.12 tmpdir /dev/shm protocol 8
What are the steps you’re taking exactly? I just flashed an sd card using [Beta] Patchbox OS image 2020-11-23, went with the setup wizard, selected ‘desktop autologin’ so the GUI is up automatically, rebooted, started Pure Data using the shortcut on the desktop, or just running ‘pd’ or ‘puredata’, it runs just fine.
Same here! Odd isn’t it? The only thing obviously different is that I’m using remote desktop to connect. I’ll try using keyboard and hdmi and see what happens. Seems unlikely but I work in software myself, so never say never
It did indeed turn out to be Remote Desktop. Connecting using VNC everything works as it should.
I prefer Remote Desktop for the ‘no tweaking, full width of screen experience’, but VNC will be fine.
The Windows RDP has settings for where audio is to be run (remote/local/off) and yes I’d set to remote as normal. Certainly there is sound coming from the RPi. But it looks like there’s something in the protocol for routing audio, and it’s not working properly. Which is where I give up looking, and just enjoy the lovely pisound instead.