RPI Pro may miss DA2 standby-triggered USB disconnect

Chris

Hello LHY team,

I am reporting a repeatable USB compatibility issue involving LHY RPI Pro and McIntosh DA2.

System

Host: LHY RPI Pro
DAC: McIntosh DA2 via USB Audio
Software tested:
- RoPieee
- Signalyst Network Audio Daemon
Symptom: after DA2 standby -> on, the first playback attempt fails in most cases; only occasional success is observed

What has been clearly confirmed

This is not a general USB disconnect detection problem on RPI Pro
- When I perform a forced physical USB unplug/replug, disconnect and re-enumeration are detected normally.
The issue appears to be specific to the DA2 standby-triggered USB transition
- In the failing case, after DA2 standby, the host does not see the expected USB disconnect.
- Instead, the device remains in a stale connected state.
- Then, after DA2 is turned on again, the first playback attempt usually fails.
This behavior is not limited to a single software environment
- I observed the same issue with RoPieee
- I also observed the same issue with Signalyst Network Audio Daemon
- Because of this, the issue does not appear to be limited to only one software stack.
A direct Mac USB connection behaves differently
- With the DA2 connected directly to a Mac, the device disappears on standby and reappears on power-on as expected.

Failure pattern on the RPI Pro side

In the failing case:

the USB device remains present after DA2 standby
the expected remove/add re-enumeration does not occur
the first playback after power-on fails
after a USB reset, playback succeeds again

Why I am asking LHY

At this point, the pattern looks quite specific:

normal physical unplug/replug is handled correctly by the RPI Pro
the same standby-related issue appears in both RoPieee and Signalyst Network Audio Daemon
but the specific USB transition generated by DA2 standby/on does not seem to be propagated correctly in the failing cases

Because of this, I would like to ask whether the issue could be related to the RPI Pro USB output path / USB isolation stage.

Questions

Is there any special logic, firmware, MCU, or configuration in the RPI Pro USB output path that affects downstream disconnect/reconnect propagation?
Have you seen similar cases where a DAC standby cycle is not reflected to the host as a proper USB disconnect/reconnect event?
Is there any known workaround, firmware update, hardware revision, or recommended setting for this behavior?
Is the RPI Pro USB output path expected to propagate all downstream USB audio disconnect/reconnect transitions, including standby-triggered ones, reliably?

I would appreciate your guidance on how LHY would like to investigate this further.

Thank you.

Jayce

Hello, we have noted your situation and will have our engineering team try to replicate your environment for testing.

We will update you as soon as we have any progress.❤

Chris

Hello @Jayce ,

I would like to add a more specific update, because the problem scope now seems much narrower.

I compared the DA2 standby/on behavior on two Linux 6.18.y test paths:

LHY RPI Pro direct USB path
Standard Raspberry Pi 4B USB path

What I observed was very different:

On the standard Pi 4B path, the DA2 is actually removed and re-enumerated after standby/on. From the host side, I can see remove/unbind -> add/bind with a new device number.
On the RPI Pro direct USB path, the DA2 does not get cleaned up as a disconnect. It remains stale-present, and the xHCI root port gets stuck at CCS=1 / PED=0 / PLS=Polling.

So at this point, the same DA2 standby transition appears to be handled normally on a standard Pi path, but not on the RPI Pro direct USB path.

This is why the issue now seems much more specific to the RPI Pro USB output path than to Linux in general.

What I would like LHY engineering to clarify is:

Is the RPI Pro USB output path expected to propagate this kind of standby-triggered downstream USB disconnect/reconnect transition to the host reliably?
Is there any logic, firmware, MCU, or configuration in the RPI Pro USB output/isolation path that could affect disconnect propagation or re-enumeration in this case?
Is a persistent host-visible state like CCS=1 / PED=0 / PLS=Polling considered normal on the RPI Pro path, or does it indicate a path/controller recovery issue?
Is there any known workaround, firmware update, hardware revision, or recommended test for this behavior?

If helpful, I can also provide a more detailed comparison timeline from the RPI Pro and standard Pi 4B tests.

Thank you.

Jayce

Chris
Hi,

This behavior has been confirmed and is not a defect, but a compatibility interaction between the USB isolation architecture and the standby behavior of certain DACs.

The RPI Pro uses a high-grade USB digital isolation design to eliminate ground noise and improve signal purity and audio performance.

Unlike the direct USB connection on a standard Raspberry Pi 4B, with isolation:

The host cannot directly detect instantaneous power loss or fast state changes on the DAC side
Some DACs (such as the McIntosh DA2) use an aggressive standby that hard-cuts USB power

In this situation, the host may not interpret it as a standard USB disconnect event, so the first playback may require reinitialization.

To clarify:

Normal USB unplug/replug works as expected on the RPI Pro
This only occurs with specific DAC + standby behavior combinations

This is a typical trade-off in high-end audio USB design:
prioritizing cleaner electrical performance and sound quality, with limited impact on hot-plug detection in rare cases.

Chris

Jayce

Thank you for the reply, but the current explanation is still too general and does not address the actual engineering contradiction.

