[IDEA] Keep Last Selected Audio Output Device After Reboot

[storaid]

Hello,

I would like to request a feature that allows Moode to keep the last selected audio output device after a reboot. 

Issue: 
If an external USB DAC(ex: AURALIC DAC) starts up slower than Moode, Moode defaults to another available output, such as the internal USB audio device. 
This requires manual re-selection of the desired output device after each reboot. 

Implementing this feature would greatly enhance the user experience. 
   
In Volumio audio linux, the last selected audio output device is remembered and automatically used after reboot. 
This behavior ensures that the user experience is seamless and consistent. 

Thank you for considering this request.

[Tim Curtis]

Correct. If the configured audio device is not found during the audio configuration section of moOde startup then fallback and reconfigure to HDMI happens.

It's not a very common scenario where a USB DAC starts slower that Pi/Linux. These DAC's usually start almost instantly but I suppose some sort of check/retry could be implemented before the automatic fallback to HDMI happens. For example check 3 times with a 10 second wait between each check. The wait period would be configurable. Something like that.

In any case here's an older thread that talks about similar issues
https://moodeaudio.org/forum/showthread....3#pid56403

What do you think?

[storaid]

Correct. If the configured audio device is not found during the audio configuration section of moOde startup then fallback and reconfigure to HDMI happens.

It's not a very common scenario where a USB DAC starts slower that Pi/Linux. These DAC's usually start almost instantly but I suppose some sort of check/retry could be implemented before the automatic fallback to HDMI happens. For example check 3 times with a 10 second wait between each check. The wait period would be configurable. Something like that.

In any case here's an older thread that talks about similar issues
https://moodeaudio.org/forum/showthread....3#pid56403

What do you think?

Hello,
Thanks for the response!
I’ve already disabled HDMI(nohdmi) and internal headphone(noaudio) output in config.txt.

The problem is that Moode always picks the first available USB audio device at startup instead of remembering the last selected one.
In my case, I have two USB devices:
card 0: Holo Audio UAC2.0 Gen2 - RED (internal built-in DDC device, always available at boot)
card 1: AURALiC ActiveUSB Audio 2.0 (external, takes longer to start)

Since the AURALiC DAC boots slower than Moode, Moode doesn't see it during startup and defaults to Holo Audio instead.
This means I have to manually reselect my AURALiC DAC every time I reboot.

Some high-end DACs, like the AURALiC VEGA, have a power-up sequence that takes longer than Moode’s startup, making this a recurring issue.

I tested this with Volumio, and it does NOT have this issue. In Volumio, when the DAC starts up late, it still gets selected correctly. 
When my AURALiC DAC finishes booting, Volumio automatically detects it and switches to it.
It doesn’t fall back to another available device like Moode does.

Is it possible to handle this by monitoring audio devices in the background and automatically switching to the last selected device when it becomes available?

That way, even if a DAC takes a long time to start, it will still be selected correctly without user intervention.

Thanks again for looking into this!

[Tim Curtis]

Couple things:

1. It does no good to compare to other softwares because I don't know how they function or how they were built
2. You are now describing a different configuration where you have 2 USB DAC's connected
3. Config.txt has been modified to disable HDMI and Headphone card assignments

This is not correct.
"The problem is that Moode always picks the first available USB audio device at startup instead of remembering the last selected one"

Because PiOS Bookworm implements dynamic ALSA card assignment, whats done is to check whether the configured (last selected) audio device is assigned to the same ALSA card number as before, a different card number or not assigned to a card for some reason (powered off, bad connection, not ready, user disconnected it, etc).

If it's not assigned to a card (because Linux/ALSA has not detected the device) the fallback is to switch to the built in HDMI 1 device, to avoid a broken audio configuration. Note that HDMI 1 may not be at card 0 because there may for example be an I2S audio device at that card number.

See /var/www/daemon/worker.php starting at line "workerLog('worker: -- Audio configuration');" for the code block that handles ALSA card assignments.

I don't see an obvious way to handle your issue where the configured audio device starts slower that the other device but maybe you will have some insights after looking at or hacking the code.

[TheOldPresbyope]

@storaid

How are you switching your DAC and your moOde player on and off now?

When I've worked with professional A/V equipment in performance spaces, we either sequenced the power of the various equipment on and off by hand (cheap but requires one's attention) or using commercial multi-step power sequencers (expensive but "one button" operation). 

For home use, I could easily imagine implementing a simple two-step power sequencer since the AC currents involved are so small...or, of course...just switching the two components on and off appropriately.

Regards,
Kent

[Nutul]

I still cannot think of a DAC taking something like 2 minutes to start up...
Unless the mentioned device is a streamer with an integrated DAC (which is the USB device moOde fails to detect because it takes longer to boot - an Android device, most probably, uh...?)

ETA
Anyway, I'd switch the DAC first, and once operating, I'd switch moOde on too... old school, here, and laziness at its best at work...

[storaid]

Hi all,
I thought I’d take a moment to explain my specific setup and share the behavior I’m encountering with Moode. 
I’m using Moode installed directly on Holo Audio RED (yes, as the platform itself).
https://www.kitsunehifi.com/product/holo...-streamer/

AFAIK
The RED device has an internal XMOS XU208 USB controller that shows up in Moode as a built-in USB audio device (Holo Audio UAC2.0 Gen2, USB Virtual Device).
It provides outputs for SPDIF, AES, COAX, and I2S.

In addition to RED’s virtual USB device, connect an AURALiC VEGA DAC via RED’s USB-OUT port.
The VEGA DAC serves as my main output device in PureDAC mode, where all streaming functions are disabled, and it’s used solely as a pure DAC.

When I power on my system, everything (including Holo RED) is powered via a central toroidal transformer power switch. Here’s the sequence:
1. Holo Audio RED starts immediately and boots Moode.
2. RED’s internal USB Virtual Device gets detected by Moode almost instantly and gets assigned as card 0.
3. Meanwhile, the AURALiC VEGA DAC remains powered off (because it needs to be manually turned on). Once I press the power button on the VEGA DAC, it takes about 30–45 seconds to initialize and become available as a USB device (card 1).

* The key detail with VEGA DAC is that it defaults to power-off state when my system starts, and requires a manual power-on followed by about 30–45 seconds to fully boot and initialize.

I always use the AURALiC VEGA DAC as my main output device, so having to manually reselect it each time is a bit of a hassle via Web GUI.
I’m wondering if it’s possible to make Moode behave a bit more flexibly in scenarios like this.

I’d appreciate any thoughts or suggestions! 
Let me know if I need to provide more details or clarify anything further.
Thanks, and looking forward to hearing from you all.

[Tim Curtis]

As I mentioned in post #2

Code:

It's not a very common scenario where a USB DAC starts slower that Pi/Linux. These DAC's usually start almost instantly but I suppose some sort of check/retry could be implemented before the automatic fallback to HDMI happens. For example check 3 times with a 10 second wait between each check. The wait period would be configurable. Something like that.

I don't know of this will work for your scenario but if you want to try a test file let me know. You will just need to be able to edit the file and adjust the wait period if necessary, and do additional debugging if needed.