[alsa-devel] pcm512x driver: Mixer control naming issue

Mark Brown broonie at kernel.org
Mon Mar 16 12:38:45 CET 2015


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150316/fc4a6a85/attachment.sig>


More information about the Alsa-devel mailing list