I recently purchased a Hifime UR23 SPDIF to USB device to play some CDs using an external CD player and a Raspberry Pi. The device works fine with my Pi4 but not with the Pi5 due, I think, to the wrong idProduct (arecord -l shows no capture devices).
Below is the dmesg and lsusb for the Pi 4 (Server kernel 6.6.51):
And for the Pi 5 (Desktop kernel 6.6.51):
I thought the device firmware would have the appropriate vendor and product IDs which in turn would be used by the kernel.
Any ideas?
Thanks
Below is the dmesg and lsusb for the Pi 4 (Server kernel 6.6.51):
Code:
dmesg
[ 27.584961] usb 1-1.2: new full-speed USB device number 3 using xhci_hcd
[ 27.772506] usb 1-1.2: New USB device found, idVendor=262a, idProduct=10e7, bcdDevice= 0.01
[ 27.772514] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 27.772519] usb 1-1.2: Product: UR23 USB SPDIF Rx
[ 27.772522] usb 1-1.2: Manufacturer: HiFimeDIY Audio
[ 27.793642] hid-generic 0003:262A:10E7.0001: No inputs registered, leaving
[ 27.793780] hid-generic 0003:262A:10E7.0001: hidraw0: USB HID v1.00 Device [HiFimeDIY Audio UR23 USB SPDIF Rx] on usb-0000:01:00.0-1.2/input0
[ 27.907527] usbcore: registered new interface driver snd-usb-audio
lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 262a:10e7 SAVITECH Corp. UR23 USB SPDIF Rx
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubAnd for the Pi 5 (Desktop kernel 6.6.51):
Code:
[ 163.011601] usb 3-1: new full-speed USB device number 3 using xhci-hcd
[ 163.202710] usb 3-1: config 1 has an invalid interface number: 3 but max is 2
[ 163.202714] usb 3-1: config 1 has an invalid interface number: 3 but max is 2
[ 163.202716] usb 3-1: config 1 has an invalid interface number: 3 but max is 2
[ 163.202718] usb 3-1: config 1 has an invalid interface number: 3 but max is 2
[ 163.202721] usb 3-1: config 1 has no interface number 2
[ 163.223709] usb 3-1: New USB device found, idVendor=262a, idProduct=9023, bcdDevice= 0.01
[ 163.223713] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 163.223716] usb 3-1: Product: Bravo-X USB Audio
[ 163.223718] usb 3-1: Manufacturer: SAVITECH
[ 163.290947] input: SAVITECH Bravo-X USB Audio as /devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb3/3-1/3-1:1.0/0003:262A:9023.0003/input/input7
[ 163.347716] hid-generic 0003:262A:9023.0003: input,hidraw2: USB HID v1.00 Device [SAVITECH Bravo-X USB Audio] on usb-xhci-hcd.1-1/input0
lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 20b1:3008 XMOS Ltd iFi (by AMR) HD USB Audio
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 262a:9023 SAVITECH Corp. SA9023 audio controller
Bus 001 Device 005: ID 046d:c315 Logitech, Inc. Classic Keyboard 200
Bus 001 Device 004: ID 046d:c077 Logitech, Inc. Mouse
Bus 001 Device 002: ID 214b:7250 Huasheng Electronics USB2.0 HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubI thought the device firmware would have the appropriate vendor and product IDs which in turn would be used by the kernel.
Any ideas?
Thanks
Interesting. SA9023 documentation is very sparse https://guitarplayer.ru/equipment-c...svoimi-rukami/?action=dlattach;attach=2378648 . The device has EEPROM which should customize SA9023. Maybe reading from EEPROM does not succeed in RPi5 or some other reason when negotiating with the USB host. Clearly some RPis have issues when initializing the board https://www.diyaudio.com/community/...prom-reading-re-flashing.356566/#post-6256143 - presumably due to the built-in USB single-TT hub. Your RPi5 lsusb list shows there are other less-then-highspeed devices hooked to bus 1, while on RPi4 the audio device is the only one hooked to bus 1. Maybe some USB2 -> USB1 translation /device reset gets in conflict with SA9023 reading the EEPROM and the device ends up configured differently in each case.
I would try an external multi-TT USB 2.0 hub for both RPi4 and RPi5, to see what happens. Maybe trying to hook the DAC/keyboard/mouse to different USB ports. Also 'lsusb -t' may give some clue. Also wireshark USB dump may show something.
I would try an external multi-TT USB 2.0 hub for both RPi4 and RPi5, to see what happens. Maybe trying to hook the DAC/keyboard/mouse to different USB ports. Also 'lsusb -t' may give some clue. Also wireshark USB dump may show something.
I did try removing the extra USB devices from the Pi5 - I'll have another play around with what you suggest - thanks!
Maybe without the external USB hub the delay between USB reset and incoming request for sending USB configuration is too short and the chip does not finish reading the EEPROM and updating its configuration with the custom data.
I think I need to get up to speed on Pi USB - typically I've just used the Pi headerless with maybe just one device attached to it but now I'm using it as a desktop and with various USB devices I need to know a little more. One final thing, where would the erroneous idProduct come from - is there a vendor list stored locally somewhere?
IMO what you saw were default values stored in SA9023 ROM (or some mix). Upon reset the chip reads custom configs from the attached EEPROM via I2C and updates the hard-coded values with the values read from the EEPROM. It looks like this procedure did not not finish on time before a request for sending this configuration came from the USB host and the chip sent the default values (or maybe some mixture of default and custom values).
IIUC the EEPROM config contents can be written with some proprietary Savitech tool, undocumented.
IIUC the EEPROM config contents can be written with some proprietary Savitech tool, undocumented.
Last edited: