[alsa-devel] asihpi: Control naming
Hi all,
I'm struggling with getting the correct names for controls, so that they show up correctly in the Playback or Capture modes of alsamixer
E.g. "PCM 3 Capture Meter" appears in the playback controls?
How is capture vs playback display determined? or to put it another way: What are the rules for creating control names.
Here is a reduced schematic of one of our cards (in reality more channels e.g. 4 physical stereo ins and outs, 12 players, 8 recorders) All players and inputs are mixed to outputs. All inputs and players multiplexed to each capture.
How should all these controls be named?
(1)-[vol]--+ (2)-[vol]--+ [play0]--[vol]--[meter]--[mode]--,-[vol]--+----[vol]-[meter]--[level]--[lineout0] `-[vol]--|-. | | .-[vol]--' | [play1]--[vol]--[meter]--[mode]--'-[vol]----+--[vol]-[meter]--[level]--[lineout1] (1)-[vol]----+ (2)-[vol]----+
[linein0]-[level]-\ \ mux>-[meter]-(1)-,-------|\ [digitalin0]------/ | mux >--[mode]--[meter]--[cap0] | ,../ | | `--|--\ [linein1]-[level]-\ | >--[mode]--[meter]--[cap1] mux>-[meter]-(2)-----'--/ [digitalin1]------/
notes [level] means calibrated reference level setting in dBu [mode] stereo channel modifier + summing junction --|-- wires cross, no join (1) connect from input to matrix mix output
thanks and regards
At Thu, 30 Sep 2010 16:44:14 +1300, Eliot Blennerhassett wrote:
Hi all,
I'm struggling with getting the correct names for controls, so that they show up correctly in the Playback or Capture modes of alsamixer
E.g. "PCM 3 Capture Meter" appears in the playback controls?
How is capture vs playback display determined? or to put it another way: What are the rules for creating control names.
The rule is simple. The control name consists of three parts, base-name, direction, and suffix. The direction is either "Playback" or "Capture", and the suffix is either "Volume" or "Switch". Then the direction and the capture are omitted, and grouped together with other controls with the same base name. (There are a few exceptional cases, but in general the rule above is applied.)
"PCM 3 Capture Meter" is regarded as a playback control since it has an invalid (unknown) suffix. If it's "PCM 3 Meter Capture Volume", in mixer, it'll become "PCM 3 Meter". Also, you can (better to) use an index for each control, so it can be expressed as "PCM Meter" with index 3, too.
Takashi
Here is a reduced schematic of one of our cards (in reality more channels e.g. 4 physical stereo ins and outs, 12 players, 8 recorders) All players and inputs are mixed to outputs. All inputs and players multiplexed to each capture.
How should all these controls be named?
(1)-[vol]--+ (2)-[vol]--+[play0]--[vol]--[meter]--[mode]--,-[vol]--+----[vol]-[meter]--[level]--[lineout0] `-[vol]--|-. | | .-[vol]--' | [play1]--[vol]--[meter]--[mode]--'-[vol]----+--[vol]-[meter]--[level]--[lineout1] (1)-[vol]----+ (2)-[vol]----+
[linein0]-[level]-\ \ mux>-[meter]-(1)-,-------|\ [digitalin0]------/ | mux >--[mode]--[meter]--[cap0] | ,../ | | `--|--\ [linein1]-[level]-\ | >--[mode]--[meter]--[cap1] mux>-[meter]-(2)-----'--/ [digitalin1]------/
notes [level] means calibrated reference level setting in dBu [mode] stereo channel modifier
- summing junction
--|-- wires cross, no join (1) connect from input to matrix mix output
thanks and regards
-- Eliot Blennerhassett AudioScience Inc.
Thanks Takashi,
On 30/09/10 18:46, Takashi Iwai wrote:
At Thu, 30 Sep 2010 16:44:14 +1300, Eliot Blennerhassett wrote:
Hi all,
I'm struggling with getting the correct names for controls, so that they show up correctly in the Playback or Capture modes of alsamixer
E.g. "PCM 3 Capture Meter" appears in the playback controls?
How is capture vs playback display determined? or to put it another way: What are the rules for creating control names.
The rule is simple. The control name consists of three parts, base-name, direction, and suffix. The direction is either "Playback" or "Capture", and the suffix is either "Volume" or "Switch". Then the direction and the capture are omitted, and grouped together with other controls with the same base name. (There are a few exceptional cases, but in general the rule above is applied.)
"PCM 3 Capture Meter" is regarded as a playback control since it has an invalid (unknown) suffix. If it's "PCM 3 Meter Capture Volume",
But it is not a volume, it is a level meter?! We also have controls for tuners, microphones, equalizers, sampleclocks etc. Surely these can't be all "Volume" or "Switch" I'm not sure why the suffix has any bearing on the direction?
in mixer, it'll become "PCM 3 Meter". Also, you can (better to) use an index for each control, so it can be expressed as "PCM Meter" with index 3, too.
We used to have it this way. It makes sense for the controls attached to the single node e.g. player or lineout. However, it is confusing for identifying the volumes between play1 and lineout0?
Without using indices I have (consistent)
PCM 0 Playback Volume PCM 1 Playback Volume PCM 0 to Lineout 0 Playback Volume PCM 0 to Lineout 1 Playback Volume PCM 1 to Lineout 0 Playback Volume PCM 1 to Lineout 1 Playback Volume Lineout 0 Playback Volume Lineout 1 Playback Volume
with indices (maybe) PCM Playback Volume, 0 PCM Playback Volume, 1 PCM 0 to Lineout 0 Playback Volume PCM 0 to Lineout 1 Playback Volume PCM 1 to Lineout 0 Playback Volume PCM 1 to Lineout 1 Playback Volume Lineout Playback Volume, 0 Lineout Playback Volume, 1
Now, if I could have 2 indices, maybe ... PCM to Lineout Playback Volume, 1, 0
Also, on the input multiplexer (route?), the options are Linein 0 Linein 1
rather than Linein, 0 Linein, 1
I.e. the names match, rather than using indices in one place, and distinct names in another
At Fri, 01 Oct 2010 09:23:52 +1300, Eliot Blennerhassett wrote:
Thanks Takashi,
On 30/09/10 18:46, Takashi Iwai wrote:
At Thu, 30 Sep 2010 16:44:14 +1300, Eliot Blennerhassett wrote:
Hi all,
I'm struggling with getting the correct names for controls, so that they show up correctly in the Playback or Capture modes of alsamixer
E.g. "PCM 3 Capture Meter" appears in the playback controls?
How is capture vs playback display determined? or to put it another way: What are the rules for creating control names.
The rule is simple. The control name consists of three parts, base-name, direction, and suffix. The direction is either "Playback" or "Capture", and the suffix is either "Volume" or "Switch". Then the direction and the capture are omitted, and grouped together with other controls with the same base name. (There are a few exceptional cases, but in general the rule above is applied.)
"PCM 3 Capture Meter" is regarded as a playback control since it has an invalid (unknown) suffix. If it's "PCM 3 Meter Capture Volume",
But it is not a volume, it is a level meter?! We also have controls for tuners, microphones, equalizers, sampleclocks etc. Surely these can't be all "Volume" or "Switch" I'm not sure why the suffix has any bearing on the direction?
Actually, this control is handled as a "neutral" control without the directional attribute. alsamixer or else may show it in the playback but also may show in capture, too.
Maybe the mixer element parser can be improved to look for the direction word to determine the additional direction attribute. If one word of either "Playback" or "Capture" is found, we can assume its direction as such.
in mixer, it'll become "PCM 3 Meter". Also, you can (better to) use an index for each control, so it can be expressed as "PCM Meter" with index 3, too.
We used to have it this way. It makes sense for the controls attached to the single node e.g. player or lineout. However, it is confusing for identifying the volumes between play1 and lineout0?
Without using indices I have (consistent)
PCM 0 Playback Volume PCM 1 Playback Volume PCM 0 to Lineout 0 Playback Volume PCM 0 to Lineout 1 Playback Volume PCM 1 to Lineout 0 Playback Volume PCM 1 to Lineout 1 Playback Volume Lineout 0 Playback Volume Lineout 1 Playback Volume
with indices (maybe) PCM Playback Volume, 0 PCM Playback Volume, 1 PCM 0 to Lineout 0 Playback Volume PCM 0 to Lineout 1 Playback Volume PCM 1 to Lineout 0 Playback Volume PCM 1 to Lineout 1 Playback Volume Lineout Playback Volume, 0 Lineout Playback Volume, 1
Now, if I could have 2 indices, maybe ... PCM to Lineout Playback Volume, 1, 0
So, you have matrix volumes. We had discussions how to implement the matrix volumes, and there is actually an infrastructure to handle multi-dimension volume arrays. But, no driver is using the feature, IIRC...
Also, on the input multiplexer (route?), the options are Linein 0 Linein 1
rather than Linein, 0 Linein, 1
I.e. the names match, rather than using indices in one place, and distinct names in another
One (known) remaining problem is the matching between an enum item string to a control (or mixer) with an index number. For example, some HD-audio codecs have multiple mics, and a similar problem appears there.
Takashi
"PCM 3 Capture Meter" is regarded as a playback control since it has an invalid (unknown) suffix. If it's "PCM 3 Meter Capture Volume",
But it is not a volume, it is a level meter?! We also have controls for tuners, microphones, equalizers, sampleclocks etc. Surely these can't be all "Volume" or "Switch" I'm not sure why the suffix has any bearing on the direction?
Actually, this control is handled as a "neutral" control without the directional attribute. alsamixer or else may show it in the playback but also may show in capture, too.
This is interesting. In alsamixer-qt4 I've just stumbled over enum elements for which both snd_mixer_selem_is_enum_playback and snd_mixer_selem_is_enum_capture return 0/false (2.6.32 kernel emu10k1 chip).
May I drop the question in if this state can be considered valid and besides *playback* and *capture* elements there's a third group of *neutral* elements?
(On the other hand switches and volumes are always directed.)
Right now I handle it by dumping a warning message to stdout and puting it into the playback direction element list.
Sebastian
Sebastian H. wrote:
In alsamixer-qt4 I've just stumbled over enum elements for which both snd_mixer_selem_is_enum_playback and snd_mixer_selem_is_enum_capture return 0/false (2.6.32 kernel emu10k1 chip).
May I drop the question in if this state can be considered valid
Yes.
and besides *playback* and *capture* elements there's a third group of *neutral* elements?
Those are elements where the simple mixer code doesn't know the direction (because the driver author didn't put "Playback" or "Capture" into the name).
Regards, Clemens
Am 01.10.2010 09:05, schrieb Clemens Ladisch:
Sebastian H. wrote:
In alsamixer-qt4 I've just stumbled over enum elements for which both snd_mixer_selem_is_enum_playback and snd_mixer_selem_is_enum_capture return 0/false (2.6.32 kernel emu10k1 chip).
May I drop the question in if this state can be considered valid
Yes.
and besides *playback* and *capture* elements there's a third group of *neutral* elements?
Those are elements where the simple mixer code doesn't know the direction (because the driver author didn't put "Playback" or "Capture" into the name).
Ok, but I wonder how to interpret this state in which both functions return zero.
1) There's a bug or uncertainty somewhere in the libs/driver and in a perfekt world this would not happen. It always should be either.
2) This is intentional and the respective element belongs to the group of *general* elements which exists in parallel to the *playback* and the *capture* element groups.
As mentioned alsamixer-qt4 considers 1) and handles it somehow gracefully. I just wonder if that is the correct thing to do in case.
2010/10/1 Sebastian H. vand2@gmx.de
Am 01.10.2010 09:05, schrieb Clemens Ladisch:
Sebastian H. wrote:
In alsamixer-qt4 I've just stumbled over enum elements for which both snd_mixer_selem_is_enum_playback and snd_mixer_selem_is_enum_capture return 0/false (2.6.32 kernel emu10k1 chip).
May I drop the question in if this state can be considered valid
Yes.
and besides *playback* and *capture* elements there's a third group of *neutral* elements?
Those are elements where the simple mixer code doesn't know the direction (because the driver author didn't put "Playback" or "Capture" into the name).
Ok, but I wonder how to interpret this state in which both functions return zero.
- There's a bug or uncertainty somewhere in the libs/driver and
in a perfekt world this would not happen. It always should be either.
- This is intentional and the respective element belongs to the
group of *general* elements which exists in parallel to the *playback* and the *capture* element groups.
As mentioned alsamixer-qt4 considers 1) and handles it somehow gracefully. I just wonder if that is the correct thing to do in case.
But the number of control related to capture is limited
1) Capture Volume 2) Capture Switch 3) Capture Source 4) Input Source 5) Mic Boost 6) ADC attenuation
Most of the other controls are related to playback
Sebastian H. wrote:
Am 01.10.2010 09:05, schrieb Clemens Ladisch:
Those are elements where the simple mixer code doesn't know the direction (because the driver author didn't put "Playback" or "Capture" into the name).
Ok, but I wonder how to interpret this state in which both functions return zero.
There are cases where the playback/capture direction is obvious from the name ("just implement an AI!"), but these can be considered bugs.
In the other cases, the control really doesn't belong to a direction. (Which doesn't prevent many mixers that have two pages from just throwing them in with the playback controls.)
Regards, Clemens
Am 01.10.2010 15:19, schrieb Clemens Ladisch:
Sebastian H. wrote:
Am 01.10.2010 09:05, schrieb Clemens Ladisch:
Those are elements where the simple mixer code doesn't know the direction (because the driver author didn't put "Playback" or "Capture" into the name).
Ok, but I wonder how to interpret this state in which both functions return zero.
There are cases where the playback/capture direction is obvious from the name ("just implement an AI!"), but these can be considered bugs.
Ok, I'll stick to the element name list from Raymond then for an automated detection.
In the other cases, the control really doesn't belong to a direction. (Which doesn't prevent many mixers that have two pages from just throwing them in with the playback controls.)
Bringing up a separate page for rare *general* elements doesn't seem worthwile then and the *playback* page should be fine.
Cheers, Sebastian
2010/10/2 Sebastian H. vand2@gmx.de
Am 01.10.2010 15:19, schrieb Clemens Ladisch:
Sebastian H. wrote:
Am 01.10.2010 09:05, schrieb Clemens Ladisch:
Those are elements where the simple mixer code doesn't know the direction (because the driver author didn't put "Playback" or "Capture" into the name).
Ok, but I wonder how to interpret this state in which both functions return zero.
There are cases where the playback/capture direction is obvious from the name ("just implement an AI!"), but these can be considered bugs.
Ok, I'll stick to the element name list from Raymond then for an automated detection.
I just only mention the keywords in those capture controls in sound card drivers. They may have slightly different name (e.g. 'Mic Boost (+20dB)' , 'Front Mic Boost' )
In simple_none.c , it also defined some keywords for stanard ac97 control too
some of them are used (e.g. "3D Control - Switch" is regarded a pswitch) but "Depth and Rear Depth are regarded as volume )
Simple mixer control '3D Control - Switch',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off] Simple mixer control '3D Control Sigmatel - Depth',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 3 Mono: 0 [0%] Simple mixer control '3D Control Sigmatel - Rear Depth',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 3 Mono: 0 [0%]
They are just 3D effect and have no dB information.
However alsa-python return run-time error when you try to use the function get_volume_range_dB() to find out whether the mixer elem has dB Info or not
In the other cases, the control really doesn't belong to a direction. (Which doesn't prevent many mixers that have two pages from just throwing them in with the playback controls.)
Bringing up a separate page for rare *general* elements doesn't seem worthwile then and the *playback* page should be fine.
Cheers, Sebastian
Am 02.10.2010 06:10, schrieb Raymond Yau:
2010/10/2 Sebastian H. vand2@gmx.de
Am 01.10.2010 15:19, schrieb Clemens Ladisch:
Sebastian H. wrote:
Am 01.10.2010 09:05, schrieb Clemens Ladisch:
Those are elements where the simple mixer code doesn't know the direction (because the driver author didn't put "Playback" or "Capture" into the name).
Ok, but I wonder how to interpret this state in which both functions return zero.
There are cases where the playback/capture direction is obvious from the name ("just implement an AI!"), but these can be considered bugs.
Ok, I'll stick to the element name list from Raymond then for an automated detection.
I just only mention the keywords in those capture controls in sound card drivers. They may have slightly different name (e.g. 'Mic Boost (+20dB)' , 'Front Mic Boost' )
For sure, I won't do an exact match comparison but rather look for occurences of a "Mic" strings or so.
In simple_none.c , it also defined some keywords for stanard ac97 control too
Thanks, I'll have a look into that one.
The whole issue is probably no big deal at all. In the worst case the elements just ends up in the playback page.
some of them are used (e.g. "3D Control - Switch" is regarded a pswitch) but "Depth and Rear Depth are regarded as volume )
Simple mixer control '3D Control - Switch',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off] Simple mixer control '3D Control Sigmatel - Depth',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 3 Mono: 0 [0%] Simple mixer control '3D Control Sigmatel - Rear Depth',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 3 Mono: 0 [0%]
They are just 3D effect and have no dB information.
However alsa-python return run-time error when you try to use the function get_volume_range_dB() to find out whether the mixer elem has dB Info or not
The ambiguity can only appear for enum elements because the following functions allow uncertain return value combinations.
snd_mixer_selem_is_enumerated ( ... ) snd_mixer_selem_is_enum_playback ( ... ) snd_mixer_selem_is_enum_capture ( ... )
Volumes and Switches are always playback and/or capture because they can be detected by direction aware functions.
snd_mixer_selem_has_playback_volume ( ... ) snd_mixer_selem_has_capture_volume ( ... )
snd_mixer_selem_has_playback_switch ( ... ) snd_mixer_selem_has_capture_switch ( ... )
Sebastian
On Thu, Sep 30, 2010 at 10:56:45PM +0200, Takashi Iwai wrote:
So, you have matrix volumes. We had discussions how to implement the matrix volumes, and there is actually an infrastructure to handle multi-dimension volume arrays. But, no driver is using the feature, IIRC...
If there was something working well it'd be very useful for embedded stuff where flexible mixers are very common.
On 01/10/10 09:56, Takashi Iwai wrote:
So, you have matrix volumes. We had discussions how to implement the matrix volumes, and there is actually an infrastructure to handle multi-dimension volume arrays. But, no driver is using the feature, IIRC...
Further on the subject of playback vs capture vs other... Of course we do have controls that are obviously "Playback" or "Capture", however we also have controls that connect PCM out to PCM in i.e. both Playback and Capture are involved,
"PCM0 to PCM1 Playback Capture Volume" .. nooo! "PCM0 to PCM1 Loop Volume" ???
and others that connect linein to lineout ie. neither Capture or Playback involved.
"LineIn2 to LineOut3 Volume" maybe "LineIn2 to LineOut3 Loop Volume" ?
Also, on the input multiplexer (route?), the options are
...
I.e. the names match, rather than using indices in one place, and distinct names in another
One (known) remaining problem is the matching between an enum item string to a control (or mixer) with an index number.
Exactly!
For example, some HD-audio codecs have multiple mics, and a similar problem appears there.
Takashi
Eliot Blennerhassett wrote:
Further on the subject of playback vs capture vs other... Of course we do have controls that are obviously "Playback" or "Capture", however we also have controls that connect PCM out to PCM in i.e. both Playback and Capture are involved,
"PCM0 to PCM1 Playback Capture Volume" .. nooo! "PCM0 to PCM1 Loop Volume" ???
Capture controls affect audio data that is recorded by the computer. Playback controls affect audio data that comes out of the sound card.
With this definition, these controls are clearly capture controls, e.g., "PCM0 to PCM1 Loopback Capture Volume".
and others that connect linein to lineout ie. neither Capture or Playback involved.
"LineIn2 to LineOut3 Volume" maybe "LineIn2 to LineOut3 Loop Volume" ?
Monitoring controls like these are playback controls: "LineIn2 to LineOut3 Monitor Playback Volume"
If your card has so many controls that you need a special mixer application, the exact control names don't matter anyway.
Regards, Clemens
On 05/10/10 20:07, Clemens Ladisch wrote:
Capture controls affect audio data that is recorded by the computer. Playback controls affect audio data that comes out of the sound card.
OK. I think everything fits one of these two.
I find the asymmetry a little odd. (i.e. Capture controls defined by destination of PCM Capture, while Playback controls not defined by source of PCM Playback)
I.e. in reality they are "Capture" and "Output"
On 05/10/10 20:07, Clemens Ladisch wrote:
Capture controls affect audio data that is recorded by the computer. Playback controls affect audio data that comes out of the sound card.
OK. I think everything fits one of these two.
I find the asymmetry a little odd. (i.e. Capture controls defined by destination of PCM Capture, while Playback controls not defined by source of PCM Playback)
I.e. in reality they are "Capture" and "Output"
Eliot Blennerhassett wrote:
On 05/10/10 20:07, Clemens Ladisch wrote:
Capture controls affect audio data that is recorded by the computer. Playback controls affect audio data that comes out of the sound card.
OK. I think everything fits one of these two.
I find the asymmetry a little odd. (i.e. Capture controls defined by destination of PCM Capture, while Playback controls not defined by source of PCM Playback)
In both cases, it's the destination that determines the type.
When it comes to partitioning the controls into two groups according to overall direction, using the destination makes the most sense in practice.
I.e. in reality they are "Capture" and "Output"
Yes, but this naming convention is already there for hysterical raisins.
Regards, Clemens
At Tue, 05 Oct 2010 11:47:12 +0200, Clemens Ladisch wrote:
Eliot Blennerhassett wrote:
On 05/10/10 20:07, Clemens Ladisch wrote:
Capture controls affect audio data that is recorded by the computer. Playback controls affect audio data that comes out of the sound card.
OK. I think everything fits one of these two.
I find the asymmetry a little odd. (i.e. Capture controls defined by destination of PCM Capture, while Playback controls not defined by source of PCM Playback)
In both cases, it's the destination that determines the type.
When it comes to partitioning the controls into two groups according to overall direction, using the destination makes the most sense in practice.
Yes, basically this is a heuristic mapping to the traditional mixer interface. Not all components match properly, indeed. We need either give compromised element names or implement something new...
I.e. in reality they are "Capture" and "Output"
Yes, but this naming convention is already there for hysterical raisins.
Still better than angry grapes :)
Takashi
Thanks for your comments
FYI Here is what I now have for ASI6644 mode 1 (4 player) http://audioscience.com/internet/products/sound_cards/asi664x.htm
I think it conforms, in that Playback or Capture is the second to last word, and the last word is the control type. (?) Of course I'm open to suggestions how to improve further...
numid=1,iface=MIXER,name='Line 0 Capture Level' numid=2,iface=MIXER,name='Line 1 Capture Level' numid=3,iface=MIXER,name='Line 2 Capture Level' numid=4,iface=MIXER,name='Line 3 Capture Level' numid=5,iface=MIXER,name='Digital 0 Capture Format' numid=6,iface=MIXER,name='Digital 0 Capture Status' numid=7,iface=MIXER,name='Digital 1 Capture Format' numid=8,iface=MIXER,name='Digital 1 Capture Status' numid=9,iface=MIXER,name='Digital 2 Capture Format' numid=10,iface=MIXER,name='Digital 2 Capture Status' numid=11,iface=MIXER,name='Digital 3 Capture Format' numid=12,iface=MIXER,name='Digital 3 Capture Status' numid=13,iface=MIXER,name='Clock 0 Capture Format' numid=14,iface=MIXER,name='Clock 0 Capture Status' numid=15,iface=MIXER,name='Line 0 Capture Route' numid=16,iface=MIXER,name='Line 1 Capture Route' numid=17,iface=MIXER,name='Line 2 Capture Route' numid=18,iface=MIXER,name='Line 3 Capture Route' numid=19,iface=MIXER,name='PCM0 Line0 Playback Volume' numid=20,iface=MIXER,name='PCM1 Line0 Playback Volume' numid=21,iface=MIXER,name='PCM2 Line0 Playback Volume' numid=22,iface=MIXER,name='PCM3 Line0 Playback Volume' numid=23,iface=MIXER,name='Line0 Line0 Monitor Playback Volume' numid=24,iface=MIXER,name='Line1 Line0 Monitor Playback Volume' numid=25,iface=MIXER,name='Line2 Line0 Monitor Playback Volume' numid=26,iface=MIXER,name='Line3 Line0 Monitor Playback Volume' numid=27,iface=MIXER,name='Line 0 Playback Volume' numid=28,iface=MIXER,name='PCM0 Line1 Playback Volume' numid=29,iface=MIXER,name='PCM1 Line1 Playback Volume' numid=30,iface=MIXER,name='PCM2 Line1 Playback Volume' numid=31,iface=MIXER,name='PCM3 Line1 Playback Volume' numid=32,iface=MIXER,name='Line0 Line1 Monitor Playback Volume' numid=33,iface=MIXER,name='Line1 Line1 Monitor Playback Volume' numid=34,iface=MIXER,name='Line2 Line1 Monitor Playback Volume' numid=35,iface=MIXER,name='Line3 Line1 Monitor Playback Volume' numid=36,iface=MIXER,name='Line 1 Playback Volume' numid=37,iface=MIXER,name='PCM0 Line2 Playback Volume' numid=38,iface=MIXER,name='PCM1 Line2 Playback Volume' numid=39,iface=MIXER,name='PCM2 Line2 Playback Volume' numid=40,iface=MIXER,name='PCM3 Line2 Playback Volume' numid=41,iface=MIXER,name='Line0 Line2 Monitor Playback Volume' numid=42,iface=MIXER,name='Line1 Line2 Monitor Playback Volume' numid=43,iface=MIXER,name='Line2 Line2 Monitor Playback Volume' numid=44,iface=MIXER,name='Line3 Line2 Monitor Playback Volume' numid=45,iface=MIXER,name='Line 2 Playback Volume' numid=46,iface=MIXER,name='PCM0 Line3 Playback Volume' numid=47,iface=MIXER,name='PCM1 Line3 Playback Volume' numid=48,iface=MIXER,name='PCM2 Line3 Playback Volume' numid=49,iface=MIXER,name='PCM3 Line3 Playback Volume' numid=50,iface=MIXER,name='Line0 Line3 Monitor Playback Volume' numid=51,iface=MIXER,name='Line1 Line3 Monitor Playback Volume' numid=52,iface=MIXER,name='Line2 Line3 Monitor Playback Volume' numid=53,iface=MIXER,name='Line3 Line3 Monitor Playback Volume' numid=54,iface=MIXER,name='Line 3 Playback Volume' numid=55,iface=MIXER,name='PCM 0 Playback Volume' numid=56,iface=MIXER,name='PCM 1 Playback Volume' numid=57,iface=MIXER,name='PCM 2 Playback Volume' numid=58,iface=MIXER,name='PCM 3 Playback Volume' numid=59,iface=MIXER,name='Line 0 Capture Volume' numid=60,iface=MIXER,name='Line 1 Capture Volume' numid=61,iface=MIXER,name='Line 2 Capture Volume' numid=62,iface=MIXER,name='Line 3 Capture Volume' numid=63,iface=MIXER,name='Line 0 Capture Meter' numid=64,iface=MIXER,name='Line 1 Capture Meter' numid=65,iface=MIXER,name='Line 2 Capture Meter' numid=66,iface=MIXER,name='Line 3 Capture Meter' numid=67,iface=MIXER,name='Line 0 Playback Meter' numid=68,iface=MIXER,name='Line 1 Playback Meter' numid=69,iface=MIXER,name='Line 2 Playback Meter' numid=70,iface=MIXER,name='Line 3 Playback Meter' numid=71,iface=MIXER,name='Line0 Line0 Monitor Playback Mode' numid=72,iface=MIXER,name='Line1 Line0 Monitor Playback Mode' numid=73,iface=MIXER,name='Line2 Line0 Monitor Playback Mode' numid=74,iface=MIXER,name='Line3 Line0 Monitor Playback Mode' numid=75,iface=MIXER,name='Line 0 Playback Level' numid=76,iface=MIXER,name='Line 1 Playback Level' numid=77,iface=MIXER,name='Line 2 Playback Level' numid=78,iface=MIXER,name='Line 3 Playback Level' numid=79,iface=MIXER,name='Digital 0 Playback Format' numid=80,iface=MIXER,name='Digital 1 Playback Format' numid=81,iface=MIXER,name='Digital 2 Playback Format' numid=82,iface=MIXER,name='Digital 3 Playback Format' numid=83,iface=MIXER,name='PCM 0 Playback Meter' numid=84,iface=MIXER,name='PCM 1 Playback Meter' numid=85,iface=MIXER,name='PCM 2 Playback Meter' numid=86,iface=MIXER,name='PCM 3 Playback Meter' numid=87,iface=MIXER,name='PCM 0 Playback Mode' numid=88,iface=MIXER,name='PCM 1 Playback Mode' numid=89,iface=MIXER,name='PCM 2 Playback Mode' numid=90,iface=MIXER,name='PCM 3 Playback Mode' numid=91,iface=MIXER,name='PCM 0 Capture Route' numid=92,iface=MIXER,name='PCM 1 Capture Route' numid=93,iface=MIXER,name='PCM 2 Capture Route' numid=94,iface=MIXER,name='PCM 3 Capture Route' numid=95,iface=MIXER,name='PCM 0 Capture Mode' numid=96,iface=MIXER,name='PCM 1 Capture Mode' numid=97,iface=MIXER,name='PCM 2 Capture Mode' numid=98,iface=MIXER,name='PCM 3 Capture Mode' numid=99,iface=MIXER,name='PCM 0 Capture Meter' numid=100,iface=MIXER,name='PCM 1 Capture Meter' numid=101,iface=MIXER,name='PCM 2 Capture Meter' numid=102,iface=MIXER,name='PCM 3 Capture Meter' numid=103,iface=MIXER,name='Clock 0 Capture Source' numid=104,iface=MIXER,name='Clock 0 Capture Localrate' numid=105,iface=MIXER,name='Clock 0 Capture Rate'
And example capture source selector numid=93,iface=MIXER,name='PCM 2 Capture Route' ; type=ENUMERATED,access=rw------,values=1,items=8 ; Item #0 'Line 0' ; Item #1 'Line 1' ; Item #2 'Line 2' ; Item #3 'Line 3' ; Item #4 'PCM 0' ; Item #5 'PCM 1' ; Item #6 'PCM 2' ; Item #7 'PCM 3' : values=2
Input analog/digital select. numid=15,iface=MIXER,name='Line 0 Capture Route' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Line 0' ; Item #1 'Digital 0' : values=0
At Fri, 01 Oct 2010 09:23:52 +1300, Eliot Blennerhassett wrote:
Thanks Takashi,
On 30/09/10 18:46, Takashi Iwai wrote:
At Thu, 30 Sep 2010 16:44:14 +1300, Eliot Blennerhassett wrote:
Hi all,
I'm struggling with getting the correct names for controls, so that they show up correctly in the Playback or Capture modes of alsamixer
E.g. "PCM 3 Capture Meter" appears in the playback controls?
How is capture vs playback display determined? or to put it another way: What are the rules for creating control names.
The rule is simple. The control name consists of three parts, base-name, direction, and suffix. The direction is either "Playback" or "Capture", and the suffix is either "Volume" or "Switch". Then the direction and the capture are omitted, and grouped together with other controls with the same base name. (There are a few exceptional cases, but in general the rule above is applied.)
"PCM 3 Capture Meter" is regarded as a playback control since it has an invalid (unknown) suffix. If it's "PCM 3 Meter Capture Volume",
But it is not a volume, it is a level meter?! We also have controls for tuners, microphones, equalizers, sampleclocks etc. Surely these can't be all "Volume" or "Switch" I'm not sure why the suffix has any bearing on the direction?
Actually, this control is handled as a "neutral" control without the directional attribute. alsamixer or else may show it in the playback but also may show in capture, too.
Maybe the mixer element parser can be improved to look for the direction word to determine the additional direction attribute. If one word of either "Playback" or "Capture" is found, we can assume its direction as such.
in mixer, it'll become "PCM 3 Meter". Also, you can (better to) use an index for each control, so it can be expressed as "PCM Meter" with index 3, too.
We used to have it this way. It makes sense for the controls attached to the single node e.g. player or lineout. However, it is confusing for identifying the volumes between play1 and lineout0?
Without using indices I have (consistent)
PCM 0 Playback Volume PCM 1 Playback Volume PCM 0 to Lineout 0 Playback Volume PCM 0 to Lineout 1 Playback Volume PCM 1 to Lineout 0 Playback Volume PCM 1 to Lineout 1 Playback Volume Lineout 0 Playback Volume Lineout 1 Playback Volume
with indices (maybe) PCM Playback Volume, 0 PCM Playback Volume, 1 PCM 0 to Lineout 0 Playback Volume PCM 0 to Lineout 1 Playback Volume PCM 1 to Lineout 0 Playback Volume PCM 1 to Lineout 1 Playback Volume Lineout Playback Volume, 0 Lineout Playback Volume, 1
Now, if I could have 2 indices, maybe ... PCM to Lineout Playback Volume, 1, 0
So, you have matrix volumes. We had discussions how to implement the matrix volumes, and there is actually an infrastructure to handle multi-dimension volume arrays. But, no driver is using the feature, IIRC...
Also, on the input multiplexer (route?), the options are Linein 0 Linein 1
rather than Linein, 0 Linein, 1
I.e. the names match, rather than using indices in one place, and distinct names in another
One (known) remaining problem is the matching between an enum item string to a control (or mixer) with an index number. For example, some HD-audio codecs have multiple mics, and a similar problem appears there.
Takashi
On 2010-09-30 05:44, Eliot Blennerhassett wrote:
Hi all,
I'm struggling with getting the correct names for controls, so that they show up correctly in the Playback or Capture modes of alsamixer
E.g. "PCM 3 Capture Meter" appears in the playback controls?
How is capture vs playback display determined? or to put it another way: What are the rules for creating control names.
In addition to Takashi's comment, please consider either making your control names compliant with PulseAudio (see earlier post on "alsamixertest" for more information), or make a PulseAudio mixer profile for your card. (At least until UCM is finished enough.)
Thanks!
participants (8)
-
Clemens Ladisch -
David Henningsson -
Eliot Blennerhassett -
Eliot Blennerhassett -
Mark Brown -
Raymond Yau -
Sebastian H. -
Takashi Iwai