I’m using a McIntosh DA2 (firmware v5.12, USB descriptor bcdDevice 1.30) via USB, upsampling to DSD512 with HQPlayer.
The problem
When switching between DSD512 tracks of different rate families — e.g., DSD512×48k (768 kHz) to DSD512×44.1k (705.6 kHz) or vice versa — audible ticks occur at the transition. Playback within the same rate family is perfectly clean.
This is a USB protocol level issue, not OS-specific.
What I found
I captured USB traffic with usbmon and traced the issue to the oscillator switching behavior:
When the host sends a UAC2 SET_CUR at a high rate (e.g., 705600 Hz) to cross rate families, the DA2 acknowledges the request and returns the correct value on GET_CUR
But the physical oscillator does not actually switch — the feedback endpoint keeps reporting the previous family’s frequency indefinitely
When a base rate (44100 or 48000 Hz) is sent, the oscillator switches correctly within ~28 ms
The DA2’s XMOS firmware appears to only trigger the oscillator switch on base-rate SET_CUR commands, not on high-rate multiples. This is not a limitation of the XMOS platform itself — the reference firmware handles all rates — but seems specific to the DA2’s custom firmware implementation.
Evidence from USB traces
Test
SET_CUR
Feedback EP result
Same family (768k → 768k)
768000
Correct (48k family)
Cross family (768k → 705600)
705600
Stuck on 48k family (6,082 packets)
Base rate cross (48000 → 44100)
44100
Correct switch in ~28 ms
Possible fix
A workaround at the USB audio driver level would be straightforward: when crossing rate families at rates above 48 kHz, send the target family’s base rate first (to trigger the oscillator switch), then send the actual target rate. This pattern is already used for other DACs in the Linux kernel (e.g., TEAC devices).
Alternatively, a DA2 firmware update that handles oscillator switching on high-rate SET_CUR would resolve this at the source.
Has anyone else experienced ticks or glitches with the DA2 when switching between 44.1k-based and 48k-based DSD content?
@Chris.Ha I don’t have experience with the McIntosh DA2. However, I used to own an SMSL DAC with the XMOS XU-316 chip, and I would hear clicks/pops with rate changes. Sharing a couple links that might provide lateral options for your situation.
Windows users who connect SML DACs via USB, tweaked the XMOS supplied ASIO driver via UI and that apparently prevents the pop/click.
Linux users don’t have XMOS supplied drivers so they wrote their own and add silence between rate changes to prevent the pop/click.
In my case, there were no USB drivers for Mac, and SMSL replied to my emails with bad news that my DAC had come to end of life and no firmware updates would be provided to address the click/pop. I started researching how to extract the firmware, modify it to add silence with rate change (saw a discussion with XMOS engineer on their customer forum), and write it back to the XMOS chip. Didn’t get to that point as I bought another DAC.
Would adding Resynch Delay in Roon help since it should detect the rate change prior to HQPlayer upscaling and add some pre-roll silence/resynch opportunity?
@Dadoo@Jay_Tee
I really appreciate the suggestions and the related XMOS examples.
The XMOS examples were helpful, because they made me look more closely at whether this might be a firmware-side clock switching issue rather than just a generic playback artifact.
And regarding the resync suggestion: in this setup, Roon’s Resync Delay was already set to 500 ms when the problem was happening. So I don’t think increasing the delay further would really solve it. This does not seem to be just a brief transition artifact — the state appears to remain wrong during playback, and the ticking continues periodically instead of settling after a short delay.
After tracing it further, what I’m seeing is actually quite narrow:
transitions within the 44.1k family are fine
transitions within the 48k family are fine
direct 44.1k ↔ 48k base-rate switching is also fine
the problem only appears on direct 44.1k×512 ↔ 48k×512 transitions
In those cases, the DA2 ACKs the high-rate SET_CUR request and returns the requested value on GET_CUR, but the USB feedback value stays on the previous family even after waiting, so the physical oscillator never actually switches. That seems to explain why the ticking keeps going instead of settling after a short delay.
For now, I do have a practical host-side workaround: on a direct 44.1k×512 ↔ 48k×512 transition, I first send the target family’s base rate (44.1k or 48k), wait briefly, and then send the final high rate. That has eliminated the ticks in my testing so far.
So this is only a workaround, not a real fix, and I’d still be very interested in two things:
whether anyone has seen similar behavior on other XMOS-based DACs, and
whether the Windows / vendor-driver path for this device uses a different switching sequence.
I’m on macOS, so I can’t test the Windows side myself. Any comparable reports or traces would be very helpful.
