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

Audio Gear Talk RoPieee
21

Hi, yo3fxy,

Thanks, that makes sense now — “Roon-only testing” means HQPlayer NAA should be disabled to avoid any possible exclusive-access conflict with Roon Bridge.

I tested again with HQPlayer NAA disabled in the Services tab, so the endpoint was running with Roon Bridge only, and the behavior is still the same.

After the DA2/C2700 is turned off and then back on, playback fails in the same way.

I also submitted this result as feedback: 3ae6a3df75a69ddc.

22

I still see HAA. Can you please disable it?

It’s only doable for me if all services except Roon are disabled and don’t interfer.

23

@Chris.Ha

I see very short logs. Are you rebooting the unit?

What I need is a log for this:

  1. turn on the RoPieee unit
  2. wait a few minutes, turn on the DAC
  3. send feedback
  4. wait a few minutes, put the DAC in stand-by
  5. wait a few minutes, turn the DAC back-on
  6. wait a minute, send feedback

During this complete cycle the RoPieee unit needs to stay powered on.

Thanks

1 Like
24

hi Harry,

Just to clarify: feedback 3ae6a3df75a69ddc was collected from a full cycle with HQPlayer disabled:

  • Boot RoPieee

  • DAC on

  • playback OK

  • DAC off/on

  • playback fails

  • send feedback

I did not reboot RoPieee in between, so if the log looks short, it was not because of an intermediate reboot.

I’ll rerun it in the more explicit before/after form and send you two feedback IDs:

  1. after DAC on, with playback confirmed working

  2. after DAC off/on, once playback failure is reproduced

It’s around 6 AM here now, so please give me a little time to run it carefully. Thanks again!!

25

Ok.

Can you also give me the exact time at which you turn the DAC off?

Because the weird thing is, that I don’t see that happening: as in, I don’t see the disconnect events.

And in the above cycle: was the DAC already on, or did you powered it on while RoPieee was already running?

1 Like
26

Hi, @spockfish ,

Thanks for waiting. I ran a quick test before work.

Other than Roon Bridge (left at its default On setting), all items under the Services tab were Off.

Test timeline:

  • Yesterday Standby DAC
  • 07:00 RoPieee Shutdown
  • 07:10 RoPieee On
  • 07:18 DAC On
  • 07:20 Play — OK
  • 07:21 Send Feedback (3970bc8ceeb32ab3)
  • 07:24 Standby DAC
  • 07:27 DAC On
  • 07:29 Play — Fail
  • 07:30 Send Feedback (52c1680b66bbd9ad)

Could you please check these two feedback reports?

Thank you again.

1 Like
27

Thanks, this is a nice clean log :wink:

Anyways, I’ve found an issue…. your DAC keeps the USB connection ‘alive’ when going into standby. So when I put my DAC in standby, it disconnects from the USB. So RoPieee knows when a DAC is disconnected. Which means I also can detect when a device is powered back on (and should receive a reset).

This cycle is absent with your device, and that’s the reason why it isn’t working….

I need to think about this, because for now I don’t see a solution.

1 Like
28

Thanks for confirming. That matches what I observed too.

In my testing, the connection still appears alive from both sides, but when actual playback / USB audio communication is attempted, the failure shows up.

The Korean McIntosh distributor told me they have already escalated the question to the US side, but they have not received a reply yet. They also confirmed that the latest DA2 firmware version is V5.12. My DA2 is up-to-date.

After work, I’m going to capture as much low-level logging as I can and investigate this further.

Thanks again.

29

Of course that’s up to you, but I don’t need more info.

It’s time for McIntosh to make their device UAC compliant. Considering the price of their hardware that’s the least they should do :wink:

30

Thanks again for taking the time to investigate this so thoroughly.

I’ve now forwarded the report and logs again to the McIntosh distributor and will wait to hear back from them.

I understand that this appears to be on the McIntosh side, but if you ever find a practical host-side workaround for this kind of standby/resume behavior, it would be very helpful in real-world use.

Also, I sent a small token of appreciation earlier. Thank you again for your time and help.

31

Well, that is/was my intent. What I build now for you to test is rather generic. I even prepared the UI elements to make it configurable.

Problem is that is relies on detecting that the device disconnects as well. And that’s not the case, so I also technically don’t see a solution for this issue (expect scanning for the specific issue in the logs and resetting based on that, but that is something I’m not willing to do).

Thanks

32

For convenience you could maybe a smart power switch on the C2700 in the mean time.

33

Thanks again for taking the time to investigate this so thoroughly.
I’ve now forwarded the report and logs to the McIntosh distributor and will wait to hear back from them.
I understand your point, and I really appreciate the time you spent looking into it.
If anything new comes back from the McIntosh side, I’ll share it.

Thanks for the suggestion.
I’m a bit cautious about hard power-cutting the C2700 directly rather than using standby first, even if it likely has protection built in.
Also, I haven’t actually tested yet whether a full power-off (rather than standby) would avoid the issue.

Hi @DDPS ,
May I ask which DA2 firmware version you are using?

Also, when you tested RoPieee with the DA2 connected, did you happen to try a standby → power on → playback again cycle?
I’m seeing a reproducible issue there on my side and was curious whether you saw the same.

Thanks very much.

34

Version 4.09. I did not try that.

1 Like
35

I have the DA2 in the McIntosh C55. No problems with standby or anything in my system.

Windows 11 i5/Bluesound Node/McIntosh C55 preamp

1 Like
36

@Chris.Ha one more thing…. we can test if the mechanism works by just pulling the USB cable.

So do the same as before, except you, after bringing your C2700 back online, also pull the USB cable and put it back again. That should trigger the reset mechanism.

37

I also did some more research… I only found a post with another device (a Behringer), but that came down to faulty USB cable.

One more question: how is your Pi powered?

38

Hi @spockfish ,

Thank you for continuing to look into this. I also wanted to mention that I still haven’t received any response from McIntosh yet.

I tested the USB pull/replug case on the 3372 test image with the following results:

  • RoPieee ON, playback OK
    Feedback: 2f49edfb8353f55e

  • C2700 standby / ON, playback fails
    Feedback: d3d024c493b23029

  • I then physically unplugged the USB cable, waited about 30 seconds, plugged it back in, waited about 1 minute, and tried playback again
    Result: playback still fails
    Feedback: 5f12b07730af8680

So on my unit, a physical USB disconnect/reconnect after the standby-resume failure did not recover playback.

For power, I’m using an LHY Audio RPI Pro powered directly from a Shunyata Research DENALI 6000/S v2 via a Jorma Design Trinity Plus power cable. For reference only, that same outlet and power cable have worked fine with other equipment in my setup.

Could you please check whether the reset-on-connect path actually triggered in the last feedback log?

Thanks again.

39

And what kinda USB cable?

40

I’m using a 1.5m USB 2.0 Type A-to-B cable from 10Hz Audio, a Korean company. The manufacturer provides impedance and insertion-loss data and specifies 26AWG conductors with dual shielding.

Also, this is a newly purchased USB A-to-B cable. Playback is stable before the standby/on event, and manual USB reset has recovered playback before, so from my side I haven’t seen signs of a persistent cable issue so far.