Home of the Squeezebox™ & Transporter® network music players.
Page 5 of 5 FirstFirst ... 345
Results 41 to 45 of 45
  1. #41
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,095
    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.

  2. #42
    Junior Member
    Join Date
    Feb 2021
    Posts
    16
    Quote Originally Posted by chill View Post
    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.
    Experiments gave interesting results. On first attempt re-powering USB led to 'sound', so worked as re-plugging.
    Second attempt gave initial situation - 'no sound'.
    The difference in dmesg log:
    [ 95.568629] usb 1-1.3: cannot submit urb (err = -19)

    sound2.txt
    no-sound2.txt

  3. #43
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,095
    OK, that's interesting that toggling the port power did result in sound on one occasion. I recall that you said that physically disconnecting and reconnecting also wasn't 100% reliable, so maybe that's what you're seeing with the port power too.

    I can't tell whether that 'usb 1-1.3: cannot submit urb (err = -19)' is associated with the disconnect or the reconnect, because there's such a small time gap between them - did you issue both uhubctl commands together?

    What the uhubctl experiments did confirm, however, is that the SABAJ DAC was rediscovered after re-powering the port exactly the same way as after physically reconnecting it, so there's an opportunity for a udev rule to work. So if you wish to experiment you could try creating a file called '10-dac.rules' in '/etc/udev/rules.d', and pasting the following line into it. You'll need to use 'sudo' to create the file because the folder is owned by root.
    Code:
    SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="152a", ATTR{idProduct}=="85df", RUN+="/home/tc/dac-delay.sh"
    That rules file should trigger the script file '/home/tc/dac-delay.sh' to run whenever a device with idVendor=152a and idProduce=85df, i.e. your SABAJ dac, is connected. So then you just need to create that script file 'dac-delay.sh' in your home directory, to contain:
    Code:
    #!/bin/sh
    
    sleep 5
    ... then make it executable with 'chmod +x dac-delay.sh'

    The hope is that if you boot normally with the dac connected, then issue your uhubctl commands to toggle the power, as soon as the dac is recognised it will call that script, which simply pauses for 5 seconds. Since this script should block any further events on this device, it may delay things long enough to see a difference in behaviour.

    To know whether this is working, take a look at the end of the dmesg file after the uhubctl commands - you will hopefully see a 5 second gap soon after the dac is found.

    EDIT: I just tried this with my DragonFly, and unfortunately there's no sign of a delay - I suspect all the events that we see in dmesg have already been triggered by the time the sleep is initiated. So I don't think this is going to work unfortunately.

    There are two things that might make it worth trying though:
    1) there is the possibility that there's something happening after the dac is inserted that doesn't register in dmesg, but that seems like a long shot.
    2) you could force an alsactl restore when the dac is inserted by including the line 'sudo /usr/local/sbin/alsactl restore' in that 'dac-delay.sh' script.

  4. #44
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Location
    Nottingham, UK
    Posts
    2,095
    Quote Originally Posted by chill View Post
    2) you could force an alsactl restore when the dac is inserted by including the line 'sudo /usr/local/sbin/alsactl restore' in that 'dac-delay.sh' script.
    I've just noticed that there's another alsactl option that might be more helpful if, say, the daemon originally scanned the sound cards before the DAC was completely ready.

    Code:
    nrestore  <card>  like restore, but notify the daemon to rescan soundcards
    So you could try that, i.e. 'sudo /usr/local/sbin/alsactl nrestore' from a command line after boot. Presumably you'd first have to successfully save the alsa settings from a time when you've got sound.

  5. #45
    Junior Member
    Join Date
    Feb 2021
    Posts
    16
    Quote Originally Posted by chill View Post
    I've just noticed that there's another alsactl option that might be more helpful if, say, the daemon originally scanned the sound cards before the DAC was completely ready.

    Code:
    nrestore  <card>  like restore, but notify the daemon to rescan soundcards
    So you could try that, i.e. 'sudo /usr/local/sbin/alsactl nrestore' from a command line after boot. Presumably you'd first have to successfully save the alsa settings from a time when you've got sound.
    Hi chill! Thanks for the idea. Tried nrestore, but with no success.
    Also tried to google 'cannot submit urb', but didn't figure out anything useful.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •