The Pauses Between Her Sentences Are Gone

You say something. She answers, and there’s a gap before her voice actually starts. Then, if the answer runs more than one sentence, there’s another gap in the middle. You didn’t imagine it. On Windows, a call with her had three separate sources of dead air layered into it, and it’s the kind of thing that’s easy to write off as “voice calls are just kind of slow” until you find out they aren’t supposed to be. All three are fixed in v1.6.3.

Dead air is the only thing that matters in a voice call

In a text conversation, a two second delay before her reply shows up barely registers. You’re reading the last message, glancing at something else, thinking about your own reply. Two seconds of nothing on screen doesn’t break anything.

In a voice call, two seconds of silence is the entire experience. There’s no message on screen to read while you wait. There’s just her, not talking, right after you finished talking. That gap is not a delay before the experience, it is the experience, in the moment it happens. A voice call that’s a little slow doesn’t feel like a slightly slow voice call. It feels like a call with someone who keeps trailing off and losing the thread, someone who isn’t quite present.

This is why the latency here mattered more than the equivalent delay would anywhere else in the app. Text chat can absorb some slowness and still feel like a conversation. A call cannot. Every pause reads as a pause in her, not in the machinery underneath her, because you can’t see the machinery. You can only hear the silence.

That’s the whole reason this write-up exists as its own thing rather than a line item buried in a changelog nobody reads. None of these three bugs were about the words she said being wrong. They were entirely about the space between the words, and in a voice call, that space is the product.

She was re-learning her own voice before every sentence

This is the centerpiece bug, and it’s the one that cost the most.

Her natural voice doesn’t come from a fixed recording of every possible sentence. It works by studying a short reference clip of a voice, the one you picked or cloned, and using what it learns from that clip to generate new speech that sounds like it. That study step happens once, and then the engine is supposed to keep what it learned and reuse it for every sentence after that, for the rest of the call.

Instead, it was doing that study step again before every single sentence. Same clip. Same result, every time, because nothing about the clip had changed between one sentence and the next. But the engine had no memory of having already done this work seconds earlier, so it repeated the entire analysis from scratch, sentence after sentence, for the whole length of the call.

[VERIFY: is this a measured number or an estimate?] According to the Windows v1.6.3 release notes, this wasted about three quarters of a second per sentence, purely on re-analyzing a reference clip that hadn’t changed. On a short reply, three sentences, that’s roughly two seconds of dead air that had nothing to do with generating her words and everything to do with the engine forgetting what it had just learned a moment earlier. Across a whole conversation with back-and-forth turns, that adds up to a lot more than two seconds.

The fix is what you’d expect once you see the bug clearly: she learns the reference clip once, and then keeps that result for the rest of the call instead of redoing the work. Nothing about how she sounds changes. It’s the same voice, the same clip, the same output. The only difference is that the engine stops paying the same cost over and over for information it already had.

I want to be honest that this specific number traces back to the release notes for this build rather than to a controlled benchmark I ran separately. It came out of measuring real synthesis calls during testing, not a lab setup built to produce a clean headline figure, which is why I’m flagging it rather than presenting it as a guaranteed number for every machine and every voice.

Her reply and her voice were fighting over the same graphics card

This one is separate from the re-encoding bug and shows up specifically when the natural voice is turned on and the model composing her reply is also running on your own machine rather than in the cloud.

Composing her reply and generating the spoken audio for it are two different jobs. On a Windows PC with a single graphics card, if both jobs try to run on that card at the same time, they end up competing for it rather than sharing it cleanly. On some graphics cards, that competition doesn’t just slow both jobs down a little. It slows both of them down badly, in a way that’s worse than if the two jobs had simply taken turns.

Before this fix, that’s exactly what could happen: the model composing her reply and the voice engine speaking it were both trying to use the graphics card at the same moment, and the card handled that overlap poorly. The result was a call that could take a long time per turn, worse than either job would take on its own, worse than the two of them taking turns.

The fix here is to stop them from overlapping in the first place. Now, when the natural voice is on and the model is running locally, she finishes composing her reply completely first, and only then does the voice engine start speaking it. No more fighting over the same card at the same time.

