My audio card (FiiO 5 Pro ESS) very frequently cannot be recognized until the hub is reconnected.
On any other system (x86_64-linux (with the same NixOS configuration), aarch64-darwin, x86_64-darwin) everything works fine - I can connect the audio card to any port I want and I won’t have any problems with it, but on asahi I need to (almost every time) reconnect the hub and (sometimes) restart the computer. audio card. Sometimes when I reconnect the audio card, I see it on the output lsusb, but it is not initialized (LED on card stays red (which means it is not configured to any of PCM or DSD input)).
This could be a USB or related power/timing issue. I’ve noticed the same behaviour with a Glorious Model O USB LED mouse. It doesn’t get detected after boot (LEDs are off too), but once I disconnect and reconnect it again, it works fine and LEDs are on.
The lsusb output is important here. If the hub does not show up on boot, that’s likely our problem with the port drivers. If only the hub shows up, that’s weird. If the hub and card show up but the card doesn’t work, that’s probably an issue on the audio driver or PipeWire side (which would be interesting if that doesn’t happen on x86-64), unless it’s caused by a USB speed downgrade in which case we’re back to the port driver.
Note that USB3.0 hubs should show up as two hubs, one each on the USB2.0 and USB3.0 buses, with the audio card connected to the correct one depending on what kind of device it is.
It would be nice to get several lsusb dumps of the problem cases and how often each happens, so we can get an idea of what’s going on. The log shows a number of reconnects, sometimes with different error/warning messages attached to the audio card, but it’s hard to know what happened there. Can you maybe do a fresh boot and take notes of exactly what gets plugged/unplugged how many times and what the results are? Or maybe see if you can correlate the issues with specific kernel messages.
One possibility, given this kind of “weirdness” where the card works sometimes and not other times but is always detected at the USB level, is that it’s one of those picky/buggy USB devices that gets confused or stops working if things happen too fast for its liking. Different USB controllers (and different drivers) will have different timings even while meeting USB specifications, which could explain why this works on some systems but not Asahi. Alternatively it could be the same kind of problem/race, but in the ALSA driver instead.
I am also running NixOS on a 14” MacBook Pro M1 Max machine.
My mouse requires a USB-A receiver to work and I use this via a USB-C adapter.
If I start the machine from cold boot or restart from NixOS the mouse does not work until I unplug it and then plug it back in. Then it works fine as you would expect until the next boot.
The output of lsusb does not show the receiver in these cases until it has been unplugged and plugged back in. Perhaps my issue is related to the above.
I also have Asahi Fedora Remix on another partition for testing purposes and in my testing this issue does not occur there with the same mouse, receiver and adapter.
So NixOS must do something differently or not do something the Fedora Asahi does on boot.
Technical information:
Host: 14” MacBook Pro M1 Max
System firmware: 13.5
OS firmware: 12.3
OS: NixOS
Kernel: 6.3.0-asahi13 with GPU driver enabled
root filesystem: ZFS (waiting on a new release of openzfs that supports 6.4 before upgrading to the latest 6.4 based asahi kernel)
Best guess is NixOS is using different kernel and/or u-boot versions (or configs). You might want to ping the folks maintaining those builds so they can double check those and make sure they’re the same as on Fedora packages! In particular, u-boot needs to be from this branch, which has a lot of USB fixes.