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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
