"Silent audio -- discarding"¶

You hold the key, speak, release — and nothing is typed. The log says:

Silent audio -- discarding

This is the single most common report, and it has two quite different causes. The first thing to establish is which one you have.

What the message means¶

Before transcribing, YazSes checks whether the clip contains speech at all, by comparing the mean absolute sample value against [accessibility] vad_threshold. Below it, the clip is discarded rather than sent to Whisper — because Whisper hallucinates confident sentences out of silence, and a made-up sentence typed into your document is worse than nothing.

So the message means exactly one thing: what was recorded was quieter than the threshold. It does not say whether that is because you were quiet or because nothing was recorded at all.

Step 1 — measure your microphone¶

yazses mic-level

Real output from the machine above, recorded in a quiet room without speaking:

Recording 4s -- speak normally now...
  mean level:            0.0101
  peak level:            0.0866
  current vad_threshold: 0.0005
  recommended:           0.0051

Read it as three facts:

• mean level — what the microphone actually heard.
• current vad_threshold — the line your speech has to clear.
• recommended — half the measured mean, which is what --set would write.

Step 2 — decide which case you are in¶

Step 3 — the gate is too high¶

yazses mic-level --set    # writes the recommendation to config.toml
yazses restart

Or by hand:

[accessibility]
vad_threshold = 0.005

Lower it if quiet speech is being discarded. Raise it if silence produces spurious transcripts — the same number controls both directions, and there is no value that is right for every room.

YazSes also adjusts this on its own when it can prove it should: a run of discards with no successful transcription between them means the gate sits above your voice, so it proposes one that would have passed them (audio/adaptive_vad.py). That is deliberately one-directional — lowering repairs an invisible failure, while raising only trims noise you can already see.

Step 4 — nothing is being recorded¶

A level near zero is not a threshold problem. In order of likelihood:

yazses doctor            # says which device it will use
yazses audio devices     # ● = OS default, ★ = pinned
yazses audio status      # what the running daemon has open

• The microphone is muted. In hardware, or in your mixer. pavucontrol → Recording shows whether YazSes is receiving anything at all while you hold the key.
• The wrong device is selected. A USB-C monitor, a webcam or a headset that appeared later can become the OS default and take capture with it. Pin the one you want so it cannot be stolen:

yazses audio use "Yeti"      # substring of the name from `audio devices`

• The device changed while the daemon was running. YazSes notices a run of silent clips and heals back to the last-good device automatically ([audio] auto_heal_device, on by default), and pops a notification with Re-calibrate / Pin this mic buttons. If you dismissed it, yazses audio status still shows the streak.

What "fixed" looks like¶

yazses status

YazSes is running (PID 4084).
  state:    idle
  hotkey:   right_ctrl
  model:    base.en
  mic:      default
  latency:  base.en p50 740 ms / p95 1210 ms (n=143)

A latency: line at all means clips are reaching the decoder — the discard path never produces one. yazses logs should show Transcribed … lines rather than Silent audio -- discarding.

Where this page stops¶

• Bluetooth headsets are a known rough edge: many negotiate a low-quality mono profile when the microphone is opened, and the level can drop sharply at that moment. Nothing here was tested against one.
• PipeWire vs PulseAudio made no difference in this testing, but only PipeWire (Ubuntu 24.04's default) was actually exercised.