LlamaCasty/HANDOFF.md

HANDOFF — 2026-09-10 (afternoon)

Branch / Commit State

main HEAD currently = 5e78065 (slice 11, committed). Slice 12 (audio diagnostics) is uncommitted in the working tree. Ahead of origin by 17, NOT pushing — user ruling (2026-09-10): do not push until the web-overlay transparency AND audio-silence issues are addressed. Milestone tag milestone-recording-timing (annotated) on c45cbc9 — rollback point: git reset --hard milestone-recording-timing.

Timing saga — CLOSED (verified)

Slices 9 (bd396e4) + 10 (c45cbc9) committed. Takes 0949/0957 verified: counter +1/frame, zero gaps/dups. User confirmed → timing CLOSED.

Slice 11 (web capture cadence) — committed 5e78065

10Hz capture → ~30Hz target with de-throttle flags + CaptureScheduler (latest-wins in-flight drop). First verification take (ty-20260910-1038-0000-2.mp4, 1423 frames 23.7s) results:

• Capture cost: 35-117ms per frame (not the hoped 10-30ms). Effective cadence is ~10-14Hz, NOT 30Hz — the scheduler's in-flight drop silently collapsed the target back to roughly the old rate. The in-flight drop works (no stacking), but the decode path (BitmapImage → FormatConvertedBitmap → FindContentBounds full-scan) is too expensive to reach 30Hz. Web animation speed will not have improved meaningfully. Next: the capture cost decides — either optimize the decode path (crop-only, cached bounds) or drop the target to ~15Hz.
• FramePump: healthy (300/300 frames, 0 dropped, 6 stalls worst 166ms).
• Camera: initialized (YUY2 640×480) but "MJPG negotiation refused (being used by another process)" logged at startup — the webcam source was contested.
• Audio: full-length silent AAC (−91dB, 1124 frames). User reported: no transparency in web-uri, no webcam video, no audio. The three symptoms are separate threads.

Slice 12 (audio diagnostics) — uncommitted, in-tree

The silence is capture-side: the pipe ran for 23.95s, ffmpeg connected and read ~9.1MB of zeros. Sources started (Audio: using system default mic... logged at 10:38:01.296), no failure callbacks fired. The mixer's existing integration test (Mix_WithFiltersDuckAndGain_Lands_On_AudioPipe) proves the loop→pipe path carries real audio when fed. Two remaining capture-side suspects: (1) default render device mismatch — audio played on a non-default endpoint (common); (2) both endpoints held exclusive by another process.

Changes in tree:

• Services/Audio/AudioMixer.cs: FillAndMix now returns (MicRms, MicDrained, LoopDrained); LiveLoopAsync accumulates per-5s telemetry → startup.log: Audio live: pipe connected=, dropped writes=, micLevel=, loopLevel=, drained, peakMix; StartLive/StopLive log start/stop lines.
• Services/Audio/NamedPipeAudioWriter.cs: new DroppedWrites counter — nonzero means audio was dropped before ffmpeg connected (names "pipe never connected" stage).
• Docs: ai.md slice 12 entry.

Suite: 290/291 pass — same sole pre-existing compositor pixel failure.

NEXT STEP

1. Commit slice 12 (scope-check passed on the three source/doc files).
2. User runs a recording with DESKTOP AUDIO ACTIVE (music/game playing → verify the "Desktop Audio" footer bar moves during the take). Send startup.log lines containing Audio live:. The log names the stage:
   • loopLevel > 0 + peakMix > 0 + file silent → pipe-side (impossible per integration test; should not appear)
   • loopLevel ≈ 0 + drained 0/0 → capture delivered nothing (default device mismatch or exclusive hold)
   • dropped writes > 0 → encoder pipe never connected (timing/ordering bug)
3. If capture-side: add explicit loopback-device selection (enumerate active render endpoints, log the chosen one, allow user to pick) — the fix that makes the mismatch impossible.
4. Then return to web transparency (post-paint dump) and webcam.

Still Open

• Audio silence — push gate reason #2. Diagnostic committed pending take (see above).
• Web transparency UNVERIFIED — instrument blind (about:blank). Needs post-paint re-point. Push gate reason #1.
• Web capture speed — 30Hz target not achievable with current decode path; capture cost 35-117ms/frame → effective ~10-14Hz. Open question whether to optimize path or accept ~15Hz.
• Webcam missing in take-1038 — "MJPG negotiation refused (being used by another process)" at startup; camera initialized but possibly contested. Separate thread, queued.
• Pre-existing compositor pixel test failure (never in scope).

Landmines

• testhost shares startup.log with app — filter by time when triaging.
• Locked DLLs: taskkill //F //IM testhost.exe //IM ytLive.exe before rebuild.
• Build/tests via /mnt/c/Program Files/dotnet/dotnet.exe build … / … vstest "C:\Users\gramp\Documents\Code\projects\ytLive\ytLive.Tests\bin\Debug\net8.0-windows10.0.19041.0\ytLive.Tests.dll".
• Probing recordings: /mnt/c/Program Files/Krita (x64)/bin/ffmpeg.exe / ffprobe.exe.
• tools/ticker: constant ~+982ms offset on the FIRST line is cosmetic.
• WebView2 capture cost: 35-117ms per full-HD PNG encode+decode — the hard ceiling on web animation capture rate. Slice 13 candidate if the user wants to pursue 30Hz.
• WASAPI loopback: captures the DEFAULT render endpoint only — if the user plays audio through a non-default device, the recording is silently silent. This is likely the root cause of the audio-silence issue. The fix requires device enumeration + selection.