Background
Soniox shipped in v0.33.0 (#339). Its real-time API exposes several documented features we don't use yet. This issue tracks four worth adding later. None are required for the current integration — this is a backlog.
Docs: https://soniox.com/docs
1. context — custom vocabulary & preferred translations
The STT WebSocket config accepts a context object:
context.general — key/value metadatacontext.text — reference text that biases recognitioncontext.terms — domain-specific vocabulary (names, jargon, product names)context.translation_terms — force preferred translations for specific terms
Benefit: better accuracy on names/jargon, and consistent user-controlled translations of specific terms.
Where: add to the STT connect config in src/services/clients/SonioxSttStream.ts; surface as an optional setting (e.g. a terms list / glossary) in SonioxProviderConfig + settings UI.
2. endpoint_sensitivity / endpoint_latency_adjustment_level — endpoint tuning (v5)
We already send enable_endpoint_detection: true + max_endpoint_delay_ms: 500. The v5 model additionally supports:
endpoint_sensitivity — range -1.0 .. 1.0 (default 0.0)endpoint_latency_adjustment_level — range 0 .. 3 (default 0)
Benefit: tune how eagerly the model closes an utterance — trade latency against premature cut-offs.
Where: same STT config in SonioxSttStream.ts; optionally expose as an advanced setting.
3. speed — TTS speaking rate
Soniox real-time TTS accepts a speed parameter controlling the speaking rate of synthesized output.
Benefit: let users slow down / speed up the spoken translation.
Where: add to the TTS config in src/services/clients/SonioxTtsStream.ts; expose a speed control in the Soniox provider settings (follow the existing per-provider voice-dropdown pattern).
4. enable_speaker_diarization + token speaker — speaker separation
STT can label each token with a speaker id when enable_speaker_diarization: true.
Benefit: proper speaker attribution. Today, in Both single-session mode we infer which side a token belongs to by comparing its language to the configured source (utteranceSide in SonioxClient.handleSttMessage). Real diarization would be more robust and could distinguish multiple speakers on the same side. The speaker token field is already typed in SonioxSttStream.ts but unused.
Where: enable the flag in the SonioxSttStream.ts config; consume token.speaker in SonioxClient.
Other documented-but-unused features (word-level timestamps, per-token confidence, async/batch file transcription) are noted for completeness but out of scope here.
Temporary/ephemeral API keys are not a concern for this frontend repo — it never needs to mint them. If we ever want backend-managed Soniox keys (the way Kizuna AI keys are handled), that belongs in sokuji-backend, not here.
🤖 Generated with Claude Code
Background
Soniox shipped in v0.33.0 (#339). Its real-time API exposes several documented features we don't use yet. This issue tracks four worth adding later. None are required for the current integration — this is a backlog.
Docs: https://soniox.com/docs
1.
context— custom vocabulary & preferred translationsThe STT WebSocket config accepts a
contextobject:context.general— key/value metadatacontext.text— reference text that biases recognitioncontext.terms— domain-specific vocabulary (names, jargon, product names)context.translation_terms— force preferred translations for specific termsBenefit: better accuracy on names/jargon, and consistent user-controlled translations of specific terms.
Where: add to the STT connect config in
src/services/clients/SonioxSttStream.ts; surface as an optional setting (e.g. a terms list / glossary) inSonioxProviderConfig+ settings UI.2.
endpoint_sensitivity/endpoint_latency_adjustment_level— endpoint tuning (v5)We already send
enable_endpoint_detection: true+max_endpoint_delay_ms: 500. The v5 model additionally supports:endpoint_sensitivity— range-1.0 .. 1.0(default0.0)endpoint_latency_adjustment_level— range0 .. 3(default0)Benefit: tune how eagerly the model closes an utterance — trade latency against premature cut-offs.
Where: same STT config in
SonioxSttStream.ts; optionally expose as an advanced setting.3.
speed— TTS speaking rateSoniox real-time TTS accepts a
speedparameter controlling the speaking rate of synthesized output.Benefit: let users slow down / speed up the spoken translation.
Where: add to the TTS config in
src/services/clients/SonioxTtsStream.ts; expose a speed control in the Soniox provider settings (follow the existing per-provider voice-dropdown pattern).4.
enable_speaker_diarization+ tokenspeaker— speaker separationSTT can label each token with a
speakerid whenenable_speaker_diarization: true.Benefit: proper speaker attribution. Today, in Both single-session mode we infer which side a token belongs to by comparing its language to the configured source (
utteranceSideinSonioxClient.handleSttMessage). Real diarization would be more robust and could distinguish multiple speakers on the same side. Thespeakertoken field is already typed inSonioxSttStream.tsbut unused.Where: enable the flag in the
SonioxSttStream.tsconfig; consumetoken.speakerinSonioxClient.Other documented-but-unused features (word-level timestamps, per-token confidence, async/batch file transcription) are noted for completeness but out of scope here.
Temporary/ephemeral API keys are not a concern for this frontend repo — it never needs to mint them. If we ever want backend-managed Soniox keys (the way Kizuna AI keys are handled), that belongs in
sokuji-backend, not here.🤖 Generated with Claude Code