[IDEA] Automatically suspend USB DACs when idle

[sll552]

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.

That's basically why I was suggesting the hook idea, it would have provided a nice extension point for interested/expert users to call their own stuff without adding too much complexity at moode side and also being far away from any hardware problems. Unfortunately it seems like there is no place to put something like this because some renderers bypass moode completely if I understood that right.
The problem to be solved, at least from my experiments, is that some renderer tries to open the alsa device while USB is powered off and gets an error because there is no easy way to intercept such a call and make it wait until the USB is powered up again. So my current idea (without having any kind of knowledge of alsa) is having some kind of virtual device in alsa that's always available (pointing to loopback or something) and as soon as its used the USB can be powered on and then point the virtual device to the USB. Maybe something like this works but I have no idea if that's even possible with alsa.

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.

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.

I don't actually know if there is much difference between the models as I would rely on uhubctl and its hardware support. So basically get the usb port of the currently selected output and turn this off/on. Of course there must be a warning for the internal RPi hub that every port is disabled. Also this feature in general should be somehow marked as "for experts" or unstable or something along those lines in the UI.
I am fully on board with the consistency argument. I just thought there would be some kind of callback or whatever to moode code in every case when music is playing mainly because of the UI. But that doesn't seem to be the case which basically kills the hook idea. I am still positive however that something involving alsa could be possible.

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

In my case unfortunately the DAC is USB-powered so this is not an option

[DRONE7]

In my case unfortunately the DAC is USB-powered so this is not an option 

It is an option...with a little DIY
https://www.tnt-audio.com/clinica/221_diy_usb_e.html

The additional benefit being more reliable performance, less power supply noise, and less load.

[bitlab]

@sll552 maybe a workarround:

• activate camilladsp as dsp option
  
• you can use the flat config to make sure that it doesn't alter the audio
  
• test if it works
  
• next we will run command before the audio device is started by:
  
• edit the file /etc/alsa/conf.d/camilladsp.conf
  
• add the following option (should be above the last '}' ):
  

Code:

 # An option not directly related to camilladsp.  A command to run when
     # the plugin is first created.  (Meaning when a playback program opens
     # the audio device.)  Use it for whatever you want.  Set gpio pins on a
     # raspberry pi to turn on your amp for example.
     start_cmd "/path/to/start_command"

Of course replace it by your command

If you are luckly enough it runs fast enough before camilladsp is started and opened the actual audio device.

Good luck!

Marcel

[sll552]

Nice idea, but seems like the command is called after opening the device, if I understand the code correctly https://github.com/scripple/alsa_cdsp/bl...sp.c#L1513

Anyway after seeing this I will take a look at maybe writing a small alsa plugin that does what I need. Should only be a few lines of code.

[bitlab]

@sll552 did you try it? Because the audio device isn't opend by this plugin, but by camilladsp later on if an audio stream is started.
I'm afraid that it doesn't work for another reason; the plugin is prob only loaded once and so the cmd runs also only once.

And if it doesn't work you can modify the alsa_cdsp, moode uses a different code branch then the one from scripple;
https://github.com/bitkeeper/alsa_cdsp

[sll552]

I guess it would be much easier to create a new plugin instead of messing with the camilla integration. But I need to test myself if I can make that work, but those plugins seem reasonable easy to implement at least for what I am trying to achieve.

It's all about making it work for every case, my current solution works for me but is tailored to my environment and use cases only, and won't work if integrated into moode.

[arczar]

For me, the problem is the opposite. I have a DAC with USB input on XMOS DIYINHK. I never turn off the RPI from moode, but I do power off the DAC. After turning it back on, moode does not see the DAC and I have to do an RPI reboot. It happened after upgrading to the new version - I didn't have to reboot before.

[Tim Curtis]

For me, the problem is the opposite. I have a DAC with USB input on XMOS DIYINHK. I never turn off the RPI from moode, but I do power off the DAC. After turning it back on, moode does not see the DAC and I have to do an RPI reboot. It happened after upgrading to the new version - I didn't have to reboot before.

No issues on my end with powering off/on my USB DAC.

How are you determining the DAC is not being recognized after powering on?

[arczar]

These are my bugs in MPD and audio:

       

[CallMeMike]

(probably this reported issue should have been the subject of a new thread)

@arczar ...it may be that your XMOS DIYINHK DAC needs to be powered on (and possibly 'ready') before the RPi so it gets recognised.