asihpi: Control naming

asihpi: Control naming

[Eliot Blennerhassett]

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

-- 
Eliot Blennerhassett
AudioScience Inc.

Re: asihpi: Control naming

[Takashi Iwai]

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.
> 

Re: asihpi: Control naming

[Eliot Blennerhassett]

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

Re: asihpi: Control naming

[Takashi Iwai]

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

Re: asihpi: Control naming

[Sebastian H.]

>>> "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

Re: asihpi: Control naming

[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).


Regards,
Clemens

Re: asihpi: Control naming

[Sebastian H.]

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.

Re: asihpi: Control naming

[Raymond Yau]

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.
>
> 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.
>

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

Re: asihpi: Control naming

[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.

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

Re: asihpi: Control naming

[Sebastian H.]

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

Re: asihpi: Control naming

[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' )


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
>
>

Re: asihpi: Control naming

[Sebastian H.]

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

Re: asihpi: Control naming

[Mark Brown]

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.

Re: asihpi: Control naming

[Eliot Blennerhassett]

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
AudioScience Inc.

Re: asihpi: Control naming

[Clemens Ladisch]

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

Re: asihpi: Control naming

[Eliot Blennerhassett]

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"

Re: asihpi: Control naming

[Eliot Blennerhassett]

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
AudioScience Inc.

Re: asihpi: Control naming

[Clemens Ladisch]

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

Re: asihpi: Control naming

[Takashi Iwai]

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

Re: asihpi: Control naming, Irritated Currant edition

[Eliot Blennerhassett]

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

-- 
Eliot Blennerhassett
AudioScience Inc.

Re: asihpi: Control naming

[Takashi Iwai]

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

Re: asihpi: Control naming

[David Henningsson]

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!

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic