The problem is fixed now! I tried the alsa-driver-1.0.14_rc3, which is used by the Redflag os, and everything is fine, now.
It's very weird. Just as what I mentioned above, the 1.0.14_rc3 version one is a unstable one. I have tried both version 1.0.14,the stable one that come out after 1.0.14_r3, and the 1.0.15_rc2 one, but both of them can't drive my sound card. But now, the 1.0.14_rc3 fixed it! It's a big surprise. 2007/10/14, Chuanwen Wu <[EMAIL PROTECTED]>: > 2007/10/14, Hans-Werner Hilse <[EMAIL PROTECTED]>: > > Hi, > > > > On Sun, 14 Oct 2007 15:25:12 +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. > > > Oh, I just forgot that the Redflag is a i386 OS but the gentoo is > > > amd64 OS. So gentoo can't use the Redflag's modules and kernel(vice > > > versa). > > > > Hm, I see. I think the different IRQs are not really worth mentioning, > > since they get automatically assigned. All that fooling around with > > different versions of ALSA didn't help much, so it boils down to > > - either it's a modified kernel what Redflag uses (I agree they use > > in-kernel ALSA), or > > - it's really an AMD64 vs. i386 matter. > > > > > When I do #modprobe snd_hda_intel(or #alsaconf), I can see the message > > > below appending to the ouput of dmesg: > > > ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 > > > PCI: Setting latency timer of device 0000:00:1b.0 to 64 > > > stac92xx_auto_fill_dac_nids: No available DAC for pin 0x0 > > > > I had a really deep look > > into /usr/src/linux/sound/pci/hda/patch_sigmatel.c, but nothing really > > rings a bell. I think this indicates the problem (since nothing will > > get routed correctly when it fails on the first pin, 0). But I don't > > think the problem is located in the function that prints this error. In > > any case, after printing that error, the initialization of the pin > > routing fails with an error. So it's definately a driver issue, not > > something about machine configuration. > > > > In any case, I think you should report to the alsa mailinglist. FWIW, I > > can't currently access www.alsa-project.org either. You can find the > > subscription interface here: > > https://lists.sourceforge.net/lists/listinfo/alsa-user > > > > I'm sorry that after all this there isn't really much success. One > I am really appreciate for your patience and help. And I have learned > some ways to detect and trace my os's status from you. > > could certainly do more debugging by comparing a 32bit vs a 64bit > > kernel with the exact same config otherwise. That might actually prove > > that there's something fishy. > > > The 64bit os support is not very well at the moment. After I switch to > 64bit os, I have found some applications and driver did not support > 64bit os,like Eclipse. > But thing will get better and better. > > -hwh > > -- > > [EMAIL PROTECTED] mailing list > > > > > > > -- > wcw > -- wcw -- [EMAIL PROTECTED] mailing list
