Skip to content

fix(openai): treat mp3 responseFormat as voice-compatible for Telegram voice notes#80326

Closed
hclsys wants to merge 2 commits into
openclaw:mainfrom
hclsys:fix/openai-tts-mp3-voice-note-80317
Closed

fix(openai): treat mp3 responseFormat as voice-compatible for Telegram voice notes#80326
hclsys wants to merge 2 commits into
openclaw:mainfrom
hclsys:fix/openai-tts-mp3-voice-note-80317

Conversation

@hclsys

@hclsys hclsys commented May 10, 2026

Copy link
Copy Markdown

Summary

Extends the voiceCompatible flag in the OpenAI TTS provider to accept mp3 in addition to opus when the synthesis target is voice-note. Telegram (and other channels) accept MP3 natively via sendVoice, mirroring the behavior of the Edge TTS / Microsoft provider which already uses isVoiceCompatibleAudio to detect mp3 as voice-compatible.

Closes #80317

Changes

extensions/openai/speech-provider.ts

  • Line 320: voiceCompatible condition extended to responseFormat === "opus" || responseFormat === "mp3"

extensions/openai/speech-provider.test.ts

  • Updated test name from "clears voice-note compatibility when not opus" → "clears voice-note compatibility for non-voice-compatible formats" (wav case unchanged — still false)
  • New test: "marks mp3 responseFormat as voice-compatible for voice-note target" — asserts voiceCompatible === true when responseFormat: "mp3" and target: "voice-note"

Real behavior proof

Behavior or issue addressed: OpenAI-compatible local TTS servers (Piper, Kokoro) configured with responseFormat: "mp3" now route Telegram voice notes through sendVoice (showing native waveform UI) instead of sendAudio (showing as file attachment).

Real environment tested: Ubuntu 22.04 (DGX Spark), Node 22.x, vitest 4.1.5

Exact steps or command run after this patch:

node scripts/test-projects.mjs extensions/openai/speech-provider.test.ts

Evidence:
Terminal output:

 Test Files  1 passed (1)
      Tests  10 passed (10)
   Start at  23:38:02
   Duration  365ms (transform 181ms, setup 105ms, import 133ms, tests 53ms, environment 0ms)

New test "marks mp3 responseFormat as voice-compatible for voice-note target" verifies result.voiceCompatible === true when synthesizing with responseFormat: "mp3" and target: "voice-note". The existing wav voice-note test confirms voiceCompatible === false for non-voice-compatible formats.

Observed result after fix: voiceCompatible: true for (target="voice-note", responseFormat="mp3"). All 10 tests pass.

What was not tested: Live Piper/Kokoro TTS server synthesis with actual Telegram sendVoice call; m4a or ogg formats (not in OPENAI_SPEECH_RESPONSE_FORMATS).

@openclaw-barnacle openclaw-barnacle Bot added proof: supplied External PR includes structured after-fix real behavior proof. extensions: openai size: XS labels May 10, 2026
@clawsweeper

clawsweeper Bot commented May 10, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge.

Summary
The PR changes the OpenAI speech provider to mark explicit MP3 voice-note output as voice-compatible and adds a focused regression test.

Reproducibility: yes. by source inspection. Current main preserves configured MP3 responseFormat, marks OpenAI voiceCompatible true only for Opus, and speech-core only requests voice delivery for Telegram voice-note output when that provider flag is true.

Real behavior proof
Needs real behavior proof before merge: The PR body shows only the focused Vitest run and no live Telegram or local TTS sendVoice proof, so contributor proof is still required before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, ask a maintainer to comment @clawsweeper re-review.

Next step before merge
Needs contributor-supplied redacted real behavior proof before merge; there is no narrow code repair for ClawSweeper to make.

Security
Cleared: The diff only changes OpenAI provider compatibility metadata and a focused test, with no dependency, workflow, secret, or supply-chain surface change.

Review details

Best possible solution:

Land the narrow provider compatibility change with the regression test after redacted real behavior proof shows MP3 OpenAI-compatible TTS routing through Telegram sendVoice.

Do we have a high-confidence way to reproduce the issue?

Yes, by source inspection. Current main preserves configured MP3 responseFormat, marks OpenAI voiceCompatible true only for Opus, and speech-core only requests voice delivery for Telegram voice-note output when that provider flag is true.

Is this the best way to solve the issue?

Yes. The PR is the narrowest maintainable code fix: it broadens only the explicit MP3 OpenAI voice-note case already accepted by the shared Telegram/media contract while leaving non-compatible WAV false.

Acceptance criteria:

  • Contributor should provide live Telegram proof via telegram-crabbox-e2e-proof or an equivalent redacted local Telegram/local TTS run showing sendVoice behavior.
  • Before landing, run pnpm test extensions/openai/speech-provider.test.ts or the repository wrapper for that focused test lane.

What I checked:

  • Current-main root cause: Current main preserves an explicit configured responseFormat, but the OpenAI provider only sets voiceCompatible for voice-note output when the resolved responseFormat is opus, so configured MP3 remains non-voice-compatible. (extensions/openai/speech-provider.ts:320, c7879bbc27ac)
  • Speech-core delivery gate: For voice-note channels, speech-core only marks TTS delivery as audioAsVoice when provider voiceCompatible is true or the channel advertises transcoding, so the OpenAI provider flag controls this path. (extensions/speech-core/src/tts.ts:836, c7879bbc27ac)
  • Telegram voice-note capability: Telegram declares voice-note TTS as its synthesis target, so OpenAI voice-note synthesis feeds the speech-core voice delivery path for Telegram. (extensions/telegram/src/shared.ts:166, c7879bbc27ac)
  • Shared media compatibility: The shared media helper already treats .mp3 and audio/mpeg as voice-message-compatible audio. (src/media/audio.ts:4, c7879bbc27ac)
  • Telegram send path: Telegram send selection calls sendVoice when asVoice is requested and resolveTelegramVoiceSend accepts the media; otherwise it falls back to sendAudio. (extensions/telegram/src/send.ts:916, c7879bbc27ac)
  • Existing Telegram MP3 test: Current Telegram tests already expect audio/mpeg with a .mp3 file and asVoice true to use sendVoice rather than sendAudio. (extensions/telegram/src/send.test.ts:1584, c7879bbc27ac)

Likely related people:

  • steipete: The provided prior review context records repeated merged work on the OpenAI speech provider and adjacent speech-core TTS surfaces that own this compatibility decision. (role: recent OpenAI TTS and speech-core contributor; confidence: high; commits: 827b0de0ce74, 5e3265b09bfe, 5aefe6abd6be; files: extensions/openai/speech-provider.ts, extensions/openai/speech-provider.test.ts, extensions/speech-core/src/tts.ts)
  • azade-c: The provided prior review context identifies the media compatibility commit that recognized MP3 and M4A as voice-compatible audio used by Telegram routing. (role: introduced related shared compatibility behavior; confidence: medium; commits: 1b95220a99e0; files: src/media/audio.ts, src/media/audio.test.ts)
  • obviyus: The provided prior review context identifies recent work on Telegram send routing and tests near the sendVoice/sendAudio path involved here. (role: recent Telegram send-path contributor; confidence: medium; commits: 7a2cc4b8d65c, b66cc66440a7; files: extensions/telegram/src/send.ts, extensions/telegram/src/send.test.ts)

Remaining risk / open question:

  • The PR body only supplies unit-test output; it does not yet show a live OpenAI-compatible TTS response routing through Telegram sendVoice.

Codex review notes: model gpt-5.5, reasoning high; reviewed against c7879bbc27ac.

Re-review progress:

@clawsweeper clawsweeper Bot added the mantis: telegram-visible-proof Mantis should capture Telegram visible proof. label May 10, 2026
@hclsys

This comment was marked as low quality.

Sign in to view
@clawsweeper clawsweeper Bot mentioned this pull request May 17, 2026
Closed
@clawsweeper clawsweeper Bot mentioned this pull request Jun 18, 2026
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

extensions: openai mantis: telegram-visible-proof Mantis should capture Telegram visible proof. proof: supplied External PR includes structured after-fix real behavior proof. size: XS

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

TTS OpenAI provider: MP3 responseFormat not voice-compatible for Telegram, unlike Edge TTS

1 participant

@hclsys