On Sun, Mar 15, 2015 at 10:28:01PM +0000, Howard Mitchell wrote:
On 13/03/15 18:27, Mark Brown wrote:
You say "these controls" but it seems like only "Playback Volume" has a problem? My first suggestion would be to define "Analog" or "Analogue" as a prefix in ControlNames and then use that, that would avoid confusing applications while still fittig in with the naming convention.
Yes you are correct that it's only "Playback Volume" that is causing a problem. However, I included "Playback Boost Volume" as it also provides a selection of analogue gain so I think it should be treated similarly for consistency.
Oh, I see.
Defining a new prefix sounds like a reasonable idea in principle but calling it "Analog(ue)" seems like it's saying this is a proper analogue volume control whereas these particular controls merely provide very limited selections of gain. I could imagine that at some point in the future a
Userspace can determine how much control there is from the TLV information. Ideally a smart userspace will manage to combine all the different controls it finds to make the best use it can of them - if it can use analogue volume control for some of the control that's generally better since it maximizes the resolution of the digital parts.
default for "Analogue Playback Volume" may well be added to "alsactl restore" and then we end up back in the same situation. How about defining a prefix that is documented as saying that a default should not be used if there's nothing in asound.state for that control?
Really the problem here is using asound.state - it's far too dumb a means of controlling random cards, and attempting to change it is most likely going to break something else. Any attempt to introduce a default for analogue control will inevitably result in problems on cards that currently work fine with digital/default control unless those are changed which would then cause problems for things without the analogue control.