In our call testing, Gemini 3.1 Flash Live followed the system instruction of having a “British accent” pretty much all the time. Now with this new gemini live 3.8, I’ve noticed that it completely ignores this instruction and just continues with an American accent. I’ve tried multiple different prompts i.e. shorter, longer and it seems to ignore the accent request.
Hello @Ned_Cerneckis ,
DM’ed you for more details.
We too are noticing this, and can we please urge google QA team to start adding such tests to your QA test plans.
It is then speaking words even in British English accent like ROWTER (ROUTER)
So one of your tests must be to test pronunciations in an accent in a same lingual language.
What concerns me is 2.5 end of life 13th December. The 3.8 live speech side is way way better and incredibly more robust. The audio generation is also a step back, sounds not so expressive but also no matter what is done it switches between UK and US accents. I tried a Scottish accent and it went to an UK English, tried again then got a Scottish accent.
The problem also is you can’t switch off the audio tokens, forced to have them/pay for them whilst using a work around using a pure fast parallel tts option.
Any thoughts
I tried gemini live 3.8 with another vendors fast live streaming expressive TTS voice GB English and it was as fast as gemini 3.8 (native audio streaming) but importantly it stuck to GB English but then this breaks the AInAOut Model
I don’t want to switch or mix vendors so was a test. Many of us are committed to Google and mixing vendors complicates billing for us too.
I would say this is a P1 critical fix 48 hours, a lot of projects will be put on hold. I have 8 on my plate, and 3 massive ones and one delayed because of a data vendor (100’s of outlets).
I would say this is an immediate urgency and cannot be delayed.
thank you kindly for listening!
Can you DM me as well please? Same issue as him
We have the same issue. Gemini 3.8 live drifts on the accent back to US natural accent all the time and keeps doing it. If we ask it what accent you are speaking in it would say, i.e “South African Afrikaans”, and for a short while speak in that accent before then regresses and again speak in the US accent. We can’t lock in accents which makes it unusable for our purpose. We must revert to 3.1 flash live but that will discontinue soon. So, Google has to sort this asap else the model can’t be used for many reasons.
we’ve had to pivot using a separate TTS which defeats the whole model approach.
This can’t be left, it has to be fixed immediately.
Personally I prefer when a language code could be put in and enforced be it for the session, at least then its clear. Or if you want universal you can leave it open to work out the speaking language.
Hello @Gerrard_Smith ,
DM’ed you for more details.
I also have the same issue. But interestingly, when I test it in Google studio, it correctly speaks in British accent. If someone found work around, can you please share it also with me?
Can confirm this is a regression issue (from 3.1 → 3.8) for any accent in English: every speaker seems to have an American undertone.
The only thing that seems to have a mildly positive effect is removing the language code completely from the API call.
Hey @Ned_Cerneckis did you get any work around or solution for this issue, I am also facing the same issue.
Likewise here - this is the main issue preventing my migration from 3.1 live preview to 3.8 live, as otherwise I cannot support my customers. Using Gemini 3.8 TTS and requesting the accent per voice works flawlessly, and using AI Studio reproduces my production stack where it might remember an accent for 1 turn and then back to American as it forgets.
I too am monitoring this thread or others like it, to trigger a workaround or when a fix might be available.
We’re seeing a related issue on gemini-3.8-live . The model many times mispronounces names that are given in the prompt, shortening or changing them, and the listener doesn’t recognise their own name. In our testing it happened in about 2 out of 5 calls. A pronunciation instruction in the system prompt helps only slightly, and changing voice didn’t help.
Is there a supported way to control pronunciation on native-audio Live models, and is this a known issue?
Hi @Pragi_Singh
Not knowing how to submit issues to Google properly on things like that, but I believe I ran into a very similar issue as you describe. For us, the issue stemmed from token size and tool declaration lengths - see the issue I wrote up here: [Live API] Function declaration size degrades speech output (name pronunciation): is there a documented budget or design pattern? · Issue #3120 · googleapis/python-genai · GitHub
That then made the audio mispronounce names at a significant rate for our usage, and this was much more sensitive on Gemini 3.8 live over Gemini 3.1 Live preview.
Maybe that information helps you work around the issue, albeit still a mysterious limitation.
I am seeing a related issue on gemini-3.8-live via Vertex AI . The model sometimes mispronounces names that are given in the prompt, shortening or changing them, and the listener doesn’t recognise their own name. A pronunciation instruction in the system prompt helps only slightly, and changing voice didn’t help.
Is there a supported way to control pronunciation on native-audio Live models, and is this a known issue?
Thanks @Rocalyn_Dave
Hello Everyone,
I have DM’ed you for more details.
I’ve found that using a supported language code such as en-IN (Indian English) allows the model to maintain a consistent accent.
config = types.LiveConnectConfig(
speech_config=types.SpeechConfig(
voice_config=types.VoiceConfig(
prebuilt_voice_config=types.PrebuiltVoiceConfig(
voice_name="Kore"
)
),
language_code="en-IN",
)
)
Sadly it doesn’t help with the actual accent I need (East African English), but it’s better than the American English we are stuck with otherwise.
@Sai_Deepika_K if you need more help testing, I’d be very keen to help out.