Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Howard Mitchell <hm@hmbedded.co.uk>
To: Mark Brown <broonie@kernel.org>
Cc: Takashi Iwai <tiwai@suse.de>,
	alsa-devel@alsa-project.org,
	Gordon Garrity <gordon.garrity@gmail.com>
Subject: Re: pcm512x driver: Mixer control naming issue
Date: Sun, 15 Mar 2015 22:28:01 +0000	[thread overview]
Message-ID: <55060771.7060200@hmbedded.co.uk> (raw)
In-Reply-To: <20150313182729.GE28806@sirena.org.uk>

On 13/03/15 18:27, Mark Brown wrote:
> On Fri, Mar 13, 2015 at 12:41:05PM +0000, Howard Mitchell wrote:
>
>> Boost Volume) provides a boost of +0.8dB. The hardware reset value of both
>> of these gain controls is 0dB, however, in the Raspbian distribution
>> 'Playback Volume' is being defaulted to -6dB.
>>   * Either change the names of these controls to something that's not
>>     affected by the alsa restore mechanism,
> 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.

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 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?

>>   * or remove them as mixer controls, but make them accessible some
>>     other way - e.g. device tree.
> It may not be policy that someone wants to tweak at runtime on your
> board but it almost certainly will be on someone's board.
>
Fair enough, if that's the general alsa ethos I'm happy to go along with it.

  reply	other threads:[~2015-03-15 22:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5500DE5B.2020401@hmbedded.co.uk>
2015-03-13 12:41 ` pcm512x driver: Mixer control naming issue Howard Mitchell
2015-03-13 18:27   ` Mark Brown
2015-03-15 22:28     ` Howard Mitchell [this message]
2015-03-16  7:47       ` Takashi Iwai
2015-03-16  9:47         ` Howard Mitchell
2015-03-16 10:11           ` Takashi Iwai
2015-03-16 11:38       ` Mark Brown
2015-03-16 11:59         ` Takashi Iwai
2015-03-16 17:37         ` Howard Mitchell
2015-03-17 17:23           ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55060771.7060200@hmbedded.co.uk \
    --to=hm@hmbedded.co.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=gordon.garrity@gmail.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox