Looking back over this thread I gather you've tried toggling the power to the USB port, but that didn't change anything. There are a couple of things that don't seem to fit any kind of theory.
Firstly, powering off the USB port then re-powering it seems like it should be no different from physically removing it, but evidently they're not the same. Secondly, the dmesg files that you posted earlier show that in the 'no sound' case (presumably a normal boot) there's already a ~9 second gap between the hardware being detected and the driver loading. I wonder what was happening in those 9 seconds. In the 'sound' case that gap is only ~0.2 seconds. I had thought about delaying the audio driver during boot via a udev rule, but couldn't think of a way to make that work, since udev rules don't seem to trigger during boot. And anyway, the timing doesn't seem to be the problem. But it might be worth a try anyway, and I think in combination with uhubctl it might be possible to interrupt the process with a udev rule (since you could run uhubctl once boot-up is complete). Would you mind providing a single complete dmesg log from the following scenario: 1) Boot normally with the DAC connected. This presumably will result in 'no sound' 2) Once booted, use uhubctl to turn off the USB port power, then again to re-power it. Presumably this will still result in 'no sound', but it would be interesting to see what's going on in dmesg in this case, and it would confirm whether a udev rule can be applied to experiment with timing. ------------------------------------------------------------------------ chill's Profile: http://forums.slimdevices.com/member.php?userid=10839 View this thread: http://forums.slimdevices.com/showthread.php?t=113895 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
