记录一下那天晚上的排查过程。浏览器端用 WebSocket 连 gpt-4o-realtime-preview，音频按 24k 单声道 pcm16 每 20ms 送一帧，刚送两帧就发 input_audio_buffer.commit，服务端回 error 说 buffer too small，原文 expected at least 100ms of audio but got 40ms，把每帧调到 100ms 再发仍然偶发。
刚开始盯着「append 消息还在发送队列里就抢先发 commit」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。累计音频不足 100 毫秒就提交缓冲。少数情况下是采样率按 16k 计算导致实际时长只有一半。
不容易想到的是，断线重连后服务端缓冲已被清空。
上来先用 Python 生成 240ms 静音 pcm 再 append
python -c "import base64,struct;d=b'\x00\x00'*5760;print(base64.b64encode(d).decode())"append 后间隔 300ms 再发 commit
python ws_commit.py --chunk-ms 240 --wait 0.3本地记录字节数换算出的时长与帧数
python -c "n=5760;print(n*2/24000, 's')"剩下的就是把 commit 放进队列按 300ms 节流发送
python realtime_client.py --commit-interval 0.3 --min-audio-ms 120怎么算真的好了，看的是同一批现象。能收到 input_audio_buffer.committed 事件，随后 response.audio.delta 正常返回，日志里不再出现 buffer too small。
服务端按 24k 单声道折算时长，传 mp3 或双声道数据会被判成时长不足，采样率必须和 append 的格式一致。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。