On Tuesday 30 May 2006 8:37 pm, Hamish Moffatt wrote: > > Does the kernel (via dmesg or kern.log) report any errors? Unknown codec > does sound like a problem. It's most likely a driver issue and not > something you can fix except by upgrading ALSA.
some clues there. kern.log: May 30 06:26:53 slt kernel: input: PC Speaker as /class/input/input2 May 30 06:26:53 slt kernel: ACPI: PCI Interrupt 0000:00:14.5[B] -> Link [LNKB] - > GSI 10 (level, low) -> IRQ 10 dmesg: MC'97 0 converters and GPIO not ready (0x1) input: PC Speaker as /class/input/input2 ACPI: PCI Interrupt 0000:00:14.5[B] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 From lshw id 14.5 is the sound card: *-multimedia description: Multimedia audio controller product: IXP SB400 AC'97 Audio Controller vendor: ATI Technologies Inc physical id: 14.5 bus info: [EMAIL PROTECTED]:14.5 version: 02 width: 32 bits clock: 66MHz capabilities: bus_master cap_list configuration: driver=ATI IXP AC97 controller resources: iomemory:c0003400-c00034ff irq:10 I notice from these same three locations (dmesg, kern.log and lshw) that ndiswrapper is also using irq:10. Maybe its the (very old) DOS memories, but could that be causing the problem? I noted the entry in the dmesg output saying "If a device doesn't work, try "pci=routeirq". " That raises two questions: (1) would this apply to my situation? and (2) is that a kernel param similar to noapic? > Which kernel do you have? I have 2.6.15-1-amd64-generic > > Just an aside, another person responded by saying to "use udev, that > > should take care of the devices." As far as I can see, udev is being > > used, but I don't know enough about udev to know how I can correct this > > problem. > > udev creates the relevant entries in /dev/snd, but it won't be the cause > here. That helps. Thanks. Scott
