Topping D10s DAC auto standby?

[Tim Curtis]

I've done a bit more digging, I might need to revert to uhubctl if it at all is available for RaspiOS....
Could that be something to integrate in MoOde, it seems some sort of support for USB standby is available in Picore player and Ropiee it seems

https://github.com/mvp/uhubctl

Can you provide links to how the other players implement USB standby? 
AFAIK its not part of RaspiOS.

[Falco]

I've done a bit more digging, I might need to revert to uhubctl if it at all is available for RaspiOS....
Could that be something to integrate in MoOde, it seems some sort of support for USB standby is available in Picore player and Ropiee it seems

https://github.com/mvp/uhubctl

Can you provide links to how the other players implement USB standby? 
AFAIK its not part of RaspiOS.

Hi Tim, I need to look that up again, read something over at audiosciencereview.com

In the mean time I've also found this, will try that first when I'm home again.
https://www.baeldung.com/linux/control-usb-power-supply

[Tim Curtis]

The real issue though is the DAC firmware should be checking the audio signal and not the power to determine whether to blank it's display.

[Falco]

The real issue though is the DAC firmware should be checking the audio signal and not the power to determine whether to blank it's display.

yes, you're right, unfortunately the D10s doesn't have upgradeable firmware it seems...

[TheOldPresbyope]

Judging by a 10-minute surf of the InterWeb™ over my coffee, this is a bit of a rabbit hole

Would seem the D30 is another DAC which has this behavior. Some sites refer vaguely to others from Chinese contract manufacturers.

Questions in my mind include how general a problem is this, how general a solution is possible, and how copacetic is it with the various Pi models’ USB subsystems?

Be interested to see what develops here.

Regards,
Kent

[Falco]

I did find a download section from Topping, but nothing (yet) for the D10s unfortunately.

I've sent their tech support department an email, let's see what comes back.....

At least sound wise there's nothing to complain, best sounding DAC I've owned so far

[Nutul]

The real issue though is the DAC firmware should be checking the audio signal and not the power to determine whether to blank it's display.

Absolutely right,

though, since this is not the case with "some" DACs (or other products) would it be possible to have a man-in-the-middle checking the audio signal, and if it is not playing for some time issue a power-off on the USB bus? Although at the moment nothing comes to mind, Linux surely allows some dirty things to be done...

Only my awoke-5-minutes-ago-had-no-coffee-yet thought...

[Sehnsucht]

would it be possible to have a man-in-the-middle checking the audio signal, and if it is not playing for some time issue a power-off on the USB bus? Although at the moment nothing comes to mind, Linux surely allows some dirty things to be done...

Of course, you'd want whatever solution you come up with to use less power than just leaving the DAC on.... (They're not exactly power-hungry after all!)

[Falco]

I did get my response from Topping, but unfortunately not really helpful...

Code:

Dear,

Thank you for contacting TOPPING support. We are happy to assist.


Even though the audio stops, there will still be a signal coming in, so it won't go into standby. If you turn off the computer it will go into standby

Best Regards


    
service
service@tpdz.net

[Nutul]

I did get my response from Topping, but unfortunately not really helpful...

Code:

Dear,

Thank you for contacting TOPPING support. We are happy to assist.


Even though the audio stops, there will still be a signal coming in, so it won't go into standby. If you turn off the computer it will go into standby

Best Regards


    
service
service@tpdz.net

Hmm,

I am reading right now... depending on where your DAC is located on the usb bus, it should be possible to power it off and on...
On my Pi4 we are looking for the DAC-Z8

lsusb returns the following:

Code:

Bus 002 Device 002: ID 1058:264f Western Digital Technologies, Inc. My Passport 264F
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 20b1:30fd XMOS Ltd EVER SOLO DAC-Z8
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

from which I see my DAC is on BUS 1, DEVICE 5, then

lsusb -t returns the following:

Code:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
   |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
   |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
       |__ Port 1: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 480M
       |__ Port 1: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 480M
       |__ Port 1: Dev 5, If 2, Class=Application Specific Interface, Driver=, 480M
       |__ Port 1: Dev 5, If 3, Class=Human Interface Device, Driver=usbhid, 480M

From which I see my DAC is on BUS 1, Port 1, Port 1 (look at the cascading entries after the BUS line)

the syntax is BUS- then the ports, one after another separated by dots: port[.port[.port[.port]]] etc etc, so for me the device identifier would be 1-1.1

as Bus 01 => gives the first 1
  the underneath Port 1 => gives the second 1
    the further underneath Port 1 => gives the third 1 (as we found here our device number, 5)

the whole idea is to power off the data lines of the port, then allow the device to autosuspend and ask it to suspend itself ASAP:

## first, power off the data lines of the port

Code:

echo '1-1.1' | sudo tee /sys/bus/usb/drivers/usb/unbind

## allow autosuspend

Code:

echo auto | sudo tee /sys/bus/usb/devices/1-1.1/power/control

## try to autosuspend in 1 second

Code:

echo 1000 | sudo tee /sys/bus/usb/devices/1-1.1/power/autosuspend_delay_ms

## wake it back up by powering the data lines

Code:

echo '1-1.1' | sudo tee /sys/bus/usb/drivers/usb/bind