Summary
WhatsApp voice notes synthesized via ElevenLabs TTS are sent with a hardcoded audio/ogg; codecs=opus mime even though ElevenLabs returns MP3 by default, so the actual payload (MP3) does not match the declared container.
Mobile WhatsApp tolerates the mismatch (its decoder sniffs the magic bytes and falls back to MP3), but the Beeper / mautrix-whatsapp bridge rejects the message as Unsupported content type in Web mode — the recipient gets no voice bubble, no audio file, a silent drop.
Root cause
packages/whatsapp-gateway sendAudio hardcodes the outgoing mime as audio/ogg; codecs=opus regardless of the real buffer format, and the ElevenLabs path in crates/librefang-runtime/src/tts.rs does not request an Opus output_format, so the buffer is MP3 while the wire says Ogg/Opus.
Repro
- Configure an agent on a WhatsApp channel bridged through mautrix-whatsapp / Beeper with ElevenLabs TTS.
- Have the agent send a voice note.
- The message is dropped by the bridge with
Unsupported content type in Web mode; no audio reaches the recipient.
Prior fix attempt
A fix was implemented in PR #5283 (request a config-driven Opus output_format from ElevenLabs; sniff the real mime via magic bytes in sendAudio and auto-downgrade ptt to false for non-Opus buffers).
That PR was closed unmerged during a stale-PR sweep, so the underlying problem is most likely still present on main and needs re-verification before any new fix.
Suggested labels
bug, area/channels
Summary
WhatsApp voice notes synthesized via ElevenLabs TTS are sent with a hardcoded
audio/ogg; codecs=opusmime even though ElevenLabs returns MP3 by default, so the actual payload (MP3) does not match the declared container.Mobile WhatsApp tolerates the mismatch (its decoder sniffs the magic bytes and falls back to MP3), but the Beeper / mautrix-whatsapp bridge rejects the message as
Unsupported content type in Web mode— the recipient gets no voice bubble, no audio file, a silent drop.Root cause
packages/whatsapp-gatewaysendAudiohardcodes the outgoing mime asaudio/ogg; codecs=opusregardless of the real buffer format, and the ElevenLabs path incrates/librefang-runtime/src/tts.rsdoes not request an Opusoutput_format, so the buffer is MP3 while the wire says Ogg/Opus.Repro
Unsupported content type in Web mode; no audio reaches the recipient.Prior fix attempt
A fix was implemented in PR #5283 (request a config-driven Opus
output_formatfrom ElevenLabs; sniff the real mime via magic bytes insendAudioand auto-downgradeptttofalsefor non-Opus buffers).That PR was closed unmerged during a stale-PR sweep, so the underlying problem is most likely still present on
mainand needs re-verification before any new fix.Suggested labels
bug, area/channels