Ein Armutszeugnis: Isochroner Datentransfer bei USB-Audio

[JoeBroesel]

Hi,

was habe ich da kürzlich gelesen: Die Datenübertragung bei USB-Audio-Daten findet isochron statt.

Wikipedia erklärts: http://de.wikipedia.org/wiki/Universal_ ... r_Transfer

Das ist ja lächerlich. Da hat man eine Verbindung, die 480 MBit/s übertragen kann, für Audio-Daten bräuchte man max. ca. 10 MBit/s, und könnte so eine perfekt sichere Übertragung durchführen, aber nein, man überträgt isochron. D.h. die Daten werden geschickt, und wenn sie fehlerhaft ankommen, werden sie nicht wiederholt, sondern? verworfen? interpoliert? ignoriert?

Kein Wunder also, wenn durch Kabel und unterschiedliche Erdungsverhältnisse Unterschiede auftreten, dynamische Fehler bei der Übertragung etc. Das ist allerdings kein "Kabelklang", das ist nur traurig.

Grüße
J.

[wgh52]

...die Daten werden geschickt, und wenn sie fehlerhaft ankommen, werden sie nicht
wiederholt, sondern? verworfen? interpoliert? ignoriert?...

Wie unterscheidet man denn zwischen normaler und isosynchroner Übertragung? Müsste doch Einstellungssache sein, oder? Oder woher weiss "USB", dass es Audio überträgt?

Gruss,
Winfried

[Alex8529]

das ist nur traurig....

Hallo Zusammen,

so hart würde ich mit der USB Schnittstelle nicht ins Gericht gehen, denn die Sache ist ja ein bisschen anders zu sehen.

USB wurde ja nicht erfunden, dass der bequeme Hi-Ender jeden möglichen Audio-Kram zusammenstecken kann, nur weil grad eine USB-Dose vorhanden ist. USB hat einen ganz anderen Zweck, und wurde quasi für Streaming vergewaltigt.

Der Fall Franz+USB Kabel ist ja ein Paradebeispiel (sorry Franz), wie man es eben nicht machen sollte. Hätte Franz gleich die Bedienungsanleitung gelesen, und die Festplatte, wie von mir vorgeschlagen, eingebaut, gäbe es kein Problem mit dem USB-"Kabel"-Klang. Das Problem von Franz ist ja bislang ungeklärt, und wird es wohl auch bleiben.

AES/EBU sieht ja nicht viel besser aus, es kann zwar zwei Fehler erkennen und einen korrigieren, aber das Streaming-Paket ist fast 8 mal so groß.

Ohne reines Streaming würde aber auch keine Audio-Übertragung funktionieren, denn Fehlererkennungen und nochmaliges Senden, weil Fehler da war, frisst Zeit.

Die Daten-Transfer-Angaben von USB, AES, Ethernet, etc. sind rein theoretischer Natur. Ethernet hat zum Beispiel nur eine effektive Datenrate von ca. 5-10 % !!! der theoretischen.

Die Sorgfalt bei der Auswahl der Protokolle, Kabel, Abschirmungen, Stecker etc. bei einer digitalen Datenübertragung muss ganz einfach viel größer sein als bei einer analogen Übertragung.

Digital ist wie Licht, entweder es brennt, oder es brennt nicht.

Bei der analogen Übertragung wird der Signalpegel eben nur verringert, wenn die Übergangswiderstände nicht optimal sind, kein Problem, macht man eben lauter...

Grüße Frank

[aktivposten]

Hallo Frank,

Ethernet hat zum Beispiel nur eine effektive Datenrate von ca. 5-10 % !!! der theoretischen.

wo hast du diese Angabe her?

Gruß
Holger

[Franz]

Der Fall Franz+USB Kabel ist ja ein Paradebeispiel (sorry Franz), wie man es eben nicht machen sollte.
Hätte Franz gleich die Bedienungsanleitung gelesen, und die Festplatte, wie von mir vorgeschlagen, eingebaut, gäbe es kein Problem mit dem USB-"Kabel"-Klang.

Das hat mir mittlerweile auch gedämmert. Ich mußte da Lehrgeld zahlen, aber durch solche Geschichten werd ich auch ein Stück erfahrener. Inzwischen läuft die eingebaute Festplatte zu meiner vollsten Zufriedenheit. Und ein Gutes hatte die Sache - jedenfalls für mich - nämlich die Einsicht, daß eine externe Festplatte mittels USB-Kabel-Transport bei audio-Wiedergabe nicht angemessen erscheint.

Gruß
Franz

[Alex8529]

Hallo Frank,

Ethernet hat zum Beispiel nur eine effektive Datenrate von ca. 5-10 % !!! der theoretischen.

wo hast du diese Angabe her?

Hallo Holger,

das haben wir in unseren Anlagen gemessen, und entspricht auch in etwa den uns vorliegenden Angaben industrieller Hersteller.

Ich möchte aber das Schreckgespenst ein bisschen entschärfen.

Wenige, oder gar nur 2 Teilnehmer und große Pakte bringen mehr Durchsatz.

Grüße Frank

@Franz,
habe schon gelesen, dass es nun gut läuft.

[aktivposten]

Hallo Frank,

wir reden von einem realen Netzwerk (Server, PCs, Switch), richtig? Und in einem GBit Netzwerk beispielsweise hast du 6 - 12 MB gemessen?

Gruß
Holger

[JoeBroesel]

... Ethernet verwendet eine Methode (CSMA/CD), bei der jede Station, die etwas senden will, dies einfach tut. Senden zufällig zwei Stationen gleichzeitig, ist das eine Kollision (Ethernet kann das nicht). Beide Stationen warten mit dem nächsten Versuch eine zufällig gewählte Zeit - beiim nächsten Versuch gibt es nun hoffentlich keine Kollision. Wenn viele Stationen am Netz aktiv sind, gibt es häufiger Kollisionen. Bei zu vielen Stationen, die senden wollen, gibt es nur noch Kollisionen und keine Übertragung mehr....

Hi,

das war mal so.

Jetzt hat jeder einen Switch, statt einem Hub, und das Problem der Kollisionen ist passé.

Grüße
J.

[Fujak]

Hallo zusammen,

noch ein Beitrag zum Thema isochron und asynchron (genauer isochron mit asynchronen Endpunkten). Mittlerweile gibt es einige DACs die diesen asynchronen Modus mittels eigens programmierter USB-Schnittstelle praktizieren. Dazu gehört der Ayre QB9 oder die DACs der Firma Wavelength (der Pionier auf dem Gebiet) und in abgewandleter Form auch der NAIM DAC.

Daneben gibt es auch von EMU und Musiland USB-DACs mit asynchronem Modus, die allerdings eher von minderer Klangqualität sind, da deren asynchrone Schnittstelle mit nicht so hochwertigen Bauteilen realisiert wurde.

Übrigens verwendet auch das USB-SPDIF-Interface HiFace von M2Tech den asynchronen Modus mit 2 internen Clocks (jeweils für 44.1 und 48.0 und deren ganzzahlige Vielfachen).

Also insgesamt sieht es gar nicht sooo schlecht aus auf dem USB-DAC-Sektor.

Grüße
Fujak

[Bernd Peter]

Hallo,

asynchron bedeutet, dass der Rechner dem Wandler die Daten nur noch auf Anforderung (wenn der Buffer frei ist) liefert, weil hier ein Rückkanal zur Steuerung verwendet wird.

Der Oszillator des Wandlers besitzt dann die Takt-Herrschaft über das gesamte Wiedergabesystem, die hochwertige Clock des Wandlers erzeugt wesentlich wenig Jitter als die im PC.

Dieser Modus wurde erst mit USB 2.0 und den dazugehörigen Chips eingeführt. Das hat aber überhaupt nichts mit der Übertragungsgeschwindigkeit zu tun oder der Fehlerkorrektur.

Für diese programmierbaren Chips muss aber eine eigene Software geschrieben werden, das ist der Kostenfaktor und das Problem.

Man braucht einen geduldigen und fleißigen HiFi-Freak als Softwareentwickler, wie z.B. J. Gordon Rankin von Wavelength, der hat darüber fast 2 Jahre gesessen.

USB wurde von Intel nicht für Audiozwecke entwickelt, sondern um einen universellen, ab USB 2.0 auch schnellen neue seriellen Bus für die Datenübertragung zu schaffen. Der verwendete isochrone Modus garantiert dabei eine Mindestdatenrate bzw. eine konstante Periodendauer.

Das ist und war für die PC-Anwender das wichtige und richtige.

Und jetzt kommen die Leute aus der HiFi-Ecke und wollen gerade das Gegenteil, die Bytes sollen zu einem frei bestimmbaren, beliebigen Zeitpunkt versendet werden.

Also nicht aufregen, hier wird eine technische Entwicklung für einen neuen, kleineren Benutzerkreis angepasst, wäre natürlich schön, wenn das schon bezahlbarer Standard ist.

Gruß


Bernd

[KSTR]

Für DAC-Selberbastler scheint das hier sehr interessant, weil es liefert I²S (zumindest an Testpunkten) und an die Clocks kommt man auch ran, und ein einfacher CODEC (DAC+ADC) ist auch mit drauf:

http://www.xmos.com/products/development-kits/usbaudio2

Der XMOS-Gründer ist der seinerzeitige Mann hinter INMOS (und deren TRANSPUTERn, wem das noch was sagt), schonmal kein schlechte Basis.

MacOS kann es (d.h. 192/24 Audio asynchron USB2.0) schon ohne Treiber (heißt es, ich kenn mich da nicht aus), für Windows liegt einer dem EV-Kit bei.

Ich kenn noch ein andereres, ähnliches Async-USB2-Referenzdesign, muss ich aber erst nachschauen wie das heißt...

Grüße, Klaus

[Bernd Peter]

Kleiner Nachtrag,

ein erster bezahlbarer DAC mit asynchronem Eingang ist

http://rms-audio.com/produkte_det.php?brand_id=8&id=187

http://www.heimkinomarkt.de/News/8581/A ... A-Wandler/

der ARCAM rDAC

Gruß

Bernd

[Alex8529]

ein erster bezahlbarer DAC mit asynchronem Eingang ist
http://rms-audio.com/produkte_det.php?brand_id=8&id=187
http://www.heimkinomarkt.de/News/8581/A ... A-Wandler/

Hallo Jitter-Freunde,

ich bin da mal wieder skeptisch, denn es steht geschrieben

...der die eingehenden Daten in einem von dCS entwickelten Verfahren penibel neu taktet, und so komplett von Jitter befreit und eine Klangqualität ermöglicht, die bisher vom Computer undenkbar gewesen wäre.

das bedeutet: die Daten vom PC via USB kommen weiterhin als isochroner Stream an, und werden DANN bearbeitet.

dies wiederum bedeutet: dass Datenverfälschungen im USB Stream weiterhin existent sind, und dann eben als falscher Datensatz "verbessert" werden.

Der Jitter ist also gar nicht das Problem, er wird. m.E. wieder mal als Teufels Großmutter aufgebauscht.

Grüße Frank

[Fujak]

das bedeutet: die Daten vom PC via USB kommen weiterhin als isochroner Stream an, und werden DANN bearbeitet.
dies wiederum bedeutet: dass Datenverfälschungen im USB Stream weiterhin existent sind, und dann eben als falscher Datensatz "verbessert" werden.

Und genau bei Deinen Aussagen bin nun ich wieder sehr skeptisch. Bei der DCS-Technologie handelt es sich um eine Taktung des USB-Streams bzw. des Buffer-Verhaltens. Es sind ja nicht die Audio-Daten, die verfälscht werden, sondern das Clocksignal des PC ist oft fehlerbehaftet, und wenn die Clock des PC die Steuerung des Buffers übernimmt, ist dies eine potentielle Jitterquelle bei der Wandlung im DAC. Insofern greift dieser Modus genau dort an, wo die Ursache des Jitters im USB-Weg liegt - so auch im rDAC.

Wo ich hingegen beim rDAC skeptisch bin, ist die Frage, wie gut das Prinzip vom Schaltungslayout und den Bauteilen umgesetzt wurde. Es wäre nicht der erste DAC, der sich mit dem asynchronen Modus rühmt, der Hörvergleich aber deutlich werden lässt, dass andere DACs mit herkömmlicher isochroner Technik deutlich besser klingen. Siehe asynchrone Negativbeispiele Emu 0202 / Emu 0404 oder Musiland 01.

Grüße
Fujak

[Alex8529]

Bei der DCS-Technologie handelt es sich um eine Taktung des USB-Streams bzw. des Buffer-Verhaltens. Es sind ja nicht die Audio-Daten, die verfälscht werden, sondern das Clocksignal des PC ist oft fehlerbehaftet, und wenn die Clock des PC die Steuerung des Buffers übernimmt, ist dies eine potentielle Jitterquelle bei der Wandlung im DAC. Insofern greift dieser Modus genau dort an, wo die Ursache des Jitters im USB-Weg liegt - so auch im rDAC.

Mahlzeit zusammen,
hallo Fujak,

ich meine Dein obiger Beitrag vermischt ein bisschen den Ursache-Auswirkung-Heilung-Ablauf.

Was haben wir also im USB System.

1. PC
Der eventuell nicht in der Lage ist, die Datenpakete in korrekten/gleichen Zeitabständen abzuschicken

2. USB-Datenstream
Der keine Sicherungsmechanismen gegen Datenverfälschungen hat

3. DCS-Empfänger
Der die Daten im Buffer empfängt, und DORT besser getacktet weitergibt oder direkt verarbeitet

Gegen Punkt 2. kann der Empfänger Punkt 3 eben nichts machen.
Bitkipper bleiben Bitkipper und werden auch falsch weiter verarbeitet.
Der DCS-Empfänger kann auch nicht in den laufenden Stream, der vom PC kommt eingreifen.

Was wir in der Praxis immer beherzigen ist die Erkenntnis, dass Störungen immer an der Quelle bekämpft werden sollten, und nicht beim Empfänger.

Lösungen:

- einen Rechner nehmen/so ausrüsten, der korrekt die Daten absendet
- ein anderes Datenübertragungsformat nehmen, dass Bitkipper korrigieren kann

USB scheint nach den jetzigen Erkenntnissen kein HiFi taugliches Format zu sein.

Grüße Frank