my udev rules are breaking my dmixer setup why?

my udev rules are breaking my dmixer setup why?

[Jelle de Jong]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

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

[-- Attachment #2: udev-alsa-setup.txt --]
[-- Type: text/plain, Size: 3978 bytes --]

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

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

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: my udev rules are breaking my dmixer setup why?

[Takashi Iwai]

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

Re: my udev rules are breaking my dmixer setup why?

[Jelle de Jong]

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

Re: my udev rules are breaking my dmixer setup why?

[Takashi Iwai]

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

Re: my udev rules are breaking my dmixer setup why?

[Jelle de Jong]

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

Re: my udev rules are breaking my dmixer setup why?

[Jaroslav Kysela]

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.

Re: my udev rules are breaking my dmixer setup why?

[Takashi Iwai]

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

Re: my udev rules are breaking my dmixer setup why?

[Jelle de Jong]

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

Re: my udev rules are breaking my dmixer setup why?

[Takashi Iwai]

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

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

Re: my udev rules are breaking my dmixer setup why?

[Jelle de Jong]

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

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

Re: my udev rules are breaking my dmixer setup why?

[Jaroslav Kysela]

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

Re: my udev rules are breaking my dmixer setup why?

[Jelle de Jong]

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

Re: my udev rules are breaking my dmixer setup why?

[Jelle de Jong]

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

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

Best regards,

Jelle

Re: my udev rules are breaking my dmixer setup why?

[Jelle de Jong]

[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]

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

[-- Attachment #2: alsa-debug.log --]
[-- Type: text/x-log, Size: 9701 bytes --]

http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012366.html

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

echo 'SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.1", KERNEL=="controlC[0-9]", NAME="snd/controlC4"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.2", KERNEL=="controlC[0-9]", NAME="snd/controlC5"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.3", KERNEL=="controlC[0-9]", NAME="snd/controlC6"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.4", KERNEL=="controlC[0-9]", NAME="snd/controlC7"

SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.1", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC4D0c"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.2", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC5D0c"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.3", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC6D0c"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.4", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC7D0c"

SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.1", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC4D0p"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.2", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC5D0p"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.3", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC6D0p"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.4", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC7D0p"

SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.1", KERNEL=="controlC[0-9]", ATTR{device/id}="audiodevice1"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.2", KERNEL=="controlC[0-9]", ATTR{device/id}="audiodevice2"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.3", KERNEL=="controlC[0-9]", ATTR{device/id}="audiodevice3"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.4", KERNEL=="controlC[0-9]", ATTR{device/id}="audiodevice4"' | sudo tee /etc/udev/rules.d/10-persistent-sound.rules
sudo chmod 600 /etc/udev/rules.d/10-persistent-sound.rules
sudo cat /etc/udev/rules.d/10-persistent-sound.rules

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

echo 'SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.1", MODE="0660", OWNER="root", GROUP="jelle"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.2", MODE="0660", OWNER="root", GROUP="jelle"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.3", MODE="0660", OWNER="root", GROUP="jelle"
SUBSYSTEM=="sound", ACTION=="add", KERNELS=="1-2.4", MODE="0660", OWNER="root", GROUP="jelle"' | sudo tee /etc/udev/rules.d/92-persistent-sound.rules
sudo chmod 600 /etc/udev/rules.d/92-persistent-sound.rules
sudo cat /etc/udev/rules.d/92-persistent-sound.rules

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

sudo udevadm control --reload-rules
tail -n 1000 /var/log/syslog

Jul 27 12:48:38 debian-eeepc udevd[1001]: invalid rule '/etc/udev/rules.d/10-persistent-sound.rules:16'
Jul 27 12:48:38 debian-eeepc udevd[1001]: invalid ATTRS operation
Jul 27 12:48:38 debian-eeepc udevd[1001]: invalid rule '/etc/udev/rules.d/10-persistent-sound.rules:17'
Jul 27 12:48:38 debian-eeepc udevd[1001]: invalid ATTRS operation
Jul 27 12:48:38 debian-eeepc udevd[1001]: invalid rule '/etc/udev/rules.d/10-persistent-sound.rules:18'
Jul 27 12:48:38 debian-eeepc udevd[1001]: invalid ATTRS operation
Jul 27 12:48:38 debian-eeepc udevd[1001]: invalid rule '/etc/udev/rules.d/10-persistent-sound.rules:19'
------------------------------------------------------------------------

$ ls -hal /dev/snd/
total 0
drwxr-xr-x   2 root root       400 2009-07-27 12:29 .
drwxr-xr-x  14 root root      4.2K 2009-07-27 12:29 ..
crw-rw----+  1 root audio 116,   0 2009-07-27 12:18 controlC0
crw-rw----+  1 root jelle 116,  32 2009-07-27 12:29 controlC1
crw-rw----+  1 root jelle 116,  64 2009-07-27 12:29 controlC2
crw-rw----+  1 root jelle 116,  96 2009-07-27 12:29 controlC3
crw-rw----+  1 root jelle 116, 128 2009-07-27 12:29 controlC4
crw-rw----+  1 root audio 116,   4 2009-07-27 12:18 hwC0D0
crw-rw----+  1 root audio 116,  24 2009-07-27 12:18 pcmC0D0c
crw-rw----+  1 root audio 116,  16 2009-07-27 12:18 pcmC0D0p
crw-rw----+  1 root jelle 116,  56 2009-07-27 12:29 pcmC1D0c
crw-rw----+  1 root jelle 116,  48 2009-07-27 12:29 pcmC1D0p
crw-rw----+  1 root jelle 116,  88 2009-07-27 12:29 pcmC2D0c
crw-rw----+  1 root jelle 116,  80 2009-07-27 12:29 pcmC2D0p
crw-rw----   1 root jelle 116, 120 2009-07-27 12:29 pcmC3D0c
crw-rw----+  1 root jelle 116, 112 2009-07-27 12:29 pcmC3D0p
crw-rw----+  1 root jelle 116, 152 2009-07-27 12:29 pcmC4D0c
crw-rw----+  1 root jelle 116, 144 2009-07-27 12:29 pcmC4D0p
crw-rw----+  1 root audio 116,   1 2009-07-27 12:18 seq
crw-rw----+  1 root audio 116,  33 2009-07-27 12:18 timer

$ cat /proc/asound/cards
 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xf7eb8000 irq 16
 1 [default        ]: USB-Audio - USB  AUDIO
                      USB  AUDIO   at usb-0000:00:1d.7-2.1, full speed
 2 [default_1      ]: USB-Audio - USB  AUDIO
                      USB  AUDIO   at usb-0000:00:1d.7-2.2, full speed
 3 [default_2      ]: USB-Audio - USB  AUDIO
                      USB  AUDIO   at usb-0000:00:1d.7-2.3, full speed
 4 [default_3      ]: USB-Audio - USB  AUDIO
                      USB  AUDIO   at usb-0000:00:1d.7-2.4, full speed

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

$ udevinfo info --attribute-walk --name=/dev/snd/controlC2
the program '/bin/bash' called 'udevinfo', it should use 'udevadm info <options>', this will stop working in a future release

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/sound/card2/controlC2':
    KERNEL=="controlC2"
    SUBSYSTEM=="sound"
    DRIVER==""

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/sound/card2':
    KERNELS=="card2"
    SUBSYSTEMS=="sound"
    DRIVERS==""
    ATTRS{id}=="default_1"
    ATTRS{number}=="2"

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0':
    KERNELS=="1-2.2:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="snd-usb-audio"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bNumEndpoints}=="00"
    ATTRS{bInterfaceClass}=="01"
    ATTRS{bInterfaceSubClass}=="01"
    ATTRS{bInterfaceProtocol}=="00"
    ATTRS{modalias}=="usb:v1130pF211d010Bdc00dsc00dp00ic01isc01ip00"
    ATTRS{supports_autosuspend}=="0"

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2':
    KERNELS=="1-2.2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 5"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="80"
    ATTRS{bMaxPower}=="500mA"
    ATTRS{urbnum}=="11825"
    ATTRS{idVendor}=="1130"
    ATTRS{idProduct}=="f211"
    ATTRS{bcdDevice}=="010b"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="8"
    ATTRS{speed}=="12"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="21"
    ATTRS{version}==" 1.10"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{authorized}=="1"
    ATTRS{product}=="USB  AUDIO  "

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-2':
    KERNELS=="1-2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}=="100mA"
    ATTRS{urbnum}=="65"
    ATTRS{idVendor}=="058f"
    ATTRS{idProduct}=="6254"
    ATTRS{bcdDevice}=="0100"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="01"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="480"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="19"
    ATTRS{version}==" 2.00"
    ATTRS{maxchild}=="4"
    ATTRS{quirks}=="0x0"
    ATTRS{authorized}=="1"

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1':
    KERNELS=="usb1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}=="  0mA"
    ATTRS{urbnum}=="108"
    ATTRS{idVendor}=="1d6b"
    ATTRS{idProduct}=="0002"
    ATTRS{bcdDevice}=="0206"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="480"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="1"
    ATTRS{version}==" 2.00"
    ATTRS{maxchild}=="8"
    ATTRS{quirks}=="0x0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="Linux 2.6.30-1-686 ehci_hcd"
    ATTRS{product}=="EHCI Host Controller"
    ATTRS{serial}=="0000:00:1d.7"
    ATTRS{authorized_default}=="1"

  looking at parent device '/devices/pci0000:00/0000:00:1d.7':
    KERNELS=="0000:00:1d.7"
    SUBSYSTEMS=="pci"
    DRIVERS=="ehci_hcd"
    ATTRS{vendor}=="0x8086"
    ATTRS{device}=="0x27cc"
    ATTRS{subsystem_vendor}=="0x1043"
    ATTRS{subsystem_device}=="0x830f"
    ATTRS{class}=="0x0c0320"
    ATTRS{irq}=="23"
    ATTRS{local_cpus}=="ffffffff"
    ATTRS{local_cpulist}=="0-31"
    ATTRS{modalias}=="pci:v00008086d000027CCsv00001043sd0000830Fbc0Csc03i20"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}==""

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel