USB-Sound kackt nach einer Weile immer ab

K

Kuli

Jungspund
Moin,

ich habe ein sehr seltsames Problem. Ich habe eine USB-Soundkarte (Soundblaster Audigy 2 NX), die unter Windows am selben Rechner immer tadellos funktioniert hat. Auch unter Linux habe ich sie nach einigem Krampf zum laufen bekommen; der Krampf dabei war, daß sie partout nur dann irgendeinen Laut von sich gibt, wenn sie nicht am USB-Hub angeschlossen ist, sondern direkt und unmittelbar am USB-Anschluß vom Laptop (Acer Travelmate 280).

Wenn sie am Hub ist, wird sie erkannt, ich kann sie mit dem Mixer aktivieren, aber sobald ich nur ein einziges Byte auf /dev/dsp haue, blockiert dieses, d.h. schon ein echo "bla" > /dev/dsp blockiert und kann nur mit STRG-C abgebroochen werden. Aber direkt am USB funktioniert sie ja, daher ist das hier nicht das Hauptproblem, aber es ist schon seltsam genug.

Das Hauptproblem ist, daß anscheinend der ganze USB-Kanal nach einer Weile Benutzung komplett abkackt und nur durch einen kompletten Warmstart des Rechners wieder zu leben erweckt werden kann. Es passiert nur, wenn die Soundkarte in Benutzung ist, und es ist nicht vorhersehbar, wann das passiert; manchmal kann ich stundenlang ununterbrochen Musik hören, manchmal bricht mir der Sound schon nach fünf Minuten weg. Es passiert nie, wenn ich keinen Sound abspiele, aber es passiert immer irgendwann, wenn ich was abspiele.

Das ganze sieht dann so aus, daß sich die Soundkarte deaktiviert und auch nicht mehr aktiviert werden kann. Das Device /etc/dsp ist völlig verschwunden, genauso wie die entsprechenden mixer usw. alsamixer u.a. melden nur "No such device".

Völlig strange: Wenn der Sound futsch ist, stürzt lsusb vor der Ausgabe des eigentlichen Sounddevices ab, und zwar so, daß es sich nicht mal mehr mit kill -9 beenden läßt, auch läßt sich der Rechner dann nicht mehr vollständig runterfahren. Wenn ich kein lsusb ausgeführt habe., ist das kein Problem.

Unter /proc/asound/cards findet sich nur noch die interne Karte vom Laptop. Die Dateien unter /proc/asound/NX sind noch alle da, melden aber bei Ausgabe nur
Code:
/proc/asound/NX/usbbus: No such device
.

Des weiteren habe ich noch eine wenig aussagekräftige Zeile in /var/log/kernel/current:
Code:
Nov 16 11:25:18 [kernel] hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling...

Auf der Konsole, von der ich X gestartet habe, wird mir ungefähr zehn millionen mal
Code:
ALSA lib pcm_direct.c:1086:(snd_pcm:direct_open_secondary_client) unable to open hardware
ausgegeben.

Das ganze sieht schwer nach einem USB-Problem aus. Allerdings habe ich noch einige andere USB-Geräte am laufen (Maus, Tastatur, zwei externe Festplatten), die alle noch wie geschmiert funktionieren, auch hinter dem USB-Hub. Nur der Sound hat sich verdünnisiert, d.h. nur der externe Sound; die interne Karte macht's noch tadellos.

Ich habe den ganzen Scheiß als Module im Kernel aktiviert, und ich habe das Problem seit 2.6.12-r10 bis jetzt 2.6.14-r2 (Gentoo). Das folgende sind die Ausgaben bei noch funktionierendem Sound:

Code:
[B]lsusb:[/B]
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 002: ID 041e:3020 Creative Technology, Ltd SoundBlaster Audigy 2 NX
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 006: ID 046d:c00e Logitech, Inc. Optical Mouse
Bus 001 Device 005: ID 0d49:7110 Maxtor
Bus 001 Device 004: ID 046a:0001 Cherry GmbH My3000 Keyboard
Bus 001 Device 003: ID 05e3:0702 Genesys Logic, Inc. USB 2.0 IDE Adapter
Bus 001 Device 002: ID 05e3:0605 Genesys Logic, Inc.
Bus 001 Device 001: ID 0000:0000

[B]cat /proc/asound/cards[/B]:
0 [NX             ]: USB-Audio - SB Audigy 2 NX
                     Creative Technology Ltd SB Audigy 2 NX at usb-0000:00:1d.1-1, full speed
1 [I82801DBICH4   ]: ICH4 - Intel 82801DB-ICH4
                     Intel 82801DB-ICH4 with CS4299 at 0xd0080c00, irq 16

[B]cat /proc/asound/NX/usbbus[/B]:
003/002

[B]cat /proc/asound/NX/usbid[/B]:
041e:3020

[B]cat /proc/asound/NX/audigy2nx[/B]:
SB Audigy 2 NX jacks

dig in : ff 00
line in: 01 00
spk out: 01 00
hph out: 01 01

[B]cat /proc/modules[/B]:
...
snd_intel8x0 30304 0 - Live 0xf8bd3000
snd_ac97_codec 93820 1 snd_intel8x0, Live 0xf8b85000
snd_ac97_bus 2048 1 snd_ac97_codec, Live 0xf8855000
snd_usb_audio 74688 1 - Live 0xf8bb4000
snd_pcm 82696 4 snd_pcm_oss,snd_intel8x0,snd_ac97_codec,snd_usb_audio, Live 0xf8b9e000
...

Hat irgendjemand eine Idee, wonach ich noch suchen kann? Wie ich das Problem in den Griff kriegen kann? Ihr könnt Euch vorstellen, daß sowas einem langsam auf die Eier gehen kann.

Ich danke schonmal für das aufmerksame Lesen! :(

-Kuli
 
Hi Kuli,


erstmal danke fuer die ausfuehrliche Fehlerbeschreibung. Mit diversen Outputs, strukturiert getippt, leider ist das erwaehnenswert und nicht selbstverstaendlich.


Kuli schrieb:
Wenn sie am Hub ist, wird sie erkannt, ich kann sie mit dem Mixer aktivieren, aber sobald ich nur ein einziges Byte auf /dev/dsp haue, blockiert dieses,

Dazu habe ich mal einen Forenthread gelesen, der genau dieses Verhalten auch festgestellt hat - ohne Hub ja, mit Hub nein. Leider erinnere ich mich nicht mehr, wo das stand, eine Loesung gab es dafuer jedoch nicht, das hab ich mir gemerkt. ;)

Das Hauptproblem ist, daß anscheinend der ganze USB-Kanal nach einer Weile Benutzung komplett abkackt und nur durch einen kompletten Warmstart des Rechners wieder zu leben erweckt werden kann.

Das wiederum passiert bei mir in aehnlicher Form, wenn ich die USB-Festplatte nutze, waehrend ich TV ueber die TV-Karte schaue. Nicht immer reproduzierbar, manchmal passierts gleich, manchmal spaeter.
Umgehen kann ich das Problem, wenn ich die Interrupts anders verteil. Auch heute scheint Interrupt-Sharing noch nicht immer selbstverstaendlich zu sein. Wenn du Zeit hast, koenntest du also mal die "Alles raus und nacheinander wieder rein"-Methode probieren. Sollte das nichts fruchten, hast du wohl einen Bug im USB-Code gefunden - ob im Bustreiber selbst oder im Sound-Treiber oder wo genau, kann ich dir beim besten Willen nicht sagen.

Fuer mich ist in solchen obskuren Faellen das gentoo-Forum http://forums.gentoo.org oefters eine gute Anlaufadresse gewesen. Auch als Nicht-Gentoo-User finden sich dort wertvolle Tips.


-khs, neugierig, ob du etwas rausbekommst
 
Hallo khs,

danke für die ausführliche Antwort, auch wenn sie noch nicht die erhoffte Lösung erbracht hat!

Was die Sache mit dem Hub angeht: Das ist zwar ärgerlich, aber zumindest hier am Laptop zu verschmerzen. Dann habe ich eben alle anderen Geräte am Hub, die funktionieren ja. Ärgerlich ist es, wenn es auch zu hause am PC nicht anders gehen sollte, denn u.a. gerade deshalb habe ich mir ja die externe Karte gekauft: Um sie mit superlangen USB-Verlängerungskabeln im Wohnzimmer anschließen zu können, während der Rechner im Arbeitszimmer herumstinkt. Und solche Verlängerungen funktionieren natürlich als Hub. Ich könnte mir aber vorstellen, daß es da geht, ich bin leider noch nicht dazu gekommen, das auszuprobieren: Momentan bin ich zu glücklich, daß ich auf der Arbeit Musik habe! :D

Das andere Problem ist ja viel dringender, aber vielleicht habe ich das jetzt sogar gelöst, auf die denkbar einfachste Variante: Indem ich die USB-Anschlüsse vertauscht habe! Zumindest läuft die Soundkarte seitdem durch, ohne Probleme. Darauf hätte ich auch gleich kommen können! 8) Peinlicherweise hatte ich wohl mal zu Anfang die Maus an eben jenem schrottigen USB-Port angeschlossen, denn einmal oist mir das Maus-Device flöten gegangen, und ich mußte den Rechner ebenfalls neu booten. Da das nur ein einziges mal passiert ist, habe ich das völlig verdrängt. Aber daher scheint es wohl eher ein reines USB-Problem zu sein und keines von ALSA.

Ob es ein interrupt-Konflikt ist, wie Du vermutest, oder ob der USB-Port einfach eine Macke hat, kann ich nicht sagen: Bei diesem Acer-Teil kann man die IRQ-Belegung nicht mal im BIOS abfragen, geschweige denn einstellen! Wundern tu ich mich halt, weil das Ding früher mit Windows problemlos lief, aber jeder Treiber ist natürlich anders.

Wenn ich mir /proc/interrupts reinpfeife, erkenne ich da auch nichts spannendes: Beide USB-Busse haben unterschiedliche, ungeteilte IRQs (17 und 19). Einziger Unterschied: Der "schrottige" Bus nennt sich "ehci" statt "uhci".

Code:
 17:    7916208   IO-APIC-level  uhci_hcd:usb2
 18:     145556   IO-APIC-level  uhci_hcd:usb3, eth0
 19:     275964   IO-APIC-level  ehci_hcd:usb1
 20:          0   IO-APIC-level  uhci_hcd:usb4

Da ich jetzt alle anderen Geräte am USB 1 angeschlossen habe, bin ich mal gespannt, ob sich davon was mal im Laufe der Zeit verdünnisiert. Zumindest die externen Platten senden ja schon mal längere Zeit kontinuierlich Daten. Bisher läuft aber alles stabil.

-Kuli
 
Hallo allerseits,

ich bin zwar neu hier, aber als Entwickler von USB-Hardware kann ich zu obigem Problem etwas sagen:

Es handelt sich vermutlich um ein Kabelproblem. Kabel für USB-2.0-Busse (480 MBit/s) müssen eine höhere Qualität haben als welche für USB-1.X (12 MBit/s). (Besseres Dielektrikum mit geringerer Dämpfung für hohe Frequenzen , bessere Abschirmung, etc.)

Der "schrottige" Bus nennt sich "ehci" statt "uhci"

Ein EHCI-Controller ist ein Controller für USB-2.0 (480 MBit/s), OHCI und UHCI sind USB-1.X Controller. (max 12 MBit/s). Der „gestörte“ Anschluss ist also „zufällig“ der, der einen sehr breitbandigen Leitungsempfänger besitzt und Signale (aber auch Störungen) zwischen DC und ein paar hundert MHz verarbeiten kann.

Mit hoher Wahrscheinlichkeit wird der beschriebene Fehler also dadurch ausgelöst, dass irgend eine Störquelle in den Kabelstrang einstrahlt, der an dem EHCI-Controller dranhängt. Die Störung wurde von der Hardware offensichtlich sogar als solche erkannt:

Nov 16 11:25:18 [kernel] hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling.

EMI meint vermutlich Electro-Magnetic-Interference, also eine Störeinstrahlung durch Funkwellen oder irgendwelche starken magnetischen Wechselfelder (z.B. von einem Halogenlampen-Trafo). Auf Arbeit hatte ich mal das Problem, dass die USB-Verbindung zu einer E-Motorsteuerung (die ich gerade entwickelte) sporadisch zusammenbrach. Wie bei Kuli war dann der USB-Controller des PCs bis zum nächsten Warmstart des Rechners tot. Nach langem erfolglosem suchen in meiner Prototypen-Hard-Software, hab ich dann das Noname-USB-Kabel gegen ein Qualitätsprodukt getauscht und die Kabel ordentlich festgemacht (so dass keine E-Motor-Power-Strippen mehr parallel zum USB-Kabel verliefen). Der Fehler trat danach nie mehr auf…


Also:

Vorschlag 1: Für alle Kabel, die von einem USB-2.0-tauglichen Anschluss ausgehen, nur Qualitätskabel verwenden, die ausdrücklich für USB-2.0 geeignet sind, selbst wenn man damit dann nur USB-1.X-Geräte anschießt.

Vorschlag 2: Störquellen, wie Funk-Sender jeglicher Art sowie „Magnetfelderzeuger“ wie Motoren, Trafos, Subwoofer, Starkstromleitungen, etc. räumlich von Kabeln fernhalten, über die Daten übertragen werden.

-Jörg
 
Hallo Jörch,

danke für die ausführliche Beschreibung! Habe ich leider erst jetzt gelesen, macht aber wiederum nichts, weil ich mittlerweile einen anderen PC habe, an dem das gute Stück hängt und problemlos funktioniert.

Zunächst: Beide USB-Ports sitzen nebeneinander im Laptop und sind beide definitiv USB 2.0. Ich habe allerdings den Verdacht, daß auch beide anfällig sind, der eine nur nicht so sehr wie der andere.

Das Kabel kann's eigentlich nicht sein, sämtliche Kabel sind echte 2.0-Kabel und funktionieren woanders wunderbar.

Allerdings können es die anderen von Dir genannten Funkstörungen sein. Hier auf der Arbeit, wo ich das Teil nutze, laufen etliche Geräte quer durcheinander. Gut möglich, daß es da mal Interferenzen gibt. Der von Dir beschriebene Fall ist ja genau ähnlich wie meiner.

Eine fröhliche Zeit und baldigen Sommer wünsche ich!
-Kuli
 

Ähnliche Themen

NUT (Network UPS Tools) Package auf Xenserver 7.2

usb Maus über udev konfigurieren

Problem mit externer Festplatte

Rollei Mini Wifi Camcorder

Mp3-Player wird nicht erkannt unter OpenSuse 11.4

Zurück
Oben