All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.