Bugzilla Bug 176278

There is a problem with alsa-driver and 2.6.20 Core2 kernel profile that has
already been reported a few times (e.g. see bug #175699). 2.6.20 has gone
stable quite a while ago, therefore I suggest either patching the stable
alsa-driver versions with this patch:

http://bugs.gentoo.org/attachment.cgi?id=112847

or stabilizing alsa-driver1.0.14_rc3 which does not require the above patch to
work with the core2 profile

CC:ing arches where we have Core 2 available

don't mark -rc3 stable. It has compile issues on 2.6.20 (yes, moreso than -rc2)

Ok, so let's do the other thing, shall we? ;)

anything new on this? what about the final alsa-driver-1.0.14 which seems to be
released some days ago? :>

Alsa team - anyone? The Core2 kernel profile is not that unpopular

removing amd64 from CC until there's something to do for us ;)

same for x86

The release version of alsa 0.14 is required to build against the newly
stabilized 2.6.21 kernel on x86. Please stabilize.

yes, kernel 2.6.21 is stabilized as well as 2.6.21 headers, we need 1.0.14
stable!

(In reply to comment #8)
> The release version of alsa 0.14 is required to build against the newly
> stabilized 2.6.21 kernel on x86. Please stabilize.

I'm using Pentium III and alsa-driver-1.0.14_rc2-r1 failed to build against
vanilla-sources-2.6.21.6. Version 1.0.14 compiled fine. Looks like 1.0.14
should be stabilized ASAP.

Please, someone add all arches to CC list.

I guess due to bug #183418 the alsa-driver package is no longer prefered and
therefor maintained as it used to be...
This is a bad news for me;
1.0.14 compiled and works for me too, Pentium-M (Banias) on a Thinkpad R51 with
stable gentoo-source-2.6.21-r4.

Please make it stable!

alsa team? anyone?

Hi all, alsa-driver-1.0.14_rc2-r1 don't compile with gentoo-sources-2.6.22-r2
on amd64. Somebody from alsa team should investigate it! This both are stable
versions for platform! 

OK, so it's not the preferred method to get sound drivers, but I thought Gentoo
was about choice?
OK, so it's not very different from in-kernel, but it asks me to confirm any
ALSA issues with alsa-driver before filing bugs. But I try to emerge
alsa-driver and it won't (gentoo-sources-2.6.22-r5 / alsa-driver-1.0.14_rc2-r1
/ x86). So now what do I do?

When I have time I might try and write a 1.0.14 ebuild and then try that, but
it's a load of work for trying to deal with a problem in the loopback driver.
If I do want to migrate to using the kernel ALSA drivers I can't use the
ALSA_CARDS variable I have nicely set up, but have to go and mess with
menuconfig. On every machine I look after. This is a load of admin hassle I
could do without, especially as there is no warning whatsoever in the ebuild
that it is now not the recommended way to do your sound drivers, and I had not
the faintest idea it was coming until I got a compile fail re-emerging after a
kernel upgrade (which is now on hold, pending time to fix this).

That's because this bug was filed right after stabilization of
gentoo-sources-2.6.20. 2.6.21 requires alsa-drivers-1.0.14 (comment #8) and
that's why we have bug #189155

(In reply to comment #14)
> OK, so it's not the preferred method to get sound drivers, but I thought Gentoo
> was about choice?
> OK, so it's not very different from in-kernel, but it asks me to confirm any
> ALSA issues with alsa-driver before filing bugs. 

What asks you to do that? (we should remove that statement)


I'm sorry that in-kernel is a little inconvenient to you, compared to the
out-of-kernel version. For many users it is a little more convenient. But the
real problem is that we have almost no manpower behind alsa-driver --
maintaining kernel code outside of the kernel is a huge task. It's a source of
bugs (including this one) which simply don't exist when kernel code is kept
solely in the kernel.

I don't think anyone has objections to someone improving the maintenance effort
behind alsa-driver. The missing component is "someone".

All further discussions in bug #189155.