A popping sound occurs with Weiss DAC204 when using Audirvana to play DSD tracks using DoP 1.0, as someone in this community already described in this thread:
I have tried the following Audirvana versions:
Origin latest version 2.5.20.0, on Windows 11 24H2, with both official USB driver from Weiss website, and the builtin USB Audio 2.0 driver shipped with Windows 11, using WASAPI mode and kernel streaming mode.
Legacy version 3.5, on macOS Sequoia.
Unfortunately, all versions above have the same popping sound behavior when playing DSD tracks, no matter how I configure Audirvana. Haven’t had the time to try Origin version on macOS though.
I am really bothered by this problem, which makes the “builtin DSD to PCM conversion” feature of Weiss DAC204 essentially unusable.
As I understand Weiss DAC204 is officially supported device by Audirvana, this really should not happen.
I mean the builtin feature of Weiss DAC204, which accepts DSD64/DSD128 format on USB interface, then converts to PCM internally before passing it to the DAC section of the device.
You could get more details of this feature on Weiss DAC204 product page:
In this case, Audirvana is configured to send DSD format to Weiss DAC204 with DoP 1.0, the DSD to PCM conversion is performed by the DAC, not by Audirvana.
Well, DAC204 has no option to disable DSD to PCM feature.
The most I could do is to configure Audirvana to convert DSD format to PCM itself, so that Audirvana sends the converted PCM format to DAC204.
If I do that, then the popping sound never occurs. But this means I’m just not using the DSD to PCM feature of DAC204 anymore. And this feature was one of the reasons why I purchased DAC204 in the first place.
Why do you think the Weiss SRC is doing a better job than can be achieved with r8Brain or SoX SDM in the computer + Audirvāna synergy? Have you done a blind comparison? The computer will have vastly more resources than the Weiss box for SRC.
Well, perhaps because Weiss DAC204 is using industry-leading DSD to PCM conversion algorithm? AFAIK, Weiss developed Saracon, which is Super Audio Center’s recommended DSD converter.
I am fully aware of the Weiss lineage and the industry… This is primarily a production or post production tool… You are running the hardware box, not the software SRC on the computer… There is a vast difference.
Please paste your debug information report here, so folks can see your computer resources and Audirvāna settings you are applying, so to possibly provide more insights… Mask or remove any TCP/IP address information for security…
Note:
Apparently this Weiss box, does not have enough headroom and clips easily on ISP’s (Inter Sample Peaks)… It probably is not handling the increased dynamic range of the DSD files well… The sample-rate conversion in Audirvāna normalizes the file, so this is probably why you don’t get the hard clipping when Audirvāna decimates the DSD files to PCM.
Also this Weiss box uses ESS chipsets that convert all DSD files to PCM internally… So I recommend letting Audirvāna convert the DSD files, as this will off-load processing overhead from the DAC clocking topologies and the ESS chipset resources which will reduce noise (jitter).
As a production and post-production tool, it is rare that this particular box is used for DSD decimation… Even the Weiss performance specifications are measurements from a PCM 192kHz signal. Typically, DSD productions, in post-production will have their outputs attenuated when presented to a SRC for decimation for whatever reason, to accommodate DSP… There is no DSP done on 1-bit files, they are typically decimated to 352.8kHz (DXD) and then modulated again to 1-bit PDM (DSD). Otherwise they are down-converted for other production work done in PCM… It would be rare for a reviewer to include DSD playback in the assessment.
It is because of the Weiss SRC architecture that presents this potential for clipping… The ESS chipset when implemented as recommended, has no problem with the conversion of 1-bit DSD signals to their multi-bit PCM output signal delivered to the D/A circuitry.
The Weiss box is a production tool that facilitates sample-rate conversion in a digital-audio workflow… There are many high-quality audiophile DACs that employ ESS chipsets, that do not implement a SRC function such as this DAC. These DAC designs pass the native DSD and DSD over PCM (DoP) transmission to the internal SDM (Sigma delta Modulator) of the ESS chipset that decimates the 1-bit DSD signal for output.
The advantage of using both the PCM up-sampling module and the DSD conversion to PCM function in Audirvāna, is that it allows for the up-sampling of all PCM files to the logical maximum sample-rate capability of your DAC (176.4kHz, 192kHz respectively) (176.4kHz for decimated DSD to PCM) this would be done by using the ‘Power of Two’ up-sampling strategy and converting 1-bit DSD to PCM.
Otherwise if you have DXD files, you would then need to use a ‘Custom’ up-conversion/downconversion strategy… The ESS chipset up-samples all PCM (and PCM iterations of decimated DSD) signals to a high sample-rate, applies their brand of DSP and subsequently decimates this high sample-rate signal to a lower sample-rate for D/A output.
This is not an Audirvāna operational issue… It is a function of your DAC and settings…
I modulate all PCM files (including DXD 352.8kHz) after HRTF DSP in AU plug-ins module, to 5.6MHZ (DSD128) and playback native binaural DSD128 files, via DoP 1.1 to my DSD-centric TEAC UD-501 DAC… playback is flawless.
You have yet to provide your debug information…
I don’t like to disparage folks choice of DAC, however in this case I feel the need to make a point.
Without pushing the clocking topologies and the DSP by offloading sample-rate conversion to Audirvāna, you are faced with this level of performance… you can only improve the performance by offloading this DSP overhead from the DAC architecture.
IMO the workaround is to let Audirvana handle the downsampling from DSD to PCM. Audirvana on a computer does this objectively better than the ESS chip in the Weiss DAC. This should theoratically result in an even better sound quality.
The question is: is this workaround reasonable for you?
I have written a post in this community (years ago) regarding a popping sound with my Topping D90 DAC when switching from PCM to DSD. This occured only when using an ASIO driver (Windows). WASAPI and kernel streaming worked without problems. The workaround here was to use WASAPI for this particular DAC. After Googling I found out that this had something to do with the hardware implementation of this specific Topping DAC. If it is in the hardware of the DAC there is not much Audirvana can do about it. Your issue with your Weiss DAC could be related or not at all. In any case for you there is a workaround (as described earlier) in Audirvana too, which does not deteriorate the sound quality at all (but probably improves it).
Audirvana Origin 2.5.20 (20520)
Windows 11 (26100) x86_64 with 64GB physical RAM
Connected account of : <redacted>
NETWORK
Status: available
Available network interfaces:
Ethernet (<redacted>) is private
vEthernet (WSL (Hyper-V firewall)) (<redacted>) is PUBLIC
Windows Defender Firewall status for this instance of Audirvana Origin
Active profile types: all
Private profile:
Firewall: enabled
Inbound: allowed
Outbound: allowed
Notifications: enabled
Public profile:
Firewall: enabled
Inbound: blocked
Outbound: allowed
Notifications: enabled
SIGNAL PROCESSING:
Polarity Inversion:
Globally: OFF
Per track: ON
Effects plugins NOT ACTIVE
UPSAMPLING:
r8brain not in use
r8brain filter parameters
Bandwidth = 99.5%
Stop band attenuation 218dB
Phase linear
AUDIO VOLUME:
Max allowed volume: 100
Replay Gain: None
SW volume control: OFF
LIBRARY SETTINGS:
Sync list: 1 folders
AUTO: <redacted>
Sort and display order: en_US
Library database path: <redacted>
Remote Control server:
Listening on <redacted> on port <redacted>
APPEARANCE SETTINGS:
UI theme: dark
Font size: large
Language: System language
Show album covers in tracks list: yes
Source list sorted:
My Music
Library
Startup view: My Music: Albums
Show local extended in source list: yes
Use media keys: yes
Use media keys for volume control: yes
Use legacy Bonjour protocol: no
Number of paired remotes: 0
Remote pairing code required: yes
Screen saver disabled: no
=================== AUDIO DEVICE ========================
Active method: Local
Max. memory for audio buffers: 256MB
Local Audio Engine: WASAPI
Use max I/O buffer size: ON
Preferred device:
Weiss DAC204 (XMOS USB Audio)
Model UID:TUSBAUDIO_ENUM\VID_20B1&PID_300F&KS
UID:\\?\SWD#MMDEVAPI#{0.0.0.00000000}.{0d4ed99d-4777-412f-8fac-7e79abea8c96}#{e6327cad-dcec-4949-ae8a-991e976a79d2}
Active Sample Rate: 96kHz
Bridge settings:
Sample rate limitation: none
Sample rate switching latency: none
Limit bitdepth to 24bit: OFF
Mute during sample rate change: ON
Selected device:Weiss DAC204 (XMOS USB Audio)
Manufacturer: XMOS
Model name: xCORE USB Audio 2.0
Model UID: TUSBAUDIO_ENUM\VID_20B1&PID_300F&KS
UID: \\?\SWD#MMDEVAPI#{0.0.0.00000000}.{43cd91f1-146c-4cbe-8d78-27bfd272ea71}#{e6327cad-dcec-4949-ae8a-991e976a79d2}
USB Vendor ID: 0x20b1
USB Product ID: 0x300f
6 available sample rates up to 192000Hz
44100
48000
88200
96000
176400
192000
Volume Control
Physical: Yes
Virtual: No
Max volume alert: Disabled
MQA capability
Auto-detect MQA devices: No
Not automatically detected, user set to not MQA
DSD capability
DSD via PCM 1.0
Device audio channels
Preferred stereo channels L:0 R:1
Channel bitmap: Ox3, layout:
Channel 0 mapped to 0
Channel 1 mapped to 1
Audio channels in use
Number of channels: 2
Use as stereo device only: No
Simple stereo device: No
1 output streams:
Number of active channels: 2, in 1 stream(s)
Channel #0 :Stream 0 channel 0
Channel #1 :Stream 0 channel 1
2 ch Integer PCM 16bit little endian 44.1kHz
2 ch Integer PCM 24bit little endian 44.1kHz
2 ch Integer PCM 16bit little endian 48kHz
2 ch Integer PCM 24bit little endian 48kHz
2 ch Integer PCM 16bit little endian 88.2kHz
2 ch Integer PCM 24bit little endian 88.2kHz
2 ch Integer PCM 16bit little endian 96kHz
2 ch Integer PCM 24bit little endian 96kHz
2 ch Integer PCM 16bit little endian 176.4kHz
2 ch Integer PCM 24bit little endian 176.4kHz
2 ch Integer PCM 16bit little endian 192kHz
2 ch Integer PCM 24bit little endian 192kHz
Local devices found : 1
Device #0: Weiss DAC204 (XMOS USB Audio)
Manufacturer: XMOS
Model UID: TUSBAUDIO_ENUM\VID_20B1&PID_300F&KS
UID: \\?\SWD#MMDEVAPI#{0.0.0.00000000}.{43cd91f1-146c-4cbe-8d78-27bfd272ea71}#{e6327cad-dcec-4949-ae8a-991e976a79d2}
USB Vendor ID: 0x20b1
USB Product ID: 0x300f
Model name: xCORE USB Audio 2.0
UPnP
UPnP network interface
Available Network interfaces:
Ethernet
vEthernet (WSL (Hyper-V firewall))
UPnP devices found : 0
Chromecast
Chromecast devices found : 0
And maybe you and Agoldnear are right: maybe this workaround even improves the result sound quality.
I guess what bothers me is that this issue effectively makes the DSD capability of Weiss DAC204 useless in my case.
Putting this issue aside, from my own listening experience, the DAC204 is a wonderful DAC, no matter what the measurements say. The sound it makes is musical and full of details, I am really happy for this purchase.
It is not useless… It is a functional DAC with superfluous features in comparison to other very high performance DACs costing far less… The issue I see, is that you have chosen to restrict your PCM file playback experience, to sample-rates up to 192kHz and your DSD file playback experience to 2.8MHz DSD64 and 5.8MHz DSD128 (Where DSD128 gets even more decimation to 176.4kHz, rather than the logical 352.8kHz)… If you are doing DSD post work, why would you choose this SRC anyway? Why would you restrict the output to 176.4kHz and not 352.8kHz?
You will be well served by allocating 8GB of System RAM for playback pre-load memory… no reason to allocate more than this.
I don’t know about WASAPI, but in Windows, you should be able to transmit raw native DSD64 and DSD128 via USB without using DoP… The DAC204 manual does not specifically state anything about DoP transmission in relationship to the SRC function.
I have seen some discussions of this DSD popping sound issue, like this thread:
In this thread there is another opinion:
The problem of muting the initial start is due to certain OS and apps - when the sample rate changes, the data in the buffers get sent out at the wrong rate. When you switch from DSD to PCM you then get a loud bang, or track played at the wrong rate for a period. Now this fault is in the app, its absolutely nothing to do with the DAC.
If your noise is consistently produced while the track is playing, then no…
However if the transient ‘pop or tick’ is related to sample-rate switching between PCM an DSD files at the start or the end of the DSD playback, then this is the issue:
From the iFI-Audio technical article linked below…
“Pop” goes DSD? Why does this happen?
PCM can produce a true zero (silence) output in an instant. When the data stream stops, the DAC is then reset to “zero” for PCM.
As DSD only records the difference in level between each sample and during track changes (or a switch from PCM to DSD), the Player no longer sends DoP markers.
As a result, the DSD’s output levels (via DSD-DoP) of the DAC output can ‘stick’ at any possible level (almost anything but rarely zero) between the two extremes.
When the next song commences, the DAC suddenly receives a new DAC value (usually this new value is zero), which has no relevance to the previous sample- hence the ‘pop’. “Pop” goes DSD? Why does this happen? - iFi audio
If so increase the sample-rate change time and mute during sample-rate changes.
