[RPi4] USB DAC disconnects

    I have been having issues with my USB DAC and found this in DMESG. LibreELEC (official): 12.2.1

    Any ideas why it is disconnecting? I was thinking maybe a power issue but:

    vcgencmd get_throttled
    throttled=0x0

    So no undervolts and I am using a good original Raspberry Pi 4 power supply.


    [ 91.758264] usb 1-1.2: new full-speed USB device number 3 using xhci_hcd
    [ 91.854913] usb 1-1.2: New USB device found, idVendor=0d8c, idProduct=0012, bcdDevice= 1.00
    [ 91.854943] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    [ 91.854954] usb 1-1.2: Product: USB Audio Device
    [ 91.854963] usb 1-1.2: Manufacturer: C-Media Electronics Inc.
    [ 91.865704] input: C-Media Electronics Inc. USB Audio Device as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1
    -1.2/1-1.2:1.3/0003:0D8C:0012.0001/input/input2
    [ 91.918680] hid-generic 0003:0D8C:0012.0001: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB Audio Device] on usb-0000:01:00.0-1.
    2/input3
    [ 92.046382] usbcore: registered new interface driver snd-usb-audio
    [ 93.230156] usb 1-1.2: USB disconnect, device number 3

    Edited once, last by duncang92: adding info re power and throttling check (July 20, 2026 at 10:44 PM).

    As the DAC uses generic usb-audio drivers used by tens of millions of devices, it's probably NOT a driver problem.

    Two suggestions (test them separately):

    a) If the device is connected to a USB 3.0 port, move it to a USB 2.0 port (some CMedia devices prefer 2.0)

    b) See if adding usbcore.autosuspend=-1 to kernel params in cmdline.txt changes the behaviour

    Quote from chewitt

    As the DAC uses generic usb-audio drivers used by tens of millions of devices, it's probably NOT a driver problem.

    Two suggestions (test them separately):

    a) If the device is connected to a USB 3.0 port, move it to a USB 2.0 port (some CMedia devices prefer 2.0)

    i moved it from the USB 3.0 port and it showed up with lsusb ..... I then rebooted the Pi and lsusb doesn't show it.

    Quote from chewitt

    b) See if adding usbcore.autosuspend=-1 to kernel params in cmdline.txt changes the behaviour

    I added the param and lsusb still doesn't show it


    I think my next step will be to do a clean new install and start afresh

    Quote from Da Flex

    duncang92 Which USB DAC do you have? It's not visible in your log snippet.

    Other than it telliing me it is a C-Media product I do not know as there is nothing written on it

    Edited once, last by duncang92: Merged a post created by duncang92 into this post. (July 22, 2026 at 4:15 PM).

    Quote from chewitt

    Most odd. Does the device show up again when reconnected to the USB 3.0 port (with autosuspend=-1 set)?

    Well yes it did. Then after reboot it was gone again.

    I decided to see what happens with all the USB ports and nothing. I did notice that sometimes the display (1080p TV on HDMI) will go off when unplugging which seems mightily odd and then once a reboot for no apparent reason.

    I am starting to think something is corrupted in my install as it seems CEC has now decided not to work.

    It's not really possible to corrupt the core OS as LE packages kernel and userspace into two squashfs files that are expanded on boot into a virtual read-only filesystem. If you corrupt either file on the SD card they fail to decompress and the OS fails to boot. Once the OS has booted; 99% of important things are read-only. For kicks please experiment with the latest LE13 nightly on a spare SD card; it has newer kernel/drivers than LE12.2.

    Quote from duncang92

    I am starting to think something is corrupted in my install as it seems CEC has now decided not to work.

    Please provide a full debug log.

    How to post a log (wiki)

    1. Enable debugging in Settings>System Settings>Logging
    2. Restart Kodi
    3. Replicate the problem
    4. Generate a log URL (do not post/upload logs to the forum)

    use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

    The only unusual thing that I see in the log is related to time/timing:

    As RPi4 lacks an RTC time starts at the libc release date and then after the network is up NTP syncs the clock, so there's an initial large time jump forwards:

    Then the next item is an SSH login:

    Code
    Jul 26 17:30:01.911967 Bedroom4 sshd-session[1067]: Accepted password for root from 192.168.86.236 port 53399 ssh2

    Then 3.5 mins later there's a USB device connected:

    Code
    Jul 26 17:33:27.301690 Bedroom4 kernel: usb 1-1.1: new full-speed USB device number 3 using xhci_hcd
