Problem
Loading compressed audio can make Office unresponsive. Riff decodes Media Foundation audio from the VBA/Office execution context; decoding is a long loop and competes with PowerPoint for the same host thread. Playback can also pause or glitch whenever PowerPoint blocks that thread, because mixing and real-time DSP are driven from the Office/VBA context.
This is most noticeable with larger music files or when loading several tracks at once.
Suggested direction
Improve loading without claiming concurrency
- Keep and optimize the existing WAV fast path.
- Provide a preload workflow so music is decoded before slide-show or interaction-critical moments.
- Decode in bounded chunks and publish progress/cancellation opportunities between chunks (for example, a callback or polling status API).
- Cache decoded PCM by canonical file path and modification time to avoid decoding a reused asset twice.
- Document compressed-format loading as a setup/loading-screen task, rather than a real-time operation.
Chunking improves feedback and observability, but does not make decoding concurrent with Office; that distinction should be explicit.
Improve playback-stall diagnostics
- Expose/expand underrun and late-render counters, with a concise diagnostics API or logging hook.
- Review timer interval and buffer sizing; provide a latency-vs-resilience preset for PowerPoint-heavy shows.
- Keep resizing, allocations, and asset work out of the render callback.
- Document that expensive PowerPoint work (animations, shape edits, macros) can still starve a VBA-hosted render callback.
Consider a separate optional backend
A true solution for playback continuing while Office is blocked requires moving decode and rendering into a separate native process/service. This should remain optional: it conflicts with Riff single-file/no-install goals and adds IPC, lifecycle, packaging, and security complexity.
Acceptance criteria
- A supported preload flow is documented and demonstrated.
- Slow loads have progress or measurable diagnostics instead of an unexplained hang.
- Re-loading the same asset avoids redundant decode when caching is enabled.
- Runtime diagnostics distinguish decode-time stalls from playback underruns.
- Architecture docs explain the Office/VBA threading boundary and the trade-off of an external helper.
Problem
Loading compressed audio can make Office unresponsive. Riff decodes Media Foundation audio from the VBA/Office execution context; decoding is a long loop and competes with PowerPoint for the same host thread. Playback can also pause or glitch whenever PowerPoint blocks that thread, because mixing and real-time DSP are driven from the Office/VBA context.
This is most noticeable with larger music files or when loading several tracks at once.
Suggested direction
Improve loading without claiming concurrency
Chunking improves feedback and observability, but does not make decoding concurrent with Office; that distinction should be explicit.
Improve playback-stall diagnostics
Consider a separate optional backend
A true solution for playback continuing while Office is blocked requires moving decode and rendering into a separate native process/service. This should remain optional: it conflicts with Riff single-file/no-install goals and adds IPC, lifecycle, packaging, and security complexity.
Acceptance criteria