The issue is not simply that “USB isolation exists.”

The issue is that the RPI Pro direct / isolated USB path does not appear to handle the DA2 standby-triggered downstream USB transition as a clean, host-visible disconnect / cleanup / re-enumeration event, while other paths do.

At this point, the publicly described behavior is already much narrower than a general “compatibility interaction”:

This does not look like a general DA2 problem.
The same DA2 standby/on behavior is handled correctly on other host paths.
A standard Raspberry Pi 4B path can remove and re-enumerate the device properly.
A Mac direct USB path also handles the DA2 standby/on transition as a normal disconnect/reconnect sequence.
This also does not look like a general “RPI Pro cannot detect disconnects” problem.
Normal physical unplug/replug is detected correctly on the RPI Pro.
There is also an additional point that makes the scope even narrower:
the powered USB 2.0 hub path behaved normally, while the RPI Pro direct path did not.

That means this is not just “DA2 standby is unusual,” and it is not just “Linux behaves differently.”

The same DAC, with the same standby behavior, can be handled correctly:

on a Mac direct USB path
on a standard Pi 4B path
and even on the RPI Pro when a powered USB 2.0 hub is inserted in between

But the RPI Pro direct path still fails.

That makes the problem look far more specific to the RPI Pro direct USB output / isolation path than to the DA2 itself.

Because of that, saying this is “not a defect, but a compatibility interaction” is not a sufficient technical answer.

Also, saying that “with isolation, the host cannot directly detect instantaneous power loss or fast state changes” does not resolve the contradiction.

If:

normal unplug/replug is propagated correctly,
other host paths handle the same DA2 standby transition correctly,
and even the RPI Pro + powered USB 2.0 hub path behaves normally,

then the real question is no longer whether isolation exists.

The real question is:

Why does the RPI Pro direct / isolated USB path fail to convert this specific downstream standby-triggered USB transition into a proper host-visible disconnect / cleanup / re-enumeration sequence?

At that point, this is no longer a generic statement about “high-end audio USB design trade-offs.”
It becomes a concrete implementation question about the RPI Pro USB output / isolation path.

In other words, this appears to be a path-specific handling or recovery problem on the RPI Pro side, not a general DA2 explanation.

So I would like a precise engineering answer to the following points:

Which exact block is responsible for this behavior?
- the isolation IC itself
- power sequencing around the isolated USB stage
- any MCU / firmware / glue logic
- or host-side recovery handling
Is the persistent host-visible state
CCS=1 / PED=0 / PLS=Polling
considered normal behavior on the RPI Pro path?
Or does LHY consider this an abnormal stale state / recovery failure?
If LHY considers this “expected behavior,” please explain why the same DA2 standby transition is handled normally on:
- a standard Raspberry Pi 4B path
- a Mac direct USB path
- and an RPI Pro path with a powered USB 2.0 hub inserted
If LHY considers this a compatibility limitation rather than a defect, what is the official mitigation?
- firmware update
- hardware revision
- recommended workaround
- or explicit product limitation
If there is no mitigation, does LHY explicitly consider it acceptable that the RPI Pro direct / isolated USB output can fail to reflect and recover from a downstream USB standby transition that standard host paths and even a hub-assisted RPI Pro path handle correctly?

This is the key point that still needs a clear answer:

“USB isolation” by itself is not an explanation.

The actual question is whether the RPI Pro implementation is expected to propagate and recover from this class of downstream USB state transition correctly.

If the answer is yes, then what exact mechanism is failing here?
If the answer is no, then this should be stated clearly as a path-specific limitation of the RPI Pro direct / isolated USB output.

Please provide one of the following clearly:

the exact engineering mechanism
the official workaround
or an explicit acknowledgement that this is a path-specific limitation of the RPI Pro direct / isolated USB output

At this stage, a concrete engineering explanation is needed, not a general statement about sound-quality trade-offs.

Jayce

Chris

Hi,

Thanks for the detailed write-up.

The main difference in this setup is the USB isolation stage (ADuM3165) sitting between the CM4 and the output port. Compared to a native USB path like a Pi 4B or a Mac, that layer changes how certain low-level transitions are presented to the host.

On a native path, the host has direct visibility of VBUS and the D+/D− line states. When the DA2 goes into standby and cuts power aggressively, the host sees a clear disconnect event, then a clean reconnect on wake. That's why re-enumeration happens reliably there.

With the isolated path, the signaling is reconstructed rather than passed through transparently. The isolator has its own internal state handling and edge detection, so it doesn't always mirror very fast or abrupt downstream transitions in the same way. In most normal cases this is fine, including standard unplug/replug, which is why those are detected correctly.

Where it gets tricky is with this type of standby behavior. The DA2 effectively simulates a very fast power loss and line collapse. Under that condition, the transition seen on the upstream side can end up not being interpreted as a full disconnect event by the host controller. That's when you see the kind of state you mentioned (CCS=1 / PED=0 / PLS=Polling), where the link is still logically present but not recoverable without reinitialization.

This also explains why inserting a powered USB 2.0 hub changes the outcome. The hub doesn't just pass the signal through, it re-terminates and manages the connection state, so it ends up presenting a fresh attach event to the host even if the downstream behavior is abrupt. In effect, it "normalizes"that transition.

So it's less a case of one side being strictly right or wrong, and more about how a specific standby implementation interacts with an isolation-based USB topology. Most DACs don't trigger this edge case, but some with more aggressive power handling do.

From a practical standpoint, the hub workaround you tested is the most reliable way to avoid the issue in this scenario. We're also reviewing whether there's any room to improve handling on our side, but with this class of isolation device, behavior under very fast power transitions can vary depending on the downstream device.

Appreciate the level of detail you brought into this .

Chris

Jayce

Thank you for the detailed follow-up.

I understand the direction of your explanation, especially the distinction you are making between a native USB path and the isolated USB path in the RPI Pro.

However, I still think one important inconsistency remains.

What matters most from the user side is not yet which internal block is responsible, but the observable result:

a real downstream USB disconnect appears to occur, yet the RPI Pro direct / isolated USB path does not present that event to the host in a form the OS can handle as a normal disconnect / cleanup / re-enumeration sequence.

That is why this still seems difficult to describe simply as a generic “trade-off.”

The same DA2 standby/on transition is handled correctly:

on a standard Raspberry Pi 4B path
on a Mac direct USB path
and even on an RPI Pro path when a powered USB 2.0 hub is inserted

Only the RPI Pro direct / isolated path fails.

That comparison is why I still think the problem looks more like a path-specific handling or recovery issue in the RPI Pro direct USB output / isolation stage than a general DA2 issue.

I also still struggle with the phrase “cuts power aggressively.”

A forced physical USB unplug is already a very clear disconnect event, and normal unplug/replug is detected correctly on the RPI Pro.

So if physical unplug is handled correctly, but this DA2 standby-triggered transition is not, then it seems the issue is not simply that the DA2 transition is somehow too abrupt in a generic sense.

The hub result also makes this harder to view as a normal design trade-off.

If the same RPI Pro can behave normally once a cheap powered USB 2.0 hub is inserted, then it seems the transition itself is not inherently impossible to handle.
Instead, it suggests that the direct / isolated path is the part that is not presenting or recovering from that transition correctly.

From a user perspective, that is difficult to accept as a normal trade-off, because recognizing disconnect / reconnect is one of the most basic parts of USB host behavior.

So I think the key remaining question is not whether the DA2 really disconnected.

The key question is why the RPI Pro direct / isolated USB path does not reflect and recover from that same downstream transition correctly, while:

standard Pi 4B does
Mac direct USB does
and even RPI Pro + powered USB 2.0 hub does

At this point, it would be very helpful if LHY could clearly state one of the following:

whether this is considered a path-specific limitation of the RPI Pro direct / isolated USB output
whether there is a fix or improvement plan
or whether there is an official workaround beyond relying on an external hub

I appreciate the additional technical explanation, but I think this part still needs a more direct answer from the product side.

Jayce

Chris
Hi,

To put it simply, the difference comes down to how the host "sees" a real unplug versus a DAC standby.

Physical unplug: When you pull the USB cable, the host immediately notices the lines and power go away—this is like a clear "stop"signal, and the host triggers a full disconnect and re-enumeration. RPI Pro handles this perfectly.
DAC standby: Each DAC can implement standby differently. Some cut power aggressively, some lower signals slowly, some have internal timing. From the host's perspective, the USB isolation stage (ADuM3165) can't always tell that the DAC is "gone." It may appear logically connected, even though the DAC is actually offline.

This also explains why inserting a powered USB hub works reliably: the hub reconditions the connection and presents a standard attach event to the host, effectively "normalizing" any abrupt standby behavior.

Because every DAC's standby logic is different, it's very hard to make the host universally handle all standby behaviors. For your setup, the powered USB hub remains the most reliable solution, while we continue to explore whether any improvements are possible on the RPI Pro side.

Hope this makes the difference easier to visualize.

Chris

Jayce

Thank you for the clarification.

From the user side, I think the remaining question is now simple.

In this scenario, the RPI Pro direct / isolated USB path does not always recover from the DA2 standby transition in a way that allows normal stable use without reinitialization or an external hub.

For actual product use, I do not think repeated reinitialization or reliance on an external USB hub is a realistic long-term usage model.

So at this point, it would be most helpful if LHY could clearly state one of the following:

LHY intends to improve / fix this behavior
or this is a current limitation of the RPI Pro direct / isolated USB output in this scenario

If improvement is possible, I would appreciate a clear statement that you plan to address it.

If not, then I think it would be important to state clearly that stable use in this scenario may currently require reinitialization or an external hub.

Jayce

Chris

After internal review, we would like to clarify that this behavior is not classified as a bug, but rather a result of the design characteristics of the direct / isolated USB output, which prioritizes signal quality and electrical isolation.

At this stage, there are no planned changes to this USB output design.

In this specific use case, achieving consistent stability after DAC standby transitions may require either reinitialization or the use of a USB hub.