Hi All,
This proposal is the result of discussion about various problems with the
current setup, for the original discussion see:
https://bugzilla.redhat.com/show_bug.cgi?id=232217
First lets try to describe the problem, currently system-config-soundcard and /
or some part of the installer (haven't figured out which part yet, guess
firstboot), write a module alias for snd-card-0 to /etc/modprobe.conf and adds
an options line for the selected module with "index=0" as option. Usually the
module alias will point to the onboard ac97 soundcard.
There are various problems with this:
1) If an usb webcam with usb-audio mic is plugged in and then one reboots, the
driver for this gets loaded by udev before the driver for the ac97 soundcard.
Then once the onboard ac97 soundcard driver gets loaded, it gets passed index=0
as option causing it to fail to load because the usb-audio mic of the webcam
is index 0.
This could be negated by by default adding the following 2 lines to
/etc/modprobe.conf:
options snd cards_limit=10
options snd-usb-audio index=7,8,9
2) Some motherboards have onboard usb sound (and I happen to own such a
motherboard), and in some cases the user may want for example a pair of
usb-speakers become the default soundcard (aka index 0), in the case the above
workaround for problem 1 would actually become a problem
This could be negated by letting the workaround lines be written by the same
tool as adding the mod alias and the index=0 mod option, and not writing them
when an usb soundcard is selected as the default
3) However what happens if I plug an usb webcam with usb-audio mic into my usb
onboard audio motherboard? ... Then the mic becomes index 0.
This could be negated by adding special module options for snd-usb-audio for an
usb default soundcard, which bind vendor and device id's to index's
snd-usb-audio supports this (but I haven't tested it yet).
So our current scheme has a number of problems, which can be workaround, but
that would require some serious surgery to system-config-soundcard, and I
wonder if this is the right solution. Esp since we have been slowly moving away
from using /etc/modprobe.conf at all, to a system where udev loads all drivers
(and udev also already loads the soundrivers).
We've matched this no longer using /etc/modprobe.conf for driver loading and
there by loosing the ability to determine "device numbers" (eth0 / eth1, sdf /
sdg) with smarter userspace support to determine which device is what:
determine which ethernet card is which by hardware address, hal for removale
media. I would like to propose to do the same for sound.
Given that pulseaudio is integrated with hal and that we are
moving to pulseaudio, I think that the solution is to stop trying to hard
assign indexes to soundcards, or to add module aliases for them to
/etc/modprobe.conf. Just let udev load the modules (as it already does).
pulseaudio gives names to soundcards based on various info, which does not
include the topology of the connection to the device for example:
usb_device_d8c_201_noserial_if0_sound_card_0_alsa_playback_0
So one could make for example an usb headset the prefered default sound-device
in pulseaudio, and then it would use that when available even independend of in
which usb port it is plugged.
To me this is the way forward, and using /etc/modprobe for soundcard config is
obsolete (just like /etc/fstab is for removable media).
So what do others think about this?
Notice that since problem 1) above is pretty common (many dups already in
bugzilla) we will need to fix this one way or the other for F-9. I know the
freeze is close, but I believe that fixing this by not writing sound stuff
/etc/modprobe.conf is the answer.
All we then need is a (simple) tool to change the default output device for
pulseaudio, and put that under an appropriately named menu entry under user
preferences. This is another advantage of this new scheme, the default output
device then become a per user preference instead of a system wide settings, as
it should be.
Regards,
Hans
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
