Why voice-tracked scrolling stops when you record video

Voice-tracked scrolling — the prompter listens to you and moves the script at your actual pace — is the most genuinely useful idea anyone has had in this category. It removes the thing that makes prompter delivery sound like prompter delivery, which is you matching a machine instead of the machine matching you.

It also has a well-known failure mode: it frequently stops following you the moment you start recording video. PromptSmart’s VoiceTrack is the feature people usually mean, and it is the one we looked at closely when deciding what to build. The cause is not a bug in a particular release. It is a resource conflict, and it explains why almost nobody ships both halves working together.

Two things want the microphone

When you record video with voice tracking on, two independent consumers need the same audio input at the same time:

• The video encoder, which needs a continuous audio stream to mux into the file alongside the picture. A gap here is a gap in your recording.
• The speech recogniser, which needs the same stream to work out which word you just said and how far down the script you are.

On both iOS and Android, a microphone input is normally handed to one consumer. Two subsystems that each independently ask the operating system for “the microphone” do not quietly share it. One of them wins. Which one depends on ordering, on the audio session category, and on details that change between OS versions — which is why the symptom is inconsistent enough to read like a flaky bug.

The outcomes are all bad in different ways: voice tracking goes silent and the script stops moving, or the recording ends up with no usable audio, or the session drops and capture stops altogether.

The fix, and why it is rare

There is a correct answer, and it is not a flag you can toggle. The app has to own its audio pipeline: open the microphone once, as a single source it controls, then fan the buffers out to both destinations — a copy to the encoder for the file, and a copy to the recogniser for the scroll position. Neither consumer ever talks to the microphone. Only the app does.

That is real work. It means writing your own capture layer instead of connecting a recording SDK to a speech SDK and hoping, and it means handling route changes, interruptions and sample-rate conversion yourself. It is considerably more expensive than either half alone, which is why the two features exist widely and the combination barely does.

For what it is worth, this is why our capture layer sits behind an interface with exactly one implementation behind it — the seam is there so that owning the audio path later does not require rewriting the app around it. Orate v1 does not ship voice tracking, and we would rather say that plainly than imply otherwise in a post about someone else’s version of it.

Test it yourself in two minutes

Whatever app you are using, this tells you where you stand:

1. Turn voice tracking on and do not record. Read a few lines. Confirm the script follows you — this proves the recogniser works at all.
2. Now start recording video and read the same lines at the same pace.
3. Watch the script rather than yourself. Does it still follow, or has it reverted to a constant crawl, or stopped?
4. Stop, and play the recording back with the volume up. Check the audio is actually there. An app can keep the tracking working and quietly lose your sound, which is the worse outcome of the two because you will not notice until later.

Do this on the phone you shoot on. It is the kind of behaviour that varies by device and OS version, so somebody else’s result is weak evidence about yours.

What to do while recording

If voice tracking is unreliable during capture — and today it usually is — a calibrated fixed speed is better than an intelligent one that drops out. Three things make fixed-speed scrolling much less robotic than its reputation:

• Calibrate to yourself, not to a default. Read 20 seconds of your own script aloud, count the words, multiply by three. That is your rate in words per minute, and it is probably not the number the app shipped with. Ours differ by writing system for the same reason — see teleprompter speed by language.
• Write in short paragraphs with deliberate breaks. A fixed scroll punishes long unbroken blocks, because there is nowhere to catch up. Line breaks give you slack.
• Record in shorter takes. Drift accumulates. Two ninety-second takes are far easier to keep in sync than one three-minute take, and you will cut between them anyway.

If voice tracking is the only thing you want

Then use it the way it works today: as a rehearsal and delivery aid, not during capture. Track your voice with the prompter while you practise, then record with a fixed speed you have calibrated. It is two passes instead of one, and it is more reliable than hoping the microphone conflict resolves in your favour on the take that matters.

And if you are recording something you cannot repeat, the more important question is not how the script scrolls but whether the file survives. That one has its own test.