mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-03 04:38:33 +00:00
Miguel Ángel
2e9a33ca71
Two independent post-release feedback reports of the same mechanism from two different skills (both delegate to this one shared engine): audio.mjs fired every line's Kokoro TTS + whisper-transcribe subprocess concurrently via a bare Promise.all with no cap. - One OOM'd 12/13 lines on a resource-constrained laptop (32GB total, ~7GB free), requiring a manual patch to a sequential for-loop. - The other saw 7/8 lines fail on first run, then pass on retry once the model was cached — concurrent cold-start model loads overwhelming the machine, not a real synthesis failure. Kokoro/Whisper each load their own local model per subprocess, so firing every line at once multiplies that cost by the line count. Extracted the concurrency cap into lib/concurrency.mjs (audio.mjs is a script — it runs CLI/exit side effects on import, so it can't be unit-tested directly; the cap is small enough to pull out and test in isolation). Default 4, overridable via HYPERFRAMES_TTS_CONCURRENCY, floored at 1 (matching one report's own manual workaround). hyperframes-media/scripts/audio.mjs is the single canonical engine per its own header comment; product-launch-video, faceless-explainer, and pr-to-video each carry a thin wrapper that spawns this file as a subprocess (confirmed via their DEFAULT_ENGINE path), so this one fix covers all four skills without touching the other three. Tests: 4 new cases for mapWithConcurrency (order preserved regardless of completion order, cap actually enforced, limit > item count doesn't hang, empty input). Full skills test suite (514 tests) shows no new failures — the 444 pre-existing failures are environment-dependent and reproduce identically on unmodified main.