tools/niner-launch.sh picks the ALSA backend only when it finds an Arturia BeatStep specifically (line 81). With any other controller, or none at all, MIDI_INPUT stays empty and it falls through to line 156:
exec "$STANDALONE" --dpi-scale "$SCALE" --backend jack "$@"
The comment on line 125 reads "No BeatStep found — fall through to JACK below (works without MIDI)." On a PipeWire system that is not safe: the JACK client can attach to PipeWire's Dummy-Driver instead of the real output device, never receive a process() call, and stall the entire audio graph.
Impact
This affects any Linux user launching the standalone from the desktop entry without a BeatStep connected. It is not confined to Niner: while wedged, all system audio capture and playback breaks. In my case pw-record began returning 44-byte WAVs (header only, zero frames), which silently broke an unrelated dictation tool until I traced it back here.
Evidence
pw-top with the standalone running:
R 29 512 44100 11.7ms 7.4us 1.01 0.00 0 Dummy-Driver
R 93 512 44100 +++ --- +++ --- 22584 + niner
22,584 accumulated audio errors, and the real output device sat idle. Niner's own log:
[heartbeat] still dead after ~140s (counter=0)
[heartbeat] healthy: 0 process() calls in last 30s (counter=0)
counter=0 from launch, so it was never alive rather than degrading over time. The GUI was fine throughout and logged keypresses normally ([keyboard] Space shortcut fired), which makes this look like a UI bug from the user's side.
Workaround
Kill the client, do not restart PipeWire:
pkill -f 'niner[-]standalon'
Note the bracket. Without it, pkill -f niner-standalone matches its own shell wrapper and kills the calling shell.
Then relaunch on ALSA, matching pw-metadata -n settings 0:
niner-standalone --dpi-scale 1 --backend alsa --sample-rate 44100 --period-size 512
After that: [heartbeat] healthy: 10320 process() calls in last 30s, and the client shows as a child of the real sink with ERR 0.
Suggested fix
Either drop the BeatStep-specific match so any MIDI device (or none) still takes the ALSA path — --midi-input is optional, so ALSA works fine with no controller — or keep JACK as an option but verify a real driver is attached before trusting it and fall back to ALSA otherwise.
The credit here goes to the [heartbeat] diagnostic, which made this diagnosable in seconds. Worth keeping.
tools/niner-launch.shpicks the ALSA backend only when it finds an Arturia BeatStep specifically (line 81). With any other controller, or none at all,MIDI_INPUTstays empty and it falls through to line 156:The comment on line 125 reads "No BeatStep found — fall through to JACK below (works without MIDI)." On a PipeWire system that is not safe: the JACK client can attach to PipeWire's Dummy-Driver instead of the real output device, never receive a
process()call, and stall the entire audio graph.Impact
This affects any Linux user launching the standalone from the desktop entry without a BeatStep connected. It is not confined to Niner: while wedged, all system audio capture and playback breaks. In my case
pw-recordbegan returning 44-byte WAVs (header only, zero frames), which silently broke an unrelated dictation tool until I traced it back here.Evidence
pw-topwith the standalone running:22,584 accumulated audio errors, and the real output device sat idle. Niner's own log:
counter=0from launch, so it was never alive rather than degrading over time. The GUI was fine throughout and logged keypresses normally ([keyboard] Space shortcut fired), which makes this look like a UI bug from the user's side.Workaround
Kill the client, do not restart PipeWire:
pkill -f 'niner[-]standalon'Note the bracket. Without it,
pkill -f niner-standalonematches its own shell wrapper and kills the calling shell.Then relaunch on ALSA, matching
pw-metadata -n settings 0:After that:
[heartbeat] healthy: 10320 process() calls in last 30s, and the client shows as a child of the real sink withERR 0.Suggested fix
Either drop the BeatStep-specific match so any MIDI device (or none) still takes the ALSA path —
--midi-inputis optional, so ALSA works fine with no controller — or keep JACK as an option but verify a real driver is attached before trusting it and fall back to ALSA otherwise.The credit here goes to the
[heartbeat]diagnostic, which made this diagnosable in seconds. Worth keeping.