DSD Playback
This guide is for users who want to play DSD in ECHO Next. DSD playback depends on the DAC, driver, output mode, and volume chain. Confirm regular PCM playback first, then enable DSD options.

Short version
Section titled “Short version”- Confirm that your DAC really supports DSD at the target rate.
- Verify normal FLAC / WAV playback first.
- In
Settings->General->Advanced audio engine, enable the DSD-related options. - Try
DSD DoP direct output experimentfirst. - Only try
ASIO native DSD experimentwith the DAC manufacturer’s official ASIO driver. - Keep digital volume at
100%for DSD playback and control loudness from your DAC, preamp, headphone amp, or amplifier. - Do not chase DSD blindly. Many DSD files in circulation are unofficial upsampled or transcoded versions, not native DSD recordings or trustworthy DSD masters.
Options to enable
Section titled “Options to enable”| Option | Recommendation | Meaning |
|---|---|---|
Persistent native decoding | Enable | Keeps native decoding available for DSD playback and falls back when needed. |
DSD DoP direct output experiment | Try first | Wraps DSD data in PCM frames so a DoP-capable DAC can recover DSD. |
ASIO native DSD experiment | Use carefully | Only for official DAC ASIO drivers and DACs that explicitly support Native DSD. |
Lock volume while playing DSD | Strongly recommended | Locks ECHO volume to 100% while DSD plays, then restores the previous volume for PCM. |
Do not chase DSD blindly
Section titled “Do not chase DSD blindly”DSD is a digital audio format, not an automatic quality guarantee. Many unofficial DSD files are converted from CD rips, PCM masters, or already-processed digital files. Converting a weak source to DSD does not create missing detail or turn it into a better master.
Prioritize the recording, mastering source, release credibility, and actual listening result. A trustworthy PCM master can be more valuable than an unknown DSF / DFF file that merely makes a DAC display DSD.
Upsampling to DSD1024 or higher
Section titled “Upsampling to DSD1024 or higher”If you want to upsample PCM to DSD1024 or even higher in real time, use software designed for high-quality upsampling and modulation, such as HQPlayer.
This is a different job from regular playback. DSD1024-class upsampling involves filters, noise shaping, modulators, CPU / GPU load, buffering, DAC capability, and driver stability. It is not just a matter of choosing DSD1024 in an output menu.
A better chain is:
ECHO manages the library and starts playback -> HQPlayer handles upsampling / modulation / output -> DAC decodesECHO focuses on library management, playback control, stable output, and safe fallback. HQPlayer is the specialized tool for advanced upsampling, DSD modulation, NAA, and high-end DAC output chains.
Why third-party ASIO drivers contradict DSD playback
Section titled “Why third-party ASIO drivers contradict DSD playback”DSD direct playback aims to send DSD data to the DAC with as few transformations as possible. It should avoid system mixing, resampling, digital volume, DSP, and unnecessary driver layers.
DSD and PCM are transported differently. PCM is a stream of multi-bit samples, and Windows mixers, volume controls, sample-rate converters, and generic drivers are mostly built around PCM. DSD is a very high-rate 1-bit stream that relies on noise shaping and downstream filtering. Ordinary digital volume, EQ, ReplayGain, or DSP usually requires converting DSD to PCM or remodulating it afterward.
Real DSD direct output needs the player, output API, driver, USB interface, and DAC to agree that the stream is DSD. For Native DSD, the driver may need to pass device-specific markers, rate information, channel layout, buffering behavior, and private control commands.
Third-party ASIO layers such as ASIO wrappers, virtual devices, or generic bridges usually do something else: they wrap WDM, WASAPI, or virtual PCM devices behind an ASIO-looking interface. They may help software that only exposes ASIO, but they do not magically provide the DAC manufacturer’s Native DSD protocol.
So the goal and the method conflict:
- You want fewer middle layers, but the wrapper adds another layer.
- You want device-level Native DSD, but the wrapper often only sees a generic PCM device.
- You want a bit-perfect or near bit-perfect DSD path, but the wrapper may resample, convert to PCM, or route through the system mixer.
- You want the DAC to detect DSD, but the driver layer may not pass DSD markers correctly.
In short:
Intended Native DSD path:Player -> official DAC ASIO driver -> DAC DSD receive path
Common third-party ASIO wrapper path:Player -> ASIO wrapper -> Windows generic audio path / virtual device -> DACThe first path depends on device knowledge from the DAC vendor. The second path mostly gives software an ASIO-shaped output. Those are not the same problem, which is why using the second path to pursue the first result is contradictory.
Use the DAC manufacturer’s official USB audio driver and official ASIO driver when Native DSD matters. If you do not have one, use stable WASAPI / PCM playback instead of installing unknown ASIO drivers.
foobar2000 can use third-party ASIO, so why not ECHO
Section titled “foobar2000 can use third-party ASIO, so why not ECHO”Some users may point out that foobar2000 can use output components, plugins, or third-party ASIO wrappers. That is true, but it is not the same as ECHO making those paths an official support target.
foobar2000 is highly open and plugin-oriented. That freedom is useful for advanced users, but it also creates many unstable combinations: different ASIO components, wrapper drivers, Windows audio paths, DAC drivers, buffer settings, and device quirks. If one setup produces sound, it does not prove the path is correct DSD direct output, nor does it mean the same setup will be stable elsewhere.
ECHO prioritizes predictable playback, volume safety, fallback behavior, and understandable troubleshooting for regular users. Third-party ASIO wrappers are not a good support target because their behavior is hard to verify, their backend may still be WASAPI / WDM / a virtual device, and DSD markers or Native DSD controls may be lost or rewritten. If ECHO adds special handling for those wrappers, users may reasonably interpret that as an official recommendation or stability promise.
So ECHO does not aim to adapt every third-party ASIO wrapper. This is not because experimentation is impossible; it is because the path is not worth encouraging as a stable DSD solution. For DSD, use DoP first, and only use Native DSD with the DAC manufacturer’s official ASIO driver and clearly supported hardware.
Volume safety
Section titled “Volume safety”For DSD playback, keep ECHO, system, and software digital volume at 100%. Control the real listening level from the DAC, preamp, headphone amp, or amplifier.
Digital volume on DSD usually requires converting DSD to PCM or applying special processing and remodulation. That breaks the idea of DSD direct output. 100% digital volume does not mean you should listen loudly. It means the software should not rewrite the DSD stream. Start with the preamp or amp turned down, then raise it slowly after playback starts.
Recommended first test
Section titled “Recommended first test”- Connect the DAC and install the official driver.
- Play a normal FLAC file first.
- Enable
Persistent native decoding. - Enable
Lock volume while playing DSD. - Enable
DSD DoP direct output experiment. - Leave
ASIO native DSD experimentoff at first. - Turn down the DAC, preamp, or amp volume.
- Play a DSF / DFF file.
- Check whether the DAC display indicates DSD.
- If you hear noise, silence, stutter, or the DAC does not detect DSD, stop and return to PCM playback for troubleshooting.
If DoP works reliably and the DAC displays DSD correctly, you do not need to chase Native DSD. Stability and safe volume control matter more than enabling every experimental switch.