• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Topping DX1ii with Raspberry Pi 5

JunkyTalent

Member
Joined
Apr 2, 2026
Messages
11
Likes
4
Hi! I am trying to build a home audio & DSP center with Raspberry Pi 5 and Topping DX1ii, but it seems that Pi 5 cannot properly connect with DX1ii.

DX1ii requires power from the usb cable, but as far as I know Pi 5 should have enough power through USB-A ports with the official 5V/5.1A power supply which I am using right now. Furhter more: a) there's no throttle log; b) the CPU frequency is stable; c) ther's no voltage drop warning or log. So I think it's not power supply issue.

Edit: the same cable and DX1ii works with my MacBook so probably it’s not their fault.

I got the following log message, seems the Pi 5 is not correctly building connections with DX1ii? Did anyone encountered similar issue before and/or have a solution? I tried to extract essential parts of the log, basically it's those lines repreating in a random order.

Thanks in advance!

Code:
[Fri Jul 17 04:29:42 2026] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[Fri Jul 17 04:29:42 2026] usb 1-1: New USB device found, idVendor=152a, idProduct=8750, bcdDevice= 2.83
[Fri Jul 17 04:29:42 2026] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[Fri Jul 17 04:29:42 2026] usb 1-1: Product: DX1 II
[Fri Jul 17 04:29:42 2026] usb 1-1: Manufacturer: TOPPING
[Fri Jul 17 04:29:42 2026] usb 1-1: SerialNumber: 00MMJ-PD3HD-LDUGN-MGPWP-5MWMA-13XD8
[Fri Jul 17 04:29:42 2026] input: TOPPING DX1 II as /devices/platform/axi/1000120000.pcie/1f00200000.usb/xhci-hcd.0/usb1/1-1/1-1:1.4/0003:152A:8750.0001/input/input5
[Fri Jul 17 04:29:42 2026] hid-generic 0003:152A:8750.0001: input,hidraw0: USB HID v1.10 Device [TOPPING DX1 II] on usb-xhci-hcd.0-1/input4
[Fri Jul 17 04:29:42 2026] usb usb2-port1: over-current change #3
[Fri Jul 17 04:29:42 2026] usb usb1-port1: over-current change #3
[Fri Jul 17 04:29:42 2026] usb usb4-port1: over-current change #3
[Fri Jul 17 04:29:42 2026] usb usb3-port1: over-current change #3
[Fri Jul 17 04:29:42 2026] usb 1-1: 10:0: failed to get current value for ch 1 (-71)
[Fri Jul 17 04:29:42 2026] usb 1-1: 10:0: failed to get current value for ch 2 (-71)
[Fri Jul 17 04:29:42 2026] usb 1-1: 10:0: failed to get current value for ch 0 (-71)
[Fri Jul 17 04:29:42 2026] usb 1-1: 10:0: cannot get min/max values for control 2 (id 10)
[Fri Jul 17 04:29:42 2026] usb 1-1: 10:0: cannot get min/max values for control 2 (id 10)
......
[Fri Jul 17 04:29:42 2026] usbcore: registered new interface driver snd-usb-audio
......
[Fri Jul 17 04:29:42 2026] usb 1-1: uac_clock_source_is_valid(): cannot get clock validity for id 41
[Fri Jul 17 04:29:42 2026] usb 1-1: clock source 41 is not valid, cannot use
[Fri Jul 17 04:29:42 2026] usb 1-1: 1:1: cannot get freq (v2/v3): err -71
[Fri Jul 17 04:29:42 2026] usb 1-1: 1:1: cannot set freq 48000 (v2/v3): err -71
[Fri Jul 17 04:29:42 2026] usb 1-1: uac_clock_source_is_valid(): cannot get clock validity for id 41
......
[Fri Jul 17 04:29:42 2026] usb 1-1: USB disconnect, device number 2
......
[Fri Jul 17 04:29:43 2026] usb 1-1: new high-speed USB device number 3 using xhci-hcd
[Fri Jul 17 04:29:43 2026] usb 1-1: New USB device found, idVendor=152a, idProduct=8750, bcdDevice= 2.83
[Fri Jul 17 04:29:43 2026] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[Fri Jul 17 04:29:43 2026] usb 1-1: Product: DX1 II
[Fri Jul 17 04:29:43 2026] usb 1-1: Manufacturer: TOPPING
[Fri Jul 17 04:29:43 2026] usb 1-1: SerialNumber: 00MMJ-PD3HD-LDUGN-MGPWP-5MWMA-13XD8
[Fri Jul 17 04:29:43 2026] usb usb3-port1: over-current change #5
[Fri Jul 17 04:29:43 2026] usb 1-1: 1:1: cannot set freq 384000 (v2/v3): err -71
[Fri Jul 17 04:29:43 2026] usb usb2-port1: over-current change #5
[Fri Jul 17 04:29:43 2026] usb usb4-port1: over-current change #5
[Fri Jul 17 04:29:43 2026] usb 1-1: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 41)
[Fri Jul 17 04:29:43 2026] usb 1-1: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 41)
[Fri Jul 17 04:29:43 2026] usb 1-1: 10:0: failed to get current value for ch 1 (-71)
......
 
