Skip to content

First transcription of a session spins for minutes with no explanation #334

Description

@EtienneLescot

What happens

On the first transcription after launching the app, the spinner runs for several minutes with no indication that anything is happening. The audio length is irrelevant: two sentences take as long as a long recording. Every subsequent transcription in that session is fast.

Measured on Windows 11, Ryzen 5 7520U / Radeon integrated, from a build of main:

whisper-stt-server CPU, first transcription ~396 s
same server, once warm 6.5 s total
cores busy during the wait 0.5 of 8
resident memory ~1 GB

The server is not hung — GET / answers 200 ok instantly throughout. It is doing one-time work: loading ggml-small-q8_0.bin (252 MB) and bringing up the Vulkan backend (ggml-vulkan.dll + vulkan-1.dll) on the integrated GPU. Nothing is downloaded — the models were already on disk, and nothing is written during the wait.

Part of the cost is specific to a cold AMD Vulkan pipeline cache, which is keyed per executable path, so it lands hardest on a freshly installed app. That is precisely a new user's first impression.

Why this needs one global message, not a fix per spinner

Transcription is surfaced as "loading" in at least three places, each with its own spinner and its own label:

They all read the same boolean. Adding "warming up the model, this takes a minute the first time" to one of them fixes one screen and leaves the others silently wrong, and it would drift the moment a fourth surface appears.

So the state itself should carry the phase, not just pending. Something the engine already knows — initialising vs actually transcribing — surfaced once and consumed by every spinner, so a new surface gets the right message by construction.

Not a fix for this

Making the model faster, or switching backend. The wait is a fixed startup cost, and on this hardware it is not obviously wrong — it is only invisible. Telling the user what is happening is the whole fix; if it also became faster, that would be a separate piece of work.

Notes

  • Not a regression: the shipped STT binaries are byte-for-byte the same size across releases, with only build metadata differing, and the backend selection is identical.
  • Found while testing v1.9.4-rc.1, but present on the installed release too — it is only masked there by a warm cache.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions