Send the picked target language to OmniVoice (CrispASR)

[niksedk]

Fixes the SE half of #13273.

The engine advertised HasLanguageParameter and offered all 646 of the model's languages, but Speak() took the TtsLanguage and never put it on the request — the payload was only {input, response_format, speed}. As reported, the menu was decoration.

It has to be a payload field rather than a startup flag: SE keeps one crispasr server for the whole session, so a launch argument could never follow a combo change after the first line. The other cloning CrispASR engines already send it this way.

The default had to be fixed first

Adding the field alone would have made things worse. The view model had no arm for this engine, so it fell through to the first entry of an alphabetical list — "Abadi" (kbt), a real ISO 639-3 id the model would happily condition on — and the pick was never persisted.

So OmniVoiceLanguages.All now leads with "Auto" (empty code → no field → language-agnostic, i.e. the pre-existing behaviour), with the 646 generated entries kept in a private Catalog so they can still be regenerated wholesale. Both the main TTS window and the review window restore the saved pick — they had drifted apart, review already defaulting to English while the main window defaulted to Abadi — and a new OmniVoiceCrispAsrLanguage setting stores it.

Two things beyond the report

• ResolveLanguageArg(null) falls back to the saved pick. The cast dialog's voice-test button and every cross-engine cast row pass null on purpose ("engines fall back to their own saved defaults") — the same hole CosyVoice3 had in CosyVoice-TTS - The target language is not assigned during cloning. #13272.
• Values that are not the model's own ids are dropped rather than sent. crispasr falls back to language-agnostic on those anyway, but a locale code like de-DE or a leftover language object from another engine has no business on the wire.

Note on the ids

They are ISO 639-3 individual languages, so there is no ar — Arabic is arb (Standard), arz (Egyptian), ary (Moroccan) and ~20 more. That is the model's vocabulary, not a gap in the list; asserted in tests so it does not get "fixed" later by inventing an id the model has never seen.

Requires a CrispASR bump to take effect

On the pinned v0.8.25 the CLI adapter applies the language only at startup, so the field is parsed and ignored on every request. The fixes — per-request apply, the session C-ABI arm, and running _resolve_language() on the id — are on CrispASR main and in no release yet.

Sending it on v0.8.25 is harmless (SE only ever puts the model's own ids on the wire) and it goes live the moment CrispAsrDownloadService is bumped past v0.8.25 — the same bump CosyVoice3 cross-lingual (#13272) is waiting on. Flagged in the class docs so nobody debugs it as broken in the meantime.

Not fixed here

The other half of #13273 — the reference accent — is a separate, structural problem. OmniVoice has no cross-lingual mode: the reference transcript sits before the reference audio in a single token stream, so it cannot be dropped the way CosyVoice3 does. Cloning an English speaker onto German text may still sound English however the tag is set. Thanks to @CrispStrobe for the detailed backend analysis and for not overclaiming that part.

Testing

Full UI suite: 1599 passed, 0 failed. New coverage for the Auto-leads invariant, the null/Auto/unknown resolution paths, and the absent-ar case.

🤖 Generated with Claude Code