audiophiles USB-Kabel

Wenn es ein USB Kabel von Apple gäbe hätte es einen Stecker der nirgends passt.

lol

scirocco790 schrieb:

Der_Schlosser schrieb: Hauptsache das USB-Kabel ist von Apple das sind die besten. Wenn es ein USB Kabel von Apple gäbe hätte es einen Stecker der nirgends passt... :L

Bitte kein Apple-Bashing im Forum, danke.

ZeeeM schrieb:

Du suggerierst aber auch immer gerne, das bestimmte Phänomene nicht im Griff zu bekommen sind. Das von BB verwendete Sampling Period Adaptive Controlled Tracking, ist da schon ziemlich gut. http://nwavguy.blogspot.com/2011/10/uca202-dac-take-2.html

Es handelt sich doch eigentlich um Autosuggestion bestimmter Leserkreise (insb. "Glaubenstechniker" ).

Denn explizit geschrieben habe ich, daß:

-) in Fällen einer "Echtzeitaudioausgabe" des Endgerätes nicht mit der Datenrichtigkeit als Argument gegen (möglicherweise vorhandene) Klangunterschiede gearbeitet werden kann. Stichwort notwendig aber nicht hinreichend

-) es, in dem vom TE verlinkten Fall, zusätzlich überrascht, daß derartige Klangunterschiede wahrnehmbar seien, da der dort verwendete Wandler verschiedene "Gegenmaßnahmen" beeinhaltet

-) es grundsätzlich sowohl sinnvoller Hörexperimente bedarf (um festzustellen, ob wahrnehmbare Unterschiede vorhanden sind) und sinnvoll eingesetzter Messung (um herauszufinden, worauf vorhandene Klangunterschiede beruhen)

-) der Preis der verglichenen Kabel in einer technischen Betrachtung irrelevant sei, da eben keine technische Größe

-) man sich mit den Spezifikationen der Schnittstelle und der jeweiligen Realisation in den Geräten auseinandersetzen muß, um beurteilen zu können .....


Alles andere findet eben nur in der Einbildung bestimmter Leser statt.

Gruß

GraphBobby schrieb:

Wie kannst du sagen, dass er nicht im Picosekundenbereich liegt?

Kann ich nicht, wie sollte ich ohne an der fraglichen Kombination gemessen zu haben? (s.d.a. meine Beiträge anfangs des Threads; ich schrieb nicht umsonst von _sinnvoll_ eingesetzter Messtechnik, um derartige Fragen zu klären)

Wie gross ist denn nun der Jitter, ich habe schon weiter oben einmal nach konkreten Angaben gefragt, damit die Sache endlich geklaert werden kann?

s.o.

Wenn du Behauptungen wie "Zeitrichtigkeit" aufstellst, dann musst du auch mit entsprechenden Daten belegen, dass das Timing wesentliche Schwankungen aufweist.

"Zeitrichtigkeit" ist keine Behauptung, sondern die Grundlage der bislang in der Audiotechnik verwendeten zeitdiskreten Signale bzw. der Rückwandlung in analoge Signale.

Ich habe (s.d.a. die Antwort an ZeeeM) in diesem Thread gepostet, weil viele Teilnehmer argumentierten, an der Geschichte könne nichts dran sein, weil USB ja "paketorientiert sei" , "die Daten im Empfänger umsortiert würden", "Computer/Festplatten usw. ja auch funktionieren würden" usw. usw. - kurzum, die ganze Bandbreite falscher Argumente, die in derartigen Threads zu finden ist, wurde aufgeboten.

Da die Hersteller ja alle hochwissenschaftlich arbeiten, und teilweise sogar mit noch so absurden subatomaren Einfluessen argumentieren, wird sowas stinknormales wie eine Vergleichsmessung der Timing-Schwankungen eines normalen Kabels und eines "guten" Kabels ja wohl vorliegen, oder?

Ob die Hersteller "hochwissenschaftlich arbeiten" oder auch, womit sie sonst argumentieren, ist irrelevant, wenn es um grundsätzlich mögliches oder unmögliches geht.
Es sollte nur klar sein (deshalb auch häufiger so geschrieben), daß es um einen (möglicherweise vorhandenen) Klangunterschied nach Austausch eines USB-Kabels zwischen den beschriebenen Geräten geht.

Es sollte, wenn man denn einmal den Irrweg der falschen "Paketorientierungsargumentation" verlassen hat, und begriffen hat, worum es in einer derartigen Anwendung geht, daß die Ergebnisse nicht universell von Konfiguration zu Konfiguration übertragbar sein können, sonder es eben auf die gerätespezifische Realisation ankommt.

Gruß

Hallo Jakob

Jakob1863 schrieb:

Ich habe (s.d.a. die Antwort an ZeeeM) in diesem Thread gepostet, weil viele Teilnehmer argumentierten, an der Geschichte könne nichts dran sein, weil USB ja "paketorientiert sei" , "die Daten im Empfänger umsortiert würden", "Computer/Festplatten usw. ja auch funktionieren würden" usw. usw. - kurzum, die ganze Bandbreite falscher Argumente, die in derartigen Threads zu finden ist, wurde aufgeboten.

Die Argumente sind nicht falsch, auch wenn du das gerne in deratige Threads behauptest.

Es sollte nur klar sein (deshalb auch häufiger so geschrieben), daß es um einen (möglicherweise vorhandenen) Klangunterschied nach Austausch eines USB-Kabels zwischen den beschriebenen Geräten geht.

Genauer geht es darum, dass sich der Klang durch Austausch des USB-Kabels gegen das High End USB-Kabel verbessern soll. Also wie macht das USB Kabel das?

Es sollte, wenn man denn einmal den Irrweg der falschen "Paketorientierungsargumentation" verlassen hat, und begriffen hat, worum es in einer derartigen Anwendung geht, daß die Ergebnisse nicht universell von Konfiguration zu Konfiguration übertragbar sein können, sonder es eben auf die gerätespezifische Realisation ankommt.

Die "Paketorientierungsargumentation" ist kein Irrweg. Vielleicht solltest du langsam begreifen worum es in dieser Art von Anwendung geht.
Es wird ein USB Kabel angeboten, welches den Klang verbessern soll, unabhängig zwischen welchen Geräten es dann benutzt wird. Gerade die USB Kabel sind dafür konzipiert universell eingesetzt zu werden. Dem Kabel ist es egal ob es Videodaten, Audiodaten oder Sourcecode transportiert. Da muss Nichts gerätespezifisch Realisiert werden. Wenn die USB-Spezifikation eingehalten werden ist alles gut
Hast du denn schon eine Erklärung gefunden wie ein Kabel die Bits verändern kann?

pelmazo schrieb:

Und man kann davon ausgehen daß ihm genau das auch weisgemacht werden soll, damit er die überteuerten Dinger kauft.

Wobei es sich in dem vom TE verlinkten Fall um einen Leserbericht handelt.

Im Fall des Aqvox-Kabel von weiter oben im Thread ist z.B. anzunehmen, daß die beiden mit Schrumpfschlauch kaschierten Verdickungen in der Nähe der Stecker einfach Ferrithülsen enthalten, die hochfrequente Mantelströme dämpfen. Wenn solche Mantelströme zu Störungen in einem angeschlossenen USB-Audiogerät führen sollten, was nicht ausgeschlossen ist, was aber für einen konstruktiven Mangel in diesem Gerät sprechen würde, dann hätte ein solches Kabel einen realen Nutzen. Der käme bloß zu einem Wucherpreis daher, denn der Kunde könnte genauso gut Klappferrite für wenige Euro kaufen, und ein Standard-USB-Kabel damit ausrüsten. Noch besser wäre es wenn er den Gerätehersteller für das Problem verantwortlich macht.

Das ist insofern ein schönes Beispiel, denn innerhalb der Audioforen wurde ja häufiger auch über Klappferrite und ähnliche Maßnahmen diskutiert.
Würdest du mir widersprechen, wenn ich sage, daß auch in diesen Diskussione die Mehrzahl der "Glaubenstechniker" kategorisch jede Klangänderung ins Reich der Fabel verwies?

Selbstverständlich nützt es auch in diesen Fällen nichts, wenn ich mir "die Finger wundschreibe" , um die Wirkungsweise von Ferriten in Erinnerung zu rufen.

Wir können vermutlich eine Wette eingehen, daß auch der nächste, mit Sicherheit kommende, Thread über Klappferrite genau den gleichen Verlauf wie immer nehmen wird.

Wenn man den Preis dieses Kabels mit Zubehörkabel von z.N. Meßgeräteherstellern erscheint auch der Preis nicht wirklich überzogen.
Das es darüberhinaus auch nicht Sache jedes Kunden ist, per "Bastellösung" an die Sache heranzugehen, dürfte ja auch auf der Hand liegen.

Die Verarsche besteht also nicht darin, daß man ihm Klangänderungen vorspielt, die es nicht geben kann, sondern daß man ihm vormacht, er könne solche Klangänderungen durch Kauf des entsprechenden Kabels zielgerichtet herbeiführen.

Die andere Form der "Verarsche" (bei ziemlich weitreichender Ahnungslosigkeit)ist, den Leuten zu erzählen, es gäbe gar keine Klangänderungsmöglichkeiten, es sei also eigentlich vollkommen egal, welches Gerät/Konfiguration man nehme.
In meinen Augen vielleicht sogar noch schlimmer, denn wer einmal auf diese Form reingefallen ist, der glaubt danach keinem Techniker mehr etwas.

In Wirklichkeit ist es ein Hinweis auf ein Problem, wenn sich durch Kabeltausch eine Klangveränderung ergibt. Ein anderes Kabel löst in aller Regel dieses Problem nicht, sondern ändert die Symptome.

Das ist ziemlich sicher so, kann aber auch helfen.

Und nicht selten ist das die Grundlage, auf der man dem Kunden dann versucht, weiteren Ramsch anzudrehen, denn da das Problem weiter besteht kann man weitere Klangänderungen durch Tausch von irgendwas bewirken.

Das Problem gibt es durchaus. Allerdings wird es auch nicht besser, wenn man das Klangproblem negiert, und behauptet, es könne ja nicht....

Man hat die Kundschaft sogar dahingehend gedrillt, daß sie diesen Zustand für normal, erstrebenswert und ein gutes Zeichen halten, indem man ihnen das Gefühl eingetrichtert hat, die solcherart prekäre Anlage sei jetzt "hochauflösend". Das ist dann eine vollends verkehrte Welt, in der die besseren Anlagen, die auf solchen Firlefanz nicht reagieren, als schlechter gelten, eben weil sie darauf nicht reagieren.

Wobei das doch eher eine Reaktion auf die jahrelange fruchtlose Diskussion ist, denn den vielen Hörern scheint es mE egal zu sein, wie sich guter Klang entwickelt.
Ich habe es zumindest bislang noch nicht erlebt, daß jemand eine gutklingende Anlage (unterstellt für den Augenblick, daß die Betreffende es beurteilen konnten) nichts tauge, wenn nicht ausreichend "umstrittenes" eingesetzt wurde.

Es mag allerdings wohl sein, daß einige denken, die Anlage könne vielleicht noch besser klingen, wenn zusätzlich noch "umstrittenes" eingesetzt würde.
Grundsätzlich ist es auch nicht einfach zu klären, ob eine Anlage _wirklich_ nicht auf "Firlefanz" reagiert, oder ob manche es nur so hören (vielleicht, weil sie es einfach glauben wollen) .

Hinzu kommt, daß aus der "Alles klingt gleich Verarsche" häufig Gerätetipps resultieren, bei denen man mangels verfügbarer technischer Daten überhaupt keine Vorstellung mehr entwickeln kann, ob diese nun bestimmungsgemäß funktionieren. Gutes Beispiel hierfür sind mE allerlei Schnittstellenkonverter.

Gruß

Jakob1863 schrieb:

"Glaubenstechniker"

Was bitte soll das sein?

Das ist die neue Berufsbezeichnung für Pfarrer

Hallo,

es ist noch Pudding da....

oh pudding


schmeckt ein puddig aus nem goldbecher besser wie aus nem plastikbecher ?

das ist doch der gleiche sachverhalt wie mit dem kabel hier.

audiophiles neues jahr !

Jakob1863 schrieb:

Wobei es sich in dem vom TE verlinkten Fall um einen Leserbericht handelt.

Das stimmt, aber die Grenzen sind da fließend. Mir scheint, es gibt eine gewisse "Kategorie" von Lesern, die auf der einen Seite die "audiophilen" Glaubensgrundsätze voll und ganz verinnerlicht haben, und sich auf der anderen Seite den einschlägigen Herstellern als Marketinginstrument andienen, um im Gegenzug günstiger an die prestigeträchtigen Produkte zu kommen. Ich bin inzwischen davon überzeugt, daß eine ganze Reihe von Herstellern es sehr gut drauf haben, diese "unschuldige" und ziemlich naïve Ressource für sich zu nutzen. Es scheint oft zu reichen wenn man diesen Leuten das Gefühl von Wichtigkeit gibt, dann singen sie das "richtige" Lied freiwillig.

Das ist insofern ein schönes Beispiel, denn innerhalb der Audioforen wurde ja häufiger auch über Klappferrite und ähnliche Maßnahmen diskutiert. Würdest du mir widersprechen, wenn ich sage, daß auch in diesen Diskussione die Mehrzahl der "Glaubenstechniker" kategorisch jede Klangänderung ins Reich der Fabel verwies?

Nein, da widerspreche ich Dir nicht. Ich sehe das aber auch nicht als ein gravierendes Problem an. Es stimmt zwar, daß Bornierte auf beiden Seiten zu finden sind, aber ich bin davon überzeugt daß die Technikerseite öfter recht hat.

Zum Beispiel glaube ich nicht, daß die Klangänderungen, die in dem eingangs verlinkten "Leserbericht" beschrieben werden, real sind, d.H. etwas mit Klappferriten, Brummschleifen oder Jitter zu tun haben. Ich halte sie für frei erfunden/eingebildet, und ich glaube daß der Autor genau zu den Leuten gehört, die dafür besonders anfällig sind.

Ich meine auch, daß selbst die als besonders borniert rüberkommenden Techniker in weniger absurden Fällen zu einer differenzierteren Sichtweise in der Lage wären. Dafür würde es aber eine Diskussionssituation brauchen, in der man erwarten kann daß diese Differenzierung auch auf der Gegenseite ankommt.

Ich habe es selbst aber schon oft genug erlebt, daß dafür nicht die geringste Bereitschaft besteht. Wenn ich erlebe, daß ich die technischen Umstände diskutiere, unter denen es sein kann daß ein Kabel den Klang beeinflußt, und dabei ausdrücklich darauf hinweise daß das noch nicht das ist was man berechtigterweise "Kabelklang" nennen kann, und im nächsten Moment versucht man mich als Kronzeugen für Kabelklang zu mißbrauchen, dann lerne ich daraus daß die einfachen Botschaften in solchen Fällen die besseren sind.

Also: Es gibt keinen Kabelklang, basta. Die Details, unter denen es einen Klangunterschied geben kann, und was das Kabel damit zu tun haben könnte, kann man dann und mit denjenigen Leuten diskutieren, die bereit und in der Lage sind, eine technische Argumentation zu verstehen, und die nicht auf der Suche nach Rechtfertigungen für ihren Irrglauben sind.

Der Autor des Artikels müßte dazu erst einmal aus seinem Fanboy-Traum aufwachen, und drei Viertel seiner audiophilen Dogmen aus dem Fenster werfen, vorher ist mit ihm keine vernünftige Diskussion möglich.

Wenn man den Preis dieses Kabels mit Zubehörkabel von z.N. Meßgeräteherstellern erscheint auch der Preis nicht wirklich überzogen.

Die Preise von Kabeln der Meßgerätehersteller sind durchaus ebenfalls gelegentlich überzogen. Da kommt noch dazu daß man vielfach das Monopol hat, weil man spezielle Stecker einsetzt.

Es ist aber dennoch ein fauler Vergleich, denn an Meßgerätekabel werden oftmals wesentlich stärkere Anforderungen gestellt. Zudem hat man bessere Chancen einen Anwender zu finden, der weiß worauf's bei den Kabeln ankommt, und in der Lage ist, seine Kaufentscheidung danach auszurichten. Das kann vom Leser solcher Artikel wie eingangs verlinkt nicht vorausgesetzt werden.

Die andere Form der "Verarsche" (bei ziemlich weitreichender Ahnungslosigkeit)ist, den Leuten zu erzählen, es gäbe gar keine Klangänderungsmöglichkeiten, es sei also eigentlich vollkommen egal, welches Gerät/Konfiguration man nehme. In meinen Augen vielleicht sogar noch schlimmer, denn wer einmal auf diese Form reingefallen ist, der glaubt danach keinem Techniker mehr etwas.

Das mag sein, aber noch häufiger erlebe ich, daß ich einem Anwender nicht erfolgreich klar machen kann daß er mit seinen Verdachtsmomenten auf dem Holzweg ist. Ich will ihm damit gar nicht sagen daß eine Klangänderung ausgeschlossen ist, sondern daß des Anwenders Vorstellung falsch ist, wie es dazu kommt. Oft genug wird das dann in den gleichen Topf geschmissen und kommt so an als hätte ich die Klangänderung für unmöglich erklärt. Wer alle Einwände als Versuch einordnet, Klangänderungen für ausgeschlossen zu erklären, der wird selbstverständlich überall Abstreiter finden.

Das ist ziemlich sicher so, kann aber auch helfen.

Das ist nicht ausgeschlossen.

Aber es ist eben auch nicht nachvollziehbar, und nicht auf andere Situationen übertragbar.

Wobei das doch eher eine Reaktion auf die jahrelange fruchtlose Diskussion ist, denn den vielen Hörern scheint es mE egal zu sein, wie sich guter Klang entwickelt. Ich habe es zumindest bislang noch nicht erlebt, daß jemand eine gutklingende Anlage (unterstellt für den Augenblick, daß die Betreffende es beurteilen konnten) nichts tauge, wenn nicht ausreichend "umstrittenes" eingesetzt wurde.

Ich glaube nicht daß das die Reaktion auf eine fruchtlose Diskussion ist. Ich glaube das ist ein von Teilen der Branche bewußt "gepflegter" Zustand, den man als potenziell lukrativ erkannt hat.

Hinzu kommt, daß aus der "Alles klingt gleich Verarsche" häufig Gerätetipps resultieren, bei denen man mangels verfügbarer technischer Daten überhaupt keine Vorstellung mehr entwickeln kann, ob diese nun bestimmungsgemäß funktionieren. Gutes Beispiel hierfür sind mE allerlei Schnittstellenkonverter.

Das kommt ebenfalls vor, aber auch das halte ich nicht für ein besonders gravierendes Problem. Bei den eher esoterischen Tuning- und Zubehörtipps kann man ebensowenig eine Vorstellung entwickeln, denn da gibt's ebensowenig handfeste Information. Es sei denn es geht um Dinge die prinzipbedingt keine Wirkung haben können, da kann man wenigstens die Vorstellung ihrer Nichtwirksamkeit entwickeln.

Der Tipp, es bei USB-Kabeln mal mit einem Wucherteil zu probieren, um mal näher bei unserem Fall zu bleiben, ist sicher von keinerlei technischen Daten untermauert, aus denen man schließen könnte daß sie "bestimmungsgemäß" funktionieren (oder hast Du z.B. irgendwo Angaben über die Wirkung der von Aqvox vermutlich eingesetzten Ferrithülsen gefunden?)

RobertKuhlmann schrieb:

Ich finde, USB-Kabel für 500€/m erfüllen den Straftatbestand des Wuchers in vollem Umfang (StGB §291).

Bis zu 10 Jahren, wenn man es gewerbsmässig macht. Stehen Hifi-Händler dann nicht alle mit einem Bein im Knast?

Torsten70 schrieb:

...Bis zu 10 Jahren, wenn man es gewerbsmässig macht. Stehen Hifi-Händler dann nicht alle mit einem Bein im Knast?

Ja. Da es sich aber bei Wucher nicht um ein Offizialdelikt, sondern um ein Antragsdelikt handelt, ermittelt die Staatsanwaltschaft nur aufgrund einer Strafanzeige.
Außerdem muss man dem Händler Vorsatz nachweisen. Beim Hersteller ist das meistens einfacher. Da kann man von Vorsatz ausgehen. Der Wucher würde dann allerdings gegenüber dem Zwischenhändler begangen (es sei denn der Hersteller verkauft auch selbst an Endkunden). Bei einem Zwischenhändler ist allerdings die Voraussetzung für Wucher weniger wahrscheinlich gegeben (das Ausnutzen der Unkenntnis des Geschädigten durch den Wucherer) bzw. schwerer nachzuweisen.

Andererseits begeht der Händler gegenüber dem Endkunden nur dann Wucher, wenn er sich des überzogenen Preises einerseits und der Unwissenheit des Kunden andererseits bewusst ist.

Vielleicht kann uns ein Jurist, der hier mitliest, mal seine Ansicht dazu wissen lassen?

Jakob1863 schrieb:

GraphBobby schrieb: Wie kannst du sagen, dass er nicht im Picosekundenbereich liegt? Kann ich nicht, wie sollte ich ohne an der fraglichen Kombination gemessen zu haben? (s.d.a. meine Beiträge anfangs des Threads; ich schrieb nicht umsonst von _sinnvoll_ eingesetzter Messtechnik, um derartige Fragen zu klären)

Wie kommst du dann zu der Behauptung, dass Techniker, welche die Groessenordnung des Jitters bisher fuer jede Geraetekombination korrekt vorhergesagt haben, ausgerechnet bei dieser Kombination geirrt haben sollen, und stattdessen du wahrscheinlich recht hast?

Das ist nichtmal mehr duennes Eis auf dem du dich bewegst, das ist schon der Pazifische Ozean zu Mittag am Aequator bei strahlendem Sonnenschein.

"Zeitrichtigkeit" ist keine Behauptung, sondern die Grundlage der bislang in der Audiotechnik verwendeten zeitdiskreten Signale bzw. der Rückwandlung in analoge Signale.

Ja, und die Geraete zur Audiowiedergabe spielen zeitrichtig, das ist im Design beruecksichtigt und zigtausende Male nachgemessen worden.

Ich habe (s.d.a. die Antwort an ZeeeM) in diesem Thread gepostet, weil viele Teilnehmer argumentierten, an der Geschichte könne nichts dran sein, weil USB ja "paketorientiert sei", "die Daten im Empfänger umsortiert würden", "Computer/Festplatten usw. ja auch funktionieren würden" usw. usw. - kurzum, die ganze Bandbreite falscher Argumente, die in derartigen Threads zu finden ist, wurde aufgeboten.

Die Art der Uebertragung ist bei digitalen Daten irrelevant, wenn die Daten korrekt uebertragen wurden, rechtzeitig zur Verfuegung stehen, und die Wiedergabeeinheit von der Datentransfereinheit ausreichend getrennt ist (was bei allen brauchbaren Geraeten der Fall ist).

Nicht mehr oder weniger wurde behauptet, und das ist leicht ueberpruefbar.

Ob die Hersteller "hochwissenschaftlich arbeiten" oder auch, womit sie sonst argumentieren, ist irrelevant, wenn es um grundsätzlich mögliches oder unmögliches geht.

Nein, wenn ein Hersteller etwas behauptet, was von jedem gebildeten Menschen als unmoeglich betrachtet wird, dann liegt die Beweislast beim Hersteller.
Da der Hersteller den Beweis nicht erbringen kann, gehen wir davon aus, dass der Hersteller luegt, vermutlich aus Profitgier, so wie das bei tausenden anderen Produkten auch ueblich ist. Derartige Luegengeschichten sind auch unter der Bezeichnung "Marketing" bekannt.

Es sollte nur klar sein (deshalb auch häufiger so geschrieben), daß es um einen (möglicherweise vorhandenen) Klangunterschied nach Austausch eines USB-Kabels zwischen den beschriebenen Geräten geht.

Wenn ich jetzt behaupte, dass Software korrekter laeuft, wenn alle Netzwerkkabel gleich lang sind, wuerdest du mich dann als den cleveren Kritiker bezeichnen, der herausgefunden hat, dass es wegen <<<beliebig-absurde-Argumentation-hier-einsetzen,-z.B.-"geraetespezifische-Realisation">>> grundsaetzlich moeglich waere, und dass alle anderen die sturen wissenschaftsglaeubigen Dummkoepfe sind, nur weil sie meinen, ich muesste das beweisen, anstatt dass die mir das Gegenteil beweisen muessten?

Wie argumentierst du denn, dass gleichlange Netzwerkkabel keine Programmierfehler kompensieren koennen, wenn ich argumentiere, dass es vielleicht einen noch nicht bekannten Einfluss gibt, durch den gleichlange Netzwerkkabel magisch wirken?

Ich wuerde natuerlich jedes deiner Gegenargumente ablehnen, und darauf hinweisen, dass es nicht fuer jede geraetespezifische Realisation gelten koennte?

Faellt dir was auf?

Jakob1863 schrieb:

Und illustrierte auf diese Weise eindringlich, daß es trotz gegebener Datenintegrität, funktionierenden USB-Datenübertragung, eben trotzdem noch zu Signaländerungen/Klangänderungen kommen kann.

Jetzt muss ich auch mal was dazu sagen als Techniker. Warnung, leider seeehr lang.

Hier wird von fast allen Diskussionsteilnehmern viel zusammengeworfen und kräftig verrührt. Jeder hat ein bisschen Recht, auch jakob1863. Und dennoch gibt es keinen "Klang" eines USB-Kabels. Wie kommts?

Wer sich den Link den jakob1863 gepostet hat aus der EEtimes ansieht, der kann das eigentlich recht schnell rauslesen. Entscheidend für das Verständis sind die kleinen Comics in dem Artikel. Die sind der Knackpunkt.

Im Ergebnis:
a) Eine unperfekte Übertragung von Audio über USB ist trotz bitidentischer Übertragung möglich.
b) Dies hat jedoch null komma gar nichts mit dem Kabel zu tun
c) Der isochrone USB-Modus ist Müll
d) Hersteller wie der Arbeitgeber des Artikelschreibers werkeln nur um den Müll herum statt das Problem zu lösen
e) Sowohl der USB-Standard als auch das Gerät des Artikelschreibers sind fehlerhaft.

Der Reihe nach aufgedröselt:
a) Die Comics zeichnen das nach, was in einer Zwischenüberschrift steht: "USB is clockless". Das ist des Pudels Kern.

Was heißt das? Anders als synchrone Datenübertragungen (nicht RS232C und nicht LAN, eher sowas wie die PS/2-Schnittstelle für Maus und Tastatur) gibt es keinerlei (!) Taktsignal im Signal. Weder direkt noch indirekt. Daten kommen wann immer sie wollen, in einem sehr breiten Fenster.

Ab jetzt wird es wichtig zwei Sachen getrennt von einander zu betrachten, denn sie sind getrennt: Das, was auf der Leitung abgeht - die physikalische Verbindung, und das was Sender und Empfänger der Daten glauben zu sehen - die logische Vorbindung. So wie auf einer ISDN-Leitung gleich drei Datenströme laufen können und jeder Telefonteilnehmer trotzdem glaubt es gäbe nur eine Leitung und er hätte diese allein, so ist es auch bei USB. Nur mit viel mehr logischen Verbindungen.

Es gibt weder im physikalischen noch im logischen ein echtes Taktsignal. So. Und nun haben wir den isochronen Modus. Isochron heißt: Der Sender schickt seine Daten mit der gleichen Geschwindigkeit, mit der sie der Empfänger empfängt und wiedergibt.

Theoretisch. Denn praktisch gibt es keine zwei Quarze wirklich gleicher Frequenz. Die sind immer etwas unterschiedlich. Laut USB-Spec dürfen sie 500 ppm differieren, also 0,05 Prozent. Das heißt aber, dass der Empfänger in dem Zeitraum, in dem der Sender 2000 Datensätze schickt, 1999 oder 2001 lesen darf.

Es gibt keinen Rückkanal, d.h. nichts und niemand verrät dem Sender dass sein 2000stes Paket zuviel ist. Er sendet weiter. Umgekehrt fehlt vielleicht jedes 2000. Paket - dann knackst es.

Aus diesem Dilemma gibt es keinerlei Ausweg. Daher c) der isochrone Modus ist Müll.

Die einzige Möglichkeit, wie man dieses Problem, entweder ein kleines bisschen zuviel oder ein kleines bisschen zuwenig Daten zu haben lösen könnte wäre, wenn Sender und Empfänger ihre Geschwindigkeiten an einander anpassen würden. Das aber ist nicht vorgesehen - USB is clockless.

All das hat null komma garnichts mit dem Kabel zu tun.

Jetzt machen aber Hersteller wie der des Artikelverfassers, der einen USB-Lautsprecher designen wollte, aber eine in meinen Augen fatale Entscheidung: Statt offen zu sagen "isochron taugt nichts" und einfach einen anderen Modus zu nehmen mit Rückkanal und variabler Datenrate (so dass man auch größere Blöcke erneut versenden kann, oder Puffer per Burst ratzfatz füllen kann) versuchen sie den isochronen Modus zu "vergewaltigen".

Sie versuchen, dem USB einen Takt abzutrotzen. Da dies in der Spec nicht vorgesehen ist, halte ich dies für einen Missbrauch des USB.

Der Artikelverfasser will einen PLL bauen, einen Phase Locked Loop, zu deutsch: einen phasenstarren Oszillator. Dabei koppelt sich ein Oszillator an einen von außen kommenden Takt, wie eine Schwungscheibe, die eine mittlere Drehfrequenz aufbaut, auch wenn sie mal mit der einen oder der anderen Frequenz angeregt wird.

Aber USB is clockless. Die ziehen also irgendein Ereignis des Datenbusses heran. Das kann in 99,x Prozent aller Fälle auch funktionieren. Es sei denn, der USB ist noch mit anderem beschäftigt. Der isochrone Modus ist für Entwickler verführerisch, weil er dem logischen Kanal eine feste Datenrate garantiert. In allen anderen Modi konkurrieren alle Übertragungen. Wenn nun irgendwas das wasauchimmer als "Takt" missbraucht wird ein bisschen beeinflusst, ändert sich die Frequenz des PLL, und damit die Taktung des DAC. Jitter entsteht. Trotz Bitidentität.

Nur kann kein Kabel der Welt (wenn es standardkonform ist) so etwas verursachen. Wohl aber alles andere, was auf dem USB so los ist an konkurrierendem Datentraffic.

Puffer helfen nur begrenzt - kommen zuwenig Daten, laufen sie leer. Kommen zuviele, laufen sie über. Um die Übertragung einer CD zu diesem USB-Lautsprecher störungsfrei isochron garantieren zu können, bedarf es 70 Minuten / 2000 = 2,1 Sekunden Puffer. Mal zwei wegen Über- und Unterlauf. Die 2,1 Sekunden müssen am Anfang zwangsweise (!) gefüllt sein, also halbe Puffergröße. So ein USB-Lautsprecher würde also erst 2,1 Sekunden nach Beginn der Wiedergabe tönen, und immer 2,1 Sekunden zeitversetzt. Kaum brauchbar.

Und: Für größere Datenmengen, beim Streaming soll der Lautsprecher vielleicht stunden- oder tagelang tönen, braucht man noch viel mehr Puffer. Klappt nicht.

Also muss man entweder eine Frequenzangleichung einführen oder mit Knacksern ab und zu einfach leben. Frequenzangleichungen bedeuten aber ebenfalls wieder: Jitter trotz Bitidentität. Aber um die Kirche im Dorf zu lassen: wir reden hier von quasi einer Gleichlaufschwankung von 0,5 Promille schlimmstenfalls. Absolutes Gehör reicht nicht um das zu hören.

Eine Alternative zu großen Puffern oder Angleichung könnte Interpolation sein, also softwaretechnische Anpassung auf der Senke der Daten. Das bringt dann natürlich erst Recht eine Verfälschung (statt Knacksen oder Jitter) ins Spiel.

Mit einem PLL einen "Takt" aus dem Nichts zu zaubern ist störungsanfällig. Alles mögliche könnte das aus dem Tritt bringen. Interpolation ist noch schlimmer.

Ideal wäre es, wenn der Empfänger dem Sender sagen würde, wie schnell er zu sein hat (kann isochron aber nicht). Problemlos bei Wiedergabe einer Datei auf dem Sender möglich (wobei dies übrigens eine minimal andere Tonhöhe der Musik zur Folge hat, nur so nebenbei. Aber viel zu wenig als dass das irgend jemand hören könnte). Auch die Aufnahme einer analogen Quelle wie einer Schallplatte könnte man "fernsteuern".

Nicht jedoch eine ferne Einheitsquelle, wie ein Stream aus dem Internet. Jede solche Regelung geht nur mit 1 Sender und 1 Empfänger. Eine Punkt-zu-Multipunkt-Übertragung wie ein Internetstream kann niemals mit variabler Geschwindigkeit arbeiten. Hier nimmt man schlicht und einfach ab und zu Störungen in Kauf! Dito bei DVB. Sollten Sender und Empfänger jemals nennenswert auseinander laufen (unwahrscheinlich) - na dann gibt's halt ne Bildstörung.

Also Fazit nach einem ewig langen Post: Hier hat ein Entwickler statt das Problem an der Wurzel anzugehen, ein real existierendes USB-Spezifikationsproblem nur umgangen. Alle Abweichungen die er misst resultieren aus seiner Umgehungslösung.

hurgaman schrieb:

...Also Fazit nach einem ewig langen Post: Hier hat ein Entwickler statt das Problem an der Wurzel anzugehen, ein real existierendes USB-Spezifikationsproblem nur umgangen. Alle Abweichungen die er misst resultieren aus seiner Umgehungslösung.

Da hast Du dir aber wirklich viel Mühe gegeben. Und dein Fazit teile ich zu 100% (siehe auch #162).
Ich habe mir allerdings etwas weniger Arbeit gemacht.

Die grundlegende Frage ist doch, was sich jemand von einer Anbindung eines Lautsprechers per USB verspricht? Man betreibt doch solchen Entwicklungsaufwand (nicht einmal im Gedanken), ohne die Lösung für ein reales Problem im Auge zu haben - hoffe ich jedenfalls zugunsten des "Erfinders".

Und, ja, Du hast völlig recht: Das alles hat mit dem USB-Kabel und seinen Eigenschaften nicht einmal im Ansatz irgendetwas zu tun.

hurgaman schrieb:

Also Fazit nach einem ewig langen Post...

...ist, dass ich dir gratulieren möchte dafür, dass du die systemischen Unzulänglichkeiten der isochronen Datenübertragung per USB-Bus so ausführlich beschrieben hast.
Diese ist nun mal nicht determistisch (worauf Jakob gerne herumreitet), sondern auf Geschwindigkeit und Fehlertoleranz hin ausgelegt.
Funktionieren tut das Ganze dank mittlerweile ausgereifter Technik aber trotzdem hinreichend störungsfrei.

Und die Kabelage - um wieder aufs Thema zurückzukommen - hat, sofern die Spezifikationen eingehalten werden, mit der Übertragungsqualität nach wie vor gar nichts zu tun.

bapp

hurgaman schrieb:

Hier wird von fast allen Diskussionsteilnehmern viel zusammengeworfen und kräftig verrührt. Jeder hat ein bisschen Recht, auch jakob1863. Und dennoch gibt es keinen "Klang" eines USB-Kabels. Wie kommts?

Auch wenn ich mit Dir einer Meinung bin, was den Klang eines USB-Kabels angeht, so finde ich doch daß Du selber größere Fehler machst, als Du Anderen vorwirfst.

Im Einzelnen:

a) Eine unperfekte Übertragung von Audio über USB ist trotz bitidentischer Übertragung möglich. Die Comics zeichnen das nach, was in einer Zwischenüberschrift steht: "USB is clockless". Das ist des Pudels Kern. Was heißt das? Anders als synchrone Datenübertragungen (nicht RS232C und nicht LAN, eher sowas wie die PS/2-Schnittstelle für Maus und Tastatur) gibt es keinerlei (!) Taktsignal im Signal. Weder direkt noch indirekt. Daten kommen wann immer sie wollen, in einem sehr breiten Fenster.

Das ist zumindest irreführend, wenn nicht sogar falsch.

Die Taktinformation, die es erlaubt die Bits im seriellen Datenstrom zu erkennen und zu empfangen, ist durch eine geeignete Modulation mit im Signal enthalten. Sie muß daraus allerdings im Empfänger extrahiert werden. Was Du wohl meinst ist, daß es kein getrenntes Taktsignal auf einer eigenen Leitung gibt. Man kann also vielleicht sagen, daß es kein direktes Taktsignal gibt, aber indirekt im Datensignal eingebettet gibt es das sehr wohl, und das ist auch nötig, um das Signal korrekt empfangbar zu machen.

Dieser Bittakt ist allerdings für das Erzeugen eines Audio-Wordclocks nicht direkt brauchbar, denn der Bittakt ist nicht kontinuierlich vorhanden, sondern nur während der Übertragung eines Datenpaketes. Für unsere Diskussion hier kann man den Bittakt daher vernachlässigen.

Die USB-Kopfstation (der Host, also normalerweise der PC) sendet aber in regelmäßigen Abständen sogenannte Start-Of-Frame-Pakete (SOF), die im Grunde ebenfalls als eine Art Takt aufgefaßt werden können. Bei Full-Speed-USB (12 MBit/s) kommt so ein Paket einmal jede Millisekunde, bei High-Speed-USB (480 MBit/s) passiert das einmal alle 125 Mikrosekunden. Letztlich entspricht das einem Takt von 1 kHz oder 8 kHz. Diesen kontinuierlichen Takt gibt der Host vor, und die angeschlossenen Geräte können sich darauf synchronisieren.

Ein USB-Audiogerät kann diese SOF-Pakete dazu verwenden, mit Hilfe einer PLL einen Wordclock zu erzeugen. Das wäre dann der sog. "Synchronous Mode", eine von drei Alternativen woher ein Audiogerät seine Wordclock-Referenz beziehen kann.

Da das SOF-Paket mit einer gewissen zeitlichen Unsicherheit bei einem Gerät ankommt, was sich letztlich als Jitter im Ankunftszeitpunkt der Pakete äußert, muß man durch eine passende Auslegung der PLL für eine ausreichende Jitterunterdrückung sorgen. Das ist aber nicht so exorbitant schwierig wie man aus Deinem Text glauben könnte.

Siehe dazu auch meinen diesbezüglichen Blog-Artikel.

Auch Deine Beschreibung der isochronen Datenübertragung stimmt nicht, denn sie berücksichtigt die drei verschiedenen Synchronisationsmodi nicht, was aber für die Diskussion wesentlich wäre:

Aus diesem Dilemma gibt es keinerlei Ausweg. Daher c) der isochrone Modus ist Müll. Die einzige Möglichkeit, wie man dieses Problem, entweder ein kleines bisschen zuviel oder ein kleines bisschen zuwenig Daten zu haben lösen könnte wäre, wenn Sender und Empfänger ihre Geschwindigkeiten an einander anpassen würden. Das aber ist nicht vorgesehen - USB is clockless.

Ganz im Gegenteil: USB bietet für die Anpassung der Geschwindigkeiten gleich drei verschiedene Modi, die alle bei Audio möglich sind und auf unterschiedliche Weise dafür sorgen daß der Empfänger die Daten mit der gleichen Geschwiundigkeit verarbeitet wie der Sender sie sendet. Damit passiert eben das nicht was Du behauptest, nämlich daß Pakete zu viel oder zu wenig sind, und es deswegen knackst.

Der eben beschriebene synchrone Modus benutzt die SOF-Pakete, um daran das Senden und den Empfang der Audiodaten zu koppeln. Damit gibt letztlich der Host den Takt vor, weil er die SOF-Pakete verschickt. Das Gerät muß seinen Takt daran anpassen. Das funktioniert in gleicher Weise für Audio-Wiedergabe wie für Audio-Aufnahme.

Es gibt auch einen adaptiven Modus, bei dem es keinen Zusammenhang gibt zwischen SOF-Paketen und Audio-Paketen, wo das Audiogerät sich letztlich anpassen muß an die ankommenden Audio-Pakete. Kommen die etwas schneller als erwartet, muß es seinen eigenen Takt etwas erhöhen, kommen sie langsamer muß es ihn senken, so daß es im Mittel paßt.

Beim asynchronen Modus schließlich gibt das Audiogerät den Takt vor und muß ihn dem Host in einem Rückkanal mitteilen. Da gibt's also einen expliziten Rückkanal, auch wieder entgegen Deiner Behauptung.

Jetzt machen aber Hersteller wie der des Artikelverfassers, der einen USB-Lautsprecher designen wollte, aber eine in meinen Augen fatale Entscheidung: Statt offen zu sagen "isochron taugt nichts" und einfach einen anderen Modus zu nehmen mit Rückkanal und variabler Datenrate (so dass man auch größere Blöcke erneut versenden kann, oder Puffer per Burst ratzfatz füllen kann) versuchen sie den isochronen Modus zu "vergewaltigen".

Das ist völlig falsch. Der Auftrag an den Entwickler war offenbar, einen USB-Audio-Chip zu designen, der mit den Betriebssystem-eigenen Treibern zur damaligen Zeit zusammenarbeitet, und dabei bestmögliche Audioqualität bietet. Da alte Windows-Versionen auf den adaptiven Modus gesetzt haben, weil das für den PC am einfachsten war, kam der Chipdesigner nicht darum herum diesen zu unterstützen, obwohl er für die Taktrekonstruktion die schlechtesten Voraussetzungen bot.

Die Notwendigkeit, diesen Modus zu unterstützen, hat letztlich die Schwierigkeiten bei der Entwicklung der PLL verursacht, und den Anlaß für den Artikel gegeben. Die Alternative wäre gewesen, auf einen anderen Modus zu setzen, z.B. auf den für Audio günstigsten asynchronen Modus. Dann hätte er für die Takterzeugung leichtes Spiel gehabt, aber er hätte eigene Treiber für mehrere Betriebssysteme schreiben müssen, sonst hätte den Chip niemand benutzen können. Ich bezweifle daß das für seinen Arbeitgeber eine akzeptable Alternative gewesen wäre.

An dieser Entscheidung ist daher nichts fatal, sondern sie ist im Gegenteil durchaus folgerichtig, und der Mann hat aus der sich bietenden Lage das Beste zu machen versucht.

Sie versuchen, dem USB einen Takt abzutrotzen. Da dies in der Spec nicht vorgesehen ist, halte ich dies für einen Missbrauch des USB.

Wie schon geschrieben: Es ist vorgesehen, sogar in mehreren Varianten. Der Rest Deines Beitrags geht damit von falschen Voraussetzungen aus und braucht keine Widerlegung im Einzelnen.

Vielleicht ergänzen sollte man noch, daß der isochrone Modus deshalb der einzig geeignete ist (im allgemeinen Fall), da nur in diesem für den Audiostream eine ausreichende Bandbreite reserviert wird.

Man könnte sich zwar unabhängig davon machen, auf einen anderen Modus ausweichen, aber wäre immer davon abhängig, für die vorzuhaltende Buffergröße den schlimmstmöglichen Fall anzunehmen, was im Betrieb zu nichtpraktikablen Zuständen führen kann.

Ansonsten schön zu sehen, daß wir inzwischen doch weitestgehend einig darin sind, daß die Datenintegrität im vorliegenden USB-Betriebsfall noch kein hinreichendes Kriterium darstellt. (jottklas auf eigenen Wunsch von dieser Erkenntnisgruppe ausgenommen )

Gruß

Damit ist dann aber auch sicher, dass das Kabel keinen Einfluss auf den Klang hat...

Jakob1863 schrieb:

Ansonsten schön zu sehen, daß wir inzwischen doch weitestgehend einig darin sind, daß die Datenintegrität im vorliegenden USB-Betriebsfall noch kein hinreichendes Kriterium darstellt. (jottklas auf eigenen Wunsch von dieser Erkenntnisgruppe ausgenommen )

Ist das Chuzpe, wenn gerade du von "Erkenntnis" redest...?

Wirsind uns einig, dass alle deine Beispiele und Verlinkungen rein gar nichts mit USB-Kabeln zun tun haben, und dass deine ständig heraufbeschworenen denkbaren Unterschiede sich nur in Störgeräuschen oder Aussetzern bemerkbar machen können, niemals aber ein subtil geändertes Klangbild (highendisch strafferer Bass, feinere Auflösung, tiefere Bühne etc.)verursachen können!

Aber von dieser Erkenntnis nehme ich dich auch ohne eigenen Wunsch aus...

Gruß
Jürgen

Zusätzlich generierter Jitter auf einem 1-2m langen USB Kabel, das ganze dann noch messtechnisch erfassen, bei den Kindergarten-Datenraten von USB 2.0? Ja ist klar, wenn man sich noch nie im Leben mit Jitter befasst hat kann man noch träumen das man da was sinnvolles messtechnisch ermitteln kann und das es dann noch einen merkbaren Einfluss auf Klang hat. Voodoo kennt nun wirklich keine Grenzen.
Ich würde mir um andere Sachen in meiner Audio Kette Gedanken machen, aber eben, jeder nach seinen fachlichen Möglichkeiten.

pelmazo schrieb:

Die Taktinformation, die es erlaubt die Bits im seriellen Datenstrom zu erkennen und zu empfangen, ist durch eine geeignete Modulation mit im Signal enthalten. Sie muß daraus allerdings im Empfänger extrahiert werden.

Vorsicht, Vorsicht. Das ist an sich richtig. Hilft aber nicht. Denn dieser signalintegrierte Takt gilt nur für die aktuelle Übertragung. Es ist kein Generaltakt, d.h. zwischen dem Takt in Übertragung #1 und #2 kann es Phasendifferenzen geben. Somit ist dieser Takt zur Generierung eines stundenlang quasi fehlerfrei laufenden Taktes für einen DAC unbrauchbar.

Was Du wohl meinst ist, daß es kein getrenntes Taktsignal auf einer eigenen Leitung gibt.

Auch das. Ich weiß nur nicht warum "wohl" schreibst. Ich habe das explizit erwähnt.

Dieser Bittakt ist allerdings für das Erzeugen eines Audio-Wordclocks nicht direkt brauchbar, denn der Bittakt ist nicht kontinuierlich vorhanden, sondern nur während der Übertragung eines Datenpaketes. Für unsere Diskussion hier kann man den Bittakt daher vernachlässigen.

Super. Dann sind wir ja einer Meinung. Da ist kein Takt, den wir brauchen können. Es ist eine asynchrone Übertragung.

Die USB-Kopfstation (der Host, also normalerweise der PC) sendet aber in regelmäßigen Abständen sogenannte Start-Of-Frame-Pakete (SOF), die im Grunde ebenfalls als eine Art Takt aufgefaßt werden können. Bei Full-Speed-USB (12 MBit/s) kommt so ein Paket einmal jede Millisekunde, bei High-Speed-USB (480 MBit/s) passiert das einmal alle 125 Mikrosekunden. Letztlich entspricht das einem Takt von 1 kHz oder 8 kHz. Diesen kontinuierlichen Takt gibt der Host vor, und die angeschlossenen Geräte können sich darauf synchronisieren.

Das als Takt aufzufassen nenne ich mal gewagt. Zumal seine "Präzision" ja wohl zu wünschen übrig läßt. Und: Was willst Du mit 1 oder 8 kHz? Wir brauchen etwas in der Größenordnung von 44,1 kHz... Gut, das kriegen wir mit dem PLL auch noch hin. Aber die Genauigkeit...

Da das SOF-Paket mit einer gewissen zeitlichen Unsicherheit bei einem Gerät ankommt, was sich letztlich als Jitter im Ankunftszeitpunkt der Pakete äußert,

Und offenbar sind wir schon wieder einer Meinung... Wo sind denn nun meine Fehler?

muß man durch eine passende Auslegung der PLL für eine ausreichende Jitterunterdrückung sorgen. Das ist aber nicht so exorbitant schwierig wie man aus Deinem Text glauben könnte.

Jitterunterdrückung? Bei einem PLL? Wie soll das gehen? Merkmal eines PLL ist doch, dass er auf Änderungen des Anregungstaktes reagiert. Sonst bräuchte man ihn ja gar nicht, dann könnte man gleiche eine normale präzise Taktquelle nehmen.

Entweder der Takt ist starr, dann jittert er nicht. Oder er ist flexibel, dann wird er jittern, wenn seine Quelle schwankt. Die Frage ist nur wie stark (und ob es irgend jemand hören kann - was ich bezweifle).

Ganz im Gegenteil: USB bietet für die Anpassung der Geschwindigkeiten gleich drei verschiedene Modi,

Wir reden hier vom isosynchronen Modus.

Der eben beschriebene synchrone Modus benutzt die SOF-Pakete, um daran das Senden und den Empfang der Audiodaten zu koppeln. Damit gibt letztlich der Host den Takt vor, weil er die SOF-Pakete verschickt. Das Gerät muß seinen Takt daran anpassen. Das funktioniert in gleicher Weise für Audio-Wiedergabe wie für Audio-Aufnahme.

Wenn das Senden daran gekoppelt wird kommt das nächste Problem. Eine Quelle wie ein Internet-Stream kann nicht in der Geschwindigkeit variiert werden... Es wird dann zwangsweise irgendwann zu Buffer Overrrun oder Underrun kommen.

Es gibt auch einen adaptiven Modus, bei dem es keinen Zusammenhang gibt zwischen SOF-Paketen und Audio-Paketen, wo das Audiogerät sich letztlich anpassen muß an die ankommenden Audio-Pakete. Kommen die etwas schneller als erwartet, muß es seinen eigenen Takt etwas erhöhen, kommen sie langsamer muß es ihn senken, so daß es im Mittel paßt.

Womit wir wieder beim Jittern wären.

Beim asynchronen Modus schließlich gibt das Audiogerät den Takt vor und muß ihn dem Host in einem Rückkanal mitteilen. Da gibt's also einen expliziten Rückkanal, auch wieder entgegen Deiner Behauptung.

Ein isosynchroner Modus mit einem asynchronen Modus? Hast Du dafür eine Quelle? Wie isosynchron ist denn so ein asynchroner Modus? Das widerspricht der Defintion von isosynchron.

http://www.beyondlog...#EndpointDescriptors

Siehe bmAttributes

ZeeeM schrieb:

http://www.beyondlog...#EndpointDescriptors Siehe bmAttributes

Das ist interessant. In der Spec der USB finde ich davon nichts:
USB 2.0 Spec

Oder ist das ein später eingeführter Change? Wenn man den Artikel des BB-Entwicklers durchliest, dann gab es da zur Zeit seiner Entwicklung auch nichts.

Wenn eine direkte Synchronisation möglich ist, dann ist das prinzipielle Problem ja durchaus noch gelöst worden.

Dann allerdings ist es Essig mit dem Jitter! Was den ganzen Artikel des BB-Entwicklers obsolet macht (vermutlich ist's aber nur veraltet). Was jakob nicht freuen wird

hurgaman schrieb:

Das ist interessant. In der Spec der USB finde ich davon nichts: USB 2.0 Spec

Doch findest du in der besagten spec auf Seite 72:

"The following information is required in order to determine how to connect isochronous endpoints:
• Synchronization type:
− Asynchronous: Unsynchronized, although sinks provide data rate feedback
− Synchronous: Synchronized to the USB’s SOF
− Adaptive: Synchronized using feedback or feedforward data rate information
"

Oder ist das ein später eingeführter Change? Wenn man den Artikel des BB-Entwicklers durchliest, dann gab es da zur Zeit seiner Entwicklung auch nichts. Wenn eine direkte Synchronisation möglich ist, dann ist das prinzipielle Problem ja durchaus noch gelöst worden.

Es ist keine direkte Synchronisation; Pelmazo hatte den Punkt schon angesprochen, es ging vermutlich um die Vermeidung spezieller Treibersoftware.

Dann allerdings ist es Essig mit dem Jitter! Was den ganzen Artikel des BB-Entwicklers obsolet macht (vermutlich ist's aber nur veraltet). Was jakob nicht freuen wird 8)

Jakob ging es an der Stelle um das falsche Argument der hinreichenden Datenrichtigkeit.
Das die im Eingangsbeitrag verlinkten Erkenntnisse des Leser insbesondere bei dem dort verwendeten DAC überraschen hatte Jakob ebenfalls einige Male erwähnt.


Gruß

hurgaman schrieb:

Dann allerdings ist es Essig mit dem Jitter! Was den ganzen Artikel des BB-Entwicklers obsolet macht (vermutlich ist's aber nur veraltet). Was jakob nicht freuen wird 8)

Das trifft aber nur für async Endpoints zu. Die gibt es entweder mit propritären Treiber, oder nur bestimmten DIRs, die wohk auch das nicht zwingend von der Stange machen.

Jakob1863 schrieb:

Doch findest du in der besagten spec auf Seite 72: "The following information is required in order to determine how to connect isochronous endpoints: • Synchronization type: − Asynchronous: Unsynchronized, although sinks provide data rate feedback − Synchronous: Synchronized to the USB’s SOF − Adaptive: Synchronized using feedback or feedforward data rate information "

Ah. Danke. Ich lese die Spec nicht täglich

Bleibt aber die Frage, wieso der BB-Entwickler keinen Gebrauch machte? Oder galt seine Entwicklungen nur Hosts, die einfach keinerlei Sync akzeptieren wollen?

Es ist keine direkte Synchronisation; Pelmazo hatte den Punkt schon angesprochen, es ging vermutlich um die Vermeidung spezieller Treibersoftware.

Na ja. Das ist natürlich auch ein denkbares Entwicklungsziel, klar. Nur so kann man jeden "dahergelaufenen" Host als Quelle verwenden. Aber dann kann man halt nicht seine Puffer vorab schnell "zuknallen", dazu bräuchte man halt kurzfristig mehr Datenrate. Auch eine Fehlerkorrektur ist so halt unmögich. Das ist im Standard halt nicht vorgesehen. Dumm, wenn "elektrischer Dreck", also EMI, auch noch daher kommt.

hurgaman schrieb:

Vorsicht, Vorsicht. Das ist an sich richtig. Hilft aber nicht.

Was ich ja explizit schreibe.

Ich weiß nur nicht warum "wohl" schreibst. Ich habe das explizit erwähnt.

Weil Du von einem Takt "im Signal" geschrieben hast, und nicht klar war ob Du damit eine eigene Leitung meinst oder nicht. So explizit, daß es eindeutig gewesen wäre, war es nicht. Deshalb meine Korrektur.

Da ist kein Takt, den wir brauchen können. Es ist eine asynchrone Übertragung.

Es gibt keinen Takt, den man direkt brauchen könnte. Es gibt aber je nachdem welcher Modus gewählt ist, Referenzen aus denen so ein Takt abgeleitet werden kann. Auch so kann man synchron sein.

Die Übertragung eines Wordclock-Signals wäre auch kein prinzipiell anderer Fall, denn auch hier ist eine PLL nötig, um daraus ein für den Empfang nötiges Frequenzvielfaches zu erzeugen. So etwas macht die Situation nicht asynchron.

Das als Takt aufzufassen nenne ich mal gewagt. Zumal seine "Präzision" ja wohl zu wünschen übrig läßt. Und: Was willst Du mit 1 oder 8 kHz? Wir brauchen etwas in der Größenordnung von 44,1 kHz... Gut, das kriegen wir mit dem PLL auch noch hin. Aber die Genauigkeit...

Ob die Genauigkeit reicht oder nicht ist ein anderes Problem. Um ein Audiosignal auf einen Lautsprecher oder Kopfhörer auszugeben ist die Frequenzgenauigkeit des SOF-Signals nach USB-Norm ausreichend. Professionellen Ansprüchen würde es aber nicht genügen.

Wo sind denn nun meine Fehler?

Wenn Du die Augen nicht zudrückst, dann siehst Du sie deutlich.

Jitterunterdrückung? Bei einem PLL? Wie soll das gehen? Merkmal eines PLL ist doch, dass er auf Änderungen des Anregungstaktes reagiert. Sonst bräuchte man ihn ja gar nicht, dann könnte man gleiche eine normale präzise Taktquelle nehmen.

PLLs werden seit Jahr und Tag für die Jitterunterdrückung benutzt. Auch in der PLL über die der Entwickler von TI schreibt findet das statt. Du solltest Dich ein bißchen über PLL-Technik informieren. Entscheidend ist, wo man die Eckfrequenz des Schleifenfilters hinlegt.

Wir reden hier vom isosynchronen Modus.

Und ich rede vom Synchronisations-Modus innerhalb des isochronen Transfermodus. Alle drei von mir beschriebenen Synchronisations-Modi benutzen den isochronen Transfer-Modus. Du scheinst noch nicht kapiert zu haben, daß der Transfer-Modus und der Synchronisations-Modus zwei voneinander getrennte Dinge sind.

Wenn das Senden daran gekoppelt wird kommt das nächste Problem. Eine Quelle wie ein Internet-Stream kann nicht in der Geschwindigkeit variiert werden... Es wird dann zwangsweise irgendwann zu Buffer Overrrun oder Underrun kommen.

Internet-Streams sind eine völlig andere Baustelle, die auch bei anderen Soundkarten, die nicht auf USB basieren, in gleicher Weise auftreten wird. Mit dem Thema USB als solches hat das nicht viel zu tun.

Womit wir wieder beim Jittern wären.

Richtig, und als zusätzliche Anforderung an die PLL kommt hier, im Vergleich zum synchronen Modus, der größere Jitter der Pakete, der stärker gefiltert werden muß, und das Problem daß man erst mit der Synchronisation anfangen kann, wenn schon Audio läuft. Für das Gerät ist deswegen der adaptive Modus der schwierigste Modus, und genau darum dreht sich der Artikel des Entwicklers von Texas Instruments.

Ein isosynchroner Modus mit einem asynchronen Modus? Hast Du dafür eine Quelle? Wie isosynchron ist denn so ein asynchroner Modus? Das widerspricht der Defintion von isosynchron.

Nein, denn es sind wie schon geschrieben zwei getrennte Dinge. Lies das Dokument "USB Device Class Definition for Audio Devices", egal welche Version, denn da steht das drin beschrieben. Diese Sache gibt's schon seitdem es USB-Audio-Geräte gibt - die erste Version dieses Dokumentes datiert von 1998.

Wenn man den Artikel des BB-Entwicklers durchliest, dann gab es da zur Zeit seiner Entwicklung auch nichts.

Die damaligen Computer Betriebssysteme haben nicht alle Varianten unterstützt, das ist das Problem. Gegeben hat es sie als Definition sehr wohl. Wenn das Schreiben eigener Treiber für Texas Instruments in Frage gekommen wäre, dann hätte der Entwickler auch andere Modi wählen können.

ZeeeM schrieb:

Das trifft aber nur für async Endpoints zu. Die gibt es entweder mit propritären Treiber, oder nur bestimmten DIRs, die wohk auch das nicht zwingend von der Stange machen.

Inzwischen sind auch die Standard-Treiber in den Betriebssystemen besser geworden. Wenn ein solcher Chip für heutige Betriebssystem-Versionen gebaut würde, dann würde die Situation anders aussehen, und würde wohl auch andere Designentscheidungen zur Folge haben. Man sollte sich vergegenwärtigen, daß die Chipentwicklung, von der in dem Artikel berichtet wird, über 10 Jahre her ist. Da war höchstens Windows 2000 aktuell.

pelmazo schrieb:

Ob die Genauigkeit reicht oder nicht ist ein anderes Problem.

Nein, das ist genau das, was hier im Raume steht. Jittert es oder jittert es nicht. Das ist letztlich "nur" eine Präzisionsfrage. Der PLL hilft sich auf die Rate anzupassen, keine Frage. Aber wenn die Abweichung nicht konstant ist, dann wird das halt in irgendeiner Form jittern. Dass die dauerhaft konstante Ausgabe mit sowas möglich wird steht außer Frage. Und natürlich, dass vermutlich niemand diese Feinheiten, die wir hier diskutieren, je hören kann.

Richtig, und als zusätzliche Anforderung an die PLL kommt hier, im Vergleich zum synchronen Modus, der größere Jitter der Pakete, der stärker gefiltert werden muß, und das Problem daß man erst mit der Synchronisation anfangen kann, wenn schon Audio läuft.

Na ja, am Anfang jittert es halt ein bisschen mehr. Am Anfang kann man ja mit der nominalen Rate loslegen, und nach zwei Ereignissen hat man ja auch die echte Rate vorliegen. Ich glaube nicht dass das jemand hört wenn sich das Ding einschwingt... Wir reden hier ja nur von Nuancen, um die beiden Raten auseinanderliegen dürfen. 500 ppm.

Inzwischen sind auch die Standard-Treiber in den Betriebssystemen besser geworden. Wenn ein solcher Chip für heutige Betriebssystem-Versionen gebaut würde, dann würde die Situation anders aussehen, und würde wohl auch andere Designentscheidungen zur Folge haben.

Ich habe hier unter anderem als "kleine Notlösung" für eine Spezialanwendung (nein, keine wirliche HiFi- und schon gar keine Goldohranwendung) einen Aktivlautsprecher an einem M-Audio Sonica, also einem USB-gestützten DAC. Der scheint, obwohl nicht so alt, durchaus ein Problem mit Pufferüber- und Unterlauf zu haben. Alle zehn Minuten oder so knackt er (und ja, er läuft isochron, aber keine Ahnung wie er synct).

hurgaman schrieb:

Nein, das ist genau das, was hier im Raume steht. Jittert es oder jittert es nicht. Das ist letztlich "nur" eine Präzisionsfrage.

Du tust Dir keinen Gefallen, wenn Du Genauigkeit und Jitter in einen Topf wirfst. Das sind verschiedene Dinge, und man kann je nach Fall leicht mal viel Jitter bei großer Genauigkeit haben, oder schlechte Genauigkeit bei gleichzeitig sehr guten Jitterwerten. Den Fehler machen bei Taktgeneratoren viele Leute, wenn sie glauben mit einem genauen Oszillator von z.B. 10 ppm oder besser hätten sie auch zugleich weniger Jitter.

Der PLL hilft sich auf die Rate anzupassen, keine Frage. Aber wenn die Abweichung nicht konstant ist, dann wird das halt in irgendeiner Form jittern. Dass die dauerhaft konstante Ausgabe mit sowas möglich wird steht außer Frage. Und natürlich, dass vermutlich niemand diese Feinheiten, die wir hier diskutieren, je hören kann.

Wie viel Jitter nach der PLL übrig bleibt hängt wesentlich davon ab wie die PLL ausgelegt ist. Letzlich geht es genau um solche Kompromisse und Design-Optimierungen im Artikel des TI-Entwicklers.

Na ja, am Anfang jittert es halt ein bisschen mehr. Am Anfang kann man ja mit der nominalen Rate loslegen, und nach zwei Ereignissen hat man ja auch die echte Rate vorliegen. Ich glaube nicht dass das jemand hört wenn sich das Ding einschwingt... Wir reden hier ja nur von Nuancen, um die beiden Raten auseinanderliegen dürfen. 500 ppm.

Moment, im adaptiven Modus gibt es meiner Kenntnis nach die 500ppm-Restriktion nicht. Die 500 ppm gelten für den synchronen Modus, also für die mittlere SOF-Paket-Frequenz.

Lies den Artikel des Entwicklers.

Ich habe hier unter anderem als "kleine Notlösung" für eine Spezialanwendung (nein, keine wirliche HiFi- und schon gar keine Goldohranwendung) einen Aktivlautsprecher an einem M-Audio Sonica, also einem USB-gestützten DAC. Der scheint, obwohl nicht so alt, durchaus ein Problem mit Pufferüber- und Unterlauf zu haben. Alle zehn Minuten oder so knackt er (und ja, er läuft isochron, aber keine Ahnung wie er synct).

Ich hatte gerade mit den TI-Chips, um die es sich hier dreht, schon Knackprobleme bei 44100 Hz Abtastrate, aber nicht bei 48000 Hz. Ich bin allerdings der Sache nicht auf den Grund gegangen und kann mich auch an die schon Jahre zurückliegenden Details nicht mehr erinnern.

Generell hörst Du Dich schon ganz anders an als zu Anfang, wo noch von fatalen Designentscheidungen und dergleichen die Rede war. Gut so.

pelmazo schrieb:

Generell hörst Du Dich schon ganz anders an als zu Anfang, wo noch von fatalen Designentscheidungen und dergleichen die Rede war. Gut so.

Die Formulierung war wohl überdreht, sorry. Was ich meinte: Mir wäre viel lieber, die hätten einen vernünftigen Modus mit variabler (!) Bitrate spezifiziert, mit einer Minimum-Bandbreitengarantie, Puffersteuerung, Burst, Übertragungswiederholung und einer richtigen Sync-Steuerung.

Das ist sicher nicht die Aufgabe eines einzelnen Entwicklers, aber die Jungs im Konsortium haben sich und uns nach meiner Meinung keinen wirklichen Gefallen getan mit der Art und Weise wie es spezifiziert wurde. Das halte ich für eine Fehlentscheidung.

Der Entwickler hätte möglicherweise doch besser daran getan, mit einem eigenen Gerätetreiber zu arbeiten. Aber wie erwähnt, dann geht's halt nicht mehr mit x-beliebigen Hosts.

Die ganze Modussteuerung bewirkt dann in der Praxis doch immer viel zu oft, dass nur der kleinste gemeinsame Nenner genutzt wird für die Übertragung.

hurgaman schrieb:

Die Formulierung war wohl überdreht, sorry. Was ich meinte: Mir wäre viel lieber, die hätten einen vernünftigen Modus mit variabler (!) Bitrate spezifiziert, mit einer Minimum-Bandbreitengarantie, Puffersteuerung, Burst, Übertragungswiederholung und einer richtigen Sync-Steuerung.

Ich bin der Meinung, der asynchrone Modus hat alles was man bei Audio braucht. Das Audio-Device gibt den Takt vor, und es gibt Signalisierung Richtung PC für die Synchronisation und Puffersteuerung. Die kann man sogar mit einem Audiokanal Richtung PC kombinieren. Bandbreitengarantie bietet der isochrone Modus generell, aber Übertragungswiederholung halte ich für kontraproduktiv, da das zusätzliche Wartezeiten zur Folge hat.

Der einzige Nachteil ist, daß dieser Modus erst zögerlich von den Treibern unterstützt worden ist.

Das ist sicher nicht die Aufgabe eines einzelnen Entwicklers, aber die Jungs im Konsortium haben sich und uns nach meiner Meinung keinen wirklichen Gefallen getan mit der Art und Weise wie es spezifiziert wurde. Das halte ich für eine Fehlentscheidung.

Ich halte das im Gegenteil für eine durchaus zweckmäßige Definition. Nicht alle Audio-Anwendungen brauchen die ganze Funktionaliät. Für ein Telefonier-Headset z.B. spielt der Jitter keine Rolle.

Der Entwickler hätte möglicherweise doch besser daran getan, mit einem eigenen Gerätetreiber zu arbeiten. Aber wie erwähnt, dann geht's halt nicht mehr mit x-beliebigen Hosts.

Ich gehe davon aus daß sein Arbeitgeber einen eigenen Treiber nicht wollte, und der Entwickler daher keine andere Wahl hatte. Ich finde sein Verhalten durchaus in Ordnung. Ich hätte es in seiner Situation nicht viel anders gemacht.

Der Chip, den er gebaut hat, ist auch nicht für den audiophilen Markt gemacht. Es ist ein Chip für den Massenmarkt, daher auch die Beschränkung auf 16 Bit. Anforderungen an ihn zu stellen, die eher für hochqualitatives Audio gelten, wäre nicht fair.

Die ganze Modussteuerung bewirkt dann in der Praxis doch immer viel zu oft, dass nur der kleinste gemeinsame Nenner genutzt wird für die Übertragung.

Wenn man jemandem daraus einen Vorwurf machen wollte, dann müßte das Microsoft sein, denn die haben die USB-Treiber in ihren Betriebssystemen gemacht. Die wollten aber offenbar - wie so oft - zuerst den Gadget-Markt bedienen, wo die Qualität egal ist, Hauptsache es geht. Aber wenn es einen Hersteller mit audiophilem Anspruch gab, der einen besseren Adapter bauen wollte, dann konnte er das mit Hilfe eines eigenen Treibers ja von Anfang an tun. Bloß haben viele den Aufwand gescheut.

pelmazo schrieb:

hurgaman schrieb: Die Formulierung war wohl überdreht, sorry. Was ich meinte: Mir wäre viel lieber, die hätten einen vernünftigen Modus mit variabler (!) Bitrate spezifiziert, mit einer Minimum-Bandbreitengarantie, Puffersteuerung, Burst, Übertragungswiederholung und einer richtigen Sync-Steuerung. Ich bin der Meinung, der asynchrone Modus hat alles was man bei Audio braucht. Das Audio-Device gibt den Takt vor, und es gibt Signalisierung Richtung PC für die Synchronisation und Puffersteuerung. Die kann man sogar mit einem Audiokanal Richtung PC kombinieren. Bandbreitengarantie bietet der isochrone Modus generell, aber Übertragungswiederholung halte ich für kontraproduktiv, da das zusätzliche Wartezeiten zur Folge hat. Der einzige Nachteil ist, daß dieser Modus erst zögerlich von den Treibern unterstützt worden ist.

in allen Facetten d'accord - mittlerweile entwickelt sich der asynch-USB-Modus aber immer mehr zum Standard - zumindest im mittelpreissegment von DACs aufwärts sehe ich das so...

generell bin ich der Meinung, dass diese FAQ hier das Thema umfassend und professionell beantwortet; zumindest ich hab noch keine bessere Zusammenstellung der Fakten gefunden...

FAQ USB-Audio

vielleicht wurde sie auch schon in diesem Thread mal gepostet, ich hab nicht jeden einzelnen Beitrag gelesen (aber doppel gemoppelt schadet nicht ), nur das gefühl beim überfliegen der beiträge, dass oftmals schon einige Dinge gehörig durcheinander gewürfelt werden (bestes beispiel: isochron auf der einen und asynchron/synchron auf der anderen seite etc...)... deswegen mein Tipp: erstmal diese FAQ lesen...