Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Realtime: committed-utterance WAV written with fixed 16 kHz header breaks 24 kHz client commits (empty STT -> input_not_committed -> total silence)

Open
  • Is something wrong?
#12,747 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@nexxtmobile is already working on this.

Since Oct 17, 2026.

  • #12749 by @nexxtmobile — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
go
Domain
audio-video-rtc

Research direction

Read commitUtteranceWithTranscript and writeUtteranceWAV, including both call sites described in the issue. Check how the WAV header rate relates to session.InputSampleRate; done means 24 kHz client-committed audio is written with a 24 kHz header and transcribes correctly.

Written by the indexing model from the issue text.

Description

area/api bug confirmed

Bug

In the OpenAI-Realtime pipeline, the client-commit path writes the committed
utterance to a temp WAV with a fixed 16 kHz header
(laudio.NewWAVHeader(uint32(len(utt))) in commitUtteranceWithTranscript,
and writeUtteranceWAV), while the input buffer holds audio at the
session input sample rate (e.g. 24 kHz for OpenAI-Realtime clients —
session.update audio.input.format.rate = 24000).

The file-based transcription backend then decodes 24 kHz PCM data with a
16 kHz header (1.5x speed/pitch), degrading transcription to garbage or
empty output. An empty transcript fails the follow-up response with
input_not_committed → total silence after the greeting (no reply at
all, recovery phrases not triggered either).

Reproduction

  1. Start a realtime session with audio.input.format.rate = 24000 and
    turn_detection: null (client-driven commits).
  2. Stream ~2 s of speech, send input_audio_buffer.commit.
  3. The committed WAV (temp file realtime-audio-chunk-*.wav) carries a
    16 kHz header; the transcription of 24 kHz content at 16 kHz is garbage
    or empty → response.done failed input_not_committed.

Offline proof: identical audio transcribes cleanly with a 24 kHz header and
produces empty output with a 16 kHz header.

Fix

writeUtteranceWAV takes the sample rate; both call sites pass
session.InputSampleRate via the existing laudio.NewWAVHeaderWithRate
(PR follows).

Impact

Every client-commit session with an input rate other than 16 kHz
(WebRTC sessions resample to 16 kHz and are not affected).

Dominant language
Go
Stars
49.5k
Forks
4.5k
Avg merge
20h 46m
Merged PRs (30d)
371

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mudler/LocalAI

All issues in mudler/LocalAI

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.