From 568c284a8a8ff415a87b5399aa331d8b5c74e096 Mon Sep 17 00:00:00 2001
From: Jens Ahrensfeld <jens@jayfield.org>
Date: Tue, 28 Jul 2026 10:43:38 +0200
Subject: [PATCH] Add TODO items for SCUMM game manifests and low-latency game
 audio

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
---
 TODO.md | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/TODO.md b/TODO.md
index 9322c8d..92f5b9d 100644
--- a/TODO.md
+++ b/TODO.md
@@ -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.