All of lore.kernel.org
 help / color / mirror / Atom feed
* Strange bug in .asoundrc ??
@ 2007-11-19 11:06 Dominique Larchey-Wendling
  2007-11-19 14:20 ` Clemens Ladisch
  0 siblings, 1 reply; 4+ messages in thread
From: Dominique Larchey-Wendling @ 2007-11-19 11:06 UTC (permalink / raw)
  To: Alsa-devel

Dear all,

It seems that neither the current ctl.hw function nor the following
simplified function ctl.!hw work correctly when the argument CARD is
given to the function. It works however when no argument is given as the
following test examples show it. It have alsa-lib version
1.0.14-0.4.rc3.fc7 installed on FC7.

Is this a know bug of alsa-lib ? It is strange because this bug does not
   show up with pcm.hw for example.

--- .asoundrc ------------------------

ctl.!hw {
	@args [ CARD ]
	@args.CARD {
		type string
		default "0"
	}
	type hw
	card $CARD
}

ctl.rha  "hw"
ctl.tata "hw:0"
ctl.toto "hw:1"

------------------------------------------------


rha % amixer -D rha info
Card rha 'Intel'/'HDA Intel at 0xfebfc000 irq 16'
    Mixer name    : 'SigmaTel STAC9200'
    Components    : 'HDA:83847690'
    Controls      : 6
    Simple ctrls  : 4

rha % amixer -D tata info
ALSA lib control.c:781:(snd_ctl_open_conf) Invalid type for CTL tata
definition
amixer: Control device tata open error: Invalid argument

rha % amixer -D toto info
ALSA lib control.c:781:(snd_ctl_open_conf) Invalid type for CTL toto
definition
amixer: Control device toto open error: Invalid argument

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Strange bug in .asoundrc ??
  2007-11-19 11:06 Strange bug in .asoundrc ?? Dominique Larchey-Wendling
@ 2007-11-19 14:20 ` Clemens Ladisch
  2007-11-19 15:06   ` Dominique Larchey-Wendling
  0 siblings, 1 reply; 4+ messages in thread
From: Clemens Ladisch @ 2007-11-19 14:20 UTC (permalink / raw)
  To: Dominique Larchey-Wendling, Alsa-devel

Dominique Larchey-Wendling wrote:
> It seems that neither the current ctl.hw function nor the following
> simplified function ctl.!hw work correctly when the argument CARD is
> given to the function. It works however when no argument is given as the
> following test examples show it.
> 
> Is this a know bug of alsa-lib ? It is strange because this bug does not
>    show up with pcm.hw for example.
> 
> ctl.rha  "hw"
> ctl.tata "hw:0"
> 
> rha % amixer -D rha info
> Card rha 'Intel'/'HDA Intel at 0xfebfc000 irq 16'
> ...
> rha % amixer -D tata info
> ALSA lib control.c:781:(snd_ctl_open_conf) Invalid type for CTL tata definition

Using a string with parameters works only with PCM devices; the code in
alsa-lib that handles other device types doesn't bother to try to look
the string up.

It appears this behaviour is by design.

To get your own definition, write something like this:
  ctl.tata { type hw card 0 }


Regards,
Clemens

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Strange bug in .asoundrc ??
  2007-11-19 14:20 ` Clemens Ladisch
@ 2007-11-19 15:06   ` Dominique Larchey-Wendling
  2007-11-19 15:43     ` Clemens Ladisch
  0 siblings, 1 reply; 4+ messages in thread
From: Dominique Larchey-Wendling @ 2007-11-19 15:06 UTC (permalink / raw)
  To: Clemens Ladisch; +Cc: Alsa-devel

 > It appears this behaviour is by design.

Ok so this is not a bug but a feature ;-)
However, it is not specified in the doc that alsa-lib makes a semantic 
distinction between the types of objects in the alisp language.

What is strange is that the same function is called in alsa-lib to
expand hw:0 whether it is prefixed with "ctl" or "pcm" :

snd_config_search_definition(root, "ctl", name, &ctl_conf);

and

snd_config_search_definition(root, "pcm", name, &pcm_conf);

----------

Of course there is the workaround

ctl.tata { type hw card 0 }

but my question was more why is it designed this way ? Perhaps I do not
see some tricky problem but it should not be difficult to modify 
alsa-lib so that the behavior is coherent between the "ctl" and "pcm" 
contexts ?

Regards,

Dominique

> Dominique Larchey-Wendling wrote:
>> It seems that neither the current ctl.hw function nor the following
>> simplified function ctl.!hw work correctly when the argument CARD is
>> given to the function. It works however when no argument is given as the
>> following test examples show it.
>>
>> Is this a know bug of alsa-lib ? It is strange because this bug does not
>>    show up with pcm.hw for example.
>>
>> ctl.rha  "hw"
>> ctl.tata "hw:0"
>>
>> rha % amixer -D rha info
>> Card rha 'Intel'/'HDA Intel at 0xfebfc000 irq 16'
>> ...
>> rha % amixer -D tata info
>> ALSA lib control.c:781:(snd_ctl_open_conf) Invalid type for CTL tata definition
> 
> Using a string with parameters works only with PCM devices; the code in
> alsa-lib that handles other device types doesn't bother to try to look
> the string up.
> 
> It appears this behaviour is by design.
> 
> To get your own definition, write something like this:
>   ctl.tata { type hw card 0 }
> 
> 
> Regards,
> Clemens

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Strange bug in .asoundrc ??
  2007-11-19 15:06   ` Dominique Larchey-Wendling
@ 2007-11-19 15:43     ` Clemens Ladisch
  0 siblings, 0 replies; 4+ messages in thread
From: Clemens Ladisch @ 2007-11-19 15:43 UTC (permalink / raw)
  To: Dominique Larchey-Wendling; +Cc: Alsa-devel

Dominique Larchey-Wendling wrote:
>  > It appears this behaviour is by design.
> 
> Ok so this is not a bug but a feature ;-)
> However, it is not specified in the doc that alsa-lib makes a semantic 
> distinction between the types of objects

If a somewhat complete documentation existed, it would certainly mention
this.

> in the alisp language.

The configuration language is not alisp.

> What is strange is that the same function is called in alsa-lib to
> expand hw:0 whether it is prefixed with "ctl" or "pcm" :
> 
> snd_config_search_definition(root, "ctl", name, &ctl_conf);
> 
> and
> 
> snd_config_search_definition(root, "pcm", name, &pcm_conf);

This function is called with a string like "tata" and returns the string
"hw:0" (it would return the compound node {type hw card 0} when it would
be called with "hw:0").

In the PCM code, it is the following recursive call of
snd_pcm_open_noupdate() that causes the extra lookup to happen.

> but my question was more why is it designed this way ?

Well, "designed" may be too strong a word; it implies that somebody
actually thought about it.  :-)

I'd guess that this functionality was never needed for any device type
except PCM because there aren't any plugins that could be used in place
of "hw".


Regards,
Clemens

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-11-19 15:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-19 11:06 Strange bug in .asoundrc ?? Dominique Larchey-Wendling
2007-11-19 14:20 ` Clemens Ladisch
2007-11-19 15:06   ` Dominique Larchey-Wendling
2007-11-19 15:43     ` Clemens Ladisch

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.