Missing full parameter mapping for OpenAI-compatible TTS API (/v1/audio/speech)

[Scorpoon]

Hi,

thanks for this project — it works very well overall.

The current HTTP server does not expose most of the configurable fields available in qt_tts_params, as it relies entirely on qt_tts_default_params() and only forwards a minimal subset (text, speaker, instructions, lang).

It would be very useful if the API layer exposed at least the following groups of parameters:

• sampling control: seed, do_sample, temperature, top_k, top_p, repetition_penalty
• output control: max_new_tokens
• codec/streaming control: codec_chunk_sec, codec_left_context_sec

In addition, the backend already supports voice conditioning (ref_audio_24k / ref_spk_emb / ref_codes / ref_text), but this is currently not accessible via the HTTP API. A server-side voice reference mechanism (e.g. reference_id mapped to stored voices) would make this much more practical for integrations like Open WebUI or Home Assistant.

Overall, this would make the server significantly more deterministic and production-friendly.

Thanks again for your work.

[ServeurpersoCom]

I'll be pushing few commits for the first version of the server today :)

[Scorpoon]

I also just tried out the voice clone function on the server you commited earlier. First I thought it doesn't work at all, then i just put "name" instead of "lang_name_emotion" into the name field. It seems the server can't handle "" or do I have to escape ""?
Works fine after changing the name ;)

Would it be possible to auto register voices which are located in a folder on the server?
Nice to have would be to just put the wav and txt file in a folder, server starts, automatically creates spk and rvq files from it and registers the voice.

I searched a few days for a really good solution for tts running on my amd gpu and this one totally nailed it! 🥳

[ServeurpersoCom]

Voice management is handled client-side, so a script can do the job

[ServeurpersoCom]

Sampling and output params landed: seed, temperature, top_k, top_p, repetition_penalty and max_new_tokens are all accepted per request on /v1/audio/speech (temperature 0 selects greedy, so no separate do_sample). The voice reference mechanism landed as the voice registry: register a voice by name through POST /v1/audio/voices (WAV or pre-extracted spk/rvq payloads), select it per request, note the routes just moved from /v1/voices.

Not doing: the codec streaming knobs (codec_chunk_sec, codec_left_context_sec) stay out of the request API, they are deployment-level latency tuning, and folder auto-registration stays client-side, a small script over POST /v1/audio/voices does the job.

[DerGary]

FWIW, #14 addresses part of this — it exposes --codec-chunk-dur / --codec-left-dur (i.e. codec_chunk_sec / codec_left_context_sec) as tts-server CLI flags, mirroring what qwen-tts.cpp already had. It's a startup-time server config rather than a per-request override, so it doesn't cover the full ask here (sampling params, max_new_tokens, or the ref-audio/voice-reference API), but it closes the codec/streaming-control gap you listed.

[ServeurpersoCom]

FWIW, #14 addresses part of this — it exposes --codec-chunk-dur / --codec-left-dur (i.e. codec_chunk_sec / codec_left_context_sec) as tts-server CLI flags, mirroring what qwen-tts.cpp already had. It's a startup-time server config rather than a per-request override, so it doesn't cover the full ask here (sampling params, max_new_tokens, or the ref-audio/voice-reference API), but it closes the codec/streaming-control gap you listed.

Heads up on #14: I measured the chunked decode against a single pass decode and the left context turns out not to be a tuning knob at all. Below roughly 144 frames every chunk after the first is degraded over its whole length, not just at the seam, and your 4.0 / 1.5 setting sits about 19 dB below the single pass reference past the first four seconds. The convergence point is twice the codec decoder sliding window, which the model metadata already gives us, so I am deriving it at load and dropping --codec-left-dur. --codec-chunk-dur stays and is the memory knob, with the peak decode window now the chunk plus about 11.5 s. If that no longer fits next to your LLM and ASR on the 8 GB card, use response_format pcm: the streaming path carries persistent codec state, so it is bounded by construction and truncates no context. Thanks for the flag work, it is what got me to measure this properly.

[ServeurpersoCom]

Pushed: codec_chunk_sec moves to qt_init_params and resolves once at load, codec_left_context_sec is gone from the API entirely (derived from the decoder sliding window in the model metadata), and since that removes a mid-struct field the ABI bumps to a closed v4 range so stale bindings fail loudly instead of reading shifted offsets.