USB asychroner Modus?

ZeeeM schrieb:

Was man auf technischer Seite über Modus liest ist, das das USB-Gerät schlicht und ergreifend dem Sender sagt, mein Puffer ist voll, halt oder du kannst wieder senden. Von Taktung liest man da Nichts.

So ist es nach meinem Verständnis. Im Idealfall ist es deshalb so - wie ich anderweitig bereits schrieb - dass die Clock, die den DAC taktet, das Tempo vorgibt, d.h. rückwirkend je nach Pufferfüllgrad dem USB-Sender sagt, dass er schneller oder langsamer machen soll. Und genau deshalb sind Wavelength, Ayre, dsc DACs mit NUR USB-Anschlüssen. Die Technik kann man genau so nämlich nicht so einfach auf andere Quellen anwenden. Ayre hat(te) - derzeit nicht zugreifbar - ein White Paper auf der homepage, die genau diese notwendige (!) Verbindung der D/A-Clock über den Puffer rückwirkend mit dem Transport dokumentiert. (Konsequenterweise lehnen sie deshalb auch separate CD-Transports und Wandler ab - nur die Puffersteuerung "rückwärts" zum Transport erlaubt diesen schneller oder langsamer laufen zu lassen, um den Pufferfüllgrad mehr oder weniger konstant zu halten, und nur so kann die D/A-Clock unabhängig von anderen Zeiteinflüssen ihren Takt einhalten.)

Deshalb ist auch ein HiFace (und einige andere vergleichbare Produkte, die gerade für schweineteuer - masslos ÜBERteuert - auf die Welt kommen) nicht wirklich perfekt: es hat einen eigenen Takt, und der notwendig nachfolgende Wandler hat seinen eigenen Takt - im ungünstigen Fall hat man also zwei konkurrierende Clocks. Wenn der DAC sich auf den HiFace anpasst, dann sollte es im Prinzip wieder gehen. Nur ist S/P-DIF auch nicht gerade optimal für sowas ...

Beim USB-adaptiv folgt der DAC dem angelieferten Takt (mehr oder weniger schlechter Qualität); ausserdem kann die Datenanlieferung schneller oder langsamer laufen als für den DAC nötig, was gelegentliche Anpassungen des DAC-Taktes (!) zur Folge hat, sobald es einen Buffer-Under- oder Overrun zu geben droht - so wird ein "lang"fristiger Ausgleich geschaffen.

Deshalb wird in besseren DACs, die USB-adaptiv arbeiten, über ASRCs ein neuer Datenstrom generiert, völlig neu getaktet. Trotzdem muss u.U. (siehe voriger Abschnitt) gelegentlich eine Taktanpassung vorgenommen werden. Der kurzzeitige Jitter ist damit so gut wie weg, die Taktanpassung bleibt (wird aber allen Berichten nach als nicht störend empfunden). Anders ausgedrückt: die Taktung des Eingangsdatenstroms mag vergleichsweise schlecht sein, die des Ausgangsdatenstroms kann aber 100% (na ja, im technisch möglichen Rahmen eben) stabil gemacht werden. Man hat dadurch quasi eine Entkopplung des Ausgangs- vom Eingangstakt erreicht.

Die Methode der Generierung eines neu getakten Datenstromes ist universell einsetzbar, das geht für alle Eingänge, also auch S/P-DIF und weitere. Bei Benchmark heisst das dann Ultra-Lock, bei Lavry Crystal Clock, bei RME Steady Clock, bei Apogee fand ich mal Double Clocking (und noch einen zweiten Begriff, der mir entfallen ist). Etliche Hersteller haben auch lesenswerte White Papers auf ihren homepages (man muss nur die Auslassungen erkennen können ).

ZeeeM schrieb:

... Asynchrone Modus der USB-Übertragung ... Auf den Seiten der Hersteller wird geschrieben, das in diesem Modus das USBgerät das Rechnerinterface "taktet" und damit die Masterclock für die Verbindung darstellt.

Siehe oben. Nicht im Sinne der Datenstromtaktung, sondern der Paketlieferung.

Im übrigen heisst das exakt isochroner Modus mit asynchronen Endpunkten bzw. isochroner Modus mit adaptiven Endpunkten. (Es gibt noch eine dritte Variante mit isochronen Endpunkten).

Allen gemeinsam ist die im Fehlerfall nicht wiederholte Datensendung, d.h. gegenüber "herkömmlicher" Datenübertragung reduzierte Fehlerkorrektur auf digitaler Ebene.

Im übrigen kann die Spezifikationen jeder auf www.usb.org nachlesen (die neueren 2er habe ich jetzt nicht auf die schnelle gefunden):
http://www.usb.org/developers/devclass_docs/usbccs10.pdf
http://www.usb.org/developers/devclass_docs/audio10.pdf

Gruss, Werner B.

Werner_B. schrieb:

ZeeeM schrieb: ... Asynchrone Modus der USB-Übertragung ... Auf den Seiten der Hersteller wird geschrieben, das in diesem Modus das USBgerät das Rechnerinterface "taktet" und damit die Masterclock für die Verbindung darstellt. Siehe oben. Nicht im Sinne der Datenstromtaktung, sondern der Paketlieferung.

Habe ich auch so verstanden, das es so läuft und nicht irgend ein Takt an den Rechner gegeben wird.
Ich habe spasseshalber mir mal die Demo von USBSpy geladen und geschaut, wie meine EMU0202USB die Daten überträgt. Im zugehörigen Endpoint Descriptor steht unter bmAttributes 0x05 drinn und das ist isochronous asynchron.
Mir wollte doch einer erzählen das die Übertragung bei der EMU nix mit dem asyncronus Modus anderer Dacs zu tun hat und nur das Teil eh kaum besser als ne billige Soundblaster ist.

ZeeeM schrieb:

Ich habe spasseshalber mir mal die Demo von USBSpy geladen und geschaut, wie meine EMU0202USB die Daten überträgt. Im zugehörigen Endpoint Descriptor steht unter bmAttributes 0x05 drinn und das ist isochronous asynchron.

Da wäre es doch mal interessant zu untersuchen, welche das noch machen bzw. können ... vielleicht gibt es noch mehr Firmen, die nicht viel aufhebens um eine kleine Selbstverständlichkeit machen?

Also los, Leute, wer kann Daten liefern? Würde mich jetzt doch mal interessieren ... (meine geplanten USB-DAC-Alternativen laufen nach Herstelleraussagen allesamt adaptiv, bei einem ist es mir nicht bekannt - vielleicht will ich dann doch noch einen asynchronen ).

ZeeeM schrieb:

Mir wollte doch einer erzählen das die Übertragung bei der EMU nix mit dem asyncronus Modus anderer Dacs zu tun hat und nur das Teil eh kaum besser als ne billige Soundblaster ist. ;)

Ich schrieb ja auch an anderer Stelle: es kommt sicherlich mehr auf die individuelle Implementierung an, schliesslich spielen auch noch die Wandler selbst, Filter und Ausgangsstufen eine Rolle. Gleichwohl finde ich es amüsant, wenn "High-Ender" als hauptsächlich Marketing-getrieben entlarvt werden.

Gruss, Werner B.

Werner_B. schrieb:

Also los, Leute, wer kann Daten liefern? Würde mich jetzt doch mal interessieren ... (meine geplanten USB-DAC-Alternativen laufen nach Herstelleraussagen allesamt adaptiv, bei einem ist es mir nicht bekannt - vielleicht will ich dann doch noch einen asynchronen ).

Teralink X2: 0x09 (Transfer Type: Isochronous)
Matrix Mini-I: 0x09 (Transfer Type: Isochronous)

Also keine Überraschung bei diesen beiden. Mich würde brennend interessieren, wie sich das Hiface von m2tech meldet.

