[alsa-devel] my udev rules are breaking my dmixer setup why?
Hello everybody,
I am trying to use udev to get fixed device names depending on the location of the device on the usb bus. The udev rules seems to be working fine, however i cant get dmix to work with the udev rules using only hw dies work. If i remove the udev rules the dmixer works fine.
Can somebody look at the attachment, and maybe do some testing, i would highly appreciate it.
I am also on chat.freenode.org and #alsa as tuxcrafter
Thanks in advance,
Jelle
ls -hal /dev/snd/ total 0 drwxr-xr-x 2 root root 320 2008-11-09 15:44 . drwxr-xr-x 12 root root 4.8K 2008-11-09 15:50 .. crw-rw---- 1 root user0 116, 0 2008-11-09 15:44 controlC0 crw-rw---- 1 root user1 116, 32 2008-11-09 15:44 controlC1 crw-rw---- 1 root user2 116, 64 2008-11-09 15:44 controlC2 crw-rw---- 1 root user3 116, 96 2008-11-09 15:44 controlC3 crw-rw---- 1 root user0 116, 24 2008-11-09 15:44 pcmC0D0c crw-rw---- 1 root user0 116, 16 2008-11-09 15:49 pcmC0D0p crw-rw---- 1 root user1 116, 56 2008-11-09 15:44 pcmC1D0c crw-rw---- 1 root user1 116, 48 2008-11-09 15:44 pcmC1D0p crw-rw---- 1 root user2 116, 88 2008-11-09 15:44 pcmC2D0c crw-rw---- 1 root user2 116, 80 2008-11-09 15:44 pcmC2D0p crw-rw---- 1 root user3 116, 120 2008-11-09 15:44 pcmC3D0c crw-rw---- 1 root user3 116, 112 2008-11-09 15:44 pcmC3D0p crw-rw---- 1 root audio 116, 1 2008-11-09 15:44 seq crw-rw---- 1 root audio 116, 33 2008-11-09 15:44 timer
------------------------------------------------------------------------
udevinfo info --attribute-walk --name=/dev/snd/controlC0
------------------------------------------------------------------------
echo 'SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="controlC[0-9]*", NAME="snd/controlC4" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="controlC[0-9]", NAME="snd/controlC5" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="controlC[0-9]", NAME="snd/controlC6" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="controlC[0-9]", NAME="snd/controlC7"
SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC4D0c" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC5D0c" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC6D0c" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC7D0c"
SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC4D0c" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC5D0c" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC6D0c" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC7D0c"
SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC4D0p" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC5D0p" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC6D0p" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC7D0p"' | tee /etc/udev/rules.d/10-persistent-sound.rules chmod 600 /etc/udev/rules.d/10-persistent-sound.rules
------------------------------------------------------------------------ # without dmixer # this works ....
echo 'pcm.softvol { type softvol slave.pcm hw:1 control.name Master control.card 1 }
pcm.!default { type plug slave.pcm softvol }
ctl.!default { type hw card 1 }' | tee /home/user1/.asoundrc chmod 600 /home/user1/.asoundrc chown user1:user1 /home/user1/.asoundrc
------------------------------------------------------------------------ # with dmixer # this does not work
echo 'pcm.softvol { type softvol slave.pcm dmix:1 control.name Master control.card 1 }
pcm.!default { type plug slave.pcm softvol }
ctl.!default { type hw card 1 }' | tee /home/user1/.asoundrc chmod 600 /home/user1/.asoundrc chown user1:user1 /home/user1/.asoundrc
------------------------------------------------------------------------ # with dmixer # this does not work
echo 'pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 2048 slave.pcm hw:1 } ctl.dmixer { type hw card 1 } pcm.dsp { type plug slave.pcm dmixer } ctl.mixer { type hw card 1 }' | tee /home/user1/.asoundrc chmod 600 /home/user1/.asoundrc chown user1:user1 /home/user1/.asoundrc
------------------------------------------------------------------------
At Sun, 09 Nov 2008 15:59:03 +0100, Jelle de Jong wrote:
Hello everybody,
I am trying to use udev to get fixed device names depending on the location of the device on the usb bus. The udev rules seems to be working fine, however i cant get dmix to work with the udev rules using only hw dies work. If i remove the udev rules the dmixer works fine.
Can somebody look at the attachment, and maybe do some testing, i would highly appreciate it.
Swapping the card numbers with udev might have a problem because the driver itself remembers the card index, and this number isn't swapped -- thus you get inconsistency between the device file and the internal index number.
BTW, if you just would like to keep the fixed device index for a certain usb device path, try my old patch below. It adds devpath option to snd-usb-audio, and you can specify the usb device path string ("usb-$BUSNAME-$DEVPATH").
Takashi
--- diff --git a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c index bbd70d5..4e6ae0e 100644 --- a/sound/usb/usbaudio.c +++ b/sound/usb/usbaudio.c @@ -68,6 +68,7 @@ static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;/* Enable this card */ /* Vendor/product IDs for this card */ static int vid[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = -1 }; static int pid[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = -1 }; +static char *devpath[SNDRV_CARDS]; static int nrpacks = 8; /* max. number of packets per urb */ static int async_unlink = 1; static int device_setup[SNDRV_CARDS]; /* device parameter for this card*/ @@ -83,6 +84,8 @@ module_param_array(vid, int, NULL, 0444); MODULE_PARM_DESC(vid, "Vendor ID for the USB audio device."); module_param_array(pid, int, NULL, 0444); MODULE_PARM_DESC(pid, "Product ID for the USB audio device."); +module_param_array(devpath, charp, NULL, 0444); +MODULE_PARM_DESC(devpath, "USB devpath for the specific index."); module_param(nrpacks, int, 0644); MODULE_PARM_DESC(nrpacks, "Max. number of packets per URB."); module_param(async_unlink, bool, 0444); @@ -3543,6 +3546,21 @@ static int snd_usb_audio_create(struct usb_device *dev, int idx, }
+static int is_matching_device(int i, u32 id, struct usb_device *dev) +{ + if (vid[i] != -1 && vid[i] != USB_ID_VENDOR(id)) + return 0; + if (pid[i] != -1 && pid[i] != USB_ID_PRODUCT(id)) + return 0; + if (devpath[i]) { + char tmppath[64]; + usb_make_path(dev, tmppath, sizeof(tmppath)); + if (strcmp(devpath[i], tmppath)) + return 0; + } + return 1; +} + /* * probe the active usb device * @@ -3613,8 +3631,7 @@ static void *snd_usb_audio_probe(struct usb_device *dev, */ for (i = 0; i < SNDRV_CARDS; i++) if (enable[i] && ! usb_chip[i] && - (vid[i] == -1 || vid[i] == USB_ID_VENDOR(id)) && - (pid[i] == -1 || pid[i] == USB_ID_PRODUCT(id))) { + is_matching_device(i, id, dev)) { if (snd_usb_audio_create(dev, i, quirk, &chip) < 0) { goto __error; }
Takashi Iwai wrote:
At Sun, 09 Nov 2008 15:59:03 +0100, Jelle de Jong wrote:
Hello everybody,
I am trying to use udev to get fixed device names depending on the location of the device on the usb bus. The udev rules seems to be working fine, however i cant get dmix to work with the udev rules using only hw dies work. If i remove the udev rules the dmixer works fine.
Can somebody look at the attachment, and maybe do some testing, i would highly appreciate it.
Swapping the card numbers with udev might have a problem because the driver itself remembers the card index, and this number isn't swapped -- thus you get inconsistency between the device file and the internal index number.
BTW, if you just would like to keep the fixed device index for a certain usb device path, try my old patch below. It adds devpath option to snd-usb-audio, and you can specify the usb device path string ("usb-$BUSNAME-$DEVPATH").
Takashi
Thank you Takashi for thanking the time to answer the question. I don't understand. If udev created the card numbers in the first place, swapping them should not make a difference? and why does the audio work fine with only hw:x and not when using dmix:x. How is the internal index number created? Can I control this index with udev? did I forget something in my udev rules?
Custom compiling sound modules is no option, it will break maintainability of the system in every way, sorry for this not being an sustainable option.
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
Would it be possible to test my udev rules that I posted, they are not difficult and don't change your system just add the file do some testing then remove the file when done...
I can also sent some usb audio devices to some developers to do some testing.
Any help is appreciated.
Best regards,
Jelle
At Tue, 11 Nov 2008 10:43:00 +0100, Jelle de Jong wrote:
Takashi Iwai wrote:
At Sun, 09 Nov 2008 15:59:03 +0100, Jelle de Jong wrote:
Hello everybody,
I am trying to use udev to get fixed device names depending on the location of the device on the usb bus. The udev rules seems to be working fine, however i cant get dmix to work with the udev rules using only hw dies work. If i remove the udev rules the dmixer works fine.
Can somebody look at the attachment, and maybe do some testing, i would highly appreciate it.
Swapping the card numbers with udev might have a problem because the driver itself remembers the card index, and this number isn't swapped -- thus you get inconsistency between the device file and the internal index number.
BTW, if you just would like to keep the fixed device index for a certain usb device path, try my old patch below. It adds devpath option to snd-usb-audio, and you can specify the usb device path string ("usb-$BUSNAME-$DEVPATH").
Takashi
Thank you Takashi for thanking the time to answer the question. I don't understand. If udev created the card numbers in the first place, swapping them should not make a difference?
udev just renames a file. But, the index number is stored in the driver itself, and it can be read via an API function.
and why does the audio work fine with only hw:x and not when using dmix:x.
Unless you change the device file name, it works. Or, use an id string instead of an index number. The id string is found in /proc/asound/cards as [xxx]. Or, you can simply set up the slots option of snd module or set up the index option of each module. See ALSA-Configuration.txt.
How is the internal index number created?
Either via a module / kernel boot option, or created dynamically via the driver.
Can I control this index with udev? did I forget something in my udev rules?
No. As mentioned, your udev rule just renames the file.
Custom compiling sound modules is no option, it will break maintainability of the system in every way, sorry for this not being an sustainable option.
IMO, changing udev rule could be more fragile than a custom module...
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Takashi
Takashi Iwai wrote:
At Tue, 11 Nov 2008 10:43:00 +0100, Jelle de Jong wrote:
Takashi Iwai wrote:
At Sun, 09 Nov 2008 15:59:03 +0100, Jelle de Jong wrote:
Hello everybody,
I am trying to use udev to get fixed device names depending on the location of the device on the usb bus. The udev rules seems to be working fine, however i cant get dmix to work with the udev rules using only hw dies work. If i remove the udev rules the dmixer works fine.
Can somebody look at the attachment, and maybe do some testing, i would highly appreciate it.
Swapping the card numbers with udev might have a problem because the driver itself remembers the card index, and this number isn't swapped -- thus you get inconsistency between the device file and the internal index number.
BTW, if you just would like to keep the fixed device index for a certain usb device path, try my old patch below. It adds devpath option to snd-usb-audio, and you can specify the usb device path string ("usb-$BUSNAME-$DEVPATH").
Takashi
Thank you Takashi for thanking the time to answer the question. I don't understand. If udev created the card numbers in the first place, swapping them should not make a difference?
udev just renames a file. But, the index number is stored in the driver itself, and it can be read via an API function.
and why does the audio work fine with only hw:x and not when using dmix:x.
Unless you change the device file name, it works. Or, use an id string instead of an index number. The id string is found in /proc/asound/cards as [xxx]. Or, you can simply set up the slots option of snd module or set up the index option of each module. See ALSA-Configuration.txt.
How is the internal index number created?
Either via a module / kernel boot option, or created dynamically via the driver.
Can I control this index with udev? did I forget something in my udev rules?
No. As mentioned, your udev rule just renames the file.
Custom compiling sound modules is no option, it will break maintainability of the system in every way, sorry for this not being an sustainable option.
IMO, changing udev rule could be more fragile than a custom module...
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Takashi
When reading the explanations I understand that we are kind of dealing with a legacy issue. Is it possible to add some features to alsa to still get what I need to be able to always use a fixed usb port for audio for one user. For example if i take the content of ../cards it is capable of showing the usb path. If I can use this in my .asoundrc all problems go away, and no need for udev rules to rename devices. This same system is used input devices for Xorg with /dev/input/by-path/
cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xf7db8000 irq 16 1 [pcsp ]: PC-Speaker - pcsp Internal PC-Speaker at port 0x61 2 [Em28xx Audio ]: Empia Em28xx AudEm28xx Audio - Em28xx Audio Empia Em28xx Audio 3 [default ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.1, full speed 4 [default_1 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.2, full speed 5 [default_2 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.3, full speed 6 [default_3 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.4, full speed
Would it be possible to create something like the below:
echo 'pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 1024 slave.pcm hw:path:usb-0000:00:1d.7-4.1 } ctl.dmixer { type hw card path:usb-0000:00:1d.7-4.1 } pcm.dsp { type plug slave.pcm dmixer } ctl.mixer { type hw card path:usb-0000:00:1d.7-4.1 }' | tee /home/user0/.asoundrc chmod 600 /home/user0/.asoundrc chown user0:user0 /home/user0/.asoundrc
Thanks in advance,
Jelle
At Tue, 11 Nov 2008 11:57:29 +0100, Jelle de Jong wrote:
Takashi Iwai wrote:
At Tue, 11 Nov 2008 10:43:00 +0100, Jelle de Jong wrote:
Takashi Iwai wrote:
At Sun, 09 Nov 2008 15:59:03 +0100, Jelle de Jong wrote:
Hello everybody,
I am trying to use udev to get fixed device names depending on the location of the device on the usb bus. The udev rules seems to be working fine, however i cant get dmix to work with the udev rules using only hw dies work. If i remove the udev rules the dmixer works fine.
Can somebody look at the attachment, and maybe do some testing, i would highly appreciate it.
Swapping the card numbers with udev might have a problem because the driver itself remembers the card index, and this number isn't swapped -- thus you get inconsistency between the device file and the internal index number.
BTW, if you just would like to keep the fixed device index for a certain usb device path, try my old patch below. It adds devpath option to snd-usb-audio, and you can specify the usb device path string ("usb-$BUSNAME-$DEVPATH").
Takashi
Thank you Takashi for thanking the time to answer the question. I don't understand. If udev created the card numbers in the first place, swapping them should not make a difference?
udev just renames a file. But, the index number is stored in the driver itself, and it can be read via an API function.
and why does the audio work fine with only hw:x and not when using dmix:x.
Unless you change the device file name, it works. Or, use an id string instead of an index number. The id string is found in /proc/asound/cards as [xxx]. Or, you can simply set up the slots option of snd module or set up the index option of each module. See ALSA-Configuration.txt.
How is the internal index number created?
Either via a module / kernel boot option, or created dynamically via the driver.
Can I control this index with udev? did I forget something in my udev rules?
No. As mentioned, your udev rule just renames the file.
Custom compiling sound modules is no option, it will break maintainability of the system in every way, sorry for this not being an sustainable option.
IMO, changing udev rule could be more fragile than a custom module...
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Takashi
When reading the explanations I understand that we are kind of dealing with a legacy issue. Is it possible to add some features to alsa to still get what I need to be able to always use a fixed usb port for audio for one user. For example if i take the content of ../cards it is capable of showing the usb path. If I can use this in my .asoundrc all problems go away, and no need for udev rules to rename devices. This same system is used input devices for Xorg with /dev/input/by-path/
Yeah, it's worth to add a new identification way via a system path. It'll be an extention and cannot work as is now, though :)
In your case, try to pass "default", "default_1" or "default_2" to card id instead of index number.
For example, the below should work without an extra ~/.asoundrc
% aplay -Dplug:dmix:default foo.wav
Takashi
cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xf7db8000 irq 16 1 [pcsp ]: PC-Speaker - pcsp Internal PC-Speaker at port 0x61 2 [Em28xx Audio ]: Empia Em28xx AudEm28xx Audio - Em28xx Audio Empia Em28xx Audio 3 [default ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.1, full speed 4 [default_1 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.2, full speed 5 [default_2 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.3, full speed 6 [default_3 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.4, full speed
Would it be possible to create something like the below:
echo 'pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 1024 slave.pcm hw:path:usb-0000:00:1d.7-4.1 } ctl.dmixer { type hw card path:usb-0000:00:1d.7-4.1 } pcm.dsp { type plug slave.pcm dmixer } ctl.mixer { type hw card path:usb-0000:00:1d.7-4.1 }' | tee /home/user0/.asoundrc chmod 600 /home/user0/.asoundrc chown user0:user0 /home/user0/.asoundrc
Thanks in advance,
Jelle
On Tue, 11 Nov 2008, Takashi Iwai wrote:
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Note that you can identify your card via the text identification (check /proc/asound/cards to get it in []). You can set this identification in the module insert time and use for example 'hw:Intel' in your apps without bothering with indexes.
The missing part is the modification of this text identification using sysfs at runtime for udev. Some time ago, I was trying to add this setup to /sys/class/sound, but the sysfs core code was not prepared for this change. I'll try to check the situation again.
Jaroslav ----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Takashi Iwai wrote:
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Note that you can identify your card via the text identification (check /proc/asound/cards to get it in []). You can set this identification in the module insert time and use for example 'hw:Intel' in your apps without bothering with indexes.
The missing part is the modification of this text identification using sysfs at runtime for udev. Some time ago, I was trying to add this setup to /sys/class/sound, but the sysfs core code was not prepared for this change. I'll try to check the situation again.
Jaroslav
I wish it was as simple as using the [identification ]. The [id..] is not reliable for one usb port, as you can below I just unplugged some usb audio devices and plugged it in again. The [id] does not match the same usb location port anymore, so breaking the user->unique-usb-port-audio-device connection.
Being able to set the id with udev would be an possible solution.
cat /proc/asound/cards (first) 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xf7db8000 irq 16 1 [pcsp ]: PC-Speaker - pcsp Internal PC-Speaker at port 0x61 2 [Em28xx Audio ]: Empia Em28xx AudEm28xx Audio - Em28xx Audio Empia Em28xx Audio 3 [default ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.1, full speed 4 [default_1 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.2, full speed 5 [default_2 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.3, full speed 6 [default_3 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.4, full speed
cat /proc/asound/cards (second) 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xf7db8000 irq 16 1 [pcsp ]: PC-Speaker - pcsp Internal PC-Speaker at port 0x61 3 [default ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.3, full speed 4 [default_1 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.2, full speed 5 [default_2 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.4, full speed 6 [default_3 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.1, full speed
Also the limitation of [0-7] devices is kind of unclear does it something to do with limitations of timers?
Best regards,
Jelle
At Tue, 11 Nov 2008 12:21:30 +0100, Jelle de Jong wrote:
Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Takashi Iwai wrote:
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Note that you can identify your card via the text identification (check /proc/asound/cards to get it in []). You can set this identification in the module insert time and use for example 'hw:Intel' in your apps without bothering with indexes.
The missing part is the modification of this text identification using sysfs at runtime for udev. Some time ago, I was trying to add this setup to /sys/class/sound, but the sysfs core code was not prepared for this change. I'll try to check the situation again.
JaroslavI wish it was as simple as using the [identification ]. The [id..] is not reliable for one usb port, as you can below I just unplugged some usb audio devices and plugged it in again. The [id] does not match the same usb location port anymore, so breaking the user->unique-usb-port-audio-device connection.
Being able to set the id with udev would be an possible solution.
Ah, indeed. I vaguely remember why I wrote that patch...
cat /proc/asound/cards (first) 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xf7db8000 irq 16 1 [pcsp ]: PC-Speaker - pcsp Internal PC-Speaker at port 0x61 2 [Em28xx Audio ]: Empia Em28xx AudEm28xx Audio - Em28xx Audio Empia Em28xx Audio 3 [default ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.1, full speed 4 [default_1 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.2, full speed 5 [default_2 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.3, full speed 6 [default_3 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.4, full speed
cat /proc/asound/cards (second) 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xf7db8000 irq 16 1 [pcsp ]: PC-Speaker - pcsp Internal PC-Speaker at port 0x61 3 [default ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.3, full speed 4 [default_1 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.2, full speed 5 [default_2 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.4, full speed 6 [default_3 ]: USB-Audio - USB AUDIO USB AUDIO at usb-0000:00:1d.7-4.1, full speed
Also the limitation of [0-7] devices is kind of unclear does it something to do with limitations of timers?
No, it's just an issue of minor device assignment. Depending on the kernel configuration, you'll be able to have more devices.
Takashi
Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Takashi Iwai wrote:
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Note that you can identify your card via the text identification (check /proc/asound/cards to get it in []). You can set this identification in the module insert time and use for example 'hw:Intel' in your apps without bothering with indexes.
The missing part is the modification of this text identification using sysfs at runtime for udev. Some time ago, I was trying to add this setup to /sys/class/sound, but the sysfs core code was not prepared for this change. I'll try to check the situation again.
As response to: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012366.ht...
I am not sure if it is good practice to repose to an RFC if so please tell me then we will continue the discussion in the RFC thread.
Thank you Jaroslav for creating the patch this is really appreciated, if all things work I will send you some dutch stroopwafels :-D
I am just curious how you patch can be used with udev? What did you have in mind?
Would something like this be possible:
SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-1", NAME="snd/by-id/audiodevice0" SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-2", NAME="snd/by-id/audiodevice1"
pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 1024 slave.pcm hw:audiodevice0 } ctl.dmixer { type hw card audiodevice0 } pcm.dsp { type plug slave.pcm dmixer } ctl.mixer { type hw card audiodevice0 }
Thanks in advance,
Jelle
On Tue, 11 Nov 2008, Jelle de Jong wrote:
Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Takashi Iwai wrote:
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Note that you can identify your card via the text identification (check /proc/asound/cards to get it in []). You can set this identification in the module insert time and use for example 'hw:Intel' in your apps without bothering with indexes.
The missing part is the modification of this text identification using sysfs at runtime for udev. Some time ago, I was trying to add this setup to /sys/class/sound, but the sysfs core code was not prepared for this change. I'll try to check the situation again.
As response to: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012366.ht...
I am not sure if it is good practice to repose to an RFC if so please tell me then we will continue the discussion in the RFC thread.
Thank you Jaroslav for creating the patch this is really appreciated, if all things work I will send you some dutch stroopwafels :-D
I am just curious how you patch can be used with udev? What did you have in mind?
Would something like this be possible:
SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-1", NAME="snd/by-id/audiodevice0" SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-2", NAME="snd/by-id/audiodevice1"
No, something like this:
SUBSYSTEM=="sound", ACTION=="add", KERNEL=="controlC*", KERNELS=="3-2", \ ATTR{device/id}="audiodevice1"
pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 1024 slave.pcm hw:audiodevice0 }
This looks OK.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Jelle de Jong wrote:
Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Takashi Iwai wrote:
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Note that you can identify your card via the text identification (check /proc/asound/cards to get it in []). You can set this identification in the module insert time and use for example 'hw:Intel' in your apps without bothering with indexes.
The missing part is the modification of this text identification using sysfs at runtime for udev. Some time ago, I was trying to add this setup to /sys/class/sound, but the sysfs core code was not prepared for this change. I'll try to check the situation again.
As response to: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012366.ht...
I am not sure if it is good practice to repose to an RFC if so please tell me then we will continue the discussion in the RFC thread.
Thank you Jaroslav for creating the patch this is really appreciated, if all things work I will send you some dutch stroopwafels :-D
I am just curious how you patch can be used with udev? What did you have in mind?
Would something like this be possible:
SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-1", NAME="snd/by-id/audiodevice0" SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-2", NAME="snd/by-id/audiodevice1"
No, something like this:
SUBSYSTEM=="sound", ACTION=="add", KERNEL=="controlC*", KERNELS=="3-2", \ ATTR{device/id}="audiodevice1"
pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 1024 slave.pcm hw:audiodevice0 }
This looks OK.
Jaroslav
Thank you Jaroslav, that looks great.
So how does this work now, will the RFC be applied to the alsa devel repository, or does it need to be tested by an alsa committer and signed of first?
Then it will come in the developers repository? When is the next alsa release planned that will include this patch? Any ideas how long the Debian maintainer takes before creating a new binary package I currently running Debian sid with (Source: alsa-driver Version: 1.0.17.dfsg-4)
Or is it possible that the Debian maintainer can patch the current 1.0.17.dfsg-4 with the new created patch?
Or is it wanted that I build the current development code create a test package and test it on my systems and provide feedback?
What would you want me to do?
Thank in advance,
Jelle
Jelle de Jong wrote:
Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Jelle de Jong wrote:
Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Takashi Iwai wrote:
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Note that you can identify your card via the text identification (check /proc/asound/cards to get it in []). You can set this identification in the module insert time and use for example 'hw:Intel' in your apps without bothering with indexes.
The missing part is the modification of this text identification using sysfs at runtime for udev. Some time ago, I was trying to add this setup to /sys/class/sound, but the sysfs core code was not prepared for this change. I'll try to check the situation again.
As response to: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012366.ht...
I am not sure if it is good practice to repose to an RFC if so please tell me then we will continue the discussion in the RFC thread.
Thank you Jaroslav for creating the patch this is really appreciated, if all things work I will send you some dutch stroopwafels :-D
I am just curious how you patch can be used with udev? What did you have in mind?
Would something like this be possible:
SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-1", NAME="snd/by-id/audiodevice0" SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-2", NAME="snd/by-id/audiodevice1"
No, something like this:
SUBSYSTEM=="sound", ACTION=="add", KERNEL=="controlC*", KERNELS=="3-2", \ ATTR{device/id}="audiodevice1"
pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 1024 slave.pcm hw:audiodevice0 }
This looks OK.
JaroslavThank you Jaroslav, that looks great.
So how does this work now, will the RFC be applied to the alsa devel repository, or does it need to be tested by an alsa committer and signed of first?
Then it will come in the developers repository? When is the next alsa release planned that will include this patch? Any ideas how long the Debian maintainer takes before creating a new binary package I currently running Debian sid with (Source: alsa-driver Version: 1.0.17.dfsg-4)
Or is it possible that the Debian maintainer can patch the current 1.0.17.dfsg-4 with the new created patch?
Or is it wanted that I build the current development code create a test package and test it on my systems and provide feedback?
What would you want me to do?
Thank in advance,
Jelle
Hi all,
I was just wondering how I can follow the patch [1], when will it come into an official alsa tarball, then i can request a wish bug at the Debian maintainer to package the tarbal for Debian experimental/sid.
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012366.ht...
Best regards,
Jelle
On 11/11/08 18:55, Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Jelle de Jong wrote:
Jaroslav Kysela wrote:
On Tue, 11 Nov 2008, Takashi Iwai wrote:
Almost all devices can be managed with udev rules, that is where the system is designed for, there are also alsa rules in there, if they don't work what is wrong then? is it an alsa issue, or udev, what are the dependencies when alsa uses hardware. How are the /dev/snd/* devices used and what is the /proc/asound/* for ?
The card index mechanism in ALSA was introduced much before udev was born. It's just a legacy mechanism, but it's hard to kill without breaking the running system, unfortunately.
Note that you can identify your card via the text identification (check /proc/asound/cards to get it in []). You can set this identification in the module insert time and use for example 'hw:Intel' in your apps without bothering with indexes.
The missing part is the modification of this text identification using sysfs at runtime for udev. Some time ago, I was trying to add this setup to /sys/class/sound, but the sysfs core code was not prepared for this change. I'll try to check the situation again.
As response to: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012366.ht...
I am not sure if it is good practice to repose to an RFC if so please tell me then we will continue the discussion in the RFC thread.
Thank you Jaroslav for creating the patch this is really appreciated, if all things work I will send you some dutch stroopwafels :-D
I am just curious how you patch can be used with udev? What did you have in mind?
Would something like this be possible:
SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-1", NAME="snd/by-id/audiodevice0" SUBSYSTEM=="sound", ACTION="add" KERNELS=="3-2", NAME="snd/by-id/audiodevice1"
No, something like this:
SUBSYSTEM=="sound", ACTION=="add", KERNEL=="controlC*", KERNELS=="3-2", \ ATTR{device/id}="audiodevice1"
pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 1024 slave.pcm hw:audiodevice0 }
This looks OK.
Jaroslav
Hello everybody,
It has been a while and I have been waiting until the patch made it into Debian and now it finally has, so I started testing and it seems to work that the patch works and I am very grateful for it.
I still have list of issues, but I will make new treads for them now.
Thanks again,
Best regards,
Jelle de Jong
participants (3)
-
Jaroslav Kysela -
Jelle de Jong -
Takashi Iwai