Audio stoppt bei snd-usb-audio

[liquid]

Hallo,

betreibe unter gentoo linux eine USB-Soundkarte, genauer gesagt einen USB-DAC (siehe www.dddac.de für nähere Infos). USB Controller ist der auf dem Abit KT7A-RAID verbaute, ich denke mal befindet sich in der VIA 686B Southbridge - ja, das üble Ding.

Es läuft mpd (music player daemon), Problem: Audio setzt nach einiger (unbestimmter, ich habe da noch kein Muster entdeckt) Zeit einfach aus. /var/log/messages (nutze syslog-ng) und dmesg zeigen nichts an, nur der sound bleibt einfach weg. Auch mpd spielt einfach weiter, jedenfalls scheint es so.

Es läuft ein 2.6.19-r5 Kernel, die mit den gentoo-patches gepatchte version. USB controller ist vom UHCI Typen. Habe schon dmix ausgestellt, doch daran liegt es nicht. Auch wenn mpd direkt auf den DAC ausgibt, bleibt irgendwann das Audio weg.

Ich weiß leider nicht, wo ich das Debugging ansetzen soll. Ich hoffe mal dass es nicht der DAC selber ist, dann müsste ich da nämlich wieder den Lötkolben ansetzen (ist ein DIY-Projekt). Will momentan testen ob es eventuell an der Stromversorgung des DAC liegt (Schwankung verursacht Lockup des USB-Receiver chips) oder aber mit dem USB-Controller des VIA Chipsatz zusammenhängt.

Habe deshalb das Gerät an meinem Dell 1300 hängen, da ist eine ICH6 Bridge drin, die für das USB sorgt. mplayer im loop-Modus, mal sehen ob es zur selben Problematik kommt wie auf dem Abit board.

Jemand Ahnung wie man sowas debugged? Wenn es nicht der DAC ist, sondern an den Treiber liegt, so kann es ja immer noch uhci_hcd oder snd-usb-audio sein - wie geht man da am besten vor? Debugfunktionen im Kernel aktivieren? Hat der usb stack da besondere Möglichkeiten?

Ich hoffe es kann mir jemand helfen. Vielleicht kann mir auch jemand sagen ob sich das Problem evtl. mit einer dedizierten USB-Controller Karte beseitigen ließe? Gibt es da vernünftige Karten die nicht alles auf die CPU abwälzen und dann auch noch vom Kernel supportet werden?

cya
liquid

[Harleckin]

Schau dir mal die Modul Parameter von "snd-usb-audio" an.

# modinfo snd-usb-audio


Außerdem mal einen Blick ins Alsa Wiki werfen..
http://alsa.opensrc.org/Usb-audio

[liquid]

Thx, Harleckin - habe auch schon mit dieser async_unlink Option rumgespielt. Weiß man eigentlich was die genau macht?

Habe den Test heute nacht noch auf mpg123 umgeschwenkt, Gapless- und Random-Mode rein und laufen lassen. Audio war heut morgen weg, das kann jetzt natürlich viel bedeuten.

Am USB-Controller scheint es wohl nicht zu liegen. Habe allerdings diesmal was im Kernel-Log gefunden. mpg123 scheint außerdem extrem schnell zu dekodieren, wenn das audiodevice nicht mehr ansprechbar ist. Habe ich daran gemerkt, dass der Laptoplüfter öfters anlief und heute morgen die Ausgaben nur so in der Konsole herunterrasten.

Interessante Stellen des Kernel-Logs werde ich nachher noch posten. Evtl. noch ein Testlauf mit anderer Spannungsversorgung.

cya
liquid

[liquid]

So, ich habe den alten Log gelöscht und einen neuen erstellt:


(Den Laptop in Position gebracht, da ich nur ein kurzes Kabel verwenden kann. Laptop wurde also in den Schrank zum DAC hin verfrachtet.
Wir beginnen den Log mit dem Einstöpseln des DAC, dieser war bereits angeschaltet)

Mar 23 19:19:55 leena usb 1-1: new full speed USB device using uhci_hcd and address 5
Mar 23 19:19:55 leena usb 1-1: configuration #1 chosen from 1 choice
Mar 23 19:19:55 leena input: Burr-Brown from TI USB Audio DAC as /class/input/input5
Mar 23 19:19:55 leena input: USB HID v1.00 Device [Burr-Brown from TI USB Audio DAC ] on usb-0000:00:1d.0-1
Mar 23 19:19:55 leena usbcore: registered new interface driver snd-usb-audio

(Es wurde mpg123 im --gapless -Z Modus gestartet, das garantiert dass das audiodevice die ganze Zeit ohne Unterbrechung verwendet wird und die Wiedergabe unendlich lange andauert)

(Es vergeht etwas Zeit, nur cron Ausgaben und chronyd beschwert sich weil der Laptop nicht am Internet hängt)

Mar 23 21:40:34 leena usb 1-1: reset full speed USB device using uhci_hcd and address 5

(Die erste merkwürdige Ausgabe. Ich penne leider bereits schon - es war ein harter Tag - und bekomme deshalb nichts davon mit.)

(Es vergehen ein paar Stunden, ich wache vom Lüftergeräusch auf was darauf hindeutet dass mpg123 kein audiodevice mehr hat. Ich schaue in den Log, sehe nur die obige Nachricht. Will mpg123 mit strg+C beenden, drücke aber nur einmal anstatt zweimal woraufhin mpg123 wohl für kurze Zeit das device fallen lässt. Prompt tauchen Nachrichten im Log auf)

Mar 24 03:52:15 leena usb 1-1: reset full speed USB device using uhci_hcd and address 5
Mar 24 03:52:15 leena usb 1-1: device descriptor read/64, error -71
Mar 24 03:52:16 leena usb 1-1: device descriptor read/64, error -71
Mar 24 03:52:16 leena usb 1-1: reset full speed USB device using uhci_hcd and address 5
Mar 24 03:52:16 leena usb 1-1: device descriptor read/64, error -71
Mar 24 03:52:16 leena usb 1-1: device descriptor read/64, error -71
Mar 24 03:52:16 leena usb 1-1: reset full speed USB device using uhci_hcd and address 5
Mar 24 03:52:17 leena usb 1-1: device not accepting address 5, error -71
Mar 24 03:52:17 leena usb 1-1: reset full speed USB device using uhci_hcd and address 5
Mar 24 03:52:17 leena usb 1-1: device not accepting address 5, error -71
Mar 24 03:52:17 leena usb 1-1: USB disconnect, address 5
Mar 24 03:52:17 leena usb 1-1: new full speed USB device using uhci_hcd and address 6
Mar 24 03:52:18 leena usb 1-1: device descriptor read/64, error -71
Mar 24 03:52:18 leena usb 1-1: device descriptor read/64, error -71
Mar 24 03:52:18 leena usb 1-1: new full speed USB device using uhci_hcd and address 7
Mar 24 03:52:18 leena usb 1-1: device descriptor read/64, error -71
Mar 24 03:52:18 leena usb 1-1: device descriptor read/64, error -71
Mar 24 03:52:19 leena usb 1-1: new full speed USB device using uhci_hcd and address 8
Mar 24 03:52:19 leena usb 1-1: device not accepting address 8, error -71
Mar 24 03:52:19 leena usb 1-1: new full speed USB device using uhci_hcd and address 9
Mar 24 03:52:20 leena usb 1-1: device not accepting address 9, error -71

(Das sieht böse aus. Noch schlaftrunken will ich mich vergewissern ob sich der USB-Receiver des DAC total aufgehängt hat. Ich stöpsle also das Kabel aus, warte 10 Sekunden und connecte wieder)

Mar 24 03:57:12 leena usb 1-1: new full speed USB device using uhci_hcd and address 10
Mar 24 03:57:12 leena usb 1-1: configuration #1 chosen from 1 choice
Mar 24 03:57:12 leena input: Burr-Brown from TI USB Audio DAC as /class/input/input6
Mar 24 03:57:12 leena input: USB HID v1.00 Device [Burr-Brown from TI USB Audio DAC ] on usb-0000:00:1d.0-1

(Anscheinend habe ich ihn wiederbelebt, ein kurzer Test mit mpg123 zeigt dass Audio wieder geht. Muss den DAC also nicht einmal 'rebooten', also AUS-AN-Zyklus durchführen, um wieder Audio zu bekommen. Schon merkwürdig, will mich jetzt aber nicht damit befassen sondern weiterknacken. Überlege mir noch was zu testen wäre. Entlade erstmal den ALSA USB Treiber)

Mar 24 04:02:46 leena usbcore: deregistering interface driver snd-usb-audio

(/sys/module/snd_usb_audio/parameters sagt mir dass nrpacks momentan auf 8 gesetzt ist, ich modprobe mit nrpacks=1)

Mar 24 04:12:02 leena usbcore: registered new interface driver snd-usb-audio

(mpg123 wieder starten, kurz Kopfhörer auf und hören ob man was hört. Tut man, wieder zurück in die Kiste und weiterschlafen)

Mar 24 10:33:15 leena usb 1-1: reset full speed USB device using uhci_hcd and address 10

(Wieder diese Meldung, es erklingt aber immer noch Musik. Scheint sich also wieder gefangen zu haben. Warum allerdings der Reset ist mir gänzlich unklar)

Mar 24 15:21:50 leena usb 1-1: reset full speed USB device using uhci_hcd and address 10
Mar 24 15:21:50 leena usb 1-1: device descriptor read/64, error -71
Mar 24 15:21:50 leena usb 1-1: device descriptor read/64, error -71
Mar 24 15:21:51 leena usb 1-1: reset full speed USB device using uhci_hcd and address 10
Mar 24 15:21:51 leena usb 1-1: device descriptor read/64, error -71
Mar 24 15:21:51 leena usb 1-1: device descriptor read/64, error -71
Mar 24 15:21:51 leena usb 1-1: reset full speed USB device using uhci_hcd and address 10
Mar 24 15:21:52 leena usb 1-1: device not accepting address 10, error -71
Mar 24 15:21:52 leena usb 1-1: reset full speed USB device using uhci_hcd and address 10
Mar 24 15:21:52 leena usb 1-1: device not accepting address 10, error -71
Mar 24 15:21:52 leena usb 1-1: USB disconnect, address 10
Mar 24 15:21:52 leena usb 1-1: new full speed USB device using uhci_hcd and address 11
Mar 24 15:21:52 leena usb 1-1: device descriptor read/64, error -71
Mar 24 15:21:53 leena usb 1-1: device descriptor read/64, error -71
Mar 24 15:21:53 leena usb 1-1: new full speed USB device using uhci_hcd and address 12
Mar 24 15:21:53 leena usb 1-1: device descriptor read/64, error -71
Mar 24 15:21:53 leena usb 1-1: device descriptor read/64, error -71
Mar 24 15:21:53 leena usb 1-1: new full speed USB device using uhci_hcd and address 13
Mar 24 15:21:54 leena usb 1-1: device not accepting address 13, error -71
Mar 24 15:21:54 leena usb 1-1: new full speed USB device using uhci_hcd and address 14
Mar 24 15:21:54 leena usb 1-1: device not accepting address 14, error -71

(Bin im Netz und google nach dem Problem, natürlich am anderen Rechner - zurück beim Laptop: Audio ist weg)

Mar 24 15:29:01 leena usb 1-1: new full speed USB device using uhci_hcd and address 15
Mar 24 15:29:01 leena usb 1-1: configuration #1 chosen from 1 choice
Mar 24 15:29:01 leena input: Burr-Brown from TI USB Audio DAC as /class/input/input7
Mar 24 15:29:01 leena input: USB HID v1.00 Device [Burr-Brown from TI USB Audio DAC ] on usb-0000:00:1d.0-1
Mar 24 15:29:23 leena usb 1-1: USB disconnect, address 15

(Nochmal verifizieren dass sich nicht der USB-Receiver gelockt hat, Kabel REIN-RAUS - funzt wieder. Ich entferne den DAC fürs erste. Der Laptop wandert wieder auf den Tisch)


Nur die interessanten Stellen und von mir kommentiert.

[liquid]

Update:

Ich habe das Problem weiter eingegrenzt. Meiner Meinung nach ist es allerdings kein USB Problem (mehr, bzw. es war nie eins).

Ich kann den Lockup des USB-receivers provozieren indem ich das Teufel System, welches an derselben Steckdosenleiste wie der DAC hängt, an- oder auch ausschalte. Just in diesem Moment verschwindet der Sound vom DAC und ein paar Sekunden später finde ich Nachrichten über einen fehlgeschlagenen PCM write im kernel log.
Ich habe den Lockup mit dieser Methode (ich nenne sie die amp-Methode *g*) bisher jedes Mal reproduzieren können. Augenscheinlich verlagert sich das Problem also weg vom USB hin zur Spannungsversorgung, welche aber stabilisiert ist und deshalb eigentlich ein solches Verhalten nicht zeigen sollte. Die dort verbauten Elkos sollten diese Spannungsspitzen (falls sie denn entstehen, das weiß ich zur Zeit gar nicht) locker kompensieren.

Um die Problematik zu untermauern habe ich sämtliche anderen Verbindung vom Teufel Subwoofer (welcher ja gleichzeitig der Amp ist) getrennt, da ich erst dachte dass eventuell über die Cinchverbindung eine Spannungsspitze zurück zum DAC geliefert wird. Cinch trennen half aber nicht.
Weiterhin scheinen die Lautsprecherkabel keine Störungen in dem USB-Verbindungskabel zu induzieren, auch wenn sie nahe diesem verlaufen.

Ein Lockup tritt weiterhin auf. Ein Test mit einem weiteren Verbraucher, einem 1500W Staubsauger (ja, man nimmt was man kriegt), schlug leider fehl. Auch wenn direkt an der Leiste angeschlossen, bekomme ich den USB-receiver nicht zum Lockup. Kann natürlich sein dass de Staubsauger da eine Regelung hat und der Amp nicht, wer weiß.

Also Verdacht dass die Spannungsversorgung nicht vernünftig funktioniert. Habe deswegen den 12V-Adapter von meiner externen HD genommen, welcher auch 1A liefern kann (soviel zieht der DAC momentan aber nicht - ist also ausreichend dimensioniert). Auch mit diesem erzeugt das Ein-Aus-Schalten des Amp ein Lockup, selbiges wenn der Adapter an einer anderen Steckdose im Zimmer, oder auch in einem ganz anderen Raum (ich habe das Badezimmer genommen) verwendet wird.

Ehrlich gesagt kann ich mir das Verhalten nicht erklären. Jetzt bräuchte ich ehrlich gesagt ein Oszilloskop, welches aber halt nicht da ist. Nur mit dem Multimeter kann ich ja sowas schwer testen.

Jemand irgendwelche Ideen? Da dieser Thread ja nun nichts mehr mit USB geschweigen denn Linux/Unix zu tun hat, werde ich einen neuen Thread mit Verweis auf diesen aufmachen, vermutlich in 'non-PC hardware' - das passt wohl am ehesten.

Danke nochmal an Harleckin :)

cya
liquid

[Gast]

Hallo,
ich habe genau das gleiche Problem mit einem Cambridge DACMagic.
Schon irgendwie weitergekommen???

Danke und Gruß