McIntosh DA2 playback fails after C2700 standby resume on RoPieee 2026.02 (build 3360)

Audio Gear Talk RoPieee
1

Hi @spockfish,

Sorry if this turns out not to be a RoPieee issue, or if this should be reported somewhere else.

I’m not sure whether the root cause is in RoPieee itself, in the McIntosh DA2 / C2700 standby behavior, or in the USB interaction between them, so I wanted to ask for your guidance.

Music plays normally over:

Mac mini (Roon → HQPlayer) → NAA → LHY RPI Pro (RoPieee 2026.02 / build 3360) → USB → McIntosh DA2 in C2700

The issue appears when the C2700 goes into standby and is then turned on again.

After that, when I try to play music again on the same path, Roon shows:

“Roon lost control of the audio device.”

Roon appears to start playback briefly, then stops with no sound.

Repro steps:

  1. Reboot RoPieee on the LHY RPI Pro

  2. Confirm music plays normally on the HQPlayer / RPI Pro / DA2 path

  3. Put the C2700 into standby

  4. Turn the C2700 on again and leave it on the USB input

  5. Try to play music again on the same HQPlayer / RPI Pro / DA2 path

  6. Roon shows “Roon lost control of the audio device,” attempts playback, and then stops

What does not reproduce it:

  • Simple zone switching by itself

What I confirmed at failure:

  • RoPieee still detects the DA2

  • /proc/asound/card1/pcm0p/sub0/hw_params = closed

dmesg shows:

  • uac_clock_source_is_valid(): cannot get clock validity for id 41

  • clock source 41 is not valid, cannot use

  • 1:1: cannot get freq (v2/v3): err -71

  • 1:1: cannot set freq 352800 (v2/v3): err -71

I also checked older Roon community threads. The older Mac mini / C2700 discussion looked more like a DSD/DoP configuration issue, not this standby-resume failure. The closer comparison seems to be later DA2 connection / reconnect issues with Raspberry Pi / USB, but in my case the failure appears specifically after C2700 standby → on resume.

Workaround:
Rebooting RoPieee restores normal music playback, until the next time the C2700 goes to standby and comes back on.

Feedback IDs:

  • Latest: e664b7c2ae3fbfd7

  • Previous: 8e1c5866e5ef11d8

Sorry again if I am bothering you with something that may not actually be a RoPieee bug. If this should be tested or reported differently, please let me know.

Thanks very much,
Chris

2

Small update:

I tested a few more things.

  • Simple zone switching by itself does not reproduce the issue
  • The issue is reproducible after the C2700 / DA2 goes to standby and comes back on
  • Replugging the USB cable on the LHY RPI Pro side does not recover playback
  • Replugging the USB cable on the DA2 side also does not recover playback
  • Rebooting RoPieee does recover playback, until the next C2700 standby → on cycle

So at least in my testing, the failed state appears to clear only after a RoPieee reboot.

3

I think this points to an issue on the DA2 side: the loggings are showing issues on the lowest level (USB driver), and some warnings/errors in the UAC part.

Could it be that there might be a firmware update for your C2700?

And secondly: is it possible to disable C2700 standby and enable ‘USB Auto Suspend’ in RoPieee? This is a long shot (not many devices do properly support USB Auto Suspend), but it’s worth a try.

Thanks

1 Like
4

Hi @spockfish,

Thank you for taking a look at this, and for your suggestions.

A few more details from my side:

  • The DA2 firmware on my unit is v5.12
  • I received that update from Royco on 2025-10-10
  • As far as I know, that was the latest available update at the time
  • I have not been able to confirm whether there is any newer DA2 firmware after that
  • I also could not find any public DA2 firmware download page or published firmware version history

I also tested the combined experiment you suggested:

  • C2700 standby disabled
  • USB Auto Suspend enabled in RoPieee

In this case, USB Auto Suspend itself appeared to work correctly with the DA2:

  • runtime_status became suspended
  • hw_params was closed in the suspended state

After pressing Play again:

  • runtime_status returned to active
  • hw_params opened correctly
  • playback resumed normally
  • I did not see the previous
    uac_clock_source_is_valid / cannot get freq / cannot set freq / err -71
    errors

So I could not reproduce the same failure through RoPieee USB autosuspend/resume.

At least in my testing, the problem seems more specific to the C2700 / DA2 standby → on path, rather than to RoPieee USB autosuspend/resume in general.

If helpful, I can also contact McIntosh / Royco and ask whether there is any newer DA2 firmware, or whether this standby-resume USB behavior is already known on their side.

Thanks again for checking this and for pointing me in a useful direction.

Chris

5

Hi, @spockfish ,

Thank you again for taking the time to look into this.
Sorry for coming back with another update, but I wanted to gather better logs before saying anything more definite.

I collected a fuller set of logs this time, including:

  • ALSA / lsusb / /proc snapshots
  • live kernel log
  • usbmon packet capture

