Zynthian: plugin-hostd as its plugin host.

Zynthian is an open synthesizer and effects platform on a Raspberry Pi. It runs LV2 plugins through its own engines: mod-host, behind MOD-UI, which runs its effect chains, and jalv, which runs one plugin per process. plugin-hostd speaks mod-host's protocol and runs each plugin, LV2 or CLAP, in a worker process, so a plugin that crashes takes down only its own worker, which is put back with its settings. A whole chain can run in one worker instead of one process per plugin, and plugin-qualify measures each plugin on the device first, so the menus are built from what it found.

With it Zynthian gets a plugin-hostd engine beside jalv for LV2 and CLAP plugins in chains, plugin-hostd as a switchable replacement for mod-host under MOD-UI, plugin menus ordered and tagged from per-plugin qualification records, and chains whose plugins the daemon groups into as few workers as their pins allow.

The image

ZynthianOS Vangelis for the Raspberry Pi 4 and 5, with the forks of zynthian-ui and zynthian-sys, the OpenMixer apt repository, and plugin-hostd, omx-clap-host, omx-plugins, omx-panel and plugin-qualify installed and made the default. It is built from upstream's released Vangelis image with the fork's own update steps, as the fork's docs/openmixer-image.md describes, and will be a release of FreeMixer's zynthian-sys fork, in parts with their sums. It is not published yet: until it is, install the packages on a Vangelis you already run, as below.

The first boot does what any Zynthian card does once: it detects the kit, regenerates the SSH keys and the web certificate, creates the Wi-Fi access point, grows the file system to the card, and reboots once. Two minutes after boot the qualification sync starts in the background, at the lowest priority, and does not hold the boot; with the qualification records package installed it only checks that the plugin files are the ones the records describe.

On an existing Vangelis

A Vangelis system already running needs no new image. As root, add the OpenMixer repository and install the packages:

curl -fsSLO https://www.openmixer.org/deb/openmixer-release.deb
sudo apt install ./openmixer-release.deb
sudo apt install plugin-hostd omx-clap-host omx-clap-scan omx-panel

openmixer-release carries the signing key and the apt source of the running Debian release. This enables no service: mod-host, MOD-UI, jalv and the menus stay as they were until you switch them.

Turn it on, and back off

Three settings, each undone by setting it back:

# the plugin engine: in /zynthian/config/zynthian_envars.sh, then restart the UI
ZYNTHIAN_PLUGIN_ENGINE=plugin-hostd
# MOD-UI's backend
set_modhost_backend.sh plugin-hostd
# plugins in series sharing one worker: in /zynthian/config/plugin-hostd.conf
grouping on

Why

A Pi 5 has four cores. A synth plays many voices at once, and every block of audio has a deadline: all the voices must be computed before it is due. Run one after another, they all use one core. That core sets how many notes you can play, however idle the other three are.

Some synths split their voices into tasks and ask the host to run them (CLAP's thread-pool extension). Tasks like that can run side by side, if the host lets them.

How it works

omx-clap-host starts helper threads: one for each core the plugin's worker may use, minus one, because the audio thread takes the last core. Each helper is pinned to its core, runs at the audio thread's real-time priority and sleeps between blocks.

When the plugin asks for its tasks, the helpers and the audio thread take them one by one, and the call returns when the last is done. If the priority cannot be set, there are no helpers and the tasks run as before, in turn.

Who gets helpers

Not every plugin. Helper threads are given plugin by plugin, never everywhere. A plugin gets them only if its qualification found it real-time safe, with the helpers watched too, and faster with them. A task that allocates or waits on a lock would make every core miss the deadline.

Any other plugin runs as before: its tasks one after another on the audio thread. A plugin that gets helpers runs in a worker of its own, which plugin-hostd starts with the pool on.

How to switch it

It is an option of omx-clap-host:

# omx-clap-host: helper threads for the plugins that split their voices into tasks
omx-clap-host --thread-pool=qualified   # the default
omx-clap-host --thread-pool=on
omx-clap-host --thread-pool=off

• qualified (the default): only plugins whose qualification grants it get helpers. plugin-hostd gives each worker the right setting, so on Zynthian you do not set it.
• on: every plugin that uses the extension gets helpers.
• off: every plugin runs its tasks in turn.

What it gives

Measured on a Raspberry Pi 5 at 48 kHz and 256 frames, so the block is due in 5333 µs. The plugin is a test plugin that splits each block into 16 tasks, because no plugin on the Pi asks for tasks yet, Surge XT included. The time is the mean cost of one block, with the helpers off and on:

At 512 frames, the 48-voice load takes 6.6 ms of the 10.7 ms block with the helpers off and 1.7 ms with them on. No block went over its deadline in any run.

This is the best case: equal tasks that share nothing. A real instrument has not been measured with it, so there is no Surge XT figure. Surge XT does not split its voices, and for it the cores come from running each instrument in a worker of its own: four instances with 16 notes each ran at 14 to 15 % of a core each.

Surge XT measured, in full