Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, James Cameron <quozl@laptop.org>,
	David Henningsson <david.henningsson@canonical.com>
Subject: Re: Splitting out controls
Date: Fri, 16 Oct 2015 16:24:02 +0100	[thread overview]
Message-ID: <1445009042.3536.7.camel@rf-debian.wolfsonmicro.main> (raw)
In-Reply-To: <56210E75.70501@linux.intel.com>

On Fri, 2015-10-16 at 09:49 -0500, Pierre-Louis Bossart wrote:
> > We actively enable and advocate that people with limited knowledge can
> > 'mess around mixer controls'. That's why we have an alsamixer
> > application in the first place, and teach people how to use it.
> 
> What you are describing is the traditional approach where the number of 
> controls is limited, a couple of switches here and a set of volume 
> controls there.
> With new devices having mixers all over the place, be it in codecs or 
> DSPs, it's not uncommon to have several hundred controls. There is no 
> way users will be able to find out on their own what values they should 
> use and it would be misleading to think developers are able to identify 
> all lethal combinations of settings. We've also moved all these control 
> settings from kernel to userspace to avoid hardcoding values that are 
> platform specific.
> Bottom line we have to move to profiles, stop guessing values based on 
> control names or avoid letting users poke random values in alsamixer. 
> This just doesn't scale any more. thinking that the alsamixer 
> command-line remains the default user-facing interface moving forward is 
> just not right, it's a developer tool.

I believe that you are misunderstanding David's point. Yes, there can be
a large number of controls (the Wolfson WM8280 has over 400 controls,
some Cirrus Logic codecs have nearly 900). The point was not whether the
users should understand the meaning of all these controls but that they
should be able to "play around and see what happens" without any risk of
bricking their hardware. Regardless of whether what they are doing is
meaningful or whether it's really feasible to set hundreds of controls
correctly from the command line, they shouldn't damage the hardware. Not
even root should have the ability to actually damage the hardware.

  reply	other threads:[~2015-10-16 15:24 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12 13:49 [Minutes] ELCE Audio mini conf Liam Girdwood
2015-10-12 15:30 ` Jaroslav Kysela
2015-10-12 20:59 ` Splitting out controls James Cameron
2015-10-13  7:07   ` David Henningsson
2015-10-13  8:27     ` Keyon
2015-10-13 14:55     ` Pierre-Louis Bossart
2015-10-13 15:56       ` David Henningsson
2015-10-13 16:08         ` Pierre-Louis Bossart
2015-10-16  6:41           ` David Henningsson
2015-10-16 14:49             ` Pierre-Louis Bossart
2015-10-16 15:24               ` Richard Fitzgerald [this message]
2015-10-30  2:48                 ` Mark Brown
2015-10-16 15:28               ` Takashi Iwai
2015-10-14 18:20         ` Liam Girdwood
2015-10-16 15:35     ` Richard Fitzgerald
2015-10-16 16:00       ` Takashi Iwai
2015-10-16 16:31         ` Richard Fitzgerald
2015-10-16 17:00           ` Takashi Iwai
2015-10-17 15:54         ` Pierre-Louis Bossart
2015-10-17 16:02           ` Takashi Iwai
2015-10-18  6:41             ` Ricard Wanderlof
2015-10-30  2:57               ` Mark Brown
2015-10-17 16:25           ` Alexander E. Patrakov
2015-10-30  2:50       ` Mark Brown
2015-10-30  2:36     ` Mark Brown
2015-10-30  8:36       ` David Henningsson
2015-10-30  8:53         ` James Cameron
2015-10-30  9:04           ` David Henningsson
2015-11-01  2:45             ` Mark Brown
2015-10-13 14:09 ` 'BATCH flag for USB' and 'ALSA Core Challenges' Takashi Sakamoto
2015-10-13 14:44   ` Alexander E. Patrakov
2015-10-18  3:22     ` Takashi Sakamoto
2015-10-13 16:01   ` Pierre-Louis Bossart
2015-10-14 12:27   ` Liam Girdwood
2015-10-22 17:10 ` [Minutes] ELCE Audio mini conf Mark Brown
2015-10-22 17:14 ` DP hotplug on USB C 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=1445009042.3536.7.camel@rf-debian.wolfsonmicro.main \
    --to=rf@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=david.henningsson@canonical.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=quozl@laptop.org \
    /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