Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Idea: Automatically suspend USB DACs when idle
#1
Lightbulb 
Hi everyone,

It would be nice to have the possibility to automatically suspend the usb power after some timeout with no interaction/playback. Background is that some or maybe most USB DACs do not suspend themselves and stay on all the time, that means that e.g. a display stays on which can be distracting and maybe hurt the lifetime of the DAC.

For a RPi this can be achieved with uhubctl but it disables all USB Ports, this is however a RPi problem and can be worked around with adding an external USB hub.
I have scripted this myself but I had to use the mpd events which is technically a little too late for the reactivation use case. Meaning that mpd fails to open the device and I have to press play again to make it work.

So the proposed feature would be either:

A generic Hook System: Hook support for different events (playstate, library update, settings changed, etc.)
Add some setting to call a script/binary when a defined event happens before calling mpd. Maybe add some environment variables with information about the specific event when calling the script/binary.

or 

USB suspend: Automatically cut power to a defined USB port after some idle time
Add a setting to suspend an USB hub/port with a configurable timeout. At least for RPi there needs to be a warning that all USB ports will be deactivated (e.g. keyboards/mice, wifi dongle, etc. would also be deactivated).
Reply
#2
I don't quite get the usage scenario but it seems like you are going for something similar to attached display blanking/suspend except it's for the LCD on a DAC ???
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#3
Well the scenario is maybe specific to a RPi. The RPi does not have any kind of advanced power management, e.g. suspend or wake on lan capabilities. This itself is not a big problem as the power consumption is low and it can stay on all the time. But it also means that there is no USB power management either like its present on most x86 or maybe other SBCs. Which in turn means that USB DACs that mostly rely on such a behavior do not go to sleep or shutdown. Unfortunately I think that most/all DACs do not expose their display in any way to the Host, but yes basically it's about the display of the DAC which at least to me is annoying/distracting when not listening to music.

So my specific use case is that I have a RPi4 and attached to it is a Topping D10s via USB. When playing music it's nice to see the bitrate on the Display of the DAC but when I just watch TV or do something else it's rather distracting and I actually want the DAC to shutdown when it is not in use

If a generic approach (hooks) is feasible it would open a lot more possibilities for similar use cases, e.g. when pressing play in moode someone could power on their AVR via HDMI-CEC with a custom script.
Reply
#4
Maybe it’s just me, but this seems a question better suited for the official Raspberry Pi Forum where the RPI gurus hang out.

Regards,
Kent
Reply
#5
Yes and no, because the "how" is basically done (uhubctl) but to be nicely integrated it needs a little help from the service (moode) that's running on the system. Also there is nothing the Pi could do better because it's the hardware that's lacking, and even if there would be some power management it's still the service that would need to configure suspending behavior. Kodi for example has those features (suspending the device, not USB per se) integrated because its expected to exclusively manage the system, just like moode.

I have currently scripted it with a service running on the device that waits for mpc events and triggers the USB wakeup and shutdown. But the wakeup is too late because mpd tries to connect to the output device before emitting the event. So for it to work flawlessly it would be required that moode waits for the USB to come up before actually sending the play command to mpd. That's why this feature request even exists.

As I said it doesn't need to be such a specialized feature. If it's reasonable to implement a hook system, that would actually be better because it's versatile and would enable users to implement their own stuff easily.
And by thinking about this, it would be nice to have "blocking" and "non-blocking" hooks so you can trigger something like a device wake up (my use case) where moode would need to wait for completion or just be informed about an event and do something with that (idk. like updating your digital picture frame with the current album cover). Such a feature would enable many niche use cases that someone might have without having to build a full fledged plugin system.

I am currently trying to understand the code and am willing to contribute, but the first thing on my list is improving the mounts and general systemd integration.
Reply
#6
I'm just kibitzing here Rolleyes

The RPi architecture is what it is. At least uhubctl is available in the Raspberry Pi OS repro these days and it appears from the github activity to be pretty solidly supported in the larger world. As you say, however, to use it with moOde would require an external smart USB hub.

My few DACs don't have a built-in display. If they did, however, my partner who is pretty particular about how any technology she uses should "just work™" would want them to behave consistently.

Given that MPD is only one of several renderers implemented in moOde, she'd want the display-blanking to work irrespective of the client UI in use. This means not just the moOde webUI but also the Spotify app on her phone and the Airplay connection from my iPad or UPnP or Bluetooth connections from my Android phone when using other clients. Then there's moOde users who drive the internal MPD server from an external MPD client.

My grandmother was fond of telling us grandkids that "the proof of the pudding is in the eating". Always happy to see what implementations (and configuration menus!) folks come up with and this feature is no exception. 

Regards,
Kent
Reply
#7
(09-28-2022, 02:40 PM)TheOldPresbyope Wrote: The RPi architecture is what it is. At least uhubctl is available in the Raspberry Pi OS repro these days and it appears from the github activity to be pretty solidly supported in the larger world. As you say, however, to use it with moOde would require an external smart USB hub.
Well it works with the internal Hub, but can only disable all Ports at once

(09-28-2022, 02:40 PM)TheOldPresbyope Wrote: My few DACs don't have a built-in display. If they did, however, my partner who is pretty particular about how any technology she uses should "just work™" would want them to behave consistently.
The feature (whatever it is, hooks or suspend) should of course be optional, so if you want your DAC to be always on, why not.

(09-28-2022, 02:40 PM)TheOldPresbyope Wrote: Given that MPD is only one of several renderers implemented in moOde, she'd want the display-blanking to work irrespective of the client UI in use. This means not just the moOde webUI but also the Spotify app on her phone and the Airplay connection from my iPad or UPnP or Bluetooth connections from my Android phone when using other clients. Then there's moOde users who drive the internal MPD server from an external MPD client.
This is actually something I missed completely, how is a scenario like "some device is streaming spotify and someone opens the webinterface" handled? Like what is displayed on the UI and what happens if you press play in the UI? Is there no interaction with moode code when some other renderer (bluetooth, spotify, etc.) is used?
I guess that it would still be possible to do by asking alsa if its currently doing something, but I have not looked at that. Or maybe some kind of socket monitoring or whatever, so if something connects via bluetooth, wake the DAC etc. But yes multiple render paths make it at least harder.
Reply
#8
Just keep in mind that edge case usage scenarios need significant demand in order to consider adding code to moOde because that code will become yet another vector for support and troubleshooting.

You might want to look at the UDEV subsystem for monitoring and acting on USB events. There is a UDEV rule used by Bluez-alsa in /etc/udev/rules.d/ which shows the basics.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#9
Given the difference in behavior among various RPi models I think turning the internal hub on and off likely is a non-starter for most users but again that's just me.

When I said "behave consistently" I was referring to the DAC display-blanking. If it blanks when using the MPD renderer, it should blank when using the others and v.v.

Try experimenting with the various renderers to get a feel for what the moOdeUI does. Hint: it reminds me of the opening sequence to Rod Serling's 1960s TV series "The Outer Limits" with its voice-over 

There is nothing wrong with your television set. Do not attempt to adjust the picture. We are controlling transmission.

Spotify, Qobuz, and most recently Amazon Music Unlimited are three streaming services I access with other clients talking to one or another of moOde's renderers.

I too was thinking about ALSA as a possible layer to work with but I have too superficial an understanding of its internals to comment.

Regards,
Kent
Reply
#10
Another option is to just use a bn-link wireless outlet to turn the DAC on/off. They are inexpensive and super reliable. I use them in my Media Room :-)

https://www.amazon.com/dp/B01NASZ0UM?psc...ct_details
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply


Forum Jump: