A voice feature can be technically impressive and still feel broken if transcription, playback and avatar timing disagree. This article goes beyond the feature name and looks at the practical customer experience, the engineering trade-offs and the decisions AVRE is using while the product moves from development builds toward a commercial release.
Speech input should use the normal composer
A separate transcript box seems harmless until the user has to guess which text will actually be sent. AVRE's revised interaction is simpler: the microphone feeds the same message composer used for typing. The user speaks, the recogniser fills the field, the user can correct a word, and the normal Send button creates the chat message. Voice becomes another way to enter text rather than a second messaging system.
This is particularly important for languages or accents where automatic transcription is not perfect. Editing a recognised sentence before sending is faster and less frustrating than cancelling an entire voice workflow because one noun was wrong.
No-speech handling matters
Speech recognition models can hallucinate text from room noise or silence. That is more than a cosmetic problem in a Companion because a false transcript can trigger a real AI response. AVRE therefore uses guards for blank audio, near-flat microphone input, no-speech confidence where available and obvious repetition loops. The desired customer message is simple — 'No speech detected' — while the technical heuristics remain internal.
Language selection matters too. Explicitly choosing Romanian, English or another supported language can be more reliable than forcing automatic language detection on every clip. Automatic mode can remain available without pretending it is always the best option.
Automatic TTS can make fast text feel slow
During Stage 5 manual testing, text responses appeared and then the Companion spoke the same answer much later. Even if the voice engine eventually worked, the delay made the whole app feel sluggish. The better default is immediate text with a small speaker control on each Companion message. The user can decide which messages deserve voice playback.
This design also works better in public spaces. Someone can chat silently, then play only a specific message through the chosen Companion voice when appropriate. A future 'Auto speak replies' option can still exist, but it should be explicit rather than a hidden source of latency.
Lip sync follows the audio lifecycle
The 3D avatar should treat actual TTS playback as the source of truth. When audio begins, the avatar enters Speaking and mouth motion starts. When the audio buffer ends, playback is stopped or the user cancels, the mouth returns to idle immediately. A fake timer can demonstrate animation, but it is not enough for the commercial interaction.
Detailed phoneme or viseme data can improve realism later. For development, an audio-amplitude envelope can already produce visible mouth movement as long as the lifecycle is correct. A simple mouth that starts and stops at the right time feels more coherent than a sophisticated mouth animation disconnected from the voice.
Voice is part of Companion identity
The selected voice belongs to the active Companion profile. If the user switches to another Companion, voice settings and transient playback state should not leak. The application interface language and Companion voice language are also separate choices: a user may want an English UI but a Romanian or Italian-speaking Companion.
Future voice packs can add tone, timbre and language coverage without changing the underlying chat model. Keeping this as a profile-level capability makes the product extensible rather than hard-coding one voice into the application.
The goal is controllable presence
A Companion feels more present when the user can speak naturally and hear a response in a familiar voice, but constant audio is not the goal. Silence should remain silence. Text should not wait on voice. Cancellation should be immediate. The 3D mouth should stop when playback stops. These details make the feature dependable enough for everyday use.
AVRE's voice work is therefore judged by manual customer flow, not only by whether a TTS engine can output a WAV file. The integration is the product.
What this means for AVRE customers
The standard AVRE is aiming for is simple: a customer should be able to understand what a feature does, where the data goes, what hardware it uses and what happens when it fails without reading developer notes. That is why the public site now separates finished behaviour from planned behaviour and why manual testing can reject a technically present feature when the visible workflow is poor. Product documentation will continue to change as the release build becomes more stable, but those changes should make the promises more precise rather than quietly changing what the product is.