From 328ad300cb649b7885d0180bd97474c31a3348a5 Mon Sep 17 00:00:00 2001 From: boessu Date: Sun, 9 Aug 2026 16:46:55 +0200 Subject: [PATCH] Revise PROJECT_STATUS.md with recent updates Updated project status with new issues and fixes related to ROCm Docker builds, audio playback, and other tooling improvements. --- docs/PROJECT_STATUS.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/PROJECT_STATUS.md b/docs/PROJECT_STATUS.md index eef11d8a6..afae9e06b 100644 --- a/docs/PROJECT_STATUS.md +++ b/docs/PROJECT_STATUS.md @@ -277,6 +277,7 @@ Shipped 2026-04-25 (PR #544). Voicebox went from a voice-cloning studio to a ful - **Blackwell (RTX 50-series) CUDA**: cu128 + sm_120 kernel support shipped (PR #401, #316), but users still report `cudaErrorNoKernelImageForDevice` (#417, #400, #396, #395, #390, #362) — likely a stale CUDA binary on upgraded installs. Needs a follow-up diagnostic / forced re-download path. - **Long text 50k character limit** (#464, #365, #354): Still hit on GPU despite chunking (PR #266). Chunking reliability needs another pass. - **ROCm on RDNA 3/4** (#469): `HSA_OVERRIDE_GFX_VERSION` is hardcoded and harms newer cards. +- **ROCm Docker build requires pinned torch (new)**: `docker-compose.rocm.yml`'s build (`torch`/`torchvision`/`torchaudio` unpinned in `Dockerfile`) silently resolves to a CUDA wheel instead of ROCm, because PyTorch 2.9+'s wheel-variant system needs a provider plugin to detect the ROCm environment — detection that can't happen inside a `docker build` context. Symptom: `torch.cuda.is_available()` returns `False`, or (if partially masked by a stale cache) `libcudart.so.13: cannot open shared object file` at model load. Fix requires pinning `torch==2.7.1 torchvision==0.22.1 torchaudio==2.7.1` (last pre-variant ROCm release) and explicitly stripping stray CUDA transitive deps pulled in by `qwen-tts` (installed without `--no-deps`). See PR #. Also note `scripts/package_rocm.py` declares `torch_compat=">=2.9.0,<2.10.0"` — conflicts with this pin and needs separate reconciliation. - **`flash-attn is not installed` warning on every platform (cosmetic, common user complaint)**: Our transformer-based engines (Chatterbox / Qwen) emit `Warning: flash-attn is not installed. Will only run the manual PyTorch version. Please install flash-attn for faster inference.` on every startup, on every platform — we don't pin `flash-attn` in requirements because installing it is fragile and version-sensitive. Fallback is PyTorch SDPA, which is near-FA2 throughput on Ampere+ and is what actually runs. **Per-platform reality:** (a) **macOS/Apple Silicon** — FlashAttention is CUDA-only, irrelevant here; MLX has its own attention kernels. (b) **Linux** — `pip install flash-attn --no-build-isolation` works but takes 20+ min to compile. (c) **Windows** — no official support (Dao-AILab README still says only "Might work"; source builds routinely fail on recent CUDA/MSVC, issues #1715, #1828, #2395). Windows users can install community prebuilt wheels from `kingbri1/flash-attention` or `bdashore3/flash-attention` (latest v2.8.3, Aug 2025; `win_amd64` wheels for CUDA 12.4/12.8, Torch 2.6–2.9, Python 3.10–3.13) matching their exact CUDA/Torch/Python, or use WSL2. **Native-Windows alternatives worth considering as a build-time swap:** SageAttention (thu-ml, Apache 2.0, claims 2–5× over FA2) and xformers (official Windows wheels). **Action for us:** troubleshooting doc now covers it (see `docs/content/docs/overview/troubleshooting.mdx`), and we should optionally suppress the warning via `logging.getLogger(...).setLevel(ERROR)` at backend import since the fallback is functionally fine. - **WebAudio playback dies after audio-session interruption** (#41, plus an internal repro where the app is backgrounded long enough): WaveSurfer's `AudioContext` gets suspended by macOS — either because another app grabs the audio output, or because the WKWebView throttles when backgrounded. `play()` resolves and `timeupdate` can still fire, but no audio reaches the output. Only app restart fixes it. **Things already tried that didn't work:** (a) swapping WaveSurfer backend away from WebAudio — introduced more bugs, not an option; (b) remount hook on the player — doesn't help because a freshly-created `AudioContext` is born suspended and only resumes on a user gesture. PR #293 was a prior partial fix that doesn't cover this path. **Next thing to try** (not yet attempted — confirmed via grep of `AudioPlayer.tsx`): call `wavesurfer.getMediaElement().getGainNode().context.resume()` on the play button click (the click itself is a valid user gesture), plus a `visibilitychange` + `statechange` listener as belt-and-suspenders. The `ctx.resume()` pattern already exists in the codebase at `useStoryPlayback.ts:52` — just not wired into the main player. @@ -380,7 +381,7 @@ One contributor opened a large, coherent quality suite in a single day. Review a ### Build / dev tooling / docker (~6) -#764 uv for backend env · #632 docker GPU build + cache + fastmcp (+7.9k) · #630 ROCm docker overlay · #463 ghcr.io auto-publish · #543 / #681 setup-script fixes · #584 docker permission fix +#764 uv for backend env · #632 docker GPU build + cache + fastmcp (+7.9k) · #630 ROCm docker overlay (see Known Limitations — torch pin issue found post-merge)· #463 ghcr.io auto-publish · #543 / #681 setup-script fixes · #584 docker permission fix ### Smaller fixes worth grabbing