[alsa-devel] Standard mixer control names
Heya!
I'd like to add functionality to PulseAudio to allow a simplified selection of capture input (i.e. "Mic", "Line-In", ...) and playback outputs ("Headphones", "Line-Out", ...) for ALSA cards. By "simplified" I mean that only one input and output shall be active at a time. Also, some more nonsense items shall be filtered out (i.e. recording from "Phone"). Hence, basically I want to compile a list of available and whitelisted inputs and outputs and allow the user to select exactly one from each.
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".
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?
Lennart
On Sun, 2009-02-22 at 00:36 +0100, Lennart Poettering wrote:
Heya!
I'd like to add functionality to PulseAudio to allow a simplified selection of capture input (i.e. "Mic", "Line-In", ...) and playback outputs ("Headphones", "Line-Out", ...) for ALSA cards. By "simplified" I mean that only one input and output shall be active at a time. Also, some more nonsense items shall be filtered out (i.e. recording from "Phone"). Hence, basically I want to compile a list of available and whitelisted inputs and outputs and allow the user to select exactly one from each.
Fwiw, I may have mentioned at the FOSDEM beer party that this feature was on the to todo list for the hardware use case or scenario manager. Although being a beer party we may not remember discussing....
http://www.slimlogic.co.uk/?p=40
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?
This would likely be quite time consuming wrt to embedded drivers due to the complex audio hardware requirements of modern mobile phones. There are numerous hardware routes with different inputs and outputs and they are used in different combinations depending on use case.
I think it's probably quite reasonable to do this for most PC sound cards as they are often simpler in terms inputs/outputs.
Liam
On Sun, Feb 22, 2009 at 12:00:12PM +0000, Liam Girdwood wrote:
On Sun, 2009-02-22 at 00:36 +0100, Lennart Poettering wrote:
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?
This would likely be quite time consuming wrt to embedded drivers due to the complex audio hardware requirements of modern mobile phones. There are numerous hardware routes with different inputs and outputs and they are used in different combinations depending on use case.
I'd worry that it'd also have a negative impact on usability. People setting up scenarios and doing other device specific configuration often find it difficult to relate the controls visible in ALSA to the chip datasheet and keeping the names for the controls as close as possible to the datasheet helps deal with that quite a bit. If a standard naming were layered on top by something like the scenario manager this wouldn't be such an issue since device specific names would still be there and controls could be remapped dynamically depending on use case.
What would probably also help would be exposing information about the audio paths and how they relate to controls to user space but that doesn't look likely to happen any time soon.
On Sun, 2009-02-22 at 12:56 +0000, Mark Brown wrote:
On Sun, Feb 22, 2009 at 12:00:12PM +0000, Liam Girdwood wrote:
On Sun, 2009-02-22 at 00:36 +0100, Lennart Poettering wrote:
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?
This would likely be quite time consuming wrt to embedded drivers due to the complex audio hardware requirements of modern mobile phones. There are numerous hardware routes with different inputs and outputs and they are used in different combinations depending on use case.
I'd worry that it'd also have a negative impact on usability. People setting up scenarios and doing other device specific configuration often find it difficult to relate the controls visible in ALSA to the chip datasheet and keeping the names for the controls as close as possible to the datasheet helps deal with that quite a bit. If a standard naming were layered on top by something like the scenario manager this wouldn't be such an issue since device specific names would still be there and controls could be remapped dynamically depending on use case.
Standard naming just got added to the scenario manager todo list ! It's really just an extension of the control aliasing we talked about earlier.
Liam
At Sun, 22 Feb 2009 00:36:30 +0100, Lennart Poettering wrote:
Heya!
I'd like to add functionality to PulseAudio to allow a simplified selection of capture input (i.e. "Mic", "Line-In", ...) and playback outputs ("Headphones", "Line-Out", ...) for ALSA cards. By "simplified" I mean that only one input and output shall be active at a time. Also, some more nonsense items shall be filtered out (i.e. recording from "Phone"). Hence, basically I want to compile a list of available and whitelisted inputs and outputs and allow the user to select exactly one from each.
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...
Takashi
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
At Mon, 23 Feb 2009 17:47:00 +0100, Lennart Poettering wrote:
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?
I feel we need another meta data to manage / group the mixer elements. It'll be likely based on the per-driver database, or implemented as a module. We have already a framework for mixer module, so it's feasible. Where it's the best choice is another question, though.
But, as now, it's still a vaporware. So, let's assume to solve in PA.
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?
In alsa-lib mixer abstraction, there is no "Capture Source" indeed. It's always expanded to individual cswitches. "Input Source" is never cswitches, OTOH. So they are basically exclusive.
The "Capture Volume" and "Capture Switch" are basically independent from the sources. They are a kind of "master" contorl for inputs.
Also, for inputs, there are also some exceptional mixer elements such as "Mic Boost". They may work both inputs & outputs, though.
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?
At least, "Headphone" control only affects the headphone output. Ditto for "Speaker". It's just for speaker output.
But, whether "Master" controls both HP and line-out depends on the driver (rather codec chip). It sucks, but because of a long history background...
Takashi
Takashi Iwai wrote:
I feel we need another meta data to manage / group the mixer elements. It'll be likely based on the per-driver database, or implemented as a module. We have already a framework for mixer module, so it's feasible. Where it's the best choice is another question, though.
But, as now, it's still a vaporware. So, let's assume to solve in PA.
Great to hear about the planned progress in this area. Many cards define rather unintuitive but important mixer controls. Perhaps somehow we could provide control elements with optional textual descriptions. If it was somewhere in alsa-lib configs, it would even allow for translation via locales. GUI mixers could display the (localized) descriptions in many creative ways.
Pavel.
participants (5)
-
Lennart Poettering -
Liam Girdwood -
Mark Brown -
Pavel Hofman -
Takashi Iwai