Listener-specific language switching needs a rule for audio already in flight. A participant can switch from Japanese to French while the Japanese synthesis is queued or playing, and a late completion can otherwise reintroduce the old language after the interface shows the new preference.
I would attach a preference generation and speaker-turn ID to each translated segment, then discard or finish older segments according to an explicit playback policy. Test a switch during synthesis and again during reconnection. That makes the recovery behavior observable and keeps shared translation work separate from each listener's current playback state.
Our architecture works a little differently. In Voicli, users select their preferred translation language in their profile during registration, and this preference remains fixed throughout a meeting.
However, users can speak in any supported language. Voicli automatically detects the spoken language and translates it into each listener's preferred language.
This design eliminates the mid-meeting target-language switching scenario you described and helps us keep audio processing more predictable.
Your point about handling queued audio during reconnections is still very relevant. Thanks for sharing your insights!
Ahmet Özel
AI Engineer. Computer Vision, RAG and LLM agents.
Listener-specific language switching needs a rule for audio already in flight. A participant can switch from Japanese to French while the Japanese synthesis is queued or playing, and a late completion can otherwise reintroduce the old language after the interface shows the new preference.
I would attach a preference generation and speaker-turn ID to each translated segment, then discard or finish older segments according to an explicit playback policy. Test a switch during synthesis and again during reconnection. That makes the recovery behavior observable and keeps shared translation work separate from each listener's current playback state.