FAQ Streaming

Ich dachte es wäre mal wieder an der Zeit für einen Artikel in meiner FAQ Serie. Diesmal zum Thema "Streaming", welches immer mehr in den Fokus audiophiler Konversation gerückt ist, und damit auch in den Fokus derjenigen Leute, die ihren Bullshit an die Audiophilen verkaufen wollen.

Was ist Streaming eigentlich?

Streaming ist das Übertragen von Audio in "Echtzeit" über ein Computernetzwerk. Oder eigentlich nicht bloß Audio, sondern beliebige Mediendaten, also z.B. auch Video.

Was ist da so speziell dran? Sind Mediendaten nicht auch bloß Daten, für deren Übertragung Computernetzwerke seit jeher benutzt werden?

Ja, schon. Der springende Punkt hier ist aber das Wort "Echtzeit". Die Daten werden nicht so schnell wie möglich übertragen, wie z.B. wenn man über das Netzwerk eine Datei kopiert, sondern "just in time", in dem Maße wie sie zur Wiedergabe gebraucht werden.

Was ist da das Problem?

Kommt darauf an, wie "echt" die Zeit sein soll, also wie viel "Latenz" tolerierbar ist. Die Anforderungen können sehr verschieden sein, wodurch auch die Technologie deutlich unterschiedlich sein kann. Es gibt daher nicht die eine Streamingtechnik, sondern es haben sich im Laufe von etlichen Jahren sehr unterschiedliche Methoden herausgebildet, je nachdem welche Anwendungsfelder damit abgedeckt werden soll.

Die da wären?

Die Anwendungen oder die Techniken?

Ok, zuerst die Anwendungen:

Angefangen hat es mit Internetradio. Das gibt's schon ziemlich lang, unter Verwendung von MP3 hat es weite Verbreitung erlangt und wird auch heute noch betrieben. Die Latenz ist hier ziemlich egal. Mehrere Sekunden sind absolut üblich. Man merkt es daran, daß der Player am Anfang erst einmal eine Weile Daten puffert, bevor er losspielt. Wir kommen noch dazu warum das so ist. Ein weiteres Charakteristikum dieser Methode ist, daß HTTP dafür verwendet wird, also das Web-Browser-Protokoll, welches auf TCP/IP basiert. Das wird deswegen verwendet, weil man damit am leichtesten auf die Web-Infrastruktur zurückgreifen kann, und weil die Router dafür normalerweise freigeschaltet sind. Damit sind aber auch Nachteile verbunden, was den Anlaß gab, andere Methoden zu entwickeln.

Dann kamen die Streaming-Lösungen für die Heimanwendung. Streaming von einem Medienserver im Haus an Streaming-Player. Die Technik dafür ist im Grunde nichts Anderes als Dateizugriffe über Netzwerk. Das verwendete Protokoll ist das Gleiche wie das, was man für den Zugriff auf ein NAS gebraucht (NAS = Network Attached Server). Da mußte nichts wirklich neu entwickelt werden. Der Streaming-Client fordert sich die Daten einfach rechtzeitig vom Server an, bevor er sie ausspielen muss. So lange der Server keinen "Hänger" hat, klappt das problemlos.

Ergänzt werden solche Lösungen durch weitere Protokolle, die nicht direkt mit der Übertragung von Mediendaten zu tun haben, z.B. für das Durchblättern der Mediendatenbanken, oder das Auffinden der Geräte im Netzwerk. Auch da gibt's mehrere Alternativen, z.B. UPnP von Microsoft, oder Bonjour von Apple.

Es ging und geht weiter mit Live-Streaming von größeren Datenmengen wie hochauflösendes, unkomprimiertes Audio, oder von Videos. Neben der höheren Datenmenge, die nicht wirklich neue Technik braucht, bloß größere Kapazitäten im Netzwerk, kommt da vor allem das Thema Kopierschutz, und damit Verschlüsselung und Authentifizierung, dazu.

Für professionelle Anwendungen und im Heimstudio kommt dazu noch das Thema "Low Latency" auf, also eine so geringe Verzögerung bei der Übertragung durch das Netzwerk, daß die Netzwerkverbindungen mit konventioneller Verkabelung konkurrieren können, z.B. bei Anwendungen, bei denen direkt abgehört wird. Die Nagelprobe ist dabei wenn ein Musiker sein eigenes Signal während des Spiel abhört. Da sind nur noch wenige Millisekunden Verzögerung erlaubt.

Bei manchen Anwendungen, insbesondere im Profibereich, ist auch die exakte Synchronisation zwischen den Geräten wichtig. Im Extremfall geht es dabei um wenige Mikrosekunden Toleranz.

Das sieht nach einem breiten Spektrum an Anforderungen aus.

So ist es. Die ersten Techniken für Internetradio erfüllen bei weitem nicht alle Anforderungen. Der Consumer-Markt ist dabei noch der harmloseste. Profi-Streaming ist viel "härter".

Interessanterweise gibt es schon eine ganze Zeit lang eine Streaming-Technik, die niedrige Latenz braucht und bietet, nämlich "Voice-over-IP", also Telefonie über das Internet. Die neueren Streaming-Techniken, die im Profi-Bereich in den letzten Jahren Einzug gehalten haben, sind daher im Kern von der Internet-Telefonie abgeleitet, und verwenden ähnliche Techniken, allerdings mit höherer Qualität und Datenmenge. Hinzugekommen sind auch Synchronisationstechniken, die mit hoher Präzision arbeiten.

Profi-Streaming ist also eine Art von "aufgebohrter Internet-Telefonie"?

 Ja. Jedenfalls die Systeme, die auf IP-Basis arbeiten, z.B. Livewire, Dante, Ravenna, und der daraus entwickelte herstellerübergreifende AES67-Standard.

Die Consumer-Systeme nicht?

Nein, jedenfalls in der Mehrheit nicht. Die Anforderungen sind schlicht nicht da, um den höheren Aufwand zu rechtfertigen. Das ändert sich aber allmählich.

Welche Anforderungen denn?

Zum Beispiel die harte Synchronisation. Die braucht es bloß, wenn mehrere unabhängige Geräte am Netzwerk genau zur gleichen Zeit wiedergeben sollen. Die strengsten Anforderungen gelten für Geräte, die zum gleichen Schallfeld beitragen sollen. Die Richtungswahrnehmung ist sehr empfindlich für Zeitunterschiede zwischen den Kanälen, z.B. bei Stereo. Da geht's um Mikrosekunden.

Wenn beide Kanäle aus dem gleichen Gerät kommen, und aus dem gleichen Stream, dann existiert das Problem nicht, denn es obliegt dem Gerät selbst, beide Stereokanäle zeitgleich abzuspielen. Das ist trivial. Das funktioniert problemlos seit den ersten Tagen des Internetradio.

Der normale Konsument und Betreiber eines Streaming-Netzwerkes zuhause bekommt erst dann Wind von diesem Problem, wenn es um simultane Wiedergabe der gleichen Audiodaten über mehrere Geräte geht. Das ist z.B. dann der Fall, wenn über mehrere Räume hinweg das gleiche Programm gehört werden soll. Im Normalfall ist das nicht wirklich gleichzeitig, wie sicher schon Mancher bemerkt haben wird. Wer auf zwei Geräten das gleiche Internet-Radio wiedergibt, der findet oft mehrere Sekunden Unterschied zwischen den Geräten. Das war früher beim analogen Radio ganz anders, da herrschte Gleichzeitigkeit.

Wie kommt das?

Es ist letztlich eine Folge der Datenpufferung. Die Daten aus dem Netz werden erst in einen Puffer im Gerät geschrieben, und etwas später aus diesem Puffer wiedergegeben. Wenn nicht koordiniert wird, wann die Daten aus dem Puffer ausgespielt werden, und das ist der Normalfall, dann entscheidet sich das in jedem Gerät getrennt, und damit eben auch unterschiedlich. Jedes Gerät puffert am Beginn der Wiedergabe so viele Daten, wie es für richtig hält (manchmal ist das einstellbar), und fängt dann an, auszuspielen.

Selbst wenn der Beginn der Ausspielung genau koordiniert würde, dann wäre das trotzdem noch keine komplette Lösung. Die Geräte spielen alle mit ihrem eigenen Medientakt aus, der von einem Oszillator in jedem Gerät erzeugt wird. Obwohl dieser Medientakt in jedem Gerät nominell gleich ist, gibt es Toleranzen. Diese haben zur Folge, daß auch bei gleichzeitigem Start die Ausspielungen allmählich auseinander laufen. Wenn die Oszillatoren zweier Geräte sich beispielsweise um 100 ppm unterscheiden, und das ist ein durchaus praxisgerechter Fall, dann laufen die Geräte in 10000 Sekunden (also weniger als 3 Stunden) um 1 Sekunde unterschiedlich. Eine Sekunde Unterschied ist schon sehr auffällig, für einen störenden Unterschied reicht schon deutlich weniger. Das bedeutet, daß einem das vielleicht nicht auffällt, wenn man 3-minütige Singles hört, aber definitiv stört es bei einer Sinfonie oder Oper. Oder eben wenn man länger Internetradio hört.

Wieso synchronisiert man nicht einfach? Also sowohl den Start als auch die Oszillatoren?

Weil das nicht so einfach ist. Und wenn man es in den üblichen Fällen gar nicht braucht, dann spart man sich eben den Aufwand. Wer will schon die gleichen Signale über mehrere Geräte zugleich wiedergeben?

Die Profis brauchen so etwas. Da sind viel mehr Geräte beteiligt, und viel mehr Signale, die alle zeitlich koordiniert sein müssen. Oder eben anspruchsvollere Multi-Raum-Installationen in einer Wohnung.

Verstehe ich das richtig? Die Wiedergabe erfolgt mit einem Takt, den jedes Gerät selber freilaufend erzeugt?

Im Normalfall ja. Das Abspielgerät fordert über das Netzwerk die Daten in dem Rhythmus an, der durch den lokalen Medientakt vorgegeben wird. Das ist so beim Streamen aus einem Medienserver, aber auch beim Wiedergeben von Internetradio.

Wieso machen sich dann die Leute wegen Jitter in die Hose?

Frag mich nicht. ;-)

Es gibt dabei jedenfalls genau so viel Jitter wie der lokale Oszillator erzeugt. Das sollte jeder Gerätebauer im Griff haben. Das Netzwerk hat nichts damit zu tun.

Und der sogenannte "Paketjitter"?

Hat auch nichts damit zu tun. Es geht dabei um die zeitliche Unsicherheit bei der Ankunft der Datenpakete, die den Stream ausmachen. Um die auszugleichen benutzt man den Puffer. Die Situation hat große Ähnlichkeit mit der CD. Da gibt es ebenfalls so einen Puffer, und der entkoppelt die Seite mit dem Datenträger von der Seite mit dem Wandler, einschließlich der verwendeten Takte. Jitter auf der einen Seite hat dadurch nichts zu tun mit dem Jitter auf der anderen Seite. Wenn es da gegenseitige Einflüsse gibt, sind sie einem problematischen Gerätedesign geschuldet.

Wie ist das dann beim Internetradio, oder beim Live-Streaming von Fernsehkanälen? Das kann doch nicht funktionieren bei so vielen freilaufenden Oszillatoren!

Stimmt. Wenn ich das Signal auf der einen Seite mit einem freilaufenden Oszillator erzeuge, und auf der anderen Seite mit einem freilaufenden Oszillator wiedergebe, dann läuft irgendwann jeder Puffer entweder leer oder voll, je nachdem welche Seite schneller ist.

Den Effekt hat der Eine oder Andere sicher schon bemerkt wenn er Internetradio über längere Zeit gehört hat: Irgendwann gibt's eine Störung oder einen Aussetzer. Man ist geneigt, das auf die Unzuverlässigkeit des Internet zu schieben, und hat damit oft genug auch recht. Es ist aber eben oft auch die Folge der Taktungleichheit. Irgend ein Puffer läuft voll oder leer, und es bleibt keine andere Wahl als eine Unterbrechung und ein Neustart des Streams. Die Software kann das automatisch, aber eine Unterbrechung bleibt es trotzdem.

Um dem abzuhelfen muß man den Abspieltakt an den Quelltakt angleichen, und zwar durch eine Taktregelung. Im TV-Streaming ist so etwas wichtiger als bei Internetradio, demzufolge hat man eine solche Taktregelung hier vorgesehen. Die kann aber recht träge sein so lange man mit relativ großen Puffern arbeiten kann. Die entsprechende Taktsynchronisation ist so noch recht "lose", was aber gut genug funktioniert.

Wieso macht man das nicht grundsätzlich?

Man treibt den Aufwand bloß wenn's nötig ist, besonders im Consumer-Bereich, wo es beim Gerätepreis um jeden halben Cent geht.

Es kommt noch hinzu daß bei PCs, Tablets, etc. die Taktoszillatoren für die Audiowandler meist nicht regelbar sind. Das war in einer Soundkarte traditionell nicht nötig, und es gibt dafür auch keine standardisierte Programmierschnittstelle. Ein Medienplayer (die Software) hat daher u.U. gar keine andere Wahl als mit dem Takt abzuspielen, der von der Soundkarte vorgegeben wird. Wenn dadurch ein Puffer immer voller oder immer leerer wird, dann verfällt manche Software in Tricks, wie man das möglichst ohne "Aufsehen" überspielen kann. Zum Beispiel kann man auf kurze Perioden der Stille warten, und die etwas verkürzen oder verlängern. Das fällt erfahrungsgemäß kaum auf.

Aber es kommt auch vor, daß sich die Programmierer darüber keinen Kopf machen. Im Ernstfall läßt man dann einen Block Samples weg, oder man fügt einen Block Stille ein, damit der Puffer-Füllstand wieder in den grünen Bereich kommt.

Regelbare Taktoszillatoren kann man softwaremäßig simulieren, wenn es die Hardware nicht hergibt,  indem man adaptive Abtastratenwandlung betreibt. Das kann so gut sein daß man keine akustischen Artefakte mehr feststellen kann. Aber den Aufwand zu treiben wird offenbar nicht von allen Software-Schmieden für nötig gehalten.

Ziemlich hemdsärmelig.

Naja, man macht eben das was man glaubt machen zu müssen, und macht die Kompromisse dort wo man glaubt daß es nicht auffällt. Wozu sollte man mit großem Aufwand ein stringent durchsynchronisiertes System bauen, wenn die allermeisten Anwender den Unterschied gar nicht bemerken würden, weil ihr Anwendungsfall gar keine Synchronisation braucht?

Selbst in Profi-Streaming-Systemen gibt es deutliche Unterschiede in der Qualität der Synchronisation. Auf höherem Niveau zwar, aber dennoch. Immerhin ist es dort ein ausdrückliches Thema, im Gegensatz zum Consumer-Bereich, wo man den Kunden mit so etwas nicht zu belasten wagt, weil man ihm nicht zutraut daß er das versteht.

Wie geht denn so ein Streamingsystem mit Übertragungsfehlern um?

Ha, ein weites und komplexes Thema! Wie genau willst Du's wissen, und wieviel Zeit hast Du?

Zeit hab ich keine und wissen will ich alles immer sofort. Und so einfach daß ich's verstehe bitte!

Nichts leichter als das, komm mit. ;-)

Die ersten Streamingsysteme, also Internetradio mit MP3 über HTTP, sind recht tolerant für Übertragungsfehler, und müssen das auch sein weil das Internet relativ oft Datenpakete verliert. Diese Toleranz kommt daher, daß unterhalb von HTTP das TCP-Protokoll benutzt wird Genauer gesagt sieht der "Protokollstapel" so aus: HTTP über TCP, und TCP über IP. IP hat unter sich die gerade verwendete Übertragungstechnik, also z.B. WLAN wenn's über Funk geht, oder Ethernet wenn's die Heimverkabelung ist, oder auf dem Weg zum Provider was eben der Provider so nutzt.

TCP ist ein verbindungsorientiertes Protokoll mit Fehlererkennung, das bedeutet daß ein fehlendes oder beschädigtes Datenpaket erkannt werden kann, und daß es über die aufgebaute Verbindung erneut angefordert werden kann. Das passiert automatisch. Das Streaming nutzt hier eine Fähigkeit, die das Netzwerk ohnehin anbietet und für z.B. Webseiten schon nutzt. Es brauchte nichts Neues dafür erfunden zu werden.

Es ist damit aber auch ein gravierender Nachteil verbunden, der insbesondere auffällt, wenn man geringe Latenzen braucht: Diese Art der Fehlerkorrektur durch Neuanforderung der betreffenden Daten ist zeitraubend. Es dauert eine gewisse Zeit bis klar ist daß ein fragliches Paket nicht mehr kommen wird, es dauert bis eine Neuanforderung vom Empfänger zum Sender verschickt ist, und es dauert bis das nochmal verschickte Datenpaket beim Empfänger ankommt. Wenn die Gesamtdauer dieses Vorgangs länger ist als die gewählte Latenz, dann kommt das Paket zu spät, und die Lücke bei der Ausspielung ist schon entstanden.

Ein zu spät ankommendes Paket ist genauso schlecht wie eins, das gar nicht ankommt.

Genau. Das ist ein entscheidender Unterschied zu "normalen" Computerdaten, wo es darauf ankommt daß alles richtig übertragen wird, auch wenn's mal etwas länger dauert. TCP ist von seinen Eigenschaften her darauf optimiert, alles korrekt zu übertragen, auch wenn's etwas länger dauert. So etwas wie eine "Deadline" ist dem Protokoll unbekannt. Das ist für Streaminganwendungen eigentlich falsch.

Und es kommt noch ein weiteres Problem hinzu: Wenn das Netzwerk deswegen Pakete verliert, weil es stark ausgelastet ist, dann macht es TCP durch die Neuanforderung nur noch schlimmer. Besonders wenn die neu angeforderten Pakete auch noch zu spät kommen und somit nutzlos übertragen werden.

In Situationen, wo man einen Stream an viele Empfänger zugleich schicken will, ist TCP außerdem ineffizient, denn es muß mit jedem Empfänger eine eigene Verbindung aufgebaut werden, und die Daten werden für jede Verbindung separat verschickt. Das ist eine eher unvorteilhafte Ausnutzung der Übertragungskapazität, wenn man die gleichen Daten vielfach übertragen muß. Man überlege sich das bei Live-TV-Streaming mit Millionen von Zuschauern!

Was macht man da?

Man benutzt TCP nicht. Kein Streamingsystem, das für niedrige Latenz optimiert ist, benutzt TCP, aus dem eben beschriebenen Grund. Entweder es wird direkt mit IP gearbeitet, oder wahrscheinlicher benutzt man UDP über IP. Damit verliert man allerdings die automatische Neuanforderung der Daten. Man kann zwar erkennen ob ein Paket fehlt oder beschädigt wurde, aber es gibt keine automatische Reaktion darauf. Wenn man so etwas wie Fehlerkorrektur haben will, muss man es separat organisieren.

Die probate Methode der Fehlerkorrektur, wenn man so etwas braucht, ist die sogenannte "Forward Error Correction (FEC)". Man schickt dabei von vorn herein zusätzliche Daten mit, die der Empfänger zur Rekonstruktion fehlender Teile benutzen kann. Der große Vorteil ist, daß kein Rückfragen beim Sender nötig ist, sondern daß das der Empfänger ganz allein tun kann. Es funktioniert natürlich nur bis zu einer gewissen Fehlerhäufigkeit. Wird das Limit überschritten, gibt's Aussetzer. Das Prinzip ähnelt der Fehlerkorrektur beim Abspielen einer CD, wo ja ebenfalls mit Zusatzdaten gearbeitet wird.

Wenn die Latenz aber ganz gering sein soll, wie in manchen Live-Anwendungen, dann dauert sogar die FEC zu lange. Man muß dann ein zuverlässiges Übertragungsmedium benutzen, bei dem die Wahrscheinlichkeit eines Paketverlustes sehr klein ist. Also z.B. nicht das allgemeine Internet.

So langsam leuchtet mir ein warum es so viele verschiedene Varianten gibt.

Kompromisse, Kompromisse...

Man sollte nicht vergessen, daß die Computernetzwerke hier für etwas hergenommen werden, für das sie ursprünglich nicht gebaut wurden. Die Telekom-Industrie hat mit ATM in den späten 80er und vor allem den 90er Jahren des vergangenen Jahrhunderts versucht, für ihre eigenen Anforderungen ein passendes Netzwerksystem zu entwickeln und zu etablieren. Das Streaming ist für ATM von vorn herein eingeplant gewesen und war gewissermassen sogar die Hauptanwendung. Es ist aber mißlungen, diese Technologie zum Ethernet-Konkurrenten zu machen, so daß es schließlich andersrum passiert ist: Ethernet und TCP/IP hat ATM überflügelt und überflüssig gemacht, trotz der geringeren Eignung für Streaming. Heutige Streaming-Systeme versuchen daher, die Nachteile der traditionellen Netzwerktechnik zu umgehen und zu kompensieren, ohne auf eine komplett andere Technik umzusteigen. Die Telekom-Betriebe nutzen das auch intern, und inzwischen laufen große Teile des Telefonverkehrs als IP-Streaming. Die eigentlich vom Ansatz her schlechtere Technologie hat sich durchgesetzt, weil sich damit die größeren "Synergieeffekte" und damit Einsparungen realisieren lassen.

Heißt das, IP-Streaming ist Mist?

So weit würde ich nicht gehen. Es steht auf wackeligeren Füßen als es bei ATM gewesen wäre, aber damit kann man umgehen. Die Hersteller haben das gelernt, und sind noch dabei es zu lernen. Es zeigt sich hier, daß es oft besser ist, eine einfache und etwas eingeschränkte Grundlage zu haben, die dafür aber billig und überall leicht einsetzbar ist. Darauf kann man dann Mehrwertdienste aufsetzen, auch wenn das im Einzelfall etwas schwierig sein kann. Die weite Verbreitung und der günstige Preis machen das wieder wett.

Der andere Weg, nämlich der Grundlage von vorn herein alle Fähigkeiten mitzugeben, scheint demgegenüber weniger gut zu funktionieren, weil diese nicht so leicht die große Verbreitung bekommt, und damit die kritische Masse nicht erreicht. Größere Wirtschaftlichkeit gewinnt offenbar über technische Überlegenheit.

Das hat sich übrigens nicht bloß bei ATM gezeigt. Die Netzwerktechnik hat noch diverse weitere Beispiele dafür zu bieten. Beispielsweise war Firewire mal ein Versuch von Apple, ein für Streaming-Anwendungen optimiertes Heimnetzwerk zu etablieren. Im Gegensatz zu USB ist Firewire ein Netzwerk aus gleichwertigen Teilnehmern, während USB mit dem PC einen eindeutigen "Meister" hat. Der Eine oder Andere wird sich noch daran erinnern wie AV-Receiver und andere Geräte mit Firewire-Schnittstelle ausgerüstet wurden, und wie das dann wieder vom Markt verschwunden ist.

Der nächste Versuch, auf Ethernet-Basis dasselbe zu erreichen, nämlich ein Heimnetzwerk für Streaming-Dienste zu schaffen, wurde unter dem Namen AVB vor einigen Jahren betrieben, darf aber zumindest für dieses Anwendungsfeld wohl inzwischen ebenfalls als gescheitert angesehen werden. Der Fokus bei der AVB-Entwicklung liegt inzwischen offenbar bei Anwendungen in Verkehrsmitteln.

Wir haben bisher die audiophilen Aspekte ganz vernachlässigt. Wie steht's denn um die Audioqualität?

Das ist in erster Linie eine Frage der verwendeten Kodierung, und da herrscht im Prinzip völlige Freiheit. Es ist dem Netzwerk recht egal was für Daten da verschickt werden, ob das MP3 ist oder PCM bei 384 kHz und 32-bit. Der Unterschied betrifft lediglich die Datenmenge, und damit die Kapazitäten des Netzwerks. Entweder die Übertragungskapazitäten reichen, oder eben nicht. Die Frage ist eher, ob ein Endgerät eine bestimmte Kodierung beherrscht oder nicht.

Das heißt, die Qualität ist eine Frage der Endgeräte am Netzwerk, und nicht des Netzwerks selbst?

So ist es. Man muß im Netzwerk für ausreichend Kapazitätsreserven sorgen, das ist das Entscheidende. Das ist aber weder schwierig noch teuer. Über eine 1 GBit/s Netzwerkverbindung kann man schon ziemlich viel Audio übertragen.

Größere Netzwerke brauchen allerdings ein ordentliches Management, schon auch um zu gewährleisten daß sich die verschiedenen Teilnehmer und Dienste nicht gegenseitig auf die Füße treten. Wer Streaming in einem Firmen-Netzwerk einsetzen will, schafft damit für die zuständige IT-Abteilung eine neue Herausforderung. Die müssen dazulernen, und sich eine Strategie erarbeiten, die für das Unternehmen passt. Das regelt sich ebensowenig von selbst wie sich der Strassenverkehr von selbst regelt.

Und der Jitter und solche audiophilen Zipperleins?

Alles eine Frage der Endgeräte. Wenn ein Endgerät mit Jitter Probleme hat, sollte sich dessen Entwickler selbst an die Nase fassen.

Ok, dann noch eine letzte Frage: Was ist mit den Netzwerkkabeln? Haben audiophile Kabel irgendeinen Sinn?

Nur für den Verkäufer.