[Bug] process hangs indefinitely at "computing global sherpa timeline" during Sherpa diarization on Windows CUDA

[usamashafiqs]

Bug Description

When running crispasr with --diarize using --diarize-method sherpa on Windows (CUDA backend), the transcription completes successfully in ~1s, but the process hangs indefinitely during the Sherpa timeline computation phase without completing, throwing an error, or exiting.

The console output stops at:
crispasr[diarize]: computing global sherpa timeline over 987681 samples (61.7 s)...

Explicitly setting -t 2 / --threads 2 does not resolve the freeze.

---

Reproduction Command

crispasr --backend whisper -m models\ggml-large-v3-turbo-q8_0.bin -f audio.wav --diarize --diarize-method sherpa --sherpa-num-clusters 2 -ojf --sherpa-segment-model models\sherpa-segmentation.onnx --sherpa-embedding-model models\3dspeaker_speech_eres2net_base_sv_zh-cn_3dspeaker_16k.onnx

[CrispStrobe]

Two fixes have landed on main since you filed — please retest against current main.

The likely root cause on Windows: the sherpa command line was built with single-quoted arguments (--segmentation.pyannote-model='models\seg.onnx'), which cmd.exe does not interpret — sherpa would have received literal quote characters in the model paths — and it appended 2>/dev/null, which is not valid Windows redirection. The subprocess is now spawned via CreateProcessA with correct MSVC quoting, stderr to NUL, and a timeout (98ba5c2). A second fix (95dc6fb) implemented that same timeout on the POSIX side, where the parameter had been accepted and silently ignored — so the identical hang was reachable on Linux/macOS too.

Two things that will tell us a lot when you retest:

• If it completes — fixed, and the quoting was the cause.
• If you now see sherpa subprocess timed out after N s instead of an indefinite hang, then sherpa-onnx itself is wedging on your setup (CUDA init is the usual suspect) and that is a separate bug from ours — but at least crispasr now exits with a message rather than freezing. CRISPASR_SHERPA_TIMEOUT_SEC=<seconds> raises the limit if your run is legitimately slow; the default is max(120, audio_seconds x 5).

Being straight with you: I have no Windows machine, so I verified the timeout behaviour on macOS with a deliberately hanging stub and cannot confirm the Windows path end to end. Your retest is what would close this.

Worth noting --diarize-method foxnose needs no external binary at all (--diarize-embedder auto fetches a 24 MB GGUF) if you want a path that avoids the sherpa subprocess entirely.