Same problem:
ERROR Transfer event for disabled endpoint slot 2 ep 13
Just to be sure: no USB hubs or anything involved?
And powered by an ‘official’ Raspberry PS?
Same problem:
ERROR Transfer event for disabled endpoint slot 2 ep 13
Just to be sure: no USB hubs or anything involved?
And powered by an ‘official’ Raspberry PS?
Official power supply. That bedroom unit also has a display hat though so I guess it’s got some extra power load (and that one is a display 1 knockoff). I can’t easily switch units around unfortunately, they’re all somewhat inaccessible and if I just moved the DAC then I have nothing to plug the output into in a different spot.
Maybe something in the newer builds is putting more power load though and my use cases are pushing it?
And no usb hubs or usb extenders or anything.
Yeah… that crossed my mind too.
I have a new image that does 2 things: add some logging about USB power mgt, and secondly disable high speed transfer on the CM720:
https://image.ropieee.io/ropieee_pi4-2026.5.0-test.20260429.3572.bin
(or just use the regular update because I pushed it out there a well)
Can you send me feedback on the unit with the CM720 specifically with this build?
Yes, will update it and re-send.
Also for what it’s worth I’ve just tested the USB SPDIF Adapter that’s in my Garage. bc91905c8730cf31
It’s a Rpi2 running an old build, so I don’t mean you to debug it… but it’s working there and plays the tracks without issue (despite also showing the second #1 adapter) so might show you what’s “normal" with that dac.
Ok, progress and not.
I’ve put build 3572 on both units and have confirmed that the problem still exists on both. Perhaps more importantly, the “flooding of failures” is much worse with these recent builds than previously. To the extent that I’ve only been able to successfully start playing by starting somewhere else, and transferring to the ropieee zone (it’s like negotiating the start causes the failure but once it starts it’s fine).
So… sorry about the flooding of packets in the log, but I feel like these are related in some way. it’s like ropieee isn’t negotiating correctly with the DAC and then everything breaks down from there.
6f550ec6a4f60ad2 - Bedroom CM720 unit.
Nope, no change. My fix used the wrong kernel parameter.
Here’s a another attempt: https://image.ropieee.io/ropieee_pi4-2026.5.0-test.20260429.3573.bin
If I force the zone to 16 bit in Roon, the problems appear to go away, so it’s definitely behaving like a throughput issue of some sort. (the DACs in question do support 24bit high frequency though)
Thanks, will test soon.
a390927405c62cda after update but before playing anything.
Then hit play on an Imogen Heap album which is 16/44.1 and it did the whole flood the logs thing, but then started playing.
Once it was happily playing I hit play on one of the evanescence problem tracks (which sounded terrible) and then generated feedback again.
20cac99815a48b2e
Can you test with local content?
Therein lies the problem.
Roon is sending 24/192khz as you’d expect, but the DAC is not interpreting this correctly and sounds like 44.1kHz (essentially it sounds static and slow).
And it’s happening in multiple places on multiple endpoints (all with USB DACs) but it’s not happening on the Dacmagic (also via USB).
How do you know that? The CM720 doesn’t have a display?
The album I’ve been doing much of the testing with is local (but also happens with Tidal)
I’m wondering more and more if this isn’t a network issue and that your server isn’t capable of keeping up. The dropouts are just not ok, and I see that they aren’t related to the USB side of things, but the network side of things…
Because on the USB side of things the 24 bit width is properly recognized and setup.
It’s how it “sounds". Slow, with lower frequency and all staticky.
Will see if I can DM a link.
I can’t rule something like that out 100%, but
Agree, they aren’t ok. But they’re new, and only happen when I’m playing to one of the problematic USB devices (not the other USB on the same endpoint).
I don’t get it ![]()
That makes 2 of us. The only thing I can think of is making a build with the new LTS kernel release, to see if that would resolve something.
Yeah. I think Ill try putting dietpi on one and seeing what happens. If it’s built in drivers it may make no difference, but worth trying ![]()