hi, @spockfish ,
Thank you for the new beta.
I installed 3393 and did some initial testing. Right after the update, playback still worked even after about 3 to 4 standby/on cycles, so I thought the newer Raspberry Pi kernel might have improved stability.
But after additional testing, I’m now seeing the same issue again. So at least from my side, 3393 does not appear to have resolved the problem.
I haven’t sent feedback yet for the 3393 testing, since this was only a quick manual check so far.
In general I agree with you, but in this case I also believe in ‘ruling out possible issues’. In other words: would be great to test the issue with the cheapest USB cable you’ve got lying around.
On more question:
Is it possible for you to ‘rely’ on auto-suspend?
In other words: you rely on auto-suspend and do not put your C2700 in to standby manually? Or is this just not an option from user perspective.
(and yes, I’m ware that with this scenario still the problem exists when resuming from standby)
And another one:
Can you test this image?
https://image.ropieee.io/ropieee_pi4-2026.3.0-test.20260323.3402.bin
This is a longshot, but there’s a setting in the USB driver related to UAC handling, and that’s where the DA2 does not play ‘nice’. The documentation is not very clear about it, but its worth a try.
I am with @spockfish here. This sounds like an over-engineered cable ( Products – 10HZ AUDIO ) as it claims to use AWG 26/19, but that is thicker and has different impedance characteristics than what is required per the official USB standard. Thicker is not always better. See page 24 of https://www.usb.org/sites/default/files/CabConn20.pdf, which specifies:
4.10.1.1.2 Cable Assemblies The cable construction for standard detachable USB cable assemblies is to be visually verified. Cable construction must contain a braided outer shield and a metallic inner shield. A drain wire of 28 AWG must be in contact with both shields. Cables must contain two data-lines of 28 AWG, and a power pair of 28 AWG to 20 AWG. Power pairs smaller than 28 AWG are prohibited. The laboratory conducting the compliance testing is required to visually verify the construction of the cable.
So, it’s OK for the power pairs to be thicker, but not for the drain wire or data wires. If they made the drain wire and/or data wires 26 AWG, it would technically not be within official spec, and certain equipment that is tested to USB standards might not work properly. That’s why the cheap cable is worth testing.
Thank you both very much for continuing to look into this — I really appreciate it.
@DDPS , thanks for the cable suggestion. I’m trying to get hold of a cheap/generic USB cable as you recommended, so I can rule that variable out properly.
@spockfish , I tried the new 3402 image first, but in my case I could not get it into a usable state. The Web UI did not respond, the previous IP did not answer ping, and the device did not appear in the router’s DHCP client list either. I then reinstalled 3393, and it came back up normally again. So from my side, 3402 seems to have a separate boot/network usability problem, which prevented me from testing the DA2 issue on that build.
I’ll also test with a cheap/generic USB cable once I have one, so I can rule out the cable variable more cleanly.
As for the auto-suspend question, I believe I also saw the issue in that kind of scenario before. But because it requires a fairly long wait, I had been using the DA2 standby/on button for testing simply because it is much faster and easier for reproduction.
I’ll include that auto-suspend scenario in the next round of testing as well, and I’ll report back.
Well, this is not about deducting if auto-suspend causes the issue or not: it’s not.
It’s searching for a way, other then standby / resume triggered by the device itself, if we can detect that the device is going into standby. If that’s the case we can also trigger a bus reset. Hence the question.
Thanks again, and understood — I had misunderstood your earlier question.
So the point is not whether auto-suspend itself causes the issue, but whether there is any host-visible way to detect that the DA2 is entering standby, so that a bus reset could be triggered at that point.
For reference, I have now also tried a cheap/generic spare USB cable, and the behavior is the same there as well. The same issue also appears in the auto-suspend scenario from my side. I had been using the DA2 standby/on button simply because it is the fastest and easiest way to reproduce the failure.
I still haven’t received any response from McIntosh yet.
Also, 3402 was not usable in my setup, so for now I’ll continue testing on 3393.
Can you try this image @Chris.Ha ?
https://image.ropieee.io/ropieee_pi4-2026.3.0-test.20260326.3416.bin
Thanks again for making another test build for this.
I tested 3416 and I’m unfortunately still seeing the same issue.
Test sequence:
DA2 ON
RoPieee (3416) reboot
Playback success
Feedback sent: 8914413663edcd5b
DA2 standby
DA2 ON
Played the same track again at around 22:24 (UTC+9)
Playback failed
Feedback sent: 4e6f64133bd9ccd8
So from my side, the standby/on playback failure is still reproducible on 3416.
Also, I still haven’t received any response from McIntosh. Around Wednesday I was told that the Korean distributor would follow up again if there was still no reply by Friday, but Friday has now passed and there is still no response.
Thanks again — I wanted to add one more observation.
On the Mac mini direct USB path, the DA2 appears to disconnect cleanly when it enters standby. I tested standby 5 times, and all 5 times I immediately saw “USB Device Missing” in the logs. When the DA2 is turned on again, it reconnects immediately and playback works normally. In practice, I had used the Mac mini direct USB path for a long time without this standby/on problem.
That seems different from the LHY Audio RPI Pro USB host path. In the earlier testing with reset-on-disconnect logic, there did not seem to be a detectable disconnect event there. So from my side, the DA2 standby transition looks clearly visible on the Mac direct USB path, but not in the same way on the LHY Audio RPI Pro path.
I’m not sure yet whether this points to a path-specific interoperability difference or something specific to the LHY Audio RPI Pro USB host path, but it seems like an important difference.
Well, depends on what you see as important 
What you witness is the different USB handling of 2 (totally) different operating systems, which brings all kinds of nuances.
Oh!
Uhhh…. you’re not using a regular Pi?
Yes — I’m using an LHY Audio RPI Pro, not a regular stock Raspberry Pi.
Looking at the RPI Pro manual, its USB audio output path is not just a standard Pi USB port. It is CM4-based, but goes through LHY’s own isolated USB output stage. So this may be something specific to the RPI Pro USB output path rather than to RoPieee itself.
I missed this (duh), but I would definitely search in that direction. They are talking about an ‘isolated USB port’, so I suspect it’s not standard.
McIntosh still hasn’t responded yet. LHY has acknowledged the report and said their engineering team will try to reproduce the setup, but there is no technical conclusion from them yet.
Before I try anything on my side, if you would be comfortable with it, would it be alright if I did some separate private testing with a bit of extra logging, using the GitHub source and your test build as the baseline?
After reading through some related Linux/xHCI discussions, I started wondering whether a few extra logging points might help narrow things down further, and I’d like to explore that on my side.
I also feel a bit bad asking you to make a new test build for every small idea I want to check.
I would of course keep that completely separate from the official test results I report back here. Thank you.
which source?
Yeah, that’s gonna be difficult.
If you want to test things further I would take a ‘quicker route’: take a standard Pi and verify how the DA2 behaves over there. Or, even take a regular PC with a regular Linux installed.
That way you can identify pretty quickly whether you should focus on the guys from LHY, or McIntosh.
You might want to specifically ask for Chuck Hinton.
What I had originally in mind was the public RoPieee/linux kernel tree on GitHub, simply because it seemed like the closest kernel baseline to your test builds.
I was thinking of a minimal Linux analysis image on the same RPI Pro hardware, just to observe the DA2 standby/on behavior from the USB/xHCI side.
One reason I started thinking that way is that the powered USB 2.0 hub path behaved normally, while the direct path did not, so I wanted to look more closely at what the kernel is actually seeing on the direct path.
I understand your point that a standard Pi or a regular Linux PC would be the quicker route, but unfortunately I don’t have either available right now.
So if I try that route on the same RPI Pro hardware, would raspberrypi/linux make more sense as the kernel baseline than the public RoPieee/linux tree?
Well, I still don’t see how you’re able to patch the kernel and getting it running on your unit. RoPieee uses it’s own fork of the kernel, with several changes added to it.