[alsa-devel] 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