Support Opus DTX without slow-input warning oscillation #681

Problem

After the compatible dependency refresh (#674), @moq/publish changed microphone voice encoding to default to Opus DTX (usedtx: true). During silence, DTX suppresses regular 20 ms packets and emits sparse comfort-noise refresh frames roughly every 400 ms.

StreamKit’s Opus decoder currently emits audio only when an encoded packet arrives; it does not generate clocked silence/PLC for the missing interval. The clocked mixer consumes one frame every 20 ms and marks an input slow after the default 100 ms timeout. Each sparse DTX packet immediately clears that state, producing repeated slow_input_timeout degraded/running transitions (observed at about 2.35 flicker cycles per second).

This is expected codec behavior being interpreted as a transport/input stall, not evidence that MoQ itself consistently stalls. PR #680 contains the UI render fan-out but intentionally does not hide this backend state oscillation.

Proposed direction

For v0.6.0, explicitly configure the StreamKit browser microphone publisher with { mime: "opus", usedtx: false }. This restores continuous 20 ms audio frames and the behavior before the dependency update while preserving the mixer’s useful 100 ms warning for real stalls.

Longer term, support DTX intentionally in the clocked audio path by generating timestamp-aware silence/PLC through expected DTX gaps and distinguishing those gaps from transport stalls. Avoid solving this only with Monitor debounce or a globally longer mixer timeout.

Acceptance criteria

• A silent browser microphone does not repeatedly toggle slow_input_timeout.
• A genuine interruption of continuous audio input still degrades after the configured timeout and recovers when delivery resumes.
• Regression coverage exercises the selected policy (explicit DTX disable for the immediate fix and/or clocked sparse-packet handling for durable DTX support).

Written by Devin