[LAU] Audio stopped working - troubleshooting help

[Ross Hamblin]

On 31/12/11 15:43, jonetsu wrote:
> On Fri, 30 Dec 2011 13:59:36 -0500,
> Joe Hartley <jh at brainiac.com> wrote :
> 
> Hi Joe,
> 
>> While it certainly could be a failing card or a PS issue, it might
>> also be a little corrosion on the contacts making the connection
>> problematic. I'd try pulling the card out and reseating it.  If the
>> contacts on the card's PCI connection look a little dirty, you can
>> clean them with a pencil eraser before you put the card back.
>>
>> While you've got the card out, take a look at the components on it and
>> see if there are any visible issues.  I know that the Delta 1010s can
>> have issues with the capacitors, but I don't know if there's a similar
>> issue with any of the 1010LT's components.
> 
> I took the card out.  There was a thin uniform layer of dust ont he
> solder side that I removed carefully.  The component side was clean.
> The capacitors seems OK.
> 
> So I tried the card in another PCI slot.  
> 
>> Also, you might try putting the card in another computer to see if
>> it's recognized.  If the card itself is failing, it should have the
>> same type of issues about being recognized.
> 
> The other machines in the house are Windows 7.  I guess I'd need to
> download some drivers from M-Audio web site if I'd want to try it out,
> but, the 1010LT seems to be perceived by the Fedora system:
> 
> A lspci -v yields:
> 
>  1:07.0 Multimedia audio controller: VIA Technologies Inc. ICE1712
>  [Envy24] PCI Multi-Channel I/O Controller (rev 02)
>         Subsystem: VIA Technologies Inc. M-Audio Delta 1010LT
>         Flags: bus master, medium devsel, latency 32, IRQ 17
>         I/O ports at df00 [size=32]
>         I/O ports at de00 [size=16]
>         I/O ports at dd00 [size=16]
>         I/O ports at dc00 [size=64]
>         Capabilities: [80] Power Management version 1
>         Kernel driver in use: ICE1712
>         Kernel modules: snd-ice1712
> 
> dmesg reports:
> 
>  ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
>  ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [APC2] -> GSI 17 (level,
>  low) -> IRQ 17 sky2 0000:02:00.0: v1.21 addr 0xfe8fc000 irq 17 Yukon-EC
>  (0xb6) rev 1 NVRM: loading NVIDIA UNIX x86_64 Kernel Module  173.14.12
>  Thu Jul 17 18:10:24 PDT 2008 ACPI: PCI Interrupt 0000:01:07.0[A] ->
>  Link [APC2] -> GSI 17 (level, low) -> IRQ 17
> 
> /proc/asound/cards reports:
> 
>  0 [M1010LT        ]: ICE1712 - M Audio Delta 1010LT
>                       M Audio Delta 1010LT at 0xdf00, irq 17
> 
> jackd (qjackctl) starts, but when Ardour tries to playback it reports:
> 
> 20:51:05.450 Audio active patchbay scan...
> ALSA: poll time out, polled for 31999447 usecs
> DRIVER NT: could not run driver cycle
> 
> Which is consistent with mplayer seeing a 'connection refused' from
> alsa:
> 
> # mplayer -msglevel all=5 ajico-3.flv
>  [...]
>  [AO_ALSA] Playback open error: Connection refused
>  Failed to initialize audio driver 'alsa'
>  AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
>  Starting playback...
> 
> And then mplayer freezes right there.
> 
> lsmod lists a whole bunch of sound-related drivers being loaded.
> 
> I also see that /proc/irq/17/ has entries for both eth1 and the ICE1712
> device.  Is this normal that eth1 and the ICE device shares the same
> interrupt ?  From time to time I have to switch the network cable from
> the eth0 to the eth1 jack and back because sometimes the machine boots
> with udev thinking that eth0 is 'it' and at other times udev thinks
> 'eth1' is where the configured IP should be - although this has never
> affected sound before.
> 
> So the card is recognized, which is why I'm not sure about trying it
> out in a Windows machine.  For the moment it looks like alsa has some
> problem.  Why would it have a problem since yesterday and can such a
> problem happen w/o any software update or any other system modification
> is a big mystery.
> 
> It is a long time I haven't done anything with alsa like
> installing it from scratch and configuring it and doing whatever it
> takes to get it working.  I don't even recall how I configured the
> 1010LT - did I simply put it in and it started working ? ;-)
> 
> Are there ways to poke at the alsa subsystem and see anything ?  Is it
> possible to write in certain files in /proc to see anything ?  Can the
> same be done to get straight access to the 1010LT card like dump of
> registers or anything that would show something ?
> 
> What is this state in which the 1010LT is seen by the system but
> software cannot playback to it via alsa ?  
> 
> Thanks a lot for any suggestions - greatly appreciated.  I will
> certainly share back any finding I make to solve this.
> 
> Cheers,

You could try a more up to date Linux live cd and see how that works
with the sound on that system.

Ross.