Beside the fact that being _the only one_ who's currently supporting ALSA in Gentoo, I should be the one deciding what the users should be suggested to use -- but seems like GDP and logic on this issue are on opposite point of the universe -- the current text concerning the difference with in-kernel and alsa-driver is plainly wrong. It's no more (since a lot of time) a concern of freshness of the code in them: you can see older version numbers when using in-kernel drivers but they might actually fix some bugs compared to alsa-driver, especially when it comes to kernel support (that is, in-kernel drivers always _build_, it's not ensured they work though, see the _rc* versions that does not really work with external drivers most of the time). The point is that in-kernel and alsa-driver are _two different branches_ of ALSA drivers, that behave vastly differently, and this is going to show even more in the future. Please cut the crap like "Pretty stable as drivers are integrated into kernel." (it's untrue that if they compile they are stable, they might be crashing badly at use). They _might_ be fine to use with now-stable drivers like emu10k1 that does not change that much between one release and the other, but for stuff that's always in development like via82xx, or even worse the hda-intel driver, nowadays pretty widespread, it's probably a good choice _not_ to use in-kernel drivers, as a new bug can be reported to alsa's bugtracker when it comes out of alsa-driver only. And if you put "Needs certain kernel config options disabled to work correctly." as a disadvantage for alsa-driver, you should put "Needs certain kernel config options enabled to work correctly." for in-kernel, after all they are the same exact set of options: the ALSA drivers theirselves. Sigh, I really hate the way you put down that guide as you're going against the only person that's working on ALSA in Gentoo, but if you think of knowing more than me, at least get the facts straight please. Thanks.
(In reply to comment #0) > Sigh, I really hate the way you put down that guide as you're going against the > only person that's working on ALSA in Gentoo, but if you think of knowing more > than me, at least get the facts straight please. Diego, the kernel team has repeatedly stated through Daniel that they *do* support the kernel-based drivers. Please don't feel that we (the GDP) are pushing something to our users. There's no consensus between you and the kernel team about this issue, AFAIK, so we're just keeping the stuff that we (the GDP, especially Shyam Mani, Josh and me, IIRC) decided about several months ago. As a sidenote, our performance would be slightly improved by grouping related issues together instead of one bug :).
And the kernel team failed to provide a liason for ALSA herd, which puts us back to square one. They support in-kernel drivers but _I_ support the library, the headers, all the else. So I'm not asking to *remove* in-kernel driver support, but as _I_ am the one handling most of the bugs _I_ want to decide what users are suggested to.
Created attachment 108698 [details, diff] alsa-guide.xml.patch Okay, here's what I have so far. Note that this includes fixes for all the ALSA bugs. I post it here because a large part of the debate is in-kernel vs. alsa-drivers. Kernel team and Diego, please review. Same to you GDP-ers. :p This is (I feel) a nicely worded balance that takes everything into account and provides a more neutral middle ground, with neither ALSA method emphasized over the other.
I stand by my earlier views in that kernel should maintain the drivers and alsa herd should maintain the userspace stuff, and that users should be encouraged to use the in kernel stuff (i.e. alsa-driver package should not exist, well, should be for 2.4 users only) A liason thing MIGHT work but has the downside that it requires someone in kernel to do more work than they already do, and the same might also apply for the ALSA side. This just isn't going to happen on the kernel side right now, due to being very behind already and not having any real manpower in the first place. Entirely offloading the drivers stuff to the kernel maintainers is the only way that I can think of which actually reduces workload, which in my eyes is an obvious requirement for any changes we're going to make to this process. I'm not going to argue this any further as I already know that you aren't keen on that approach and I'm not expecting you to change your mind just from reading this (although you know I would welcome that anytime). I'm just stating my viewpoint, and actually it doesn't really make much difference for me as I continue to support ALSA drivers either way. Yes, this dual maintenance thing does complicate your work, it also causes me some minor headaches, but the things you write about in the top comment seem to be driver issues which do fall upon the kernelspace portion and I am happy to handle when users file bugs (this does already happen and is working). I don't deny that there are OTHER complications in this, but it seems like you are now arguing a different case. Anyway, although we disagree on this I do really appreciate your work and the userspace part works flawlessly for me thanks to your efforts. I'm signing out of this discussion before things get messy :)
There's an unescaped > while talking of udev. Remove all of ALSA_TOOLS references, the current ebuilds work just fine without and I'm going to remove it tomorrow, so please don't put it there anymore, as I said (see why I wanted to track the changes separately?). And I *do not want* that the users still get "encouraged" to use in-kernel drivers; they might get support by kernel team (yet to prove), but that does not make kernel team able to dictate what users should be encouraged to do from ALSA point of view. So let's put it bluntly: either you remove the encouragement of a practices that I discourage entirely, or you can get your whole guide out, or you're up to maintain ALSA yourselves. Having handled ALSA alone for a long time now, I think I deserve to be able to choose what to suggest users to do. Especially because it's me who get the bugs. I think most of the bugs don't hit me directly anymore because Jakub takes care of asking people to try alsa-driver before. If you want, I can make people who gets their soundcard working through alsa-driver open a new bug for GDP requiring the guide to be fixed, but I'd rather resolve this before. Especially because I'm not going to change my position on the matter while I'm alone doing the work on the herd. And that situation didn't change even if I asked _repeatedly_ for help. So, can I get the situation corrected without escalations, or do I have to ask devrel to take a look to who's handling ALSA up to now between me, "Kernel Team" (I heard only Daniel talking about ALSA, fwiw) and GDP? Yes this time I'm royally pissed off.
(In reply to comment #5) > There's an unescaped > while talking of udev. That's fine, it doesn't need to be escaped in this case because it's not in a <pre>, so guidexml is okay with it. > Remove all of ALSA_TOOLS references, the current ebuilds work just fine without > and I'm going to remove it tomorrow, so please don't put it there anymore Done > And I *do not want* that the users still get "encouraged" to use in-kernel > drivers; they might get support by kernel team (yet to prove), but that does > not make kernel team able to dictate what users should be encouraged to do from > ALSA point of view. > > So let's put it bluntly: either you remove the encouragement of a practices > that I discourage entirely, or you can get your whole guide out, or you're up > to maintain ALSA yourselves. We will take out the word "encourage", if you like, but for the guide, *the order of steps* will still be kernel first. You can make of this what you like, but the fact is that I have made the guide much more neutral in terms of methods. They do each get comprehensive, fair treatment. And as long as both the kernel team are working on alsa and you (or someone else) is working on alsa-driver, both methods will be discussed, just like both eselect and the existing changing mechanism are mentioned for timidity *because there is no single path*. > Having handled ALSA alone for a long time now, I think I deserve to be able to > choose what to suggest users to do. And the kernel folks who maintain the in-kernel alsa should also be able to suggest what users should do first, as well. The kernel folks have to deal with the pluggable sound layer etc (CONFIG_SOUND etc., which I'm sure you know about). so their input is vital as well. > Especially because it's me who get the > bugs. I think most of the bugs don't hit me directly anymore because Jakub > takes care of asking people to try alsa-driver before. If you want, I can make > people who gets their soundcard working through alsa-driver open a new bug for > GDP requiring the guide to be fixed, but I'd rather resolve this before. > > Especially because I'm not going to change my position on the matter while I'm > alone doing the work on the herd. And that situation didn't change even if I > asked _repeatedly_ for help. Then let's get the word out in the GWN about help is needed for the ALSA packages. > So, can I get the situation corrected without escalations, or do I have to ask > devrel to take a look to who's handling ALSA up to now between me, "Kernel > Team" (I heard only Daniel talking about ALSA, fwiw) and GDP? > > Yes this time I'm royally pissed off. > Diego, watch your temper. I'm worried that you're either going to piss off me or the GDP or the kernel team, and that will not help anyone, especially not if you are angry and aren't willing to listen or see a different point of view. You're escalating things with your inflammatory words here, and you know it. No one else has escalated anything *before your comment*.
The "kernel team", alias only Daniel who's the only one who ever talked about in-kernel ALSA as far as I know, has no more right than me on this issue for sure, so you either consider them both at the same level or you get to maintain ALSA yourself, that's the base of it. I'm sick tired of being told what to do by someone else who has NO concern about handling the bugs, and no, I'm not referring to you Josh, as we were talking about making it more _neutral_. But for sure, I'm not going to being told what to suggest users by GDP on this case, so I put it bluntly, either you drop that encourage, and stop valuing Daniel's word more than mine, or your own experience that in this case counts nothing as you're not receiving alsa-bugs emails, or you're up to find a new ALSA maintainer, this has to be clear. I don't care if I piss off you, GDP, Daniel or the kernel team, because _you_ pissed off me already, by ignoring repeatedly my requests as the ALSA maintainer. And yes, I tried already every damn channel to find help, and nobody ever helped, *included kernel team*. Besides, a literal > might work with GuideXML by chance, but it's not supposed to be there for general XML.
Created attachment 108704 [details, diff] alsa-guide.xml.patch , revised Okay, what about this patch instead?
(In reply to comment #7) > The "kernel team", alias only Daniel who's the only one who ever talked about > in-kernel ALSA as far as I know, has no more right than me on this issue for > sure, so you either consider them both at the same level or you get to maintain > ALSA yourself, that's the base of it. > > I'm sick tired of being told what to do by someone else who has NO concern > about handling the bugs, and no, I'm not referring to you Josh, as we were > talking about making it more _neutral_. Now, this is a switch from what you've been saying all along. First, you made it clear that you wanted alsa-driver preferred over in-kernel by default. At least, that's the way it reads. Now you're switching and you want it neutral? I've been working toward neutral all along, in hopes of a compromise since you're simultaneously claiming that you have no more right to changes than the kernel team YET you're also saying that alsa-driver should be preferred over in-kernel. This doesn't track well at all; it's just confusing things. Is the more neutral way I've been revising the guide acceptable?
What I *want*, is to have alsa-driver preferred to in-kernel, simplifies my work as an ALSA maintainer, is less likely to hit users in the back. I would have said that in-kernel was unsupported, but seems like "Kernel team" supports that for some arcane reason - as bugs in kernel that reflects on userland still gets routed my way - and thus I had to put that out of discussion. What I *can accept* is to have it neutral, and your patch is absolutely better than the current situation on this. This is what we were talking on IRC, no? I try to be open to compromises most of the time, but I don't intend the compromise being "you suck, kernel team has more voice than you, and gdp decided already". What I *won't accept ever* is to have in-kernel "encouraged" to users, as that is making my maintainer work ten times more complicated, as I repeatedly expressed.
(In reply to comment #10) > What I *want*, is to have alsa-driver preferred to in-kernel, simplifies my > work as an ALSA maintainer, is less likely to hit users in the back. I would > have said that in-kernel was unsupported, but seems like "Kernel team" supports > that for some arcane reason - as bugs in kernel that reflects on userland still > gets routed my way - and thus I had to put that out of discussion. > > What I *can accept* is to have it neutral, and your patch is absolutely better > than the current situation on this. This is what we were talking on IRC, no? I > try to be open to compromises most of the time, but I don't intend the > compromise being "you suck, kernel team has more voice than you, and gdp > decided already". > > What I *won't accept ever* is to have in-kernel "encouraged" to users, as that > is making my maintainer work ten times more complicated, as I repeatedly > expressed. > Okay. I've heard your views, and Daniel's expressed his views as well. I think the latest patch I posted, in which I specifically changed the phrase/paragraph about "encouragement" of one over the other, is sufficient. Both methods are valid and do have support, regardless of whose headache it is. So, unless I hear some last minute requests by you, the second patch (not the first) will go in as-is.
(In reply to comment #7) > Besides, a literal > might work with GuideXML by chance, but it's not supposed > to be there for general XML. False, please see [1]. It doesn't form the string "]]>" in that doc. [1] http://www.w3.org/TR/2006/REC-xml-20060816/
from the revised attachment: +You can use more than one sound card in your system <e>and</e> you have built +ALSA as modules in your kernel (or have installed <c>alsa-driver</c>); you just +need to specify which should be started first in +<path>/etc/modules.d/alsa</path>. Your cards are identified by their driver The first sentence doesn't make sense to me. Could you please rephrase it to sound clearer?
Feel free to see some parsers explode quite nicely with that. You gotta love specifications, especially when they don't always apply to everything. I talk by personal experience, as I've seen also W3C's parser die up with a similar > put in the wrong context (and not forming ]]> either).
(In reply to comment #13) > from the revised attachment: > The first sentence doesn't make sense to me. Could you please rephrase it to > sound clearer? Oops, good catch. Looks like I started re-editing in midsentence and forgot to finish what I had done. Fixed.
Created attachment 108706 [details, diff] alsa-guide.xml.patch Revised. Diego, the parser isn't the issue as much; xmllint thinks it's just fine. We're trying to move away from ascii escapes such as > because all of our documents are in Unicode, and are displayed in Unicode on g.o.
Fixed in CVS, thanks for reporting.
