[Mageia-dev] [changelog] cauldron core/release sound-scripts-0.61-2.mga2

Mon Oct 3 16:28:50 CEST 2011

Op maandag 03 oktober 2011 15:38:34 schreef Colin Guthrie:
+> 'Twas brillig, and Maarten Vanraes at 03/10/11 13:41 did gyre and gimble:
+> > Op maandag 03 oktober 2011 10:27:02 schreef Colin Guthrie:
+> >> 'Twas brillig, and Maarten Vanraes at 19/09/11 11:32 did gyre and gimble:
+> >>>> On 19 September 2011 11:44, Colin Guthrie <mageia at colin.guthr.ie> 
+wrote:
+> >>>>>>> Did you fixed the war against webcam another way?
+> >>>>>> 
+> >>>>>> Is this a problem of webcam mics not working if they are present
+> >>>>>> during boot? If not, can you remember the problem better?
+> >>>>>> 
+> >>>>>> If so, no I've not fixed, but will find an official way that we can
+> >>>>>> submit upstream.
+> >>>>> 
+> >>>>> Whoops, it seems this conversation went off list accidentally.
+> >>>>> 
+> >>>>> TV clarified that the problem the snd-usb-audio modprobe rule solved
+> >>>>> was that of webcams getting the card0 slot on boot and pushing the
+> >>>>> normal, built in audio system to card1.
+> >>>>> 
+> >>>>> As this problem attempts to resolve the underlying limitations of
+> >>>>> alsa (not preserving the audio device order) in a generic way
+> >>>>> (specific index= arguments could be added to your own specific
+> >>>>> hardware to solve it also), and considering that device order really
+> >>>>> shouldn't matter when PulseAudio is used (it has it's own built in
+> >>>>> system for determining the "priority" of devices when a first boot
+> >>>>> with a new user is encountered so that the correct defaults will be
+> >>>>> picked on first boot and there after it's the user's choice), I'm
+> >>>>> not really inclined to attempt to fix this "bug".
+> >>>>> 
+> >>>>> If people feel super strongly about it I can look into it, but I
+> >>>>> think it's really a matter of "tough love" for the non-PA case if it
+> >>>>> means we have to put in lots of crazy work arounds like this.
+> >>>>> 
+> >>>>> Opinions welcome.
+> >>>> 
+> >>>> Not all people use PA.
+> >>>> We even have options in draksound in order to disable it...
+> >>>> Hence we must still support the case were PA isn't around...
+> >>> 
+> >>> can something be done with udev rules, like it happens with other types
+> >>> of devices?
+> >> 
+> >> I'm not sure udev rules will fix this.
+> >> 
+> >> I guess we could provide some default modprobe rule that just left space
+> >> for the device 0...
+> >> 
+> >> http://alsa.opensrc.org/MultipleCards#Reordering_the_driver_for_a_partic
+> >> ula r_card
+> >> 
+> >> options snd slots=,snd-usb-audio
+> >> 
+> >> 
+> >> These rules could only be used when PA is not used (via sound profile
+> >> symlinks)
+> >> 
+> >> That will probably cover most bases and if users want to have more
+> >> configuration when they do not use PA then they can write their own
+> >> modprobe rules. I'd say that's an acceptable trade off.
+> >> 
+> >> WDYT?
+> >> 
+> >> Col
+> > 
+> > what i mean is to have some kind of udev rule generator, so that the ones
+> > you had when you started at first are kept in that order (they still can
+> > be added or removed, but the existing ones will keep their device name?
+> 
+> Potentially, tho' I'd much rather avoid complicated rules generators
+> like that as it'll just lead to problems at some point when it stops
+> working or syntax changes etc.
+> 
+> IMO it's just added complexity for questionable gain.
+> 
+> Col
+
+
+debian uses this system to make sure devices have the same device names and 
+numbers as long as they are uniquely identifyable.
+
+perhaps we can take a look at how debian does it?
+