Realtime Audio Bytes webhook + conversation audio_files stopped on CV1 v3.0.19 (~May 12); conversation/transcript webhooks unaffected

[sonsay]

Summary

On an Omi Consumer V1 (firmware Omi_CV1_v3.0.19), the Realtime Audio Bytes developer webhook stopped delivering any audio around May 12, 2026, and conversation objects stopped carrying audio_files at the same time. Conversation-created and realtime-transcript webhooks continue to work normally, so the endpoint, token, and connectivity are all fine — only the audio path is dead.

This timing lines up exactly with firmware v3.0.19 (published May 9–10) and app PR #7067 ("skip sending audio bytes to Omi backend in custom STT mode", merged May 10).

Environment

• Device: Omi Consumer V1, firmware Omi_CV1_v3.0.19
• Webhooks configured (all to the same host, token redacted): Conversation events ✅ receiving, Realtime transcript ✅, Realtime Audio Bytes ❌, Daily summary
• Audio Bytes interval: 120s, toggle ON
• STT provider tried: Local Whisper, Deepgram (fake key), and native Omi — no effect on audio bytes

Evidence (our self-hosted receiver logs)

• Real audio chunks (~3.85 MB PCM16, uid=<device>) arrived daily from Apr 27 → May 12. Last real chunk: 2026-05-12 17:52 UTC. Nothing since.
• Conversations carrying non-empty audio_files: April 69/91, May 31/110 (all 31 are early-May, before the 12th). After May 12 → audio_files: [] on every conversation.
• Conversation webhooks are still delivered today (20+ today); the audio webhook receives zero POSTs (not even a failed/UNMATCHED request) during active wear.

What we tried (no change)

• Switching STT provider (Local Whisper / Deepgram / native Omi) + Save
• Full app restart, device reconnect, re-saving the Audio Bytes webhook URL
• Confirmed firmware is the latest available (v3.0.19; no newer CV1 tag exists)

Questions

1. Did v3.0.19 and/or app PR Optimize: skip sending audio bytes to Omi backend in custom STT mode #7067 change when/whether raw audio reaches the backend (and thus the Realtime Audio Bytes webhook and audio_files)?
2. Is the audio path tied to a non-custom STT provider now? (Switching to native Omi did not restore it for us.)
3. Could the per-app webhook auto-disable (Auto-disable marketplace app webhooks after sustained failures #6885) have silently disabled only our audio webhook after sustained failures? If so, how does a developer re-enable it?
4. What is the intended way to receive raw audio (live or post-hoc via audio_files / a download endpoint) on v3.0.19?

Possibly related: #7067, #6885, #2193.

[sonsay]

Update: partially resolved on our side. The empty audio_files was caused by a custom on-device STT provider (Local Whisper) — once we switched to native Omi STT, a freshly-created conversation immediately got a populated audio_files again (provider: gcp, 120s chunk). So audio_files / backend audio storage works on native STT (consistent with #7067 gating audio to the backend in custom-STT mode).

Still open: the Realtime Audio Bytes developer webhook delivers zero POSTs even on native STT (works fine for conversation/transcript webhooks). We'll pull audio post-hoc via GET /v1/sync/audio/{conversation_id}/urls instead. Question 3 (per-app webhook auto-disable #6885 silently disabling only the audio webhook) still stands.