[T0mSIlver]

Draft for review on the fork; rewrite it in your own words before opening upstream (llama.cpp does not accept AI-written PR text). Stacked on the tests PR, so open it upstream after that one merges. It needs an issue first; the facts for it are in llama-rt-prs/issue-rate.md.

Review: Codex (gpt-6.1-sol, low effort) on 5e7c1ac, no findings.

Overview

The server always plays input_audio_buffer.append audio at the model's sample rate (16 kHz for Voxtral), because the audio is raw 16-bit samples with no header. Today a client can still set session.audio.input.format.rate to another value, such as the 24 kHz that OpenAI Realtime clients use by default. The server accepts it, then transcribes audio played at the wrong speed, and nothing reports the problem.

This PR makes the server answer such a session.update with an error (audio.input.format.rate must be 16000) and keep the previous session settings. Updates that don't set a rate behave as before. The check compares the JSON value itself, so the string "24000" and 16000.5 are rejected too; reading it with json_value() would have turned the string into the default and cut off the fraction.

It also removes a README note, now out of date since ggml-org#30994, saying held-back words go to the next item.

Additional information

test_realtime_control_events now sends four updates: 24000, "24000" as a string, 16000.5 and 16000.

without the C++ change:  FAILED (event 2 is 'session.updated', expected 'error')
with the change:         SLOW_TESTS=1 ./tests.sh unit/test_realtime.py -k control_events -> passed

For scale: on an RTX 3090, 24 kHz audio read as 16 kHz gave a 41% word error rate, against about 22% for the same audio at 16 kHz.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES.

[T0mSIlver]

Replaced by #10, which is based on upstream master and drops the dependency on the tests PR #7.