Help / Troubleshooting
The badge and the signal path disagree
You have Bit-Perfect mode on and WASAPI Exclusive selected. Open Signal Path and every processing stage reads Bypassed. Yet the Bit-perfect row on the Devices page reads NO. Nothing is broken. The two readings answer different questions.
The short answer
- The chain rows in Signal Path describe what you configured: which stages are set to act on the sound, and which the mode has switched aside.
- The Bit-perfect row on Devices describes the stream that played. The app works it out per stream, after negotiating a format with your device, and reports what happened rather than what was asked.
A spotless chain can still feed a stream that falls short, so the two can differ without either being wrong.
Where each reading lives
| Where you see it | What it tells you |
|---|---|
| Devices, the Bit-perfect row | YES, NO, or a dash until a stream has been measured |
| Signal Path, the status line below its rows | Bit-perfect when the stream qualified. Otherwise Processed, or DSP bypassed ยท output not verified |
| Its Configured and Output rows | The mode you chose, and the one this stream ran in |
Two more places carry the same verdict. The pill beside the volume slider reads At unity, and the panel headers in the DSP Rack read Bypassed. Each gains a Bit-Perfect suffix only when the stream earned it. A missing suffix means the stream did not, whatever your settings say.
What the verdict requires
It only comes out positive on the exclusive path, and all of this must hold for the stream that ran:
- It went out through WASAPI Exclusive, not the Windows mixer.
- Nothing in the chain touched the samples: no graphic EQ, no parametric EQ, no crossfeed, no ReplayGain adjustment, volume at unity.
- The device took the file at the file's own sample rate, with no conversion.
- The file's channels reached the device without a fold-down.
- The negotiated device format held the file's full bit depth, with no dither and no truncation.
Bit-Perfect mode covers point 2, and only point 2, on every output path, including paths that can never satisfy the other four. That is deliberate: it behaves the same way whatever is playing, rather than flipping your EQ and volume back on for one track and off for the next. See Bit-Perfect mode.
Common reasons a stream falls short
- It ran in Shared. Windows sits in that path, with its own volume node, enhancements and rate conversion, so the app claims nothing there.
- The rate did not match. The device negotiated 48 kHz, the file is 44.1 kHz, and the audio was resampled.
- The source is lossy. MP3, AAC and Vorbis carry no integer sample depth, so there is no original depth to preserve.
- The track went through the bundled surround decoder. That path resamples and reports no source depth. See Checking the bundled surround decoder (DTS, AC-3 & TrueHD).
- The device format is shallower than the file. A 24-bit file into a 16-bit sink loses bits, which some budget USB devices force.
- The source is multichannel. A 5.1 file folded down to stereo is a real change.
- Something in the chain was live. With the mode off, any EQ band, parametric band, crossfeed, volume below full or applied ReplayGain figure counts. See ReplayGain: what it does and how to use it.
When Configured and Output disagree
If Configured says WASAPI Exclusive and Output names Shared, the panel adds a line saying so. Either the device turned down every format offered, or it was demoted after misreporting its playback clock. For the second, in Settings, under Playback, find Device compatibility overrides and press Reset overrides, which takes effect from the next playback start. Exclusive output won't start (it falls back to Shared) and Exclusive output connects but sounds silent, garbled or lopsided cover both.
Rule this out first: exclusive output is a Lifetime feature, and the 30-day trial includes it. On Free or Pro the engine ignores both the output-mode setting and the Bit-Perfect preference, the Bit-Perfect switch shows off, and playback carries on in Shared. Your stored settings survive, and the verdict reads NO for reasons unconnected to your device.
Two states that are not failures
The first is a stream nobody has measured yet. Bit-perfect shows a dash, Output reads Not played yet, and, with exclusive configured, Configured is marked "from next playback". There is nothing to judge, so the app declines to answer.
The second is a change made mid-track. A running exclusive stream captures the mode as it starts, so toggling Bit-Perfect during a track takes effect from the next track or the next seek. The chain rows and bypass tags flip straight away, because they report the mode, not the stream, so they run ahead of the verdict. Skip forward and the two line up. Configured plays no part here: that row follows the output mode you chose in Settings.
Still not adding up
If the chain reads bypassed, Output names exclusive at the file's own rate, and the verdict still says NO, that is worth a look. Use Report a Bug in Settings, giving the file's format and rate, the device, and what both rows said. Is this a bug? How to report it explains what the report carries.