jens/docker-dosbox-novnc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add TODO items for SCUMM game manifests and low-latency game audio

Browse Source 
Audio note: rules out the obvious compressed-stream + <audio> tag
approach up front, since codec/element buffering can't realistically hit
the tens-of-ms target - raw PCM over WebSocket into an AudioWorkletNode
is the concrete plan instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NiNnj78HGx1KWyCCo39HSz
This commit is contained in:
jens
2026-07-28 10:43:38 +02:00
co-authored by Claude Sonnet 5
parent 53f36cca8e
commit 568c284a8a
1 changed files with 23 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO.md
+23
View File
@@ -26,3 +26,26 @@
hardcoded `DOSBOX_VERSION`/`run.bat` convention) were intentionally left untouched for this
pilot and now overlap with the new Start button — worth reconciling (or removing) once the
manifest approach is rolled out to all games.
- Create manifests for SCUMM engine games (Monkey Island, Day of the Tentacle, Indiana Jones,
etc.). Note these are usually best run via ScummVM rather than raw DOSBox — `scummvm` isn't
installed in the image yet, so this may need a Dockerfile change (add the `scummvm`
package) alongside the manifests themselves, and each manifest's `start_cmd` would invoke
`scummvm` with the right game-id instead of `dosbox run.bat -conf ...`.
- Get game sound actually audible during play. `--device /dev/snd` is passed through and
`alsa-utils` is installed, so DOSBox can write to an ALSA device inside the container, but
VNC/noVNC only ever streams video, not audio — nothing currently carries that sound out to
the browser.
Target latency is a few tens of ms, not seconds — that rules out the "obvious" approach of
a PulseAudio null sink piped through `ffmpeg` into a compressed (mp3/ogg) HTTP/Icecast-style
stream consumed by an `<audio>` tag: codec frame buffering plus the `<audio>` element's own
jitter buffer realistically puts that in the 1-3s range, no matter how it's tuned.
Concrete approach instead: PulseAudio null sink → capture raw/lightly-buffered PCM (small
frames, e.g. `parec` with a short `--latency`) → push those frames to the browser over a
plain WebSocket (new endpoint alongside `setup_server.py`, or a small dedicated process) →
browser side, feed them straight into the Web Audio API via an `AudioWorkletNode` (not
`<audio>`, not `ScriptProcessorNode` — that's deprecated and has worse latency) for
near-real-time scheduled playback. No container/codec framing in the path at all.