From: Lennart Poettering <mznyfn@0pointer.de>
To: alsa-devel@alsa-project.org
Subject: Re: Standard mixer control names
Date: Mon, 23 Feb 2009 17:47:00 +0100 [thread overview]
Message-ID: <20090223164700.GD22083@tango.0pointer.de> (raw)
In-Reply-To: <s5hzlgd34c3.wl%tiwai@suse.de>
On Mon, 23.02.09 10:11, Takashi Iwai (tiwai@suse.de) wrote:
> > ALSA is making that very hard to implement something like this because
> > every driver seems to wrap input/output selection differently.
> >
> > On one card I have only has a couple of cswitches
> > (snd-es1371). The same one has an enum "Mic Select". Another card has
> > an enum "Input Source", but no cswitches (a HDA chip). The
> > "ControlNames.txt" file in the kernel seems to suggest that there is an
> > element "Capture Source".
>
> That's because "Capture Source" can't work for multiple (sub)devices
> with the mixer abstraction of alsa-lib, per design.
> "Input Source" was born as a workaround (still found in many places
> in the driver code). Maybe we should update ControlNames.txt as well.
>
> > For playback it seems that some cards have a a headphone switch, and
> > others a headphone slider (which i guess makes sense).
> >
> > Now, the question, how should I implement this?
> >
> > For playback the handling is easy as long as there is only one element
> > to deal with, but what about capture? One option would be to simply
> > go by cswitch and nothing else. Or go by "Input Source" and nothing
> > else. Or combine some form. Now I'd of course prefer if the drivers
> > get fixed to use a single element naming scheme only. Is there any
> > chance to get that? And which one would that be?
>
> I rarely believe this will be ever "fixed" in the driver side
> completely. We may improve a bit, but not the whole stuff.
> It's no good idea to have a restriction in the driver code because
> the control API is just for generic purpose, not only about mixers.
> And, many embedded devices love to have specific unique control names
> just for their purpose...
Hmm, so this won't get fixed.
>From an application pov, how am I supposed to use the current
abstraction? What algorithm should I then pick for PulseAudio? How
should I compile the list of possible outputs and inputs? And if an
item is selected from that list, how am I supposed to activate the
entry?
For inputs: should I simply compile a list of all elements that have a
cswitch plus all items from "Mic Select" plus all items from "Input
Source"? And if an item is selected the logic would be like this: if a
cswitch is selected we simply activate it, deactivating all others. If
an item from "Mic Select" is selected we activate it in the enum and
set the cswitch for "Mic" if there is any. And if an item from "Input
Source" is seleced we activate it in the enum and set the cswitch for
"Capture" if there is any. And we ignore "Capture Source". Is that a
good idea?
For outputs: If there is a Headphone element we assume we can use the
"Master" and "Headphone" elements to switch between "Line-Out" and
"Headphone". Is that assumption correct?
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
next prev parent reply other threads:[~2009-02-23 16:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-21 23:36 Standard mixer control names Lennart Poettering
2009-02-22 12:00 ` Liam Girdwood
2009-02-22 12:56 ` Mark Brown
2009-02-22 15:19 ` Liam Girdwood
2009-02-23 9:11 ` Takashi Iwai
2009-02-23 16:47 ` Lennart Poettering [this message]
2009-02-24 11:19 ` Takashi Iwai
2009-02-24 12:05 ` Pavel Hofman
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=20090223164700.GD22083@tango.0pointer.de \
--to=mznyfn@0pointer.de \
--cc=alsa-devel@alsa-project.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