I’ve been hacking around on an Organelle M. To make things a little easier, I automated the process of preparing an SD card image. The project is here. It’s based on the
pi-gen tool, that the Raspbian team uses to prepare OS releases.
master branch builds an up-to-date version of Raspbian Buster with the Critter and Guitari upstream version of Organelle OS and default patches. The
python3 branch drops the EOL Python 2 interpreter and uses a forked version of Organelle OS where the Python 2 scripts have been ported to Python 3. The
systemd branch is a work-in-progress for converting the background processes to systemd services.
Note, the first boot takes a little longer as the Organelle M will create the
/sdcard partition in the remaining space of the SD card, copy the Patches directory, then make the system read only. This is done to minimize the size of the compressed image. Also, this project uses a docker container to build the image. If you’re an a Debian system, you can edit the
build.sh script to avoid the docker dependency.
Everything I’ve tested seems to be working fine in the
python3 branches. But, let me know if you find anything broken.
This is so cool! It is definitely what we wanted to do but lacked expertise with the pi-gen stuff, but going forward for future OS releases we should check this out. I look forward to trying it out. On a side, one thing I had been experimenting a bunch with was improving audio latency, which I haven’t really been able to get below 5ms without dropouts. Even a kernel with the rt preempt patch didn’t make any difference… I wonder if there is any difference in Buster. If there were tweaks to the kernel, I suppose those could be added to the pi-gen. Also would be good to properly patch the audio driver instead of the current hotfix (that nasty fixit.sh script)!
5ms is pretty good. I worked on the early stages of this product. With a custom sound card driver, zero copy audio pipeline, real time kernel, and minimal rootfs, the latency was 3-4 ms. The RT preemt patches will often make the latency longer, but they’re consistent, since the interrupts are deterministic.
You can try boosting the niceness of everything in the audio pipeline to politely ask the kernel not to spend as much time on background processes, networking, and the many other peripherals attached to shared buses.
You can also try to limit the total number of concurrent processes by building a barebones image from buildroot or yocto or by trimming down the Raspbian image as much as possible. In my opinion, one of the best things about the Organelle M is that there’s a Raspberry Pi inside running Debian, so you can
apt-get any amazing piece of software you want to try. It will be hard to match pro audio gear levels of performance without tightly controlling the software running on the Organelle M. But, maybe you guys are in a different product category with different user needs.
As for trimming down a Raspbian image, some things like the printing service CUPS and the system log to a tmpfs filesystem can be disabled. Other background processes like the wifi monitor and the power switch monitor can be turned into hooks that wpa_supplicant or dhcpcd will run when there’s a network change or a dtoverlay to register the gpio pin as a power button key event. I was doing some experimenting in the systemd branches of this project and a fork of Organelle_OS, but they’re not quite ready yet. I’m sure there’s more that can be done, since there’s quite a lot going on inside a Raspberry Pi
Thanks for the info. I want to take a look at these optimizations a little more, I think there is a bunch of stuff still to try. It would be interesting to see if a buildroot or yocto yield better results, but I agree that having Raspbian inside is very beneficial and a lot of fun and worth an extra millisecond if it comes to that! The Organelle 1 runs an old stripped down Arch Linux, and we are able to run Pd with an audiobuf of 4ms (stock kernel). So unless there is something different about the sound card driver (it was a different chip on the Organelle 1), we should be able to do the same on the Pi with some more tweaks (right now it runs with audiobuf 6ms I think).
Sounds good! I’m happy to try out any new pre-release builds.
I’m curious about the purpose of the fixit script. What does it do? (If I was a better programmer I could probably figure it out, but I’m not!)
The fixit script changes the control interface of the audio hardware from I2C to SPI. It does this by replacing a string in the kernel module binary. Really not the way to do things but saves having to compile the kernel for such a small change.
We’ve been working with the pi-gen stuff recently and hope to use it for future releases. Just an fyi, we ran into some problems with the QCOW stuff that was recently added to pi-gen, so we added USE_QCOW2=0 in the config.
Great, thanks! I suspected it might be something like that, from looking at the overlay file for the sound card.