Summary

ClientPuduMonitor::startPlayback() negotiates only Int16 stereo at 24 kHz or 48 kHz. On Windows 11 with WASAPI shared mode, the audio engine mixer runs internally in Float32. When WASAPI's shared pipeline is configured in Float32 mode, dev.isFormatSupported(Int16) returns false for both rate candidates — not because the hardware can't do Int16, but because the WASAPI shared-mode pipeline rejects the format at the OS layer.

The result: the monitor's format negotiation fails silently, startPlayback() returns early, and the user gets no audio playback (though after the fix in #3222, RX audio at least recovers).

Affected component

src/core/ClientPuduMonitor.cpp — startPlayback() format negotiation (lines 202–231)

Evidence

• Log for issue VUDU TX record / playback mutes rx #3222 shows AudioEngine opens the same C-Media USB device successfully at Float32 stereo 48 kHz (WASAPI accepts Float32 fine)
• ClientPuduMonitor demands Int16 → WASAPI rejects it → format negotiation bail path
• No Audio Auxiliary sink summary line for "Aetherial monitor playback" in the log confirms startPlayback() returned before the successful-open logger at line 282

Root cause

The monitor's format negotiation does not include dev.preferredFormat() as a fallback. QuindarLocalSink and AudioEngine both use dev.preferredFormat() for exactly this case and are unaffected.

Proposed fix

Add dev.preferredFormat() as a third format candidate when both Int16 attempts are rejected. Accept the preferred format, resample via the existing r8brain path in preparePlaybackPcm(), then convert Int16→Float32 post-resample when the sink format is Float32. Follows the QuindarLocalSink.cpp:61 pattern already in the codebase.

Related: #3222