Hi,

On Sat, 13 Oct 2007 22:23:35 +0800
"Chuanwen Wu" <[EMAIL PROTECTED]> wrote:

> Yes,both my Windows XP and another linux os Redflag have sound. Is
> there anyway that I can use  the Redflag's modules to driver my
> gentoo?

Only by using its kernel, too. Then you would just copy the kernel (and
initrd, if needed, but this might be a bag of problems if the initrd
depends on stuff from the base system) from /boot and the according
module tree from /lib/modules.

I think it would at least be interesting what /proc/asound/version is
like on the redflag distro. Also it would be interesting if they use
in-kernel ALSA or separate drivers and if the latter is the case, then
they might provide source packages -- which potentially include patches
that add support for your device.

Before trying all that: Did you had a look at the kernel log (use
"dmesg")? Were there errors or warnings around the lines that were
printed when the ALSA driver was loaded?

When you emerge alsa-drivers, also make sure that there are no stale
in-kernel modules in /lib/modules/$(uname -r)/kernel/sound/*. You can
delete them manually, just run "depmod -ae" afterwards.

> Where can I get the audio related kernel log output?

look at the output of "dmesg" (e.g. piping it to "less": dmesg|less).
However, for me (different card and all works well), there is zero
output. You might change that by enabling ALSA debug output in kernel
configuration, though... But I'm not sure whether that's worth it.

> > In any case, you should probably use the separate alsa-driver from
> > portage, preferably the newest (unstable in portage) version. There
> > were many changes (some of them adding support for more devices for the
> > hda driver) that are not yet in the kernel ALSA tree.
> >
> I have tried the version (~)1.0.15_rc2,which I heard from someone in
> some webpages that it could drive my hda sound card,but it still can't
> in my machine.

The newer ALSA versions are at least supposed to handle the hda better
w/ regard to supported hardware configurations. Doing a little
recherche for the little I know about your laptop, I came across this
thread:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg20707.html
which seems to indicate similar problems which were partly solved by a
newer version of alsa-driver. When experimenting with out-of-kernel
drivers, always keep an eye on potential conflicts in 
/lib/modules/$(uname -r), and compare /proc/asound/version against what
you think it should be.
The thread also indicates that problems with HDA based audio is not a
seldom thing to see.

You can download newer versions of alsa-driver from their homepage and
experiment with it in /usr/local/src. Currently they offer -1.0.15rc3,
you might want to try it, it lists changes w/ regard to the hda driver.
http://www.alsa-project.org/

> And the one of version 9999, I think I can never emerge it:
> >>> Emerging (1 of 2) media-sound/alsa-headers-9999 to /
>  * checking ebuild checksums ;-) ...                                     [ ok 
> ]
>  * checking auxfile checksums ;-) ...                                    [ ok 
> ]
>  * checking miscfile checksums ;-) ...                                   [ ok 
> ]
> >>> Unpacking source...
>  * hg clone http://hg.alsa-project.org/alsa-kernel ...
> real URL is http://hg.alsa-project.org/alsa-kernel/
> requesting all changes
> adding changesets
> 
> The network is so slow and this status has already keep couples of  hours.

Yes, that's the culprit with distributed versioning systems. You have
to download the full change history. I've not used mercurial recently,
so I don't have a suggestion how to only download HEAD or something
like that, if that's possible at all.

I think at the moment there is no point in using a current Mercurial
checkout. From what I see on
http://hg-mirror.alsa-project.org/alsa-driver/
the last changes after 1.0.15rc3 don't matter in your case, so start
trying that (as said, you can download it from their homepage).

-hwh
-- 
[EMAIL PROTECTED] mailing list

Reply via email to