On Tue, 23 Feb 2021 15:09:30 +0100, Mark Brown wrote:
On Tue, Feb 23, 2021 at 02:59:17PM +0100, Hans de Goede wrote:
On 2/23/21 2:45 PM, Mark Brown wrote:
On Mon, Feb 15, 2021 at 03:24:19PM +0100, Hans de Goede wrote:
Why just these particular controls - what if a system has separate mutes for speakers or something?
These are the main volume controls, which are always in the output / input path independent on if we are outputting to e.g. speakers or the headphones.
We want to use the main volume control for this, because there always is only 1 output mute LED and 1 input mute LED. Well at least that is the assumption the current ledtrig-audio.c code has.
The idea is to only turn the single LED on if we are sure there will be not sound output on any of the outputs, which is why we tie the LED to the mute switch on the main volume control.
Right, so that might work well on your particular system with your particular configuration but will it work well on other systems with different hardware? It's not clear to me that it makes sense to go through all the drivers picking controls that might be used for this purpose - it seems both time consuming and error prone. Consider a mostly digital device which has an ADC/DAC per input/output rather than a central ADC/DAC with analogue muxing for example, or a system with multiple DACs available for mixing together or analogue bypassess.
That's one of my concerns in the recent actions for putting the hard-coded mute LED controls. So far, the only usage of led-audio trigger is HD-audio, and it's enabled only for selected devices and setups. OTOH, if we apply the audio-led trigger generically in ASoC codec driver, it's always done and might misfit; e.g. what happens if two codecs are present on the system?.
Of course, this implementation would make the integration much easier, and that's a big benefit. So I have a mixed feeling and not decided yet whether we should go for it right now...
thanks,
Takashi