[alsa-devel] Strange bug in .asoundrc ??
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
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
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
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
participants (2)
-
Clemens Ladisch -
Dominique Larchey-Wendling