Edit: Der Matrix Mini-I verwendet als Receiver scheinbar einen mir bis dato völlig unbekannten CN102S+. Der wird nur auf chinesischen Websites erwähnt/gezeigt. Weiß jemand näheres?

j!more schrieb:

Teralink X2: 0x09 (Transfer Type: Isochronous) Matrix Mini-I: 0x09 (Transfer Type: Isochronous) Also keine Überraschung bei diesen beiden.

Sicher?

0x09 (00001001) ist isochronous adaptive.
http://www.beyondlogic.org/usbnutshell/usb5.htm

Aus: http://www.thewelltemperedcomputer.com/KB/USB.html

Synchronous, adaptive and asynchronous When the computer sends the audio stream to an USB port, if first reads the data from the hard disk and caches blocks of the data in memory.It is then spooled from memory to the output port in a continuous stream (Isochronous mode - 12 Mb/s USB 2). This can be done with three possible types of synchronization. * Synchronous is very prone to jitter. * Adaptive mode is less jitter prone and used by most of today's USB audio devices. * Asynchronous mode, the audio device does the clocking. It tells the PC to regulate its speed. As the clock is running on the audio device this solution can be implemented in such a way that the the DAC receives a signal with a very low jitter.

ZeeeM schrieb:

j!more schrieb: Teralink X2: 0x09 (Transfer Type: Isochronous) Matrix Mini-I: 0x09 (Transfer Type: Isochronous) Also keine Überraschung bei diesen beiden. Sicher? 0x09 (00001001) ist isochronous adaptive. http://www.beyondlogic.org/usbnutshell/usb5.htm

Genau: Isochron ist der Transfer Type, und adaptiv der Synchronization Type. Bei Teralink stimmt das mit den Herstellerangaben überein (das ist zu erwarten, da gerade dieser Punkt recht einfach nachgeprüft werden kann). Noch interessanter wäre es bei den Herstellern, die keine Angaben dazu machen.

Danke schonmal für's Nachprüfen!

Gruss, Werner B.

j!more schrieb:

Mich würde brennend interessieren, wie sich das Hiface von m2tech meldet.

Hallo j!more,

habe eben Deine PM an mich gelesen. Hier also die gewünschten Infos zum Hiface:

Interface Descriptor
bLength: 0x09

Endpoint Descriptor
bDescriptorType: 0x05

Ich habe mich an die bislang geposteten Kategorien gehalten.

Falls weitere/andere Werte interessant sind, bitte melden.

Grüße
Fujak

Noch ein Zitat nachgeschoben, dass deutlich macht, dass der asynchrone Modus nicht alles ist:

"Asynchronous mode is not better by design but by implementation because you can implement a top quality (low jitter) clock in the DAC.
There is actually a good example of this case of its the implementation of the clock thats important, not the asyncness itself that is important. The recent inexpensive Musiland devices use an asynchronous protocol but then use a frequency synthesizer to generate the local clock rather than use a fixed frequency oscillator. The result is jitter that is actually worse than some of the better adaptive implementations!"
(Quelle: http://www.thewelltemperedcomputer.com/KB/USB.html)

Darüber wurde auch ausführlich im Head-fi.com gepostet, wo in einem Hörtest die Schnittstelle USB in, bzw. USB->SPDIF out (das ganze in separaten DAC) verglichen wurden:

EMU 0404 USB (assync.)
Musiland Monitor 01 USB (assync.)
Teralink-x (adapt.)
M2Tech hiFace. (assync.)

Die Geräte haben klanglich in dieser Reihenfolge abgeschnitten, d.h. am besten Hiface, am schlechtesten EMU 0404 USB (beide assync.).

Grüße
Fujak

@fujak: Bedankt!

j!more schrieb:

@fujak: Bedankt!

Auch nochmal herzlichen Dank an fujak.

Die Erfahrungen in dem Shootout kann ich so 1:1 nachvollziehen.
Das die EMU dermassen empfindlich auf Kabel und Transport reagiert lässt den Schluss zu, das die Implementation, insbesondere mit dem propritären Treiber schlicht und ergreifend nichts taugt.
Die Härte, mangelnde Räumlichkeit, sowie der schwammige Bass wird durch den DAC nicht besser und bei der EMU0202 ist das Ganze dann entgültig unbrauchbar.
Im Hörtest sind viele PCM270x basierte DACs den EMUs weit überlegen.
Desweiteren wird in dem Shootout mit der Mär aufgeräumt, das Transport und USB-Kabel durch den async Mode keinen Einfluß auf den Klang hat.
Im Prinzip ist es in der Praxis vollkommen egal, wie die Daten übertragen werden. Es kommt nur darauf an, was hinten herauskommt.
Ich sehe in diesem Thread eigentlich kein Theman von praktischem Nutzen und bitte die Moderation darum, diesen überflüssige Thema zu schliessen.

Hearmaster schrieb:

Ich sehe in diesem Thread eigentlich kein Theman von praktischem Nutzen und bitte die Moderation darum, diesen überflüssige Thema zu schliessen.

Hallo Hearmaster,

der praktischen Nutzen dieses Threads besteht in meinen Augen genau darin, dass unter anderem solcherlei Erkenntnisse entstehen, dass der asynchrone Modus zwar bessere Ausgangsbedingungen für eine technisch gute Lösung beinhaltet aber noch lange keine Garantie dafür ist.
Insofern ist mir Dein Antrag auf Schließung zu radikal, zumal es nicht besonders respektvoll dem Threadersteller gegenüber wäre, der ja mit diesem Thread ein bestimtes Anliegen verfolgt. Und wer weiß, welche weiteren Erkenntnisse der Thread zum Thema asynchroner Modus in der Zukunft offenbart...

Grüße
Fujak

fujak schrieb:

habe eben Deine PM an mich gelesen. Hier also die gewünschten Infos zum Hiface: Interface Descriptor bLength: 0x09 Endpoint Descriptor bDescriptorType: 0x05

blength interessiert nicht, der bDescriptortype ist immer 0x05. Der bmAttributes Wert des transporienden Kanals ist interessant.

Hier nochmal der Link zum Shootout: http://www.head-fi.o...2tech-hiface-449885/
Immerhin wertet er die Emu über USB höher als den Audio-gd DAC-19MK3. Desweiteren rennt er bei Flac und kleinen Latenzzeiten in massive Störungen, was auf ein Konfigurationsproblem hinweist. Da diese Störungen woanders nicht auftreten und bei async Übertragung keine Daten erneut gesendet werden, kann dies schon für den Klangunteschied verantwortlich sein.
Weiterhin sollte man zwei Dinge im Kopf haben: 1. den Preis und 2. die Größenordnung der Unterschiede.

ZeeeM schrieb:

blength interessiert nicht,

Der Rest der Werte auch nicht, weil in der Praxis das Klangergebnis von Interesse ist und nicht was in irgendwelchen Registern steht oder irgendwo von Irgendwem gemessen wird.

Hier nochmal ein Häppchen aus der Praxis:

http://www.head-fi.o...x75.html#post6545559

Erstaunlich, das Alles für den Klang relevant ist, nicht wahr? Auch den Bericht kann ich so bestätigen.
Genau deswegen sind Alle beteiligten Parts von enormer Wichtigkeit für das Ergebnis und nicht irgendwelche Einzelwerte.

@fujak: Den Thread sollte man vieleicht nicht schließen, sondern umbenennen in "Von Digital nach Analog - Was muss beachtet werden?"
Die Holzohren aber sollte man kommentarlos links liegen lassen.

Hearmaster schrieb:

Der Rest der Werte auch nicht, weil in der Praxis das Klangergebnis von Interesse ist und nicht was in irgendwelchen Registern steht oder irgendwo von Irgendwem gemessen wird.

Wieder mal ein echter Hearmaster. Diesen Thread zu schliessen hiesse, auf Deine Kommentare zu verzichten. Wäre kontraproduktiv, denn der Unterhaltungswert ist enorm.

ZeeeM schrieb:

blength interessiert nicht,...

Geht es vielleicht noch unfreundlicher? Für mich habe ich diese Infos nicht gepostet...

Fujak

Es geht um den vom Gerät benutzen Übertragungsmodus. und die von dir angebenen Werte sind in dem Zusammenhang nun mal irrelevant. Der eine Wert beschreibt nur die Länge des Descriptor, der andere Wert ist sogar fix.
Wer hat denn genau diese Werte angefragt? Kann es sein das du, oder der Frager sich einfach verhauen habt?

PS: An den Umgangsformen des Hörmeisters hast du komischerweise nie was auszusetzen.

unnötiges Komplettzitat bei Direktantwort entfernt

Hallo,

Moderation hier, bitte beim Thema bleiben!

Grüße,
Florian

ZeeeM schrieb:

Kann es sein das du, oder der Frager sich einfach verhauen habt?

Kann sein, dass der Frager sich verhauen hat: Ich hatte auf diesen Thread verwiesen und Fujak gebeten, die Daten für das HiFace zu ermitteln. Wenn, ist es also meine Schuld.

Na, nachdem hier aufgeräumt wurde, kann Zeem vielleicht nochmal beschreiben wie man die Daten richtig ausliest und welche hier benötigt werden.
Wäre schon ne sinnvolle Sache, da einige Hersteller dazu keine Angaben machen.
Ist das für FireWire ebenso sinnvoll? Da wird ja ebenso im isochronous Modus gearbeitet. Kennt jemand Infos die über http://www.firewire-infos.de/ hinausgehen?


Grüße

j!more schrieb:

ZeeeM schrieb: Kann es sein das du, oder der Frager sich einfach verhauen habt? Kann sein, dass der Frager sich verhauen hat: Ich hatte auf diesen Thread verwiesen und Fujak gebeten, die Daten für das HiFace zu ermitteln. Wenn, ist es also meine Schuld.

Mir geht es ja in dem Thread nur darum, welche Geräte welchen Übertragungsmodus beherrschen. Einige Hersteller reklamieren, das isochron-async nur bei ach to teuren Geräten geht. Was man sehen kann ist, das es wohl kaum USB Receiver Chips gibt, die es von der Stange können. Es gibt dafür einige spezielle Bausteine, für die teurer (?) Code eingekauft werden muss, wie bei den TI TAS Teilen, so weit ich mich erinnere, oder das Hersteller ihre eigenen Schaltungen mittels FPGAs basteln. Auch EMU hat dafür eigene Hardware entwickelt. Was ich damit meine ist, das dieses Feature sicher nicht teuer sein brauch und damit reines Marketing betrieben wird.
Inwieweit das absolut klangrelevant ist, das steht auf einem anderen Blatt. In einem Head-Fi Thread findet man durchaus, das USB-Kabel deutliche Klangänderungen hervorrufen können, wie sie bei analoger Übertragung typisch sind und das ohne im Ausgangssignal nach dem DAC irgendwas davon zu sehen. It´s Magic oder G..... kann Berge versetzen.

NX4U schrieb:

Na, nachdem hier aufgeräumt wurde, kann Zeem vielleicht nochmal beschreiben wie man die Daten richtig ausliest und welche hier benötigt werden.

*2: Ich hatte mich im ersten Anlauf auch schwer getan, den richtigen Eintrag zu finden. Und man kann nicht von jedem normalen PC-Nutzer erwarten, dass er sich auf Anhieb in einem für ihn fremden, englischsprachigen Programm zurechtfindet, das als Tool für Entwickler geschrieben wurde.

Also: Eine Klickanleitung wäre nicht verkehrt.

ZeeeM schrieb:

Inwieweit das absolut klangrelevant ist, das steht auf einem anderen Blatt. In einem Head-Fi Thread findet man durchaus, das USB-Kabel deutliche Klangänderungen hervorrufen können, wie sie bei analoger Übertragung typisch sind und das ohne im Ausgangssignal nach dem DAC irgendwas davon zu sehen. It´s Magic oder G..... kann Berge versetzen. :*

Richtig gut war der Tipp, bei SPDIF-Kabeln Längen zwischen ein und zwei Metern zu meiden, weil...

j!more schrieb:

Also: Eine Klickanleitung wäre nicht verkehrt.

Jetzt habe ich es wieder runtergeschmissen, da der Treiber irgendwie bei USB_Transfers doch komisch machte.
Ich habe nach den Endpoint_descriptors gesucht und die nach "Usb in a nutshell chapter 5" ausgewertet.

j!more schrieb:

Richtig gut war der Tipp, bei SPDIF-Kabeln Längen zwischen ein und zwei Metern zu meiden, weil...

Würde mich auch nicht wundern, wenn gehört wird, ob das Spdif-Kabel auf dem Boden liegt, oder in der Luft hängt.. die böse Mikrofonie.

j!more schrieb:

Richtig gut war der Tipp, bei SPDIF-Kabeln Längen zwischen ein und zwei Metern zu meiden, weil...

Was soll daran komisch sein? Es kommt auf das hörbare Ergebnis an, oder nicht?
Man sollte sich erstmal eingehend damit beschäftigen und vor allen Dingen testen, bevor man sich über Dinge, die vieleicht auf dem ersten Blick seltsam erscheinen, lustig macht.

ZeeeM schrieb:

Würde mich auch nicht wundern, wenn gehört wird, ob das Spdif-Kabel auf dem Boden liegt, oder in der Luft hängt.. die böse Mikrofonie. :D

Soll das jetzt ein sachlicher Beitrag zum Thema sein?
Sich über Leute und deren Erfahrungen lustig zu machen ist kein sonderlich guter Charakterzug. Klar?

Hearmaster schrieb:

j!more schrieb: Richtig gut war der Tipp, bei SPDIF-Kabeln Längen zwischen ein und zwei Metern zu meiden, weil... Was soll daran komisch sein? Es kommt auf das hörbare Ergebnis an, oder nicht? Man sollte sich erstmal eingehend damit beschäftigen und vor allen Dingen testen, bevor man sich über Dinge, die vieleicht auf dem ersten Blick seltsam erscheinen, lustig macht.

Das IST komisch. Ich bestreite ja gar nicht die Wahrnehmung, aber die Schlüsse daraus sind halt daneben.

Dieser ganze Elektronik- und Computerkram ist keine Zauberei, sondern funktioniert auf Basis einer überschaubaren Reihe von Naturgesetzen. Und die machen nun mal keine Ausnahmen für eine Leitungslänge zwischen einem und zwei Metern.

WENN in einer bestimmten Konfiguration also ein Kabel mit ein bis zwei Metern Länge schlechter klingt als ein kürzeres oder längeres, liegt eine Fehlanpassung vor. Das kann am Kabel liegen oder an den Steckern (anderer Wellenwiderstand als 75 Ohm), das kann aber auch an Sendern oder Empfängern ausserhalb der Spezifikation liegen.

Das ist doch nicht so schwer zu verstehen, oder?

j!more schrieb:

WENN in einer bestimmten Konfiguration also ein Kabel mit ein bis zwei Metern Länge schlechter klingt als ein kürzeres oder längeres, liegt eine Fehlanpassung vor. Das kann am Kabel liegen oder an den Steckern (anderer Wellenwiderstand als 75 Ohm), das kann aber auch an Sendern oder Empfängern ausserhalb der Spezifikation liegen. Das ist doch nicht so schwer zu verstehen, oder?

Eigentlich nicht. Aber was willste machen, wenn zum einen große Klangunterschiede gehört werden obwohl am Ausgangssignal in keinster Weise messbar etwas festzustellen ist und zum anderen die eigene Hörwahrnehmung als unumstösslich objektiv eingeschätzt wird?

Auf der RME-Website gibt es ja wertvolle Hinweise auf mögliche Probleme beim Betrieb der USB-Schnittstelle.

Dort findet sich ein Verweis auf den DPC Latency Checker, mit dem sich prüfen lässt, ob ein System mit Echtzeit-Datenströmen umgehen kann.

Es werden auch einige Hinweise gegeben, wie störende Komponenten identifiziert werden können. In meinem Dell-Notebook etwa trägt die Deaktivierung der WLAN-Karte zur Beruhigung bei.

j!more schrieb:

Auf der RME-Website gibt es ja wertvolle Hinweise auf mögliche Probleme beim Betrieb der USB-Schnittstelle. Dort findet sich ein Verweis auf den DPC Latency Checker, mit dem sich prüfen lässt, ob ein System mit Echtzeit-Datenströmen umgehen kann. Es werden auch einige Hinweise gegeben, wie störende Komponenten identifiziert werden können. In meinem Dell-Notebook etwa trägt die Deaktivierung der WLAN-Karte zur Beruhigung bei.

Ein Video läuft, ca. 170 GB werden auf externe HD kopiert und in einer VBox Session läuft Ubuntu.
Pendelt um 100 Mikrosekuden, max. 436. Ohne Ubuntu pendelt der Wert um 20 Mikrosekunden.

Es wird bekanntermaßen viel gehört, wenn der Tag lang ist, sobald es dann unter kontrollierten Bedingungen gehört werden soll, kommt nichts dabei raus. Mit diesen Geschichten füllt sich das halbe Forum. Daher lohnt es sich auch gar nicht, auf solche anekdotischen Erzählungen einzugehen.

Es ist zwar offensichtlich in höchstem Masse unerwünscht beim Thema zu bleiben, gleichwohl nochmal zur Klärung für diejenigen, die mal Innereien nachprüfen wollen:

ZeeeM schrieb:

Im zugehörigen Endpoint Descriptor steht unter bmAttributes 0x05 drinn und das ist isochronous asynchron.

Genau. Also im Endpoint Descriptor:

bmAttributes = 0x05 isochron mit asynchronem Endpunkt
bmAttributes = 0x09 isochron mit adaptivem Endpunkt

Gruss, Werner B.

ZeeeM schrieb:

Im zugehörigen Endpoint Descriptor steht unter bmAttributes 0x05 drinn und das ist isochronous asynchron.

Ich habe mich mit einem befreundeten Techniker unterhalten, der die EMU0202 und die 0404 hat und der meint das wäre Quatsch. Er schaute nochmal nach und der Wert ist bei ihm 0x0D Nix mit asynchronous.
Und nun?

Hearmaster schrieb:

Ich habe mich mit einem befreundeten Techniker unterhalten, der die EMU0202 und die 0404 hat und der meint das wäre Quatsch. Er schaute nochmal nach und der Wert ist bei ihm 0x0D Nix mit asynchronous. Und nun?

Wahrscheinlich den falschen Endpoint Descriptor untersucht: ein Audio-Interface wie die einfachen EMUs hat mindestens dreie: einen Control (für den initialen Aufbau der Verbindung, Festlegung Transfer und Synchronization Type etc.), und zwei isochrone (je einen für Aufnahme und einen für Wiedergabe).

Aller Wahrscheinlichkeit nach hat Dein Techniker den für die Aufnahme sich nur angesehen:

Endpoint Descriptor:

bmAttributes = 0x0D isochron mit synchronem (!) Endpunkt

Das ist die dritte Variante, die ich oben schon erwähnte, und die unter den dreien für Audio-Wiedergabe am wenigsten taugt.

Gruss, Werner B.

Werner_B. schrieb:

bmAttributes = 0x0D isochron mit synchronem (!) Endpunkt Gruss, Werner B.

Bei den EMUs ist der mit dem Attribut 0x05 der für die Wiedergabe. Der für die Aufnahme hat 0x25.
Ein bmAttribut von 0x0D gibt es da weit und breit nicht.
Das Hörmeisterchen will ja auch "Rotationsjitter" von Festplatten hören. LOL!

So wenig steck in der 0202 auch nicht drinn:

http://s10.directupload.net/images/100505/v89urxix.jpg

Mich würde interessieren, was die Angabe bmAttribute 0x02 im Endpoint Descriptor bedeutet.

Grüße
Fujak

fujak schrieb:

Mich würde interessieren, was die Angabe bmAttribute 0x02 im Endpoint Descriptor bedeutet. Grüße Fujak

Bulk Transfer

ich zitiere mal:

Bulk-Transfers:

Mittels Bulk-Transfer werden typischerweise große Datenmengen übertragen, wie sie beispielsweise bei Druckern oder Scannern anfallen. Bulk-Daten sind sequentiell. Ordnungsgemäßer Datenaustausch wird auf Hardwareebene durch Fehlererkennung sichergestellt. Im Bedarfsfall können auch begrenzt Wiederholungen einer Transaktion ausgeführt werden. Eine feste Bandbreite ist für diese Art der Datenübertragung nicht vorgesehen. Es wird die Bandbreite benutzt, die gerade verfürbar ist. Ist der Bus schon voll ausgelastet wird mit der Übertragung solange gewartet, bis wieder Kapazitäten vorhanden sind.

ZeeeM schrieb:

Bei den EMUs ist der mit dem Attribut 0x05 der für die Wiedergabe. Der für die Aufnahme hat 0x25.

Das ist ein Explicit Feedback Data Endpoint ... Du hast selbst eine Spezifikation oben verlinkt, lies nochmal nach. Ein Feedback Data Endpoint passt nicht für die Aufnahme (jedenfalls nicht allein). Und die 5 sagt wieder isochron/asynchron ... Das könnte nämlich bei der asynchronen Wiedergabe genau die Steuerung beinhalten, um die Datenlieferung zu beschleunigen bzw. zu verlangsamen.

ZeeeM schrieb:

Das Hörmeisterchen will ja auch "Rotationsjitter" von Festplatten hören. LOL! :D

Dient diese Anmerkung nun der Wahrheitsfindung? Falls ja, inwiefern?

Gruss, Werner B.

Werner_B. schrieb:

ZeeeM schrieb: Das Hörmeisterchen will ja auch "Rotationsjitter" von Festplatten hören. LOL! :D Dient diese Anmerkung nun der Wahrheitsfindung? Falls ja, inwiefern?

Das man zu dem Themen dessen Aussagen einfach ignorieren sollte, da deren Nutzinformationsgehalt wohl nicht gegeben.

Zur Abwechslung mal wieder etwas on topic:

Bei teradac scheint man über einen für asynchronen Betrieb ausgelegten und optimierten X2 nachzudenken. Hier geht es zu dem entsprechenden und leider in jeder Hinsicht nebulösen Post auf Headfi.

ZeeeM schrieb:

Werner_B. schrieb: ZeeeM schrieb: Das Hörmeisterchen will ja auch "Rotationsjitter" von Festplatten hören. LOL! :D Dient diese Anmerkung nun der Wahrheitsfindung? Falls ja, inwiefern? Das man zu dem Themen dessen Aussagen einfach ignorieren sollte, da deren Nutzinformationsgehalt wohl nicht gegeben. ;)

Uverschämtheiten und Beleidigungen sind dein "Fachgebiet"?

Hearmaster schrieb:

Uverschämtheiten und Beleidigungen sind dein "Fachgebiet"?

Was ist daran beleidigend wenn es schlicht und einfach die Wahrheit ist?