PCIexpress vs. USB -> wer ist der Latenzchampion?

o0Julia0o schrieb:
Also ist AUX besser(latenzfrier) als PCIe?

Wo ordnet sich dieser(Optischer S/PDIF) ein?
1. AUX
2. PCIexpress
3. PCI
4. USB

Du vergleichst hier Äpfel mit Birnen. Wärend PCI, PCIe, PCI-X und USB multifunktionale Bussysteme mit mehreren Teilnehmern sind, handelt es sich bei dem, was Du als "Aux" bezeichnest sowie bei S/PDIF (und AES/EBU) um einfache, zweckgebundene Punkt-zu-punkt Verbindungen, "AUX" gar meist noch analog. Hier von Latenzzeiten zu sprechen, ist grober Unfug, denn da spielen Leitungslängen, Leiterquerschnitte und Materialgüte eine wesentlich entscheidendere Rolle, wie auch die interne Verschaltung von Quelle und Ziel, kurz, es lässt sich hier keine allgemeingültige, qualifizierte Aussage treffen.

Was kommt als nächstes? Line-In? Modbus? CAN? Ethercat?
 
o0Julia0o schrieb:
Wo ordnet sich dieser(Optischer S/PDIF) ein?
1. AUX
2. PCIexpress
3. PCI
4. USB

Ich nehme an, dass du den AUX oder SPDIF vom Soundchip meinst. Da der in der Regel über PCI oder PCIe angebunden ist, gibt es keinen Unterschied zu einer PCI oder PCIe Soundkarte mit diesen Ausgängen.
 
Jo, stimmt - vertan. Der S/PDIF-Weg kommt ja noch auf die PCIe-Latenzzeit draufaddiert. Jedoch kann man folgendes festhalten: Aktivboxen per USB angeschlossen haben eine höhere Latenz als die gleichen Aktivboxen per optischen S/PDIF angeschlossen? Also wenn schon externes DAC(ja z.B. in Aktivboxen), dann wenigstens per S/PDIF -> besser als USB? (Zur Info: Das Signal von S/PDIF wird ja ohnehin an der Soundkarte/OnbardSoundchip vorbegeschliffen, selbst wenn es aus der Soundkarte/Oboardsoundchip herauskommt. Und muß dann erst in ein analoges Signal gewandelt werden)
 
Irgendwas muss das Signal immer in ein analoges umwandeln, wenn Lautsprecher gefüttert werden.

S/PDIF wird nicht an der Soundkarte vorbei geleitet. Die Soundkarte erstellt dieses Signal erst einmal. Und reicht es eben digital weiter und wandelt es nicht selbst analog um.

Wir können das hier ins unendliche weiterführen. Es spielt alles keine Rolle. Nicht im Bezug auf die Latenz.
 
Nicht jede aktivbox hat auch einen DAC integriert. Aber wozu noch weitere Geräte bzw. weitere Signalverarbeitung in die Signalkette bringen? Du hast ja schon eine Wandlung von dem Signal der Soundkarte (welche z.B. die Daten aufbereitet über PCI/PCIe bekommt), dann eine Konvertierung für S/PDIF, Rückkonvertierung, Wandlung in Analog... Jede zusätzliche Verarbeitung bedeutet auch wieder höhere Signallaufzeiten.

Wenn Du möglichst wenig Verzögerung haben willst, solltest Du den Aufbau nach dem KISS-Prinzip gestalten. Such die den schnellsten Transport von Quelle zu DAC, und dann direkt an die Ausgabe. Kurze Übertragungswege, so wenige Geräte wie möglich, so wenig Wandlung/Verfremdung wie möglich.
 
Der beste Weg Latenzen zu vermeiden ist einen Kopfhörer zu verwenden. Jeder Meter den der Schall zurücklegen muss sind über 3ms. Die Unterschiede der verschiedenen Schnittstellen liegen in der Regel unter 1ms.
 
o0Julia0o schrieb:
Aktivboxen per USB angeschlossen haben eine höhere Latenz als die gleichen Aktivboxen per optischen S/PDIF angeschlossen? Also wenn schon externes DAC(ja z.B. in Aktivboxen), dann wenigstens per S/PDIF -> besser als USB?

Das kann man alles so nicht sagen. S/PDIF ist nur ein Übertragungsprotokell und kommt es darauf an wo die entsprechende Schnittstelle angebunden ist. Auch externe USB Audiointerfaces oder professionelle PCIe-Karten haben oft einen koaxialen oder optischen S/PDIF Anschluß. Der S/PDIF Anschluß einer Consumer Soundkarte oder eines Onboard Soundchips läuft auch nicht an irgendwas vorbei, sondern wird vom Treiber genauso angesprochen, wie der Rest der jeweiligen Soundkarte. Allerhöchstens hat er ein paar wenige Samples Latenzunterschied zum analogen Ausgang, Aufgrund unterschiedlicher Pufferung, Wandlerlatenzen, usw.

Generell sind über PCIe/PCI/Thunderbolt niedrigere Latenzen möglich als über USB oder Firewire. DMA Zugriffe erlauben dabei alle Schnittstellen, die Zeiten in denen jedes Sample einzlen vom Rechner abgefragt wurde sind seit 20-25 Jahren vorbei. Was aber eine Rolle spielt, ist z.B. der Treiberoverhead, der durch die USB oder Chipsatztreiber entsteht. Die Audiodaten werden in kleinen Paketen übertragen, deren Größe eines Abschnitts des für die Übertragung verwendeten Ringpuffers entspricht. D.h. der Audiotreiber inkl. der dafür notwendigen Subtreiber werden jede Sekunde mit folgender Häufigkeit aufgerufen: Samplerate / Größe eines Einzelpuffers. Klar, dass die Abarbeitung eines solchen Aufrufs etwas länger dauert, wenn der eigentliche Audiotreiber jedes Mal den USB Treiber mit aufrufen muß. Genauso spielt es eine Rolle, dass der Chipsatz des Audiointerfaces sich effizient programmieren läßt, die Effizienz des eigentlichen Treibers selbst und wieviel Rechenleistung überhaupt (ohne Störungen aus denen dann Latenzprobleme entstehen) zur Verfügung steht. Bei Consumer Soundkarten (und auch deren S/PDIF Anschluß) wird wohl nicht auf niedrige Werte geachtet, weil bei größeren Puffern natürlich die Störanfälligkeit gegenüber Lastspitzen der CPU sinkt. Selbst mit ASIO4ALL sind nicht so gute Werte möglich wie bei ordentlichen herstellerseitig optimierten Audiotreibern.

Letztendlich kommt es auf den Einzelfall an, welche Audiolösung welche Latenz bietet, ob die angegebene Latent wirklich der Realität entspricht und wieviel Rechenleistung dafür benötigt wird. Man darf auch nicht vergessen, dass jede Wandlung von digital auf analog und umgekehrt eine gewisse Latent hat und dass auch der Schall einige Zeit vom Lautsprecher zum Ohr braucht (~3ms/Meter Entfernung).
 
Mir ist zum entprechenden Beitrag von Piktogramm die Internetleitung über Nacht abgeschmiert. Das ist Latenz. :D

Noch weniger Latenz ist nur noch mit direkt angebundenen Hypertransport zwischen Prozessor, Ram und Audiohardware möglich.
Leider hat es AMD begraben und die Hersteller haben bis auf Serverhardware nicht viel angeboten bis auf daran angebundene Chipsätze.

Bei Gamer optimierten Chipsätzen durch ihre ganze Software und der angebundenen I/O Schnittstellen kann man Produktivität in der Pfeife rauchen. Ebenso wurden die Schnittstellen und zu viele Mainboards für SLi und Crossfire optimiert. Auch wurde die heutige PCIe Konfiguration sehr unflexibel gelöst und mit den PCIe Brücken mit:" mach aus 2 gleich 16 Anbindungen", machte man die Sache nicht besser. Dann gab es die billige Einführung mit dem intel DMI und AMD A-Link Verschnitt. Über viele lahme Brücken musst du gehen. Zum Zocken reichte es immerhin.


PCIe für Notebooks gab es mit Expresscard. Leider nicht weiterentwickelt um heute PCIe x16 3.0 auszuführen. Würde als Schacht durchaus brauchbare Funktionsvielfalt anbieten. M.2 SSD, Ligntingport, USB3.1, etc. oder direkt zur externen Dockingstation. Bei Tablets wäre sowas genial diese Krücken ordentlich anzubinden.
RME bot für PCMCIA und Expresscard direkte Hardware ASIO Karten für ihre externen Interface an.

Die Hardware ist heute sehr konsumlastig geworden. Auch im professionellen Einstiegsbereich.

Wobei USB deutlich bei der Latenz aufgeholt hat. Trotzdem würde ich Profihardware nicht über einen Hub mit anderen USB Geräten anbinden. Aber leider ist heute das Dilemma selbst bei Notebooks nur noch einen Multifunktions USB Port anzubieten, der auch noch das Ladegerät bedient. ich bezweifle, das die Hersteller überhaupt noch richtig ihre Hardware für unterschiedliche Anwendunsgszenarien testen.

Wenn an so einem USB Anschluss mit Hub ein Audio Interface, Drucker, Maus, Tastatur, Digicam oder Webcam, USB Stick oder Festplatte, ein Cardreader, TV Karte und USB Tannnenbaum hängen, will ich das Ergebnis nicht wirklich kennen. Da braucht nur ein Treiber eine Macke haben um die ganze USB Bundestraße durch einen Unfall mit verschütteten Bits lahmzulegen.

Da man auch noch Multimonitorbetrieb über einen USB oder TB Anschluss realisieren will, wird das mit den ganzen HUB Adapterkarten in Zukunft für unterschiedliche Zwecke sicher eine interessante Fragestellung.



Ein anderer Teil der Latenz fällt der Software zu Opfer. Mit dem Verlust von Hardwarebeschleunigung mit Auslagerung auf eine CPU, muss diese leistungsfähig genug sein um geringe Latenzen zu erlauben. Stark schwankende Taktraten durch Energierparoptionen der CPU können zu Latenzen führen.
Bei der Musikproduktion setze ich den CPU Takt meistens am Limit fest und der BUS taktet auch sonst bei mir immer auf maximalen Takt.


Noch zu dem Video von Tek Syndicate, die eigentlich die verdrehte Creative Vermarktungsstrategie ansprechen sollten. Die X-Fi Serie kommt mit sehr guten ASIO2.0 Treibern daher, die problemlos unter 5ms Latenz erlaubt. Wer nur zockt und bei der X-Fi Reihe handelte es sich schon vermehrt bei vielen Karten um für den Zocker I/O optimierte Soundkarten, der wird vom Rest nicht profitieren konnen.
Die Herren aber halten eine x-fi Preulde AKM Version von Auzentech in den Händen, die auch sonst über gute Komponenten verfügt. Die Karte in den Entwicklungs Modus versetzen, einen ordentlichen Mixer mit Routingverschaltung (falls notwendig), guten MIC und Hi-Z Preamps und KHV vorschalten und fertig ist die X-Fi DAW. Ausgänge sind genug verfügbar. einzig bei den Eingängen wird es schwierig, aber da gibt es noch das interne Creative I/O Deck mit Zusatzeingängen über 6,3mm und Cinch, MIDI I/O und 6.3mm Kopfhörerausgang.
Das rauscht garantiert nicht als Front Panel.
 
Zuletzt bearbeitet:
ich danke euch sehr!

BlubbsDE schrieb:
S/PDIF wird nicht an der Soundkarte vorbei geleitet. Die Soundkarte erstellt dieses Signal erst einmal. Und reicht es eben digital weiter und wandelt es nicht selbst analog um.
Ich habe gehört, dass Onboardsoundkarten wie die auf meinem http://www.asus.com/de/Motherboards/Z170-PRO-GAMING eine Menge Overhead produzieren. Gilt das nur für den Analogen Weg oder auch für den S/PDIF-Weg?

Twostone schrieb:
Nicht jede aktivbox hat auch einen DAC integriert.
Aha. Also einen Verstärker evlt. nur, das macht eine Aktivbox aus. Ein DAC wäre optional. Bei welchen mit 3,5mm-Anschluss ist meist kein DAC integrierst bei welchen mit USB-Anschluss ist 100%ig ein DAC integriert? Kann man das so sagen?

Twostone schrieb:
Aber wozu noch weitere Geräte bzw. weitere Signalverarbeitung in die Signalkette bringen?
Wenn Du möglichst wenig Verzögerung haben willst, solltest Du den Aufbau nach dem KISS-Prinzip gestalten. Such die den schnellsten Transport von Quelle zu DAC, und dann direkt an die Ausgabe. Kurze Übertragungswege, so wenige Geräte wie möglich, so wenig Wandlung/Verfremdung wie möglich.
jo - hört sich gut an. Und auch keine 2te Kette aufbauen. Denn die CPU bestimmt auch über die Latenz & die Auslastung des PC-Busses. Der hier hat ja auch eine hohe Latenz: http://gamona-images.de/191833/4b9003ef525d21a3302e5d866d4b0903.png - aber nen guten Bass...

Jedoch wo Mikrophon anschließen, wenn man an einem externen DAC kein Mikrophonanschluss hat. Dann muss man die Onbard-Soundkarte fürs Mikro ebenfalls aktivieren, was ja eine 2. Kätte wäre.

Nolag schrieb:
Der beste Weg Latenzen zu vermeiden ist einen Kopfhörer zu verwenden. Jeder Meter den der Schall zurücklegen muss sind über 3ms. Die Unterschiede der verschiedenen Schnittstellen liegen in der Regel unter 1ms.
In der Luft - nicht im Kabel, richtig? Jo - Kopfhörer verwende ich auch gerne, wenn ich wenig Latenz haben möchte. Doch die Boxen stehen keinen Meter weit weg. Und ist auch oft entspannender ohne Kopfhörer. Die restliche Signalkette sollte in beiden Fällen aber natürlich trotzdem möglichst Latenzklein ausfallen.

druckluft schrieb:
Das kann man alles so nicht sagen. S/PDIF ist nur ein Übertragungsprotokell und kommt es darauf an wo die entsprechende Schnittstelle angebunden ist.
Steht S/PDIF nicht für diese optische Schnittstelle? Das Protokoll wird ein anderes sein als bei USB - aber ist es nicht latenzkleiner? Dachte optisch wäre schneller generell möglich als über Kupfer. Und von daher hat man dann doch ein schnelleres Protokoll geschaffen mit Sicherheit.
 
o0Julia0o schrieb:
Aha. Also einen Verstärker evlt. nur, das macht eine Aktivbox aus. Ein DAC wäre optional. Bei welchen mit 3,5mm-Anschluss ist meist kein DAC integrierst bei welchen mit USB-Anschluss ist 100%ig ein DAC integriert? Kann man das so sagen?

wenn die box keinen eigenen verstärker hat, isses ne normale passive box ;)

3,5mm audio klinke ist IMMER analog, d.h. da findet immer vorher ne D/A wandlung statt. USB Audio hat IMMER nen DAC, weil USB digital ist.

die diskussion um die latenz find ich irgendwie grenzwertig. nutze seit einiger zeit hifi usb dacs am pc u.a. auch zum zocken und da gibts keine spürbare latenz (obwohl ich dahingehend relativ empfindlich bin - ping / inputlag usw.)

usb an sich ist sicherlich nicht der limitierende faktor, mit genügend rechenlast bekommt man auch ne pci-e karte zum laggen.

wenn man jetzt anfängt an der usb latenz rumzumachen, kann man bei der flankensteilheit der frequenzweiche und dem ein und ausschwingverhalten der membranen weitermachen. :evillol:

und irgendwann kommt man an den punkt, dass die latenz unter einem gewissen wert komplett irrelevant ist. auch laufzeitunterschiede sind unter einem gewissen wert total unproblematisch und teilweise sogar förderlich. lebewesen sind keine messmikrofone - wir kommen mit den unzulänglichkeiten von schall klar :cool_alt:
 
o0Julia0o schrieb:
Steht S/PDIF nicht für diese optische Schnittstelle? Das Protokoll wird ein anderes sein als bei USB - aber ist es nicht latenzkleiner? Dachte optisch wäre schneller generell möglich als über Kupfer. Und von daher hat man dann doch ein schnelleres Protokoll geschaffen mit Sicherheit.

Nein Toslink ist optisch. SPDIF kann elektrisch oder optisch sein

Trollst du ? Willst du wirklich über einen Geschwindigkeitsunterschied zwischen Optisch und Elektrisch reden ?! :freak:
 
danke euch! Und ein schönes Wochenende Allen!
Der Nachbar schrieb:
Noch zu dem Video von Tek Syndicate, die eigentlich die verdrehte Creative Vermarktungsstrategie ansprechen sollten. Die X-Fi Serie kommt mit sehr guten ASIO2.0 Treibern daher, die problemlos unter 5ms Latenz erlaubt. Wer nur zockt und bei der X-Fi Reihe handelte es sich schon vermehrt bei vielen Karten um für den Zocker I/O optimierte Soundkarten, der wird vom Rest nicht profitieren konnen.
Von welchem Rest?

Cokocool schrieb:
Willst du wirklich über einen Geschwindigkeitsunterschied zwischen Optisch und Elektrisch reden ?
dachte optisch wäre flotter. Ich kenne das nur vom Internet Glasfaserleitungen sind flotter als Kupferleitungen. Warum nicht auch für Audiosignale - im Grunde sind doch alles Datenpakete.

duskstalker schrieb:
die diskussion um die latenz find ich irgendwie grenzwertig. nutze seit einiger zeit hifi usb dacs am pc u.a. auch zum zocken und da gibts keine spürbare latenz (obwohl ich dahingehend relativ empfindlich bin - ping / inputlag usw.)

usb an sich ist sicherlich nicht der limitierende faktor, mit genügend rechenlast bekommt man auch ne pci-e karte zum laggen.
In vielen Baords wird darüber diskutiert. Ich stolpere bei meiner recherche immer wieder über englischsprachige Boards. Dort verstehe ich nicht alles. Aber Latenz ist ein großes Thema. Und dort werden zur Verbesserung von Problemen auch PCIe-Systeme als Lösungsvorschlag gebracht zu USB-Systemen. Wenn ich eine Taste auf nem Midi-Keyboard drücke & der Sound kommt erst 20ms später an, dann registriere ich das. Das wäre bei einem empfindlichem Menschen doch auch so, wenn die Gaming-Sound-Latenz genauso schlecht wäre. Irgendwo wird es eine Grenze geben. Doch wo liegt diese. Ab welcher Latenz spürt man keinen Unterschied mehr?

duskstalker schrieb:
wenn man jetzt anfängt an der usb latenz rumzumachen, kann man bei der flankensteilheit der frequenzweiche und dem ein und ausschwingverhalten der membranen weitermachen. :evillol:
Du meinst im DAC irgendwelche Hardwarekomponenten? Wären wohl kleinere Unterschiede. Du meinst das sicherlich übertrieben. Aber es gibt ja durchaus 2 USB DAC von verschiedenen Herstellern. Der eine ist Low-Latenz & gut geeignet zum Gamen/Musik machen - der andere nicht. Und zwar nicht aufgrund seines Klanges, sondern allein schon wegen seiner Latenz. Also diese kann bei USB unterschiedlich sei. Da - so verstehe ich hier die meisten liegt wohl der größte Hund im Grab: der Treiber. Doch eben auch 2 identische Treiber können auf unterschiedlichen DAC´s - PCIe vs. USB unterschiedliche Latenzen aufweisen. Gibt ja diesen Asio4all. Also ganz so unwichtig ist die Schnittstelle dann nicht. O.k. - erst dann nicht, wenn man einen mittelmässigen Treiber ausschließen kann.

Der Nachbar schrieb:
Wobei USB deutlich bei der Latenz aufgeholt hat. Trotzdem würde ich Profihardware nicht über einen Hub mit anderen USB Geräten anbinden. Aber leider ist heute das Dilemma selbst bei Notebooks nur noch einen Multifunktions USB Port anzubieten, der auch noch das Ladegerät bedient. ich bezweifle, das die Hersteller überhaupt noch richtig ihre Hardware für unterschiedliche Anwendunsgszenarien testen.

Wenn an so einem USB Anschluss mit Hub ein Audio Interface, Drucker, Maus, Tastatur, Digicam oder Webcam, USB Stick oder Festplatte, ein Cardreader, TV Karte und USB Tannnenbaum hängen, will ich das Ergebnis nicht wirklich kennen. Da braucht nur ein Treiber eine Macke haben um die ganze USB Bundestraße durch einen Unfall mit verschütteten Bits lahmzulegen.
leider erkennt man bei Mainboards gar nicht, wie viele USB-Hubs dort verbaut sind. Sonst könnte man Latency-empfindliche Komponenten an 2 verschiedene anschließen & am Rest den restlichen Tannenbaum. Oder man kauf sich eine PCIe-USB-Karte. Doch dann hat man wiederum Doppelkommunikation. USB mit DAC + USB-Karte mit PCIe-Slot, welcher ja dann mit dem Systembus kommuniziert.

Schade ist, dass die Hersteller so etwas nicht dazu schreiben. Jedoch auch dann wäre es bei Cocktailwirkungen wieder schwierig zu beurteilen. Nehmen wir ein Setup, was wohl viele von euch haben. Externer DAC samt KHV - daran die Kopfhörer. Das Mikrophon steckt dann auf der Onbardsoundkarte, weil der DAC nur einen Ausgang besitzt, keinen Eingang. Wäre es dann sinniger die Onbardsoundkarte zu deaktvieren & die DAC rauszuschmeissen und eine Sound Blaster X7 zu holen. Diese hat Mikrophoneingang- und Soundausgang in einem DAC. Doch das wiederum ist ja auch schlecht, da dann die USB-Leitung mit zweierlei belegt wird. Kopfhörersound-Pakete & in die andere Richtung Mikrophonsound-Pakete. Wie ist das einzuordnen? Langweilt sich USB so sehr, dass es beides schluckt? Ich mein - ist ja nix anderes als ein Keyboard bei Musikern. Ich höre es & gebe gleichzeitig input in Cubase oder Co.

Das MSI Z170A Gaming M5 bietet einen extra "GAMING DEVICE PORT". Ist das ein extra USB-Hub, welcher sich dan nur um die Maus kümmert? Das würde ja implizieren, dass ein weiterer USB-Port am Mainboard, außerhabl des "Gaming Device Port" von einem anderem USB-Hub kommt.
Y5GtLJP.png

(dieser Goldanteil bringt natürlich nix)

Zum Protokoll bitte
Shiit sagt: "Bifrost uses a sophisticated master clock management system to deliver bit-perfect data to the DAC—unlike many DACs that use asynchronous sample rate conversion (ASRC), which destroys the original samples. And, with our acclaimed Gen 2 USB input now standard, you’re ready for computer, tablet, and even phone-based sources."
Q: http://schiit.com/products/bifrost

Andere heben das ASRC gerade hervor. Ist ASRC schneller aber Verlustreicher? Also latency-freundlicher?
 
Zuletzt bearbeitet:
o0Julia0o schrieb:
leider erkennt man bei Mainboards gar nicht, wie viele USB-Hubs dort verbaut sind.

Warum nicht?
Beispiel:
Bus 002 Device 004: ID 0bda:0151 Realtek Semiconductor Corp. Mass Storage Device (Multicard Reader)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x0151 Mass Storage Device (Multicard Reader)
bcdDevice 51.95
iManufacturer 1 Generic
iProduct 2 USB2.0-CRW
iSerial 3 20060413092100000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 CARD READER
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 5 Bulk-In, Bulk-Out, Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)

Bus 002 Device 003: ID 04d9:0183 Holtek Semiconductor, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x04d9 Holtek Semiconductor, Inc.
idProduct 0x0183
bcdDevice 3.13
iManufacturer 0
iProduct 2 USB Keyboard
iSerial 3 000000000002
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 91
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 64
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 34
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 134
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x8087 Intel Corp.
idProduct 0x0024 Integrated Rate Matching Hub
bcdDevice 0.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 6
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0103 power enable connect
Port 2: 0000.0100 power
Port 3: 0000.0503 highspeed power enable connect
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 4.05
iManufacturer 3 Linux 4.5.0-0.bpo.2-amd64 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1d.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered

Bus 001 Device 005: ID 046d:c404 Logitech, Inc. TrackMan Wheel
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc404 TrackMan Wheel
bcdDevice 2.20
iManufacturer 1 Logitech
iProduct 2 Trackball
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 103
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)

Bus 001 Device 004: ID 046d:c21f Logitech, Inc. F710 Wireless Gamepad [XInput Mode]
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc21f F710 Wireless Gamepad [XInput Mode]
bcdDevice 3.05
iManufacturer 1 Logitech
iProduct 2 Wireless Gamepad F710
iSerial 3 F8A992B4
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 48
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 98mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 93
bInterfaceProtocol 1
iInterface 0
** UNRECOGNIZED: 10 21 10 01 01 24 81 14 03 00 03 13 02 00 03 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 8
Device Status: 0x0000
(Bus Powered)

Bus 001 Device 003: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0557 ATEN International Co., Ltd
idProduct 0x2221 Winbond Hermon
bcdDevice 0.01
iManufacturer 1 Winbond Electronics Corp
iProduct 2 Hermon USB hidmouse Device
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 52
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 64
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Device Status: 0x0001
Self Powered

Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x8087 Intel Corp.
idProduct 0x0024 Integrated Rate Matching Hub
bcdDevice 0.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 6
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0103 power enable connect
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0103 power enable connect
Port 6: 0000.0303 lowspeed power enable connect
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 4.05
iManufacturer 3 Linux 4.5.0-0.bpo.2-amd64 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1a.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered
oder kürzer:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 5: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 5: Dev 4, If 0, Class=Vendor Specific Class, Driver=xpad, 12M
|__ Port 6: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M

USB ist aber imho immer noch die deutlich schlechtere Wahl, alleine schon der Funktionsweise wegen. Noch dazu ist auch die Leistung stark eingeschränkt, die direkt über den Bus bezogen werden kann, und eine zweite Spannungsquelle hinzuzuziehen ist nicht immer unproblematisch.
 
Zuletzt bearbeitet:
Twostone schrieb:
oder kürzer:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 5: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 5: Dev 4, If 0, Class=Vendor Specific Class, Driver=xpad, 12M
|__ Port 6: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
Also 2 USB-Busse hat das Mainboard im Beispiel. Wo hast du diese Informationen her?
 
Zurück
Oben