From ef2093f8ad9e54d54ed6e7046b3fd548981f1b9a Mon Sep 17 00:00:00 2001 From: OmikronApex Date: Thu, 9 Jul 2026 20:47:35 +0200 Subject: [PATCH] =?UTF-8?q?feat(audio):=20renderer-bus=20feeder=20?= =?UTF-8?q?=E2=80=94=20mix=20renderer=20song=20audio=20into=20engine=20out?= =?UTF-8?q?put=20(Phase=202)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Under exclusive-style output the native backing transport (Phase 1, #824) carries loose /audio/ songs and feedpak full-mixes, but not the stems plugin's multi-stem WebAudio graph or tracks JUCE rejected. The feeder taps the renderer-side master with an AudioWorklet, re-points the owning AudioContext at a null sink so it keeps rendering without a device, and pushes ~10 ms chunks over IPC into the desktop engine's renderer bus (feedBack-desktop#90 follow-up). Inert in the Docker sphere and in shared mode. Validated by the fix12 tester spike: null-sink rendering works, clocks hold, no overflow. Co-Authored-By: Claude Fable 5 --- static/app.js | 203 +++++++++++++++++++++++++++ tests/js/renderer_bus_feeder.test.js | 195 +++++++++++++++++++++++++ 2 files changed, 398 insertions(+) create mode 100644 tests/js/renderer_bus_feeder.test.js diff --git a/static/app.js b/static/app.js index e70eaad..3287bcb 100644 --- a/static/app.js +++ b/static/app.js @@ -5264,6 +5264,209 @@ window.jucePlayer = jucePlayer; }, 350); })(); +// Renderer-audio bus feeder (desktop Phase 2): when the engine holds the +// output endpoint in an exclusive-style mode, Chromium cannot reach the +// device, so any song audio still played by the renderer goes silent. The +// Phase 1 watcher above already migrates what a single-file transport can +// carry (loose /audio/ songs, feedpak full-mixes) onto the native backing +// transport. This feeder covers the rest — the stems plugin's multi-stem +// WebAudio graph, plus