Last edited:
Google tells me that the rPi 5's eeprom is configured for a "safe" assumption that a 3A power supply will be used, and restrict the USB current. To change this configuration, run
sudo rpi-eeprom-config --edit
and add this line to the bottom -
PSU_MAX_CURRENT=5000
Press Ctrl + X to exit, type Y to confirm, and hit Enter to save.

Alternatively I think you can achieve the same thing at operating system level by opening /boot/firmware/config.txt in a text editor, and adding this line -
usb_max_current_enable=1
 
Google tells me that the rPi 5's eeprom is configured for a "safe" assumption that a 3A power supply will be used, and restrict the USB current. To change this configuration, run
sudo rpi-eeprom-config --edit
and add this line to the bottom -
PSU_MAX_CURRENT=5000
Press Ctrl + X to exit, type Y to confirm, and hit Enter to save.

Alternatively I think you can achieve the same thing at operating system level by opening /boot/firmware/config.txt in a text editor, and adding this line -
usb_max_current_enable=1
Thanks for replying, sadly neither works. I also noticed the second one before and tried it without succeeding. After some more investigation it seems it's on by default for Pi 5 so actually nothing will change by adding usb_max_current_enable=1
 
Last edited:
Why not start out with a power splitter?

then after testing and setup, happy with everything, go back and see if there are other solutions
 
Some further Googling reveals that the two configuration changes I mentioned are not an either/or situation, they are both necessary.
And of course the rPi needs to be rebooted after those changes.

But yeah, a power splitter would be a good idea, too.
 
In another thread people are reporting problems with Windows (where there's a Topping driver) and Mac where it's relying on UAC2 compatibility like linux. It could be that you're seeing UAC2 quirks rather than a power issue. If you've got a powered USB hub you could see whether it works with that to rule out power as the cause.
 
Power splitter solves the issue, thanks! Besides, the same splitter can also turn Raspberry into a USB device without requiring the weird 5.1V 5A power supply from your host computer :D

But still feel there are some bugs in either Topping or Pi OS......
 
Glad it helped.

You say your issue is resolved, what "bugs" do you mean?

Isn't it just that the DAC requires more power than RPi has available?
 
Glad it helped.

You say your issue is resolved, what "bugs" do you mean?

Isn't it just that the DAC requires more power than RPi has available?
I think it's some compatibility issue (bug) during the handshaking process, since the USB port of RPi should be more than capable to drive DX1ii.

As far as I learned from the official specifications, when powered by a proper 5.1V 5A adapter (which I am using now), RPi should be able to provide maximum 5V 1.6A all four ports combined. For the USB 3.0 it should be at least 5V 0.9A or 5V 1.6A if other ports not used at all (which is my case).

Meanwhile, DX1ii only requires 5V 0.5A maximum.

Some premature guess: according to the log file, it seems the error starts from RPi can't get supported audio formats from DX1ii, and then drops the connection. Maybe it's DX1ii not responding when not powered?
 
Can you paste the errors still appearing in the log file to take out some of the guesswork?
 
Can you paste the errors still appearing in the log file to take out some of the guesswork?
Oh, with the power splitter, everything works. I was just saying it should also work without the power splitter, but it does not.

Also attach the success log with the power splitter here, if it helps. I am also contacting Topping about it.

Code:
[Tue Jul 21 11:23:44 2026] usb 3-2: new high-speed USB device number 9 using xhci-hcd
[Tue Jul 21 11:23:44 2026] usb 3-2: New USB device found, idVendor=152a, idProduct=8750, bcdDevice= 2.83
[Tue Jul 21 11:23:44 2026] usb 3-2: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[Tue Jul 21 11:23:44 2026] usb 3-2: Product: DX1 II
[Tue Jul 21 11:23:44 2026] usb 3-2: Manufacturer: TOPPING
[Tue Jul 21 11:23:44 2026] usb 3-2: SerialNumber: 00MMJ-PD3HD-LDUGN-MGPWP-5MWMA-13XD8
[Tue Jul 21 11:23:44 2026] input: TOPPING DX1 II as /devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb3/3-2/3-2:1.4/0003:152A:8750.0008/input/input12
[Tue Jul 21 11:23:44 2026] hid-generic 0003:152A:8750.0008: input,hidraw0: USB HID v1.10 Device [TOPPING DX1 II] on usb-xhci-hcd.1-2/input4
 
It would be interesting to get some measurements of the current it's actually drawing, and whether it's occasionally going over the max current it declares in its USB properties. In the original review it was noted that it needed to be the only thing powered off the computer's USB port, and others report having to plug it into a powered hub because the firmware update wouldn't work when connected directly to the computer. I hadn't taken too much notice because I assumed there wasn't a Topping app that would work with linux for the PEQ and firmware upgrade. I've now seen they're using WebHID so it should all work fine, so taking more interest in how it's behaving.
 
It would be interesting to get some measurements of the current it's actually drawing, and whether it's occasionally going over the max current it declares in its USB properties. In the original review it was noted that it needed to be the only thing powered off the computer's USB port, and others report having to plug it into a powered hub because the firmware update wouldn't work when connected directly to the computer. I hadn't taken too much notice because I assumed there wasn't a Topping app that would work with linux for the PEQ and firmware upgrade. I've now seen they're using WebHID so it should all work fine, so taking more interest in how it's behaving.
Interesting! Taking about WebHID, on my RPi5 DX1ii can be detected by Chromium as a device but the web can't open it (ofc for this whole thing to appear power splitter is used). But it seems to be simple permission issue by Chromium log:

Code:
[86388:86388:0721/221256.642728:VERBOSE1:components/device_event_log/device_event_log_impl.cc:203] [22:12:56.642] HID: EVENT: hid_service_linux.cc:467 Access denied opening device read-write, trying read-only.
[86388:86388:0721/221256.642861:VERBOSE1:components/device_event_log/device_event_log_impl.cc:203] [22:12:56.642] HID: EVENT: hid_service_linux.cc:474 Failed to open '/dev/hidraw0': FILE_ERROR_ACCESS_DENIED

Edit: it's indeed a simple permission issue, by default, only root user can access the device. Adding proper permission solves it and now the web can be used normally.

1784686022318.png
 
Last edited:
For those who are interested, this is the reply from Topping. They don't seem to think it's their issue, and seems not very willing to debug, which is a bit underwhelming TBH. Unfortunately I am now in another place without the DX1ii so cannot further debug, let's hope someone else will either never experience it or can solve the issue.

Thank you for contacting TOPPING support. We are happy to assist.

When the DX1 II is connected directly to the Pi 5, the Pi 5’s USB ports report over-current events, which may cause the USB power supply or bus connection to become unstable. The subsequent UAC2 clock, sample-rate, and volume-control transfers then fail with -EPROTO/-71, and the device eventually disconnects. When an externally powered USB splitter is used, it bypasses the Pi 5’s USB power path, allowing the connection to work normally.

Therefore, this issue may be related to the Pi 5’s USB over-current detection, or to an edge-case compatibility issue involving the Pi firmware or Linux kernel and this USB controller/device combination. Therefore, the machine is most likely working properly.

Best Regards,
 
I agree the solution is so cheap & simple, why bother even thinking about it?

They could add a warning next manual update I suppose.

Personally I'd avoid powering anything like that from RPi in the first place, issues are so common there
 
I have an RPI5 and a DX1-II. Everything is powered by a powerful Minwell 5V 5A power supply. But without the PD and RPI doesn't know its parameters. The DAC didn't start the first time I connected it. After a quick search, I first tried the combination usb_max_current_enable=1 in the /boot/firmware/config.txt file. This helped. But I didn't like the fact that this message might disappear with OS updates. Then I found another solution that doesn't write to the SD card, but to the RPI5's eeprom: sudo rpi-eeprom-config --edit PSU_MAX_CURRENT=5000. This solution also works, even without the line in config.txt. But there's one catch: you can't disconnect the DAC from the USB connector. Then it won't start. You first need to connect the DAC to USB, and then apply power to the RPI5. In this mode, everything works for me now, without any Y splitters.

In another thread, I already measured the DX12's current consumption. It's around 530 mA. Naturally, when power is applied, the charging of the input capacitors produces a current pulse significantly exceeding 600 mA.
 
I have an RPI5 and a DX1-II. Everything is powered by a powerful Minwell 5V 5A power supply. But without the PD and RPI doesn't know its parameters. The DAC didn't start the first time I connected it. After a quick search, I first tried the combination usb_max_current_enable=1 in the /boot/firmware/config.txt file. This helped. But I didn't like the fact that this message might disappear with OS updates. Then I found another solution that doesn't write to the SD card, but to the RPI5's eeprom: sudo rpi-eeprom-config --edit PSU_MAX_CURRENT=5000. This solution also works, even without the line in config.txt. But there's one catch: you can't disconnect the DAC from the USB connector. Then it won't start. You first need to connect the DAC to USB, and then apply power to the RPI5. In this mode, everything works for me now, without any Y splitters.

In another thread, I already measured the DX12's current consumption. It's around 530 mA. Naturally, when power is applied, the charging of the input capacitors produces a current pulse significantly exceeding 600 mA.
Great results! I see, I was always trying to connect DX1ii after booting the RPi so never succeeded. The issue seems to be the current pulse then.
 
Back
Top Bottom