TESTING.md — Test log

Test 4.0 — Validating simultaneous audio + video on the real Raspberry Pi

Date: 2026-09-04 / 2026-09-05 Objective: confirm that the Raspberry Pi 2 can play an H.264 video with embedded audio (without drifting out of sync, either at the start or over time) simultaneously with an independent MP3, with the USB Behringer audio interface, the M-VAVE, and the library USB drive all connected at once (the 3 real devices used in the show).

Confirmed environment

Video playback stack — result of the investigation requested in 4.0

ALSA configuration used (~/.asoundrc on the Pi, user hesner)

pcm.mixcodec {
    type plug
    slave.pcm "dmix:CARD=CODEC,DEV=0"
}
ctl.mixcodec {
    type hw
    card CODEC
}

Results — 5-minute test, real simultaneous load

1920x1080/30fps H.264+AAC video (embedded audio) + an independent 300s MP3, played at the same time, with Behringer + M-VAVE + library USB all connected. Metrics sampled every 10s throughout the test.

Metric Result
Audio-video sync (avsync) Stayed between 0 and ~140ms over the 5 minutes, with no upward trend. Meets the section 2 critical requirement (no progressive desync).
Memory Stable: ~293→312 MB used out of 921MB total, always >600MB free. No visible leaks.
CPU ~25-30% usage during playback (70%+ idle). CPU is not the bottleneck.
Dropped video frames ~70% of frames (growing steadily and linearly, ~21 fps dropped out of a 30fps target). Confirmed real (not a test-material generation artifact).
Undervoltage during the test None new (throttled bits unchanged during the 5 minutes of real load).

Pending finding: video frame drops

Identified cause: mpv reports Assuming 60.000000 FPS for display sync while the content is 30fps — there’s a 30-into-60 mismatch that the current pipeline doesn’t handle well, resulting in massive frame dropping to keep audio in sync (which is correctly prioritized).

Power supply finding (resolved)

Follow-up finding (2026-09-05, live Core development session)

With the same 5V/2.5A charger already validated above, a second isolated undervoltage event was observed via dmesg (hwmon1: Undervoltage detected! … Voltage normalised ~4s later) about 3h40m into a single, unusually heavy session: both mpv lanes (video + audio-only) running continuously, combined with frequent main.py restarts, an ffmpeg encode (MP3 conversion + fallback-standby generation), and repeated USB mount/unmount cycles, all overlapping at various points — a heavier and much more sustained combined load than a real show, which doesn’t restart processes mid-performance. vcgencmd get_throttled immediately after showed no currently-active undervoltage (0x50000 = historical bits only), and the system remained fully responsive throughout — no freeze, no dropped MIDI, no audio/video corruption observed. Not treated as a new hardware problem requiring a fix; noted here as evidence to watch for during an eventual full-length continuous show-duration test with the final, real content and hardware setup (not a dev/test session with this much process churn).

The hardware (Raspberry Pi 2 Rev 1.1 + USB Behringer + M-VAVE + library USB, with a 5V/2.5A supply) sustains simultaneous audio+video playback without desync and without exhausting CPU/RAM — the section 2 critical requirement (audio and video of the same clip never out of sync) is validated.

Section 4.0 cannot be considered fully closed until the frame-drop check is repeated with a screen representative of the show (a real TV, not the PC monitor used in this test) — there is evidence that the issue found is specific to this test monitor’s refresh limitations (no native 1080p30 mode) and likely won’t reproduce with a real TV. This remains a follow-up task; it does not block continuing with the M-VAVE analysis (section 4.1) while a suitable test screen is obtained.

Real-TV frame-rate test (2026-09-05, closes the follow-up above)

Repeated with the actual show TV (moved the Pi there, full cold power-cycle – also incidentally the first real validation that systemd auto-boot, section on systemd/ below, works end to end from a genuine power-off, not just a systemctl restart).

Section 4.0 is now closed: audio-video sync validated, and the frame-rate-mismatch line of investigation from the original PC-monitor test was followed through to a real TV and a real, evidence-based conclusion (not a fix, but a confirmed non-issue) rather than left open.