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: Mon, 16 Mar 2015 17:37:28 +0000	[thread overview]
Message-ID: <550714D8.5060407@hmbedded.co.uk> (raw)
In-Reply-To: <20150316113845.GM28806@sirena.org.uk>



On 16/03/15 11:38, Mark Brown wrote:
> On Sun, Mar 15, 2015 at 10:28:01PM +0000, Howard Mitchell wrote:
>
>> 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.

Makes sense.
>> 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.
So it sounds like adding an analogue prefix should be fairly safe in
which case are you happy for me to go ahead and prepare a patch?

- Howard

  parent reply	other threads:[~2015-03-16 17:40 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
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 [this message]
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=550714D8.5060407@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.