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.
------------------------------------------------------------------------
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
