30 Dec
2011
30 Dec
'11
7:34 p.m.
Hello everyone,
The setup has worked for many years. M-Audio 1010LT on Fedora 8. I
know, old OS, I should update. Nevertheless, it worked nicely... until
yesterday when suddenly mplayer would stop right in its track whne
starting to play a .flv file. Same with xine: it freezed at the
beginning of an ogg file, w/o any further error msg.
Rebooting the machine, a KDE error was shown reporting that the
sound device was not there. Indeed, there is no /dev/dsp. And, lspci
does not list the audio card. In this case, dmesg reports nothing
about the audio card, no good news, no errors.
Rebooting a few times shows that sometimes dmesg does report:
ACPI: PCI Interrupt 0000:01:06.0[A] -> Link [APC1] -> GSI 16 (level,
low) -> IRQ 16 PCI: Setting latency timer of device 0000:01:06.0 to 64
invalid EEPROM version 0
invalid CS8427 signature 0x0: let me try again...
unable to find CS8427 signature (expected 0x71, read 0x0),
initialization is not completed
CS8427 initialization failed
ACPI: PCI interrupt for device 0000:01:06.0 disabled
ICE1712: probe of 0000:01:06.0 failed with error -14
... Which is about the 1010lt.
At other boot times the dsp device shows up but there's no audio, with
'mplayer -msglevel all=7 <file>' reporting:
[AO_ALSA] Playback open error: Connection refused
Failed to initialize audio driver 'alsa'
AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
Starting playback...
What would this be really about ? Is this a case of a failing 1010lt
card after so many years ? Can it suddenly fail anyways ? Or is it
a power supply that fails to deliver the necessary voltage to the
1010lt ? Or would it be a motherboard whose PCI tracks are getting
off the pcboard (or something like that) ?
There was no software change made to the Fedora 8 OS. Is there a way
to be certain of which component is failing ?
Thanks for any suggestions, observations and comments. The audio
component of the machine is quite useful and after a day now I
already miss it and do not know how to approach this problem. I
would not want to go out on a shopping spreee for a new MB (CPU, RAM)
or/and new power supply or 1010LT card without knowing what is going
on.
30 Dec
30 Dec
7:59 p.m.
On Fri, 30 Dec 2011 13:35:10 -0500
jonetsu <jonetsu(a)teksavvy.com> wrote:
What would this be really about ? Is this a case of
a failing 1010lt
card after so many years ? Can it suddenly fail anyways ? Or is it
a power supply that fails to deliver the necessary voltage to the
1010lt ? Or would it be a motherboard whose PCI tracks are getting
off the pcboard (or something like that) ?
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.
If you've never seen a problematic capacitor, I have some photos at
http://delta.brainiac.com/delta1010capfix.html that show a bulging
top on one.
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.
Good luck!
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
8:15 p.m.
On 31/12/11 07:59, Joe Hartley wrote:
On Fri, 30 Dec 2011 13:35:10 -0500
jonetsu <jonetsu(a)teksavvy.com> wrote:
> What would this be really about ? Is this a case of a failing 1010lt
> card after so many years ? Can it suddenly fail anyways ? Or is it
> a power supply that fails to deliver the necessary voltage to the
> 1010lt ? Or would it be a motherboard whose PCI tracks are getting
> off the pcboard (or something like that) ?
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.
Also try card in another PCI slot if there is one available.
31 Dec
31 Dec
3:43 a.m.
On Fri, 30 Dec 2011 13:59:36 -0500,
Joe Hartley <jh(a)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,
Al
3:50 a.m.
On 31/12/11 15:43, jonetsu wrote:
On Fri, 30 Dec 2011 13:59:36 -0500,
Joe Hartley <jh(a)brainiac.com> wrote :
Hi Joe,
You could try a more up to date Linux live cd and see how that works
with the sound on that system.
Ross.
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,
4:28 a.m.
On Sat, 31 Dec 2011 15:49:50 +1300,
Ross Hamblin <rosscoad(a)gmail.com> wrote :
Hi Ross,
You could try a more up to date Linux live cd and see
how that works
with the sound on that system.
That's an idea. Is there a Live CD/DVD that would be more suited for
audio purposes ?
Al
5:11 a.m.
On 31/12/11 16:29, jonetsu wrote:
On Sat, 31 Dec 2011 15:49:50 +1300,
Ross Hamblin <rosscoad(a)gmail.com> wrote :
Hi Ross,
I have used avlinux in the past and had good experiences with it. It is
debian based though so not sure how that will fit with your fedora
experience.
Ross.
You could try a more up to date Linux live cd and
see how that works
with the sound on that system.
That's an idea. Is there a Live CD/DVD that would be more suited for
audio purposes ?
6:35 a.m.
On 12/30/2011 10:29 PM, jonetsu wrote:
But if it WAS working with his distro, it should STILL be working with
his distro. If it's been working for 3 years up until yesterday, there
is no reason to expect that upgrading the distro will magically fix it.
My vote is for component failure on the audio card, or a bad MUX.
You could try
a more up to date Linux live cd and see how that works
with the sound on that system.
That's an idea. Is there a Live CD/DVD that
would be more suited for
audio purposes ?
7 a.m.
On 31/12/11 18:35, Al Thompson wrote:
On 12/30/2011 10:29 PM, jonetsu wrote:
But if it WAS working with his distro, it should STILL be working with
his distro. If it's been working for 3 years up until yesterday, there
is no reason to expect that upgrading the distro will magically fix it.
My vote is for component failure on the audio card, or a bad MUX.
I agree it is likely to be a hardware issue and that the live cd will
not magically fix anything. I suggested using live-CD to avoid upgrading
the distro, and I do think that testing with cd will help to confirm it
is a hardware problem at relatively small cost which is what the
original post was about.
Ross.
You could
try a more up to date Linux live cd and see how that works
with the sound on that system.
That's an idea. Is there a Live CD/DVD that
would be more suited for
audio purposes ?
2:36 p.m.
On Sat, 31 Dec 2011 00:35:48 -0500,
Al Thompson <althompson58(a)gmail.com> wrote :
But if it WAS working with his distro, it should STILL
be working with
his distro. If it's been working for 3 years up until yesterday,
there is no reason to expect that upgrading the distro will magically
fix it.
That's what I would think. If the one instance of a boot in which the
EEPROM of the 1010LT could not be read is put aside, everything else
points to a recognized card. This is the latest state in which the
system was left in. The problem was that the alsa layer was giving out
a 'connection refused' error, even with alsamixer. OTOH, running
'alsamixer -Dhw' would actually run alsamixer and would show all
controls for the 1010LT.
I do not know what the -Dhw option does precisely. Bypasses the alsa
layer to access the hardware directly ?
In any case I did a quick search and just about the first audio live
distro I found was Tango Studio, Ubuntu-based. But in the end Linux is
Linux. Debian/Ubuntu folks are not doing that much actual development I
think (might be wrong). Actually, I have the impression there's much
more Linux development on the Red Hat side (SystemTap, etc...).
Anyways, booting with Tango Studio, mounting the partition with the
audio/flash files and throwing the Tango Studio mplayer at them... works
all the way. Video and sound are just fine. I could have tried Ardour
while at it, but didn't.
My vote is for component failure on the audio card, or
a bad MUX.
Rebooting into Fedora 8 then gives out the same alsa problem as before.
Likely something has changed in the F8 system. Using a live CD turned
out to be a good test after all.
I mentioned that from time to time throughout the years I had to
sometimes switch the LAN cable from eth0 to eth1 because on certain
boots, for some reason, the F8 system (probably udev who is assigning
interface devices) would think that nope, the configured IP now goes to
eth1. At other times it'd think that it had to go to eth0. So I
switched the LAN cable accordingly when seeing that ;-) Actually I
have an alias that I use to check the IP before starting any web
app ;-))
Maybe something like that is happening now that affects *somehow* the
interface to the 1010LT, even though the /dev/dsp device exists and a
bunch of other details shows that the 1010LT is present.
At that point I would need to troubleshoot the alsa layer, how
it is brought up, etc... Maybe I can subscribe to the alsa mailing
list.
Thanks for all the help ! I'd appreciate any other troubleshooting
suggestions to perhaps be able to fix this F8 system w/o upgrading
right now.
Cheers,
Al
5120
days inactive
5121
days old
linux-audio-user@lists.linuxaudio.org
9 comments
4 participants
participants (4)
-
Al Thompson -
Joe Hartley -
jonetsu -
Ross Hamblin