![]() |
[IDEA] Automatically suspend USB DACs when idle - Printable Version +- Moode Forum (https://moodeaudio.org/forum) +-- Forum: moOde audio player (https://moodeaudio.org/forum/forumdisplay.php?fid=3) +--- Forum: Feature requests (https://moodeaudio.org/forum/forumdisplay.php?fid=8) +--- Thread: [IDEA] Automatically suspend USB DACs when idle (/showthread.php?tid=5089) |
RE: Automatically suspend USB DACs when idle - sll552 - 09-29-2022 (09-28-2022, 03:56 PM)Tim Curtis Wrote: 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. (09-28-2022, 04:05 PM)TheOldPresbyope Wrote: 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.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. (09-28-2022, 04:15 PM)Tim Curtis Wrote: 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 :-) In my case unfortunately the DAC is USB-powered so this is not an option ![]() RE: Automatically suspend USB DACs when idle - DRONE7 - 09-29-2022 Quote: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. RE: Automatically suspend USB DACs when idle - bitlab - 09-29-2022 @sll552 maybe a workarround:
Code: # An option not directly related to camilladsp. A command to run when 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 RE: Automatically suspend USB DACs when idle - sll552 - 09-30-2022 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/blob/master/libasound_module_pcm_cdsp.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. RE: Automatically suspend USB DACs when idle - bitlab - 09-30-2022 @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 RE: Automatically suspend USB DACs when idle - sll552 - 09-30-2022 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. RE: Automatically suspend USB DACs when idle - arczar - 10-01-2022 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. RE: Automatically suspend USB DACs when idle - Tim Curtis - 10-01-2022 (10-01-2022, 09:02 AM)arczar Wrote: 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? RE: Automatically suspend USB DACs when idle - arczar - 10-01-2022 These are my bugs in MPD and audio: [attachment=2987][attachment=2988] RE: Automatically suspend USB DACs when idle - CallMeMike - 10-03-2022 (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. |