As I also talked about on #gentoo-dev, ALSA guide should tell users to prefer alsa-driver to in-kernel drivers, as they have quite a few problems sometimes. Leaving a part 2.6.12 related problems (which also are resolved using alsa-driver), there are troubles when alsa-lib and alsa-driver uses different versions (it is the case for stable tree, too, as the current alsa-lib is 1.0.8, but linux 2.6.12 uses alsa 1.0.9_rc2, while latest alsa is anyway 1.0.9b). There were a few bugs reported to media-video of mediaplayers crashing with alsa-related stuff due to alsa-lib and alsa-driver mismatch, and a few related to 1.0.8 alsa, too. There were also non reported problems with xine and amarok crashing randomly caused by in-kernel drivers, too. Finally, using alsa-driver is easier for developers to find and fix a bug with a program than having to search for the exact alsa-driver used by one kernel with patches applied. CCing sound and video to see if someone has other to add to that. Thanks, Diego
well, i've been using alsa-driver ever since i dropped oss, and it has worked wonderfully for me. it is necessary to reemerge alsa-driver after installing a new kernel. however, it is a simple matter to create a small script to do that for you, and tack `emerge alsa-driver` on the end. the combined compile time is comparable since new kernel versions require recompilation of alsa anyway. there is one small problem i've come accross, though. when emerging alsa-driver, i have experienced collisions with the kernel files. FEATURES=collision-protect needs to be disabled to prevent problems
Well, using the in-kernel ALSA code makes the process easier for the end user. Afaik, the alsa-driver package should only be used when the in-kernel ALSA code is insufficient, which is quite easy to find out (just try :). After all, if the in-kernel ALSA code works, then the alsa-driver has no additional benefit for the user. The guide currently talks about both, gives pro and cons, so in my opinion the user is well informed about the situation as it is.
It does the process a little simpler to users, but it makes it more problematic for who needs to manage the bugs. alsa-driver is simpler to manage because the code is there, with a decent version number, and quicker fixes. I still prefer if it's possible to ask users to try alsa-driver before in-kernel drivers. The little more work from their side save us from many bugs.
(In reply to comment #0) I disagree. > there are troubles when alsa-lib and alsa-driver uses different versions (it is the case for stable tree, too, as the current alsa-lib is 1.0.8, but linux 2.6.12 uses alsa 1.0.9_rc2, while latest alsa is anyway 1.0.9b). This is not true - the API is compatible since 0.9x. There have been a couple of problems - bugs - which were fixable and were fixed. > There were a few bugs reported to media-video of mediaplayers crashing with alsa-related stuff due to alsa-lib and alsa-driver mismatch, and a few related to 1.0.8 alsa, too. The mismatch bug was fixed in gentoo-sources, and we fixed the ALSA 1.0.8 issues in-kernel too, if we are thinking of the same bugs. > There were also non reported problems with xine and amarok crashing randomly caused by in-kernel drivers, too. Can't do much about unreported bugs. > Finally, using alsa-driver is easier for developers to find and fix a bug with a program than having to search for the exact alsa-driver used by one kernel with patches applied. I don't understand this argument. But, my thoughts are in terms of simplicity for end users -- developers can do their own thing without following the docs word-for-word. (In reply to comment #3) > It does the process a little simpler to users, but it makes it more > problematic for who needs to manage the bugs. > alsa-driver is simpler to manage because the code is there, with a decent > version number, and quicker fixes. > > I still prefer if it's possible to ask users to try alsa-driver before > in-kernel drivers. The little more work from their side save us from many > bugs. You can argue exactly the same the other way - they can use the kernel drivers first, and if there is a problem, they can resort to alsa-driver to see if it has been fixed in newer versions. As for why I think in-kernel should be the recommended default, its mostly for simplicity and consistency. You don't have to emerge (most) other parts of the kernel seperately. And where there are external kernel module ebuilds, we are dropping them when they get included mainline. When you rebuild your kernel, external alsa-driver doesn't get rebuilt automatically. If you've changed some kernel options, you'll get unresolved symbols or just nasty behaviour. Try searching the forums for "alsa unresolved symbol". This doesn't throw up half the results I'm looking for but gives a general idea. However, these problems are avoided if you use in-kernel drivers. As for bugs in the kernel releases - yes - there occasionally are some. Just the same as there are bugs in alsa-driver releases where that version is not yet available in the mainline kernel. We fix the bugs in the kernel, at least the ones that are reported to us. We also add new hardware support from upstream alsa-driver on request, as well as ALSA feature patches where they help compatibility. Some of these patches we include straight from the ALSA tree - before the functionality is even available in alsa-driver tarballs. I wouldn't have a problem recieving (bugfix) patches from newer alsa-driver, like the old ebuild maintainers used to provide me with. I've been missing these recently. Last point, the kernel development cycle is speeding up again, so the amount of time where there is a significantly newer alsa-driver version available in portage will be reduced again. It's good that we provide both options, and that we give plenty of detail on both in the documentation - I'm not suggesting we hide or ignore alsa-driver. Just as the default way of doing things, I think in-kernel makes more sense.
Also if version mismatch *should* be fixed, I got cases in which the mismatch created random crashes. The problem is that most people doesn't report "random" crashes (and they are quite right on this generally, as we can do little for crashes which haven't a pattern). About the unresolved symbols, a simple alias or script to rebuild system is good enough.. most of the users already have external modules to rebuild anyway. The problem is: i get a lot of reports of software crashing (randomly or not) which gets fixed by alsa-driver... I'm quite annoyed by this as I need to handle them. If somebody wants to create an alsa herd to take care of both in-kernel and alsa-driver drivers, that's good enough. I just can't handle both, so I'll just accept (so start investigating) bugs with alsa-driver, as that's something I feel I can handle.
Thats fair enough. Do you find it easy to judge whether a specific problem is caused by alsa-lib or alsa-driver? If so, you could reassign driver bugs (where they are using the in-kernel drivers) to kernel, and take care of the alsa-driver bugs yourself. Alternatively you can ask them to try and reproduce while using alsa-driver. This certainly is far from optimal but I think you're saying that you don't have the time to diagnose issues with the kernel code. I'm in a similar situation - not enough time to work outside of kernel stuff. Perhaps we should recruit a liaison. Are there others on sound herd who are interested in this sort of thing, or are you fairly understaffed like kernel?
Actually, I usually just ask people to use alsa-driver and report back. Unfortunately after the new alsa guide people started replying me "but guide tell to use in-kernel drivers". From here the problem. For me just having a note saying that in-kernel drivers *can* be cause of problems and alsa-driver should be tried before reporting problems is enough at this point.
(In reply to comment #7) > For me just having a note saying that in-kernel drivers *can* be cause of > problems and alsa-driver should be tried before reporting problems is enough > at this point. i'd prefer this change ... my personal experience has been that alsa-driver never worked without a huge pita and in-kernel driver always worked without me doing anything, but that's just me ;P
As a user, I am *very strongly* against the idea of having to manually remerge alsa-driver everytime I recompile the kernel. I prefer just picking ALSA modules in-kernel, and living happily ever after. It is possible that I don't represent the average Gentoo+ALSA user. I like the suggestion of asking that the user to try alsa-driver before reporting bugs. Perhaps this can be a note at the end of the current ALSA guide. Alternatively, if we can have a external-alsa USE-flag for the kernel which forces a remerge of alsa-driver (is this even possible?) every time the kernel is remerged, the user might be more inclined to use alsa-driver.
(In reply to comment #7) > Actually, I usually just ask people to use alsa-driver and report back. > Unfortunately after the new alsa guide people started replying me "but guide > tell to use in-kernel drivers". I'm fairly used to this sort of thing anyway. When people report a kernel bug (ALSA or not), we ask them to reproduce it on the development kernel, e.g. 2.6.13-rc2. Sometimes we get a response, "An -rc kernel? Surely that might be unstable?". Yeah, correct, there might be some bugs still around. But all we're asking is (e.g.) that they boot it up, wiggle the mouse around, and see if the cursor moves.... You might have more success asking them to 'try' alsa-driver. If it solves their problem, they will probably stick with it anyway. > For me just having a note saying that in-kernel drivers *can* be cause of > problems and alsa-driver should be tried before reporting problems is enough > at this point. I don't see any problems there.
(In reply to comment #8) > i'd prefer this change ... my personal experience has been that alsa-driver > never worked without a huge pita and in-kernel driver always worked without me > doing anything, but that's just me ;P I've had the *exact* same experiences as Spanky, alsa-driver has always been a PITA ;)
How about this : I add a small note asking users to try alsa-driver in case they have issues before filing a bug. Would that be okay Diego?
Ok that's a good compromise :)
Yet another <note> in an already very colourful guide ? Why not add something like "+ Might work for you if the kernel modules do not" in the pros/cons table of alsa-drivers and mention that alsa-drivers should be tried before filing a bug about alsa in the <p> that recommends kernel modules?
(In reply to comment #14) > Yet another <note> in an already very colourful guide ? > Why not add something like > "+ Might work for you if the kernel modules do not" > in the pros/cons table of alsa-drivers and mention that alsa-drivers should be > tried before filing a bug about alsa in the <p> that recommends kernel modules? Sounds perfect. (In reply to comment #13) > Ok that's a good compromise :) Yes, we have a deal then :D
(In reply to comment #14) > Yet another <note> in an already very colourful guide ? Heh. Makes things more interesting, yes? :) > Why not add something like > "+ Might work for you if the kernel modules do not" > in the pros/cons table of alsa-drivers and mention that alsa-drivers should be > tried before filing a bug about alsa in the <p> that recommends kernel modules? Just an observation - this needs to be phrased carefully. If *I* had read this as it is above, I'd go with alsa-driver regardless of all else, because it implies: a) That the kernel version stands a reasonable chance of not working b) The alsa-driver always works (contrary to the experiences of SpanKY and Shyam) I might be nitpicking, though.
The following text has been added to the guide : Since this does not make any huge difference as such, you are encouraged to use the ALSA provided by the kernel for ease of use. Before reporting any sound related issues to Gentoo Bugzilla, please try to reproduce them using alsa-driver and file the bug report no matter what the result. Thanks for your inputs everyone!
