LinuxMusicians

I got ZynAddSubFX running on a headless Raspberry Pi 3 with a Pi-DAC+, along with a small web app to switch instruments served over wifi. I thought I'd share this tutorial and video I put together so that others can try it out. Sounds great.

DIY Raspberry Pi synth with ZynAddSubFX

Supercool! But isn't the latency a bit high? That corresponds to a system latency of almost half a second (1024/48000*2). And I see you also build Zyn from source with no optimization for the RPi3. Also I wouldn't use JACK but ALSA directly, JACK needs some resources and if you could free those Zyn could benefit from that. Just my 2¢

Jeremy

The latency is indeed high and I wouldn't use this for a lead melodic instrument the way it's set now. It's mostly for pads and textures. It's set that high because I get pops/clicks when certain instruments have 3-5 keys pressed. Keep in mind it's also serving a Node app with express, so I wanted the machine to have time to catch up on a web request. Also, I had the DAC set to 96khz+ for testing.

It's the patch level reverb and delay+reverb that's the killer in all this. Turning off reverb and delay globally as effects sends doesn't really help because the instruments themselves use fairly complex internal effects routing in distinct parts. That's the power of ZynAddSubFX, really. If I had the time, I would open up all these instruments in the GUI and hunt down the reverb and effects within the instrument patches and turn them off, and then export them all as a custom instrument bank. I could just use outboard effects. The Raspberry is very capable, but Zyn pushes it to 100% CPU pretty easily with certain instruments.

As for the compiling, I do that to be able to use the git repo latest version instead of the Sourceforge packages, or worse, the Debian package obtainable with Apt. I also thought compiling in the intended machine context would yield Debian/ARM gcc optimizations specific to it. I don't know if it actually helps, but I thought I had found a blog post somewhere recommended that. According to Fundamental, they used an external library to handle auto-configuration of ARM optimizations. Unfortunately, it doesn't work well and adds SSE and incompatible Neon instructions. So, they have to be removed. Getting Neon back would probably be a huge benefit.

I use Jack for realtime priority. I don't think ALSA can get the hardware level permissions for that. Also, I think Zyn just uses ALSA seq for timing and Jack for the audio hardware output.

It's definitely a work in progress, but I think this it at a state for release so others may be able to easily replicate the project and possibly contribute improvements.

You might have a look at the Guitarix on the RPi threads too. Maybe some of the means to get lower latency reported in those threads may also be applied here.

/Frank

I did find that thread when looking around for the realtime priority configuration options for Jack. It was useful. But, there is only so much horsepower the Pi can offer. One thing that gets overlooked is the multiple cores the Raspberry 3 offers. If Jack could be compiled to take advantage of that, I imagine the raw processing power needs would go down.

Fyi, I also built a Guitarix box with a Raspberry Pi and I'm writing that up in the next week or so.

You can give the audio driver a higher realtime priority with the rtirq-init package when using plain ALSA, that would have almost the same effect as using JACK with realtime priority. As for JACK using multiple cores, unfortunately that's not a compile time option Jack2 is SMP aware though but only if you use it with parallel processing, i.e. multiple parallel signal chains that use the same output(s). When running just Zyn this isn't the case so you can't benefit of the SMP support.

Hm, rtirq-init looks interesting. I didn't know about that. I had read up on RT distros but it seemed to really complicate the setup and they were not widely ARM compatible.

I think you're right about trying it without Jack. One less layer for the for the system to negotiate. I'll look into it. Thanks.

I've updated this tutorial and repo with improvements suggested above, as well as Raspberry specific optimizations.

Latency is down to 5.3ms and it doesn't use Jack anymore.

Setting up a Raspberry Pi 3 to run ZynAddSubFX in a headless configuration

lucidbeaming wrote:Latency is down to 5.3ms and it doesn't use Jack anymore.

Thats quite good! Are you able to use the heavier patches without xruns? If it ran solid at even twice that latency that would be quite an awesome little setup! Now all we need is an android port of the UI that we can connect over bluetooth

Some of the complex, multi-part voices with lots of sustain and delay/reverb do choke at more than 4 note polyphony. But, those are usually long evolving pads anyway and not played like an organ or keys. What's interesting is that the few underruns from Alsa recover much more usable than the glitching stutters of Jack based Xruns. Once the buffer clears, it's back to full keys.

If I could find out what the Zynaddsubfx OSC message is for reducing polyphony when sending a patch change, that would probably make it unnoticable for regular playing.

As for the UI, it's a web app made with jQuery Mobile, so it should work great on Android (or any other device, even legacy). I have an old Kindle Fire I use for controlling my Pi synths. Setting it up to work over Bluetooth is possible, but beyond my node/socket.io knowledge for now.

lucidbeaming wrote:If I could find out what the Zynaddsubfx OSC message is for reducing polyphony when sending a patch change, that would probably make it unnoticable for regular playing.

I think you're looking for /part[0,15]/Pkeylimit (e.g. /part0/Pkeylimit ,i 12 would limit the first part to 12 simultaneous notes)