Jul 26 17:33:27.395029 Bedroom4 kernel: usb 1-1.1: New USB device found, idVendor=0d8c, idProduct=0012, bcdDevice= 1.00
Jul 26 17:33:27.395906 Bedroom4 kernel: usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 26 17:33:27.396525 Bedroom4 kernel: usb 1-1.1: Product: USB Audio Device
Jul 26 17:33:27.397049 Bedroom4 kernel: usb 1-1.1: Manufacturer: C-Media Electronics Inc.
Jul 26 17:33:27.405023 Bedroom4 kernel: input: C-Media Electronics Inc. USB Audio Device as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1:1.3/0003:0D8C:0012.0001/input/input2
Jul 26 17:33:27.461692 Bedroom4 kernel: hid-generic 0003:0D8C:0012.0001: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB Audio Device] on usb-0000:01:00.0-1.1/input3
Jul 26 17:33:27.585045 Bedroom4 kernel: usbcore: registered new interface driver snd-usb-audio
Jul 26 17:33:27.641991 Bedroom4 (udev-worker)[1142]: event2: Process '/usr/bin/evrepeat -d 500 /dev/input/event2' failed with exit code 1.
Jul 26 17:33:27.796375 Bedroom4 Boot[1207]: ### Setting up sound card ###

    RPi4 has 2x USB 2.0 ports (furthest away from Ethernet) and 2x USB 3.0 ports (next to Ethernet). The lsusb log clearly shows the DAC on Bus 001 which is the USB 2.0 bus (note the root hub type):

    Code
    Bedroom4:~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 003: ID 0d8c:0012 C-Media Electronics, Inc. USB Audio Device

    This behaviour correlates with numerous online reports of CMedia audio devices not liking USB 3.0 ports, but in the lsusb log the device doesn't show up until the fourth connection attempt. As there are only 4x USB ports (and assuming no user error) this would imply one of the previous three attempts was also to the other USB 2.0 port and the device didn't show up. Other than user error I'd have no explanation for that.

    The kodi log shows the same timezone jump; marked by a failure to find releases.json as the TLS certs are probably invalid due to the wrong host datetime, which is all normal:

    Code
    2025-06-26 04:44:46.754 T:960     error <general>: SETTINGS: load_url # Error loading url: http://releases.libreelec.tv/releases.json
                                                   Reason: [Errno -3] Temporary failure in name resolution
2026-07-26 17:28:23.975 T:960      info <general>: SETTINGS: __init__ # updateThread Started
2026-07-26 17:28:23.977 T:960      info <general>: SETTINGS: set_auto_update # auto
2026-07-26 17:28:24.161 T:1039     info <general>: SETTINGS: run # Waiting

    but then Kodi appears to be in a waiting state trying to find the 192.168.86.216 device:

    Then finally some 1.5 mins later (3.5 mins after the initial timezone jump):

    The reason timing stood out to me is that Kodi only evaluates its audio devices at startup (there is no hotplug support) and the logs show the DAC device, despite the long 3.5 mins stall period between timezone jump (network up, which Kodi waits for) and the DAC being connected. It's like Kodi is waiting for the DAC ??

    Regardless, none of that would explain the original issue report of DAC disconnects though. The normal reasons for that would be power draw on the USB bus, or perhaps bad USB cables or issues with physical USB connectors.

    So back to basics. Please go try a current LE13 nightly on a spare SD card with clean Kodi config and the DAC connected to working USB ports (which are 2.0 not 3.0) and a different USB cable. Use usbcore.autosuspend=-1 in kernel boot params in cmdline.txt again if no difference.

    Pinging popcornmix to see if he has any ideas too.

    I did try LE13 nightly and that made no difference.

    192.168.86.216 seems to be a part of my Google wifi ...labelled as localhost and says "Nest Wifi router".

    The Pi 4 is connected to the Nest wifi access point in the same room although that has a different IP address.

    I will have a dig through all of my cables and see if I can find another printer style cable and see if that makes any difference.