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 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. -hwh -- [EMAIL PROTECTED] mailing list
