Skip to content

[Feature]: Parallelized per-chunk background transcription to reduce post-stop wait time #168

Description

@hopsayer

App

Android app

Problem

Chunked/streaming transcription during recording + (not sure it's reliable) maybe progressive text reveal

Currently, audio transcription starts only after the user presses Stop, and processes the entire recording as one block. This means:

  • The app is idle (transcription-wise) while recording is in progress.
  • All processing load hits at once right after Stop, causing a single lump of wait time proportional to the full recording length.
  • The user has to sit through this entire wait before getting any text back.

Smallest change

Split the audio into chunks at pause boundaries (silence detection) during recording, and transcribe each chunk in the background as it's captured, in a hidden queue running in parallel with ongoing recording:

  1. While recording, segment audio into chunks at natural pauses (VAD?) (or fixed intervals as a fallback).
  2. Transcribe each chunk in the background as soon as it's ready, storing partial transcription results.
  3. When the user presses Stop, simply concatenate the already-transcribed chunks into the final result — no need to process everything from scratch at that point.

Benefits

  • Load distribution: processing is spread evenly across the whole recording session instead of spiking right after Stop.
  • Reduced wait time after Stop: most (or all) of the recording is already transcribed by the time the user stops — only the last unprocessed chunk (a few seconds at most) needs finishing. This directly reduces how long the user's control/attention is "held hostage" waiting for output.

Other options (optional)

Enables a secondary optional feature: progressive text reveal

Because chunks are transcribed as you go, the app could reveal transcribed text progressively during dictation — similar to Gboard's real-time-ish behavior, except here it would appear in bursts every N seconds (chunk-size dependent) rather than continuously.

Important: this should be toggleable, default depends on user preference — not everyone wants it

For some users (myself included), seeing text appear on screen while dictating is actively distracting and disrupts train of thought — to the point of looking away from the screen entirely while dictating. And if the user taps some buttons or changes windows while recodring, this logic can create text insertion to random places. So:

  • This is not a good idea at all.
  • Progressive reveal should be an opt-in setting, off by default or easily switchable.
  • Users who want the "watch it type" feedback can enable it; users who find it distracting can keep the screen static until Stop is pressed, same as current behavior — just faster to appear once they do stop, thanks to the background chunking.

Before you submit

  • I looked for an existing issue

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions