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

[Maarten Vanraes]

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?