Voice and video simulations: what goes wrong and how to fix it

Voice and video simulations depend on the learner’s microphone, their browser and a live connection, so they have failure modes a text simulation does not. This article lists what actually goes wrong, what the learner sees when it does, and what fixes it.

Start here: almost every “the voice does not work” report is one of the first three items below.

1. “Audio could not start”

The learner sees Audio could not start with Try again and End Simulation buttons. When the browser refused the microphone, the message says so: “We couldn’t reach your microphone. Check that your browser is allowing microphone access for this site, then try again.” Otherwise it reads “We couldn’t start the audio conversation. Try again, or end the simulation.” The dialog also shows an Error code:, which helps support trace the problem.

If the message says voice calls aren’t available for your organization, the cause is the organization’s own AI provider connection, not the learner’s device. An organization administrator checks the AI Providers page. See Run simulations on your own AI provider account (BYOK).

Nearly always this is microphone permission. In order of likelihood:

The learner dismissed or blocked the browser prompt. Click the padlock (or the camera/microphone icon) in the address bar, allow the microphone for the site, then press Try again. In Chrome a blocked site has to be reset there; the prompt does not reappear on its own.
The device has no working microphone, or another application is holding it exclusively. Close the other application (video-conferencing tools are the usual culprit) and reload.
The organization blocks microphone access by policy. On managed laptops this is set centrally and cannot be fixed in the browser — it needs IT.

Everything else in the activity — the briefing, forms, quizzes, the report — keeps working while this is unresolved. Only the conversation is blocked.

2. The simulation is embedded in a page, and the microphone never works

This one is easy to misread as a permission problem, because the browser never even asks.

A page that embeds Cesura in an <iframe> has to grant the frame permission to use the microphone. If it does not, the browser silently refuses the microphone to the embedded page no matter what the learner allows.

The embed snippet the Share dialog gives you includes that permission. Snippets copied from an earlier version of Cesura did not, and a snippet already pasted into a page keeps whatever it was copied with — so check the page itself. The allow list should read:

<iframe src="..." width="100%" height="600px" frameborder="0"
  allow="microphone; camera; accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
  allowfullscreen></iframe>

If you would rather not edit HTML by hand, copy the embed code again from the Embedding tab and replace the whole snippet.

SCORM and LTI

Permission is passed down through every frame between the browser window and the simulation. One frame that withholds it blocks the microphone for everything inside it, however carefully the frames further in are set up.

SCORM: open the package in a new window. The player Cesura generates hands the microphone and camera to the simulation, but it sits inside your LMS’s own frame — and Moodle’s embedded SCORM player passes neither through, so voice cannot work there. Set the SCORM activity’s Display package to New window in Moodle, or the equivalent “open in a new window” setting in your LMS: a window is not a frame, so there is nothing to pass down and voice works normally. It is the same setting that fixes a blank or cramped SCORM screen.
LTI launches depend on your LMS. Moodle passes the microphone and camera to the tool frame, so voice works. Not every LMS does. If a voice simulation works from a direct link but not inside your LMS, ask your LMS administrator whether the tool frame allows the microphone — or deliver voice activities by link instead.

If in doubt, have the learner open the simulation with its direct link. If it works there and not in the page, it is the frame.

3. The browser or device is not suitable

Use a current Chrome, Edge, Safari or Firefox. Voice needs microphone capture and a live connection; older browsers and unusual in-app browsers often have neither.
In-app browsers are the common trap — a link opened inside LinkedIn, Facebook, Instagram or some corporate chat apps opens in a stripped-down browser. Tell learners to open the link in their real browser (“Open in Safari / Chrome” in the in-app menu).
On iPhone and iPad, use Safari. Other iOS browsers are wrapped around the same engine but do not always get microphone permission.
The site must be served over HTTPS, which Cesura always is — but a proxy or an LMS that re-serves content over plain HTTP will break microphone access.

4. The camera will not turn on in a video call

The camera is optional and separate from the microphone. The call continues either way.

“Your browser is blocking the camera. Allow camera access for this site to turn your video on.” — permission was denied or dismissed. Same fix as the microphone: allow the camera in the address-bar controls, then press Start video again.
“This browser cannot use a camera here. The call continues without your video.” — the browser or the embedding page does not offer a camera at all. See item 2: the frame needs camera in its allow list too.

Nothing from the camera is transmitted or recorded, so a learner who cannot get their camera working loses nothing but the picture on their own screen.

5. Echo, feedback, or the character interrupting itself

On a laptop speaker the microphone can pick up the character’s own voice, and the model then reacts to itself — the conversation stutters, or the character talks over the learner.

Tell learners to use headphones or earbuds. It is the single highest-value instruction you can put in the briefing for a voice activity, and it also improves transcription quality. A quiet room helps for the same reason.

6. The conversation stops mid-way

A voice run reconnects by itself after a network blip — it keeps trying for up to a minute, resuming the same conversation. If every attempt fails, the call stops and the learner sees The voice call stopped: “The connection to the call kept dropping, so the call had to stop. Check your internet connection, then try again.” Try again starts the call afresh. What breaks the connection:

Backgrounding the tab or locking the phone. Mobile browsers suspend a background tab, which drops the connection. Tell learners to stay on the page for the whole conversation. On an iPhone, see After switching apps on an iPhone below.
An unstable connection. Voice is far more sensitive to this than text. Prefer Wi-Fi over a weak mobile signal.
A VPN or corporate firewall blocking WebSocket traffic. If voice fails for everyone on one network but works from home, this is the cause — it is a network question for IT, not a Cesura setting.

The microphone disconnected

If the learner’s microphone goes away during the call — a Bluetooth headset that powers off, or a phone used as a wireless microphone that moves out of range — the call switches to the device’s default microphone and carries on. If no other microphone is available, the call stops with The voice call stopped: “Your microphone disconnected during the call, and no other microphone was available. Connect a microphone, then try again.” Connect a microphone and press Try again.

Connecting or disconnecting a headset during the call does not leave the character silent: the character’s voice carries on through whichever speaker or headset is now in use.

After switching apps on an iPhone

On an iPhone, switching to another app can mute the page’s microphone and stop its sound. Cesura tries to bring both back when the learner returns to the page. If it cannot, a banner asks for a tap:

“We can’t hear your microphone. Tap the screen to reconnect it.”
“The sound is off. Tap the screen to turn it back on.”

The learner taps anywhere on the screen and carries on. The call is not lost.

The call moved to another tab

A run has one call at a time. If the learner opens the same run in a second tab or window, the call moves there, and the first one shows The voice call stopped: “This conversation was opened in another tab or window, so it stopped here. Continue there, or choose Try again to bring it back to this page.”

The call paused itself

When nobody speaks for a while, in any audio experience, the learner first sees “Still there? Audio pauses in…” with a countdown, and then the call pauses: “Paused — no one was speaking. Resume when you’re ready.” Nothing is wrong. The learner presses Resume to carry on. The clock stops during the pause, so the time away does not count against their limit.

7. The character goes quiet for a moment

Sometimes the AI model behind the character does not answer a turn. The status line then says “The character isn’t responding”, and Cesura recovers on its own: it asks the character again, and if the silence continues it opens a fresh connection that picks up from the conversation so far. The learner does not need to repeat themselves or reload. A pause of several seconds before the character carries on is this recovery working, not a fault.

Two things that are not problems:

Long answers. A learner can speak at length, for example a 20-second self-introduction, without being cut off mid-sentence.
Pausing. Pause does not count as the character going silent.

8. A video avatar shows a still picture instead of a face

In a simulation that a Cesura administrator has set to a lifelike video avatar, the learner sees “Connecting to the video avatar…” while the face connects. If the face cannot connect, or drops during the run, the call carries on with the character’s picture and voice, and nothing is lost. See Video avatar mode.

9. The run ended and the learner did not expect it

These are not failures, but they get reported as ones:

“Time is up” — “Voice simulations are limited to 20 minutes, so this conversation has ended.” The cap is fixed and cannot be raised. The learner is warned two minutes out; the run goes on to the feedback report.
The activity’s own limits. A shorter Max Duration or a Max Messages allowance ends the run at that point, and offers no Keep Talking.
The character ended the conversation. Here the learner does get Keep Talking. If it happens too early, the persona or scenario is wrapping up too readily — that is an authoring fix, not a technical one.

Remind learners that Pause stops the clock as well as the microphone, so stepping away does not burn their time limit.

10. Problems on the authoring side

The Delivery Mode tab is there but everything is greyed out. “Voice simulations are switched off for this organization. An organization admin can turn them back on in the organization’s preferences.” — voice is on by default, but an organization admin switched it off for your organization. Ask them to switch Voice simulations back on in the organization’s Preferences.
“Failed to load available voices. Please try again.” — the voice list could not be fetched. Reload the editor; if it persists, it is a service issue worth reporting.
“Could not play this voice. Try again.” — the preview alone failed. It says nothing about whether the simulation will run; try another voice, or reload.
The play button is unavailable, with “Voice previews are unavailable: your organization uses its own AI provider key (BYOK), and previews run on Cesura’s account.” — this is expected for an organization on its own AI provider. The simulation itself still speaks in the voice you choose.
The voice list is shorter than you expected. It is filtered by the persona’s gender. Set the persona to neutral to see every voice.
“The selected voice, …, is a female voice, but the character is male.” (or the reverse) — the voice does not match the character’s gender. Click Use followed by the suggested voice to switch, or keep the voice if the mismatch is deliberate.
The mode list shows Immersive Avatar and you cannot get it back. Avatar mode is retired. A template already on it keeps it, but leaving it is one-way — the page warns you before you switch.
A learner cannot start the activity at all, with a billing message rather than an audio one. That is a credit or limit problem, not a voice problem: see Why can’t a learner start a simulation? Remember a voice run is charged as two runs and counts double against fair use.

11. The chat microphone is a different thing

The small microphone button in a text simulation is browser dictation — it types what the learner says into the message box. It is unrelated to voice simulations and fails differently:

“Microphone access was denied. Please enable it in your browser settings and refresh the page.”
“Voice input is not available in this browser. On iPhone or iPad, open this page in Safari and make sure Dictation is enabled in Settings — or type your message instead.”
“Dictation stopped because the speech service did not respond. Try again, or type your message instead.”
“Dictation stopped because of an error in the browser’s speech service. Try again, or type your message instead.”
“Dictation stopped because it heard no speech. Check that the right microphone is selected and not muted, then try again.”
“This browser cannot recognise speech in this simulation’s language, so dictation is off. Type your message instead.”

When dictation fails it stops and shows one of these messages, so the learner never keeps talking into a recording that produces no text.

If the button is missing altogether, the simulation has no language set that dictation can use — Cesura would rather not offer it than transcribe in a guessed language. The button also disappears after the browser reports that it cannot offer dictation at all, or not in this simulation’s language.

Before you run a voice activity with a group

Test it once yourself, on the device type your learners will use, from a testing space (free for organizations).
If you are embedding it, test the embedded page — not just the direct link.
Put “use headphones, stay on the page, allow the microphone when asked” in the briefing.
Check the activity’s time and message limits against a 20-minute ceiling.