I may be oversimplifying this, but my thinking was simply that McIntosh probably doesn’t have an RPI Pro on hand, and LHY probably doesn’t have a C2700/DA2 on hand, so I feel I should try to gather as much useful information as I can from the actual combination here.
Since Raspberry Pi hardware can generally boot many different Linux images, I just vaguely assumed that a bootable Linux image with enough xHCI/USB logging might be possible on the RPI Pro too.
If that were possible, I thought the public RoPieee/linux source might be a sensible baseline, simply because it seemed closer to what you are already using.
My point is just that: they should (imho) not focus on the RPI Pro, but on Linux support in general. That’s the reason why I suggested to test it on a regular Linux PC. Because otherwise you might end up that manufacturers point to each other.
If it’s Linux in general then McIntosh need to do something, if it’s RPI Pro specific, then those guys need to do something. And yes, if it’s RoPieee specific (which I highly doubt because of my kernel which runs the stock USB stack) then it’s me who should do something
I’ve decided to follow the quicker route first, and I’ve just ordered a Raspberry Pi 4B.
Once it arrives, I’ll test the DA2 standby/on behavior on a standard Pi/Linux path and report back. That should help separate the LHY RPI Pro path from something more Linux-general.
If you later have a 6.18-based test image available, I’d also be very happy to try that.
The Pi 4B may arrive as early as this afternoon, so once it arrives I’ll put the new image on it, test the DA2 standby/on behavior, and send feedback from that test.
The USB stack maintains state for connected device. And as soon as the device is disconnected, this state is reset. However, with the LHY this is not happening: while you put the DA2 to sleep (and thus state on the device side is changed), RoPieee (the Linux kernel) doesn’t know that. Hence a mismatch in state, which results in the errors when you try to stream.
LHY just needs to make sure that when a device disconnects, this is also reflected on the USB bus.
You may already have seen this in the feedback I sent, but from my side the key difference looked like this:
On the RPI Pro direct path, after DA2 standby the device does not get cleaned up as a disconnect; it stays stale-present, with the root port stuck at CCS=1 / PED=0 / PLS=Polling.
On the standard Pi 4B path, the DA2 under the onboard hub is actually removed and re-enumerated (remove/unbind → add/bind, with a new devnum after power-on).
So the same DA2 standby transition seems to be handled very differently by the two host paths.
From my reading, this looks much more consistent with something specific to the RPI Pro direct USB path than with a Linux-general issue.
My main question is this:
if CCS=1 / PED=0 / PLS=Polling persists for some finite time, would you still treat that as a state to preserve, or would it make more sense to treat it as a failed recovery / dead-port condition and force logical disconnect / re-enumeration?
I’m also planning to go back to LHY with the additional comparison results and ask for more detail from their side about how the RPI Pro USB output path is expected to behave here.
I don’t know. I’m not that into depth up to speed with the USB stack in the Linux kernel. IMHO it also doesn’t matter, because the issue is very simple: when you put a USB device into standby (like your McIntosh in this case), it should result in a USB disconnect. That’s not happening.
I can imagine that their devices out there who can handle this, but the DA2 is certainly not. LHY can verify this with a regular PC running Linux, and basically a random USB device.
Yes, I think that is probably the right way to look at it.
I’ve already passed the comparison results and this observation back to LHY as well.
Since this is the actual problem I’m dealing with, I still wanted to understand it a bit further, so I did one more small local experiment on the direct RPI Pro path.
In code terms, the experiment was roughly this: if the direct path stayed in the stale CCS=1 / PED=0 / PLS=Polling state after DA2 standby, I checked again after about 20 ms, and if it was still unchanged, I made the host treat it as a connection-change event (synthetic C_CONNECTION). That caused usbcore to discard the stale device state and go down the normal disconnect / re-enumeration path.
With that experiment, the direct RPI Pro path recovered cleanly again after DA2 power-on.
I’m not asking you to take this on — I just wanted to share it as a matching local observation.
FYI — LHY replied on their forum with a concrete explanation. They explicitly point to the ADuM3165 isolation stage between the CM4 and the RPI Pro USB output as the key difference vs native Pi 4B / Mac USB. Their view is that the DA2 standby transition can be so fast/abrupt that, on the isolated path, it may not always be presented upstream as a full disconnect, which they say matches the stale CCS=1 / PED=0 / PLS=Polling state I saw. They also say this is why the powered USB 2.0 hub workaround helps: the hub re-terminates/manages connection state and presents a fresh attach event to the host.
So they are essentially framing this as an RPI Pro direct USB path / isolation-stage handling issue rather than a general DA2 issue. They also say the hub workaround is the most reliable practical solution for now, and that they are reviewing whether there is room to improve handling on their side. At the moment, though, they have not provided a concrete fix or a clear product-side statement on why Mac direct USB, standard Pi 4B, and even RPI Pro + a cheap powered USB 2.0 hub all handle the same DA2 standby transition correctly while the direct RPI Pro path does not.
Hmmm… I’m not sure what to make of this: it reads that they think this is an inconvenience, where from my side imho this is wrong behavior of their device…
Anyways, I’m ‘happy’ that this is not related to RoPieee - but I can imagine that you’re not too happy about it because it does not solve your issue.
If there’s anything else I can help out with let me know.
FYI — LHY has now taken the position that this is not a bug but a design characteristic/limitation of the RPI Pro direct/isolation USB path in this use case, and they also said there are currently no planned changes to that USB output design. Since they are effectively saying stable use here may require reinitialization or a USB hub, I’ll probably try to resolve this from the return/refund side. In any case, thank you again for all your help — it was very useful in narrowing this down.
Information appreciated. I’m in the process of getting a refund for the LHY.
Currently just using a Pi 4B directly.
While running various tests, I discovered yet another issue with DSD512 Native transmission and I’m trying to work through it.
It’s not easy. Haha.. flops down
In any case, thank you again for all your help — it was very useful in narrowing this down.