The sequence now looks much clearer.

Sequence

  1. The DA2 and RoPieee communicate normally and playback works.
  2. I stop playback.
  3. I put the C2700 / DA2 into standby.
  4. I turn it back on again.
  5. After that, the DA2 is still visible to Linux as the same USB audio device:
    • still present in lsusb
    • still present in ALSA
    • still present in /proc/asound/cards
  6. When I attempt playback again, playback start fails and Roon reports:
    • “Roon lost control of the audio device.”
  7. Rebooting RoPieee restores normal playback immediately.

So in this reproduction, the DA2 does not disappear from USB.
The issue happens specifically at playback restart after standby resume.

Relevant kernel log excerpt

  • uac_clock_source_is_valid(): cannot get clock validity for id 41
  • clock source 41 is not valid, cannot use
  • 1:3: cannot get freq (v2/v3): err -71
  • 1:3: cannot set freq 705600 (v2/v3): err -71

Packet-level observation from usbmon
At the USB transaction level, the standard EP0 UAC2 control requests fail with -71 when playback is attempted again after standby resume.

Examples:

  • GET clock validity → -71
  • GET current sample rate → -71
  • SET sample rate 705600 → -71

In the normal case, the same control sequence succeeds.

So from these logs, it looks like after the DA2 has effectively rebooted through standby/on, it no longer returns the expected UAC2 control responses during playback restart.
In other words, the higher-level

  • uac_clock_source_is_valid()
  • cannot get freq
  • cannot set freq
    messages appear to be consequences of lower-level EP0 UAC2 control transfer failures.

I have also raised this with McIntosh / the local distributor, because the logs seem to point to the DA2 side first.
So I’m not trying to put this on RoPieee.

That said, I understand that this type of bad post-resume state may not be unique to the DA2, and similar USB audio devices might also end up in this kind of broken state.
So I wanted to ask, very politely, whether there is any chance RoPieee could add some stronger host-side recovery logic for this class of failure, if EP0 UAC2 control negotiation fails after resume.

I’m mainly asking whether a host-side recovery workaround might be possible, even if the primary issue is on the device side.

If useful, I can also share trimmed or full logs.

Thanks again for your help.

6

I’m pretty sure this is a device issue.

Well, in my experience this is the maybe the second time running into this issue. Can’t remember what the first time was… But I do remember that is was resolved by the hardware vendor with a firmware update.

I’m pretty sure that on a driver level (the kernel) this is not an option as the kernel community would point to the hardware.

The only thing that I can imagine what might work is an USB BUS reset, which might trigger some logic to recover.

It, however, feels a little bit… weird: me spending my (very sparse) free time to fix an issue coming from an high end hardware vendor.

1 Like
7

This is a simple test you can run:

usb_modeswitch -v 2afd -p 000b --reset-usb

Let me know if this helps.

Thanks

1 Like
8

Hi @spockfish ,

That makes complete sense, and I understand your point.
I agree it’s frustrating when this appears to be caused primarily by the device side, especially when it’s a commercial product from a large vendor.
So first of all, sorry for taking more of your time on this, and thank you again for looking into it.

I tested the command you suggested:

usb_modeswitch -v 2afd -p 000b --reset-usb

and it worked.

What happened was:

  • I reproduced the failure after C2700 / DA2 standby → on
  • playback failed again with the same UAC2 control errors
  • I then ran the USB reset command instead of rebooting RoPieee
  • the kernel logged:
    • reset high-speed USB device number 2 using xhci-hcd
  • and playback recovered successfully afterward, without a full RoPieee reboot

So this seems to confirm two things:

  1. the primary issue still appears to be on the DA2 side after standby/resume
  2. a device-level USB reset is enough to recover, so a full host reboot is not actually required

I’ve already raised the DA2 side with McIntosh / the local distributor as well.

Since your reset suggestion did recover playback, I just wanted to ask, very gently, whether you think it might be worth considering some kind of reset-based recovery logic for this specific class of failure in the future.
I completely understand if that is not something you want to take on, but I thought it was worth asking now that we know a USB reset does recover the device.

Thanks again — your suggestion was very helpful.

9

Can you provide me feedback of the whole cycle?

So, start with powered off RoPieee and DAC:

  1. power on RoPieee
  2. power on DAC
  3. play audio
  4. put DAC in standby
  5. resume DAC
  6. play audio (try to)
  7. send me feedback

And without rebooting in between steps.

Thanks

10

Thank you again for your help and for taking the time to guide me through this — I really appreciate it.

I re-ran the full cycle exactly as you described, without any reboot in between, and sent the feedback afterward.

When you have a moment, could you please check feedback report 0e8581aa3af96959?

Thanks again.

11

Quick update: I’m working on proof of concept for this functionality.

When it works, I’ll send you an image to test it out.

I’ll keep you posted.

Thanks

1 Like