Silero cannot back-date the first segment of a cold detector, so it
reports a start index several frames after speech actually began. Every
recording therefore lost its opening audio: measured across 50
utterances the median loss was 102 ms and the worst 230 ms — a full
syllable, which surfaced as dropped leading words ("麻烦把发票…" →
"把发票…", "用 Python…" → "写一个 Python…").
Only the first segment is affected; later segments aligned within 3 ms
because the detector retains history by then. Tuning cannot fix it:
lowering minSpeechSeconds from 0.25 s to 0.05 s left the median loss at
110 ms, and lowering the threshold to 0.2 still lost up to 174 ms while
risking false triggers.
Restore the dropped onset from the recording itself, bounded by the new
vadOnsetPaddingSeconds (default 0.3 s, zero disables). Measured on the
same corpus with identical DSH settings, this recovers the full no-VAD
accuracy and in the technical domain exceeds it, since segmentation also
trims silence:
语料 条件 无VAD VAD丢起音 VAD+回填 改善
audio clean 12.50% 16.33% 12.50% 23.5%
audio noisy10 17.74% 19.15% 17.94% 6.3%
audio_tech clean 10.34% 15.65% 9.81% 37.3%
audio_tech noisy10 25.73% 30.50% 26.26% 13.9%
Inference cost is unchanged (2.6 s vs 2.6 s on both clean corpora).
Use the package's own `SubprocessTerminalActivity['state']` instead of a derived
alias, label the samples as `state:revision` so a reader cannot mistake the
suffix for a count, name the summariser's bound as a group count, and state only
the two observables the prompt count supports.
Refs #5755
An activity poll that times out reports only "unknown" or "Matcher did not
succeed in time". The Linux standby has failed that way twice, at different
polls, and the log shows nothing about what `inspect()` read, which returns
`unknown` for several distinct conditions.
Every activity poll now records the state and revision it samples and counts the
prompts printed while it waits, so a timeout names both. Repeated samples
collapse and the printed list is bounded. Timeouts, intervals and expectations
are unchanged, and where the poll budget equals the test budget the test timer
can still preempt this message.
Refs #5755
An unexpected fork exit can close the worker's channel under a send, which
Vitest reports as a runner-level worker error instead of the clean exit. It
then tears the worker down before the ChildProcess exit event, and
DiagnosticForkWorker treated that teardown as an orderly shutdown: it cleared
the observer and marked the exit expected, so the coverage log lost the pid,
file, code and signal it exists to report.
A worker error observed before a stop now keeps the observer, and a stop
requested after that error no longer marks the exit as expected.
Vitest reports one such exit either as the clean exit path or as a
runner-level worker error, so the spec accepts both forms and compares the
record against whichever appeared.
Refs #5813
imccyu