I want to be specific about the boundaries of this one, because getting it wrong in either direction would either understate a real problem or scare people who were never affected by it. This only applies when two conditions are both true at once: the natural voice has to be turned on, and the model generating her reply has to be one running on your own computer rather than a cloud model. If you’re using one of the default curated voices instead of the natural voice, this competition never happened to you, because those voices don’t work the same way and were never in a position to compete with the reply model for the graphics card. The default voices were never affected by this, at any point, on any setup.

She was also cutting you off

The third source of dead air wasn’t really dead air at all in the traditional sense. It was her deciding you were done talking before you actually were, and that decision quietly threw away part of what you were about to say.

She listens for silence to figure out when you’ve stopped talking and it’s her turn to respond. Before this build, that threshold was 0.7 seconds of silence. The trouble is that 0.7 seconds is shorter than the pause a lot of people naturally leave in the middle of an answer that has more than one sentence in it. You finish your first sentence, take a breath, and start your second one. If that breath took more than 0.7 seconds, she’d already decided you were finished and start answering, and whatever you were about to say in that second sentence never got heard at all. Not delayed. Not queued up for later. Just gone.

That’s a genuinely different kind of problem than the other two. Those were about speed. This one was about her acting on incomplete information and never finding out it was incomplete. From your side, it would have felt like being interrupted mid-thought, which in a conversation with someone you’re supposed to feel close to is a worse experience than a slow reply.

The threshold is now 0.9 seconds by default, which gives an ordinary pause between two sentences enough room to not get mistaken for the end of your turn. And if 0.9 seconds still isn’t right for how you talk, Settings, Voice has a slider for this. Pick 0.7 seconds yourself if that’s genuinely what suits you, and that choice is kept and respected rather than silently overridden back to the new default.

The call used to vanish when you hung up

This last one isn’t a latency bug in the sense of dead air during the call, but it belongs in the same honest accounting because it’s the same underlying category of problem: something that was actually fine, but looked broken.

Everything said during a voice call was being saved the whole time. She could remember it days later if you brought it up. The memory side of this was never the issue. The issue was that after you hung up, the chat window on screen never went back and re-read what had just been said, so it looked, visually, like the call had never happened. You’d hang up, look at your chat history, and see nothing there, even though she genuinely remembered every word of it underneath.

That’s now fixed. Hanging up brings the conversation into view in the chat pane, matching what was actually saved the entire time. It’s a small technical fix, but the effect of watching a whole conversation apparently disappear the moment you hang up carries more weight than the size of the bug suggests. A companion whose calls seem to vanish reads as broken in a way that undermines trust in everything else, even when the underlying memory was solid the whole time.

What is still not right

Here’s the part I’m not going to soften. She can still, occasionally, clip a word at the end of something she’s saying. The voice engine sometimes keeps generating past where a sentence should end, and gets cut off before it finishes. It doesn’t happen constantly, but it happens.

This build does not fix that. What it does is add the logging needed to actually find which sentences trigger it, because right now that’s genuinely not known with any precision. Fixing something you can’t yet identify reliably tends to produce guesses dressed up as fixes, and I’d rather ship the diagnostic step honestly and follow with a real fix once the pattern is clear, than pretend a partial understanding is a solved problem.

I’m putting this in its own section on purpose, not folding it into the list of things that got better, because it didn’t get better. It’s an open issue. If you hit it, that’s not you misusing the feature or something specific to your setup, it’s a known, unresolved rough edge, and the next release is the one that should actually close it, once there’s real data on which sentences trigger it.

What it feels like now

None of this changes what she says to you. It changes how it feels to be on the other end of the call. Three separate silences, one per sentence from the re-encoding, one from two jobs fighting over the same graphics card, one from her cutting off your own thought before you’d finished it, are gone or shortened. What’s left is closer to the shape of an actual back-and-forth: you talk, there’s a normal beat, she answers, you talk again.

It still isn’t perfect. The clipped word at the end of a sentence is real, and I’d rather you hear that from me directly than notice it and wonder if something’s wrong on your end. But the difference between a call that has three stacked reasons to feel laggy and one that has none of them is not a small one, and it’s the kind of thing you only really notice once it’s gone.

If you’re on Windows and haven’t tried a call since before this update, this is worth a second look. And if you haven’t tried voice at all yet, the original announcement and the Windows voice post cover how to get started, along with cloning your own voice for her if you want something more personal than the defaults. The full changelog has every fix in this release, not just the ones covered here.

Questions people ask

Back to news