[alsa-devel] alsa-lib functions reporting conflicting information with two sound cards
Hey guys
I am rather confused that I am getting crossed information when calling snd_names_list and snd_pcm_info in order to gather information about pcm devices.
I have two sound cards in my development pc: RME Digi 96/8 PCI and an onboard VIA 8237.
I'm trying to develop a piece of code that generates a list of objects containing pcm device information, including information on virtual devices.
My current idea is to use snd_names_list() to get a full list of devices, and then get information about them by opening each device and querying.
The bizzare thing is that snd_names_list() is returning comments that do not agree with the associated device.
For example, given the following code:
#include <alsa/asoundlib.h> int main() { snd_devname_t * list; snd_config_update();
snd_names_list("pcm", &list); while (list) { if (!strcmp(list->name, "hw:0,0")) { printf("hw:0,0 comment: %s\n", list->comment); break; } list = list->next; } snd_names_list_free(list);
snd_pcm_t * pcm; snd_pcm_info_t * pcm_info; snd_pcm_info_malloc(&pcm_info); snd_pcm_open(&pcm, "hw:0,0", SND_PCM_STREAM_PLAYBACK, 0); snd_pcm_info(pcm, pcm_info); printf("id: %s\n", snd_pcm_info_get_id(pcm_info)); snd_pcm_close(pcm); snd_pcm_info_free(pcm_info);
return 0; }
The result on my pc is: hw:0,0 comment: Physical Device - VIA 8237 (Duplex) id: Digi96 IEC958
So I'm apparently doing something very wrong here.
I would like to ask if there is an easier and more reliable way of getting a list of pcm devices and querying them, and if not, what I am doing wrong here?
Regards
Nicholas
On 4/19/07, nick smethurst nick.smethurst@gmail.com wrote:
Hey guys
I am rather confused that I am getting crossed information when calling snd_names_list and snd_pcm_info in order to gather information about pcm devices.
I have two sound cards in my development pc: RME Digi 96/8 PCI and an onboard VIA 8237.
I'm trying to develop a piece of code that generates a list of objects containing pcm device information, including information on virtual devices.
I think ALSA's new device enumeration API can do this for you. See the implementation of aplay -l (or -L, don't remember which) in the latest alsa-utils.
Lee
Lee Revell wrote:
On 4/19/07, nick smethurst nick.smethurst@gmail.com wrote:
I am rather confused that I am getting crossed information when calling snd_names_list and snd_pcm_info in order to gather information about pcm devices.
I think ALSA's new device enumeration API can do this for you. See the implementation of aplay -l (or -L, don't remember which) in the latest alsa-utils.
Ok, thanks for the hint (no pun intended :) ).
I see that the pcm_list() function has changed in aplay. The new hints API looks good.
However, I note that snd_device_name_hint() does not return hw, plughw, plug, dmix, etc. Are these obtained elsewhere? I would like to build a complete list of all available devices in order to allow the user to select them from a dropdown list in a GUI.
Nicholas
On 4/19/07, Nicholas Smethurst smethurst@gmail.com wrote:
Lee Revell wrote:
On 4/19/07, nick smethurst nick.smethurst@gmail.com wrote:
I am rather confused that I am getting crossed information when calling snd_names_list and snd_pcm_info in order to gather information about pcm devices.
I think ALSA's new device enumeration API can do this for you. See the implementation of aplay -l (or -L, don't remember which) in the latest alsa-utils.
Ok, thanks for the hint (no pun intended :) ).
I see that the pcm_list() function has changed in aplay. The new hints API looks good.
However, I note that snd_device_name_hint() does not return hw, plughw, plug, dmix, etc. Are these obtained elsewhere? I would like to build a complete list of all available devices in order to allow the user to select them from a dropdown list in a GUI.
Not sure, I don't have access to a machine with a modern ALSA now but the new aplay list function definitely lists those. I do know that yours is exactly the problem it was designed to solve.
Lee
At Thu, 19 Apr 2007 20:08:21 +0200, Nicholas Smethurst wrote:
Lee Revell wrote:
On 4/19/07, nick smethurst nick.smethurst@gmail.com wrote:
I am rather confused that I am getting crossed information when calling snd_names_list and snd_pcm_info in order to gather information about pcm devices.
I think ALSA's new device enumeration API can do this for you. See the implementation of aplay -l (or -L, don't remember which) in the latest alsa-utils.
Ok, thanks for the hint (no pun intended :) ).
I see that the pcm_list() function has changed in aplay. The new hints API looks good.
However, I note that snd_device_name_hint() does not return hw, plughw, plug, dmix, etc. Are these obtained elsewhere? I would like to build a complete list of all available devices in order to allow the user to select them from a dropdown list in a GUI.
They are not shown unless you give the device description explicitly or set a global flag. See the description of snd_device_name_hint() function.
Takashi
Takashi wrote:
At Thu, 19 Apr 2007 20:08:21 +0200, Nicholas Smethurst wrote:
However, I note that snd_device_name_hint() does not return hw, plughw, plug, dmix, etc. Are these obtained elsewhere? I would like to build a complete list of all available devices in order to allow the user to select them from a dropdown list in a GUI.
They are not shown unless you give the device description explicitly or set a global flag. See the description of snd_device_name_hint() function.
Well I tried to understand how to do the two things you mention, but am still stuck..
In namehint.c, I note that the snd_device_name_hint() function has the following code:
if (strcmp(iface, "card") == 0) list.iface = SND_CTL_ELEM_IFACE_CARD; else if (strcmp(iface, "pcm") == 0) list.iface = SND_CTL_ELEM_IFACE_PCM; else if (strcmp(iface, "rawmidi") == 0) list.iface = SND_CTL_ELEM_IFACE_RAWMIDI; else if (strcmp(iface, "timer") == 0) list.iface = SND_CTL_ELEM_IFACE_TIMER; else if (strcmp(iface, "seq") == 0) list.iface = SND_CTL_ELEM_IFACE_SEQUENCER; else if (strcmp(iface, "hwdep") == 0) list.iface = SND_CTL_ELEM_IFACE_HWDEP; else return -EINVAL;
which thus gives possible interface strings of "card", "pcm", "rawmidi", "timer", "seq", and "hwdep". I concluded from this that the only way to get the default devices is to set the global variable.
I thus tried doing the following in a small test app:
snd_config_t * conf; int show_all; snd_config_update(); if (snd_config_search(snd_config, "defaults.namehint.showall", &conf) >= 0) { show_all = snd_config_get_bool(conf); if (show_all < 1) { snd_config_set_integer(conf, 1); } } else { // Create node. ... }
but this doesn't work.. I am apparently doing something wrong since the global configuration is not changed with my code.
Is it possible to change global variables from a user application? Or is it currently necessary to manually edit the alsa.conf file (as root) in order to modify "defaults.namehint.showall" to allow applications to see all devices?
I wish to obtain a full list of available devices in a user application without running as root and without insisting that the user manually edits configuration files that he doesn't understand.
Is this possible? If not, can we work towards implementing such functionality?
Nicholas
On Fri, 11 May 2007, Nicholas Smethurst wrote:
Is this possible? If not, can we work towards implementing such functionality?
User or system software manager should create a configuration which is suitable for users. You're trying to overload the user settings. Why? Use information returned without any hacks in your application (you may eventually describe in documentation, how users can get more devices).
Jaroslav
----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
Jaroslav Kysela wrote:
On Fri, 11 May 2007, Nicholas Smethurst wrote:
Is this possible? If not, can we work towards implementing such functionality?
User or system software manager should create a configuration which is suitable for users. You're trying to overload the user settings. Why? Use information returned without any hacks in your application (you may eventually describe in documentation, how users can get more devices).
I'm not sure I understand.
I found the global variable "defaults.namehint.showall" in alsa.conf, which lives in /usr/share/alsa/. This is not the sort of place a user should be fiddling with. Users don't have the knowledge (or the desire) to manually change system configuration files.. us developers should be able to do all we need to do via alsa-lib.
I understand that you are suggesting that user applications list what ever snd_device_name_hint() returns, and then describe in the application documentation that if the user does not see devices such as hw, they should manually edit a system configuration file.
Or do you mean that a user application can create its own global configuration? I didn't know that that was possible.
If this is the case, can I copy the default configuration and turn on "defaults.namehint.showall" in order that my user application can call have the full list from snd_device_name_hint()?
Nicholas
On Fri, 11 May 2007, Nicholas Smethurst wrote:
Jaroslav Kysela wrote:
On Fri, 11 May 2007, Nicholas Smethurst wrote:
Is this possible? If not, can we work towards implementing such functionality?
User or system software manager should create a configuration which is suitable for users. You're trying to overload the user settings. Why? Use information returned without any hacks in your application (you may eventually describe in documentation, how users can get more devices).
I'm not sure I understand.
I found the global variable "defaults.namehint.showall" in alsa.conf, which lives in /usr/share/alsa/. This is not the sort of place a user should be fiddling with. Users don't have the knowledge (or the desire) to manually change system configuration files.. us developers should be able to do all we need to do via alsa-lib.
Note that's why many distributions exist and make configuration more user friendly. We decided to have minimal set of offered devices by default. If any distribution feels it's better to give a full list, it's also possible by modifying the global configuration file.
I understand that you are suggesting that user applications list what ever snd_device_name_hint() returns, and then describe in the application documentation that if the user does not see devices such as hw, they should manually edit a system configuration file.
Yes (but files in share tree should not be touched - you may override config via system configuration in /etc/asound.conf or user specific ~/.asoundrc).
Or do you mean that a user application can create its own global configuration? I didn't know that that was possible.
If this is the case, can I copy the default configuration and turn on "defaults.namehint.showall" in order that my user application can call have the full list from snd_device_name_hint()?
Again, why this hack? Why your application should behave differently than others?
Anyway, you may specify a path to own alsa.conf file via ALSA_CONFIG_PATH environment variable. But if you feel in this way, it's far better to modify user's ~/.asoundrc file in my eyes (don't forget to tell user that you are doing something with the configuration, or ask user at first).
Jaroslav
----- Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs
At Fri, 11 May 2007 13:05:36 +0200, Nicholas Smethurst wrote:
Jaroslav Kysela wrote:
On Fri, 11 May 2007, Nicholas Smethurst wrote:
Is this possible? If not, can we work towards implementing such functionality?
User or system software manager should create a configuration which is suitable for users. You're trying to overload the user settings. Why? Use information returned without any hacks in your application (you may eventually describe in documentation, how users can get more devices).
I'm not sure I understand.
I found the global variable "defaults.namehint.showall" in alsa.conf, which lives in /usr/share/alsa/. This is not the sort of place a user should be fiddling with. Users don't have the knowledge (or the desire) to manually change system configuration files.. us developers should be able to do all we need to do via alsa-lib.
You can override the values easily in user configuration, e.g. by adding the following line to ~/.asoundrc:
defaults.namehist.showall on
To force to override even the variable type, you can add '!' modifier,
defaults.namehist.!showall 1
Takashi
Takashi Iwai wrote:
You can override the values easily in user configuration, e.g. by adding the following line to ~/.asoundrc:
defaults.namehist.showall on
To force to override even the variable type, you can add '!' modifier,
defaults.namehist.!showall 1
So global variables found in alsa.conf can be overridden in ~/.asoundrc.. I didn't realise this either..
Thanks for the advice.
Nicholas
Takashi Iwai wrote:
You can override the values easily in user configuration, e.g. by adding the following line to ~/.asoundrc:
defaults.namehist.showall on
To force to override even the variable type, you can add '!' modifier,
defaults.namehist.!showall 1
Well I tried doing both of the above in ~/.asoundrc, but I'm still not getting any listing of the pcm hw or plughw devices, or any plugins.
The only thing that changes is the addition the following when calling the hints function with "hwdep":
hw:CARD=PAD RME Digi96/8 PAD
hw:CARD=UART MPU-401 UART
hw:CARD=V8237 VIA 8237
I'm not sure what hwdep means exactly.. Are these also pcm devices?
Here's my test application.. Is there anything wrong here?
#include <alsa/asoundlib.h> #include <iostream>
int main() { size_t start, end; std::string desc; void ** hints, ** str_c; char * name_c, * desc_c; int index = 0; const char * ifaces[] = { "card", "pcm", "rawmidi", "timer", "seq", "hwdep", 0 };
snd_config_update();
while (ifaces[index]) { std::cout << "---- Trying "" << ifaces[index] << "" ----\n\n"; if (snd_device_name_hint(-1, ifaces[index], &hints) < 0) { std::cerr << "hint failed on "" << ifaces[index] << ""\n\n"; ++index; continue; }
str_c = hints; while (*str_c) { name_c = snd_device_name_get_hint(*str_c, "NAME"); desc_c = snd_device_name_get_hint(*str_c, "DESC");
std::cout << name_c << "\n"; start = 0; desc = desc_c; do { end = desc.find("\n", start); std::cout << " " << desc.substr(start, end - start) << "\n"; start = end + 1; } while (end != std::string::npos); std::cout << "\n"; free(name_c); free(desc_c); ++str_c; } snd_device_name_free_hint(hints); ++index; } return 0; }
My system has two soundcards: an RME Digi96/8 PAD and an onboard VIA. The RME has two devices, and the VIA four.
The result of the test application with showall set to on is the following:
---- Trying "card" ----
hint failed on "card"
---- Trying "pcm" ----
default:CARD=PAD RME Digi96/8 PAD, Digi96 IEC958 Default Audio Device
null Discard all samples (playback) or generate zero samples (capture)
default:CARD=UART MPU-401 UART Default Audio Device
default:CARD=V8237 VIA 8237, VIA 8237 Default Audio Device
front:CARD=V8237,DEV=0 VIA 8237, VIA 8237 Front speakers
surround40:CARD=V8237,DEV=0 VIA 8237, VIA 8237 4.0 Surround output to Front and Rear speakers
surround41:CARD=V8237,DEV=0 VIA 8237, VIA 8237 4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=V8237,DEV=0 VIA 8237, VIA 8237 5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=V8237,DEV=0 VIA 8237, VIA 8237 5.1 Surround output to Front, Center, Rear and Subwoofer speakers
iec958:CARD=V8237,DEV=0 VIA 8237, VIA 8237 IEC958 (S/PDIF) Digital Audio Output
---- Trying "rawmidi" ----
hw:CARD=PAD RME Digi96/8 PAD Direct rawmidi driver device
hw:CARD=UART,DEV=0 MPU-401 UART, MPU-401 UART MIDI Direct rawmidi driver device
hw:CARD=V8237 VIA 8237 Direct rawmidi driver device
---- Trying "timer" ----
---- Trying "seq" ----
---- Trying "hwdep" ----
hw:CARD=PAD RME Digi96/8 PAD
hw:CARD=UART MPU-401 UART
hw:CARD=V8237 VIA 8237
At Mon, 14 May 2007 10:36:48 +0200, Nicholas Smethurst wrote:
Takashi Iwai wrote:
You can override the values easily in user configuration, e.g. by adding the following line to ~/.asoundrc:
defaults.namehist.showall on
To force to override even the variable type, you can add '!' modifier,
defaults.namehist.!showall 1
Well I tried doing both of the above in ~/.asoundrc, but I'm still not getting any listing of the pcm hw or plughw devices, or any plugins.
A typo of "namehint", sorry.
Takashi
Takashi Iwai wrote:
At Mon, 14 May 2007 10:36:48 +0200, Nicholas Smethurst wrote:
Takashi Iwai wrote:
You can override the values easily in user configuration, e.g. by adding the following line to ~/.asoundrc:
defaults.namehist.showall on
To force to override even the variable type, you can add '!' modifier,
defaults.namehist.!showall 1
Well I tried doing both of the above in ~/.asoundrc, but I'm still not getting any listing of the pcm hw or plughw devices, or any plugins.
A typo of "namehint", sorry.
Takashi
I did see the typo before, and I corrected it before testing.. I had used:
defaults.namehint.showall on and defaults.namehint.!showall 1
for my tests - my results are in the previous email.
At Mon, 14 May 2007 11:27:38 +0200, Nicholas Smethurst wrote:
Takashi Iwai wrote:
At Mon, 14 May 2007 10:36:48 +0200, Nicholas Smethurst wrote:
Takashi Iwai wrote:
You can override the values easily in user configuration, e.g. by adding the following line to ~/.asoundrc:
defaults.namehist.showall on
To force to override even the variable type, you can add '!' modifier,
defaults.namehist.!showall 1
Well I tried doing both of the above in ~/.asoundrc, but I'm still not getting any listing of the pcm hw or plughw devices, or any plugins.
A typo of "namehint", sorry.
Takashi
I did see the typo before, and I corrected it before testing.. I had used:
defaults.namehint.showall on and defaults.namehint.!showall 1
for my tests - my results are in the previous email.
Hm, do you see any change in "aplay -L" output with and without this definition?
Takashi
Takashi Iwai wrote:
defaults.namehint.showall on and defaults.namehint.!showall 1
for my tests - my results are in the previous email.
Hm, do you see any change in "aplay -L" output with and without this definition?
No, "aplay -L" gives the same list with or without the option. I tried changing it in /usr/share/alsa/alsa.conf as well, but the change had no effect.
NB: this is with 1.0.14rc4.
nicholas@Nicholas:~$ aplay -L default:CARD=V8237 VIA 8237, VIA 8237 Default Audio Device front:CARD=V8237,DEV=0 VIA 8237, VIA 8237 Front speakers surround40:CARD=V8237,DEV=0 VIA 8237, VIA 8237 4.0 Surround output to Front and Rear speakers surround41:CARD=V8237,DEV=0 VIA 8237, VIA 8237 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=V8237,DEV=0 VIA 8237, VIA 8237 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=V8237,DEV=0 VIA 8237, VIA 8237 5.1 Surround output to Front, Center, Rear and Subwoofer speakers iec958:CARD=V8237,DEV=0 VIA 8237, VIA 8237 IEC958 (S/PDIF) Digital Audio Output null Discard all samples (playback) or generate zero samples (capture) default:CARD=UART MPU-401 UART Default Audio Device default:CARD=PAD RME Digi96/8 PAD, Digi96 IEC958 Default Audio Device
nicholas@Nicholas:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: V8237 [VIA 8237], device 0: VIA 8237 [VIA 8237] Subdevices: 4/4 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 card 0: V8237 [VIA 8237], device 1: VIA 8237 [VIA 8237] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: PAD [RME Digi96/8 PAD], device 0: Digi96 IEC958 [Digi96 IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: PAD [RME Digi96/8 PAD], device 1: Digi96 ADAT [Digi96 ADAT] Subdevices: 1/1 Subdevice #0: subdevice #0
At Mon, 14 May 2007 12:38:49 +0200, Nicholas Smethurst wrote:
Takashi Iwai wrote:
defaults.namehint.showall on and defaults.namehint.!showall 1
for my tests - my results are in the previous email.
Hm, do you see any change in "aplay -L" output with and without this definition?
No, "aplay -L" gives the same list with or without the option. I tried changing it in /usr/share/alsa/alsa.conf as well, but the change had no effect.
Then something wrong with your set up. It works for me. aplay -L shows different outputs with the "showal on".
You should check whether ~/.asoundrc is really read.
Takashi
participants (6)
-
Jaroslav Kysela -
Lee Revell -
Nicholas Smethurst -
Nicholas Smethurst -
nick smethurst
-
Takashi Iwai