[mcinnisdev]

The Linux desktop app was completely silent on a machine where chopdeck.com played fine.

Cause

WebKitGTK has no audio stack of its own. Web Audio leaves through GStreamer, and WebKit asks autoaudiosink to choose the output element. autoaudiosink prefers pulsesink, and pulsesink talking to PipeWire's PulseAudio compatibility layer is silent on a Bluetooth sink.

Silent in the worst possible way: the stream opens, unmuted, at 100%, attached to the right device, the AudioContext reports running and currentTime advances. Nothing looks wrong from inside the page and nothing is logged. Measured by recording the sink's own monitor — same page, same packages, same Bluetooth device:

sink element	peak
autoaudiosink → pulsesink	0.0000
pipewiresink ranked MAX	0.3349

On a wired output pulsesink happened to work (peak 0.3119), which is what made this look intermittent rather than reproducible.

Browsers never use GStreamer, which is why the same build plays in Chromium and not in the desktop window — worth remembering before blaming the machine.

Fix

src-tauri/src/lib.rs sets GST_PLUGIN_FEATURE_RANK=pipewiresink:MAX before the webview starts. The sink then follows whatever the desktop's default output is, rather than binding to one card.

• Set before tauri::Builder, because GStreamer reads the variable while building its registry.
• GStreamer runs in the child WebKitWebProcess, which inherits the value from us.
• An existing GST_PLUGIN_FEATURE_RANK is appended to, not replaced, and left untouched if it already mentions pipewiresink.
• Linux only (#[cfg(target_os = "linux")]).

Testing

Built the .deb, then ran the binary with GST_PLUGIN_FEATURE_RANK explicitly unset in the launch environment, after killing every stale WebKit process:

stale webkit processes before launch: 0
parent pid: 604276
  pid 604364 (started after parent? yes) -> GST_PLUGIN_FEATURE_RANK=pipewiresink:MAX

Note that /proc/<pid>/environ of the parent is useless here: it snapshots the environment at execve() and never reflects a runtime setenv(). The child web process is the authoritative check.

Also ruled out by measurement rather than assumption: the two engines are not the difference. Rendering a synthesised kick through Chop Deck's exact master chain (gain → DynamicsCompressor threshold −3 / knee 6 / ratio 12 → destination) in an OfflineAudioContext gives identical output in Chromium and WebKitGTK — dry peak 0.72000 rms 0.19554, limiter peak 0.43997 rms 0.15852, matching to five decimal places.

Docs

docs/DESKTOP.md gains the Bluetooth trap with the measurements and how to override it, plus one more time-waster: WebKit parks the AudioContext in a non-standard interrupted state whenever the window lacks focus, freezing currentTime. An unfocused window is silent by design.

🤖 Generated with Claude Code

https://claude.ai/code/session_019U7kCMZc9a7sezDwKKseJy

[cloudflare-workers-and-pages]

Deploying chopdeck with    Cloudflare Pages

Latest commit:	1985ba7
Status:	✅  Deploy successful!
Preview URL:	https://4500b33b.chopdeck.pages.dev
Branch Preview URL:	https://desktop-linux-audio-sink.chopdeck.pages.dev

View logs