Sonntag, 3. April 2016

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.

Kommentare :

Christian Roll hat gesagt…

Hi Pelmanzo,

eine gute Zusammenfassung die auch für mich einige neue Aspekte enthielt. Es fehlt aber meiner Ansicht nach der wichtigste Aspekt der ganzen Angelegenheit (und damit auch der Grund für den letzten Satz dass nämlich "audiophile LAN Kabel" nur die Taschen der Verkäufer füllen). In KEINEM Fall wird über Audio Streaming Musik übertragen, genausowenig wie auf einer CD oder in einer MP3 oder FLAC Datai Musik ist. Auf allen Medien sind nur Daten vorhanden, die aus der Musik über ein vereinbartes Kodierungsverfahren erzeugt wurden. Erst im (aus Datenträgersicht) Endgerät wird aus diesesn Daten über das entsprechende Dekodierungsverfahren wieder Musik generiert. Eventuell gibt es Geräte die das besser oder schlechter können als andere, aber das ist nicht Sache des Übertragungsmediums (egal ob WLAN oder Kabel) sondern des Endgeräts.

viele Grüße, Christian

MW hat gesagt…

Nur eine Idee - ob es audiophile ist, müssen andere Ohren beurteilen;)
audiophile LAN als Jitter-Killer: Eingangsclock über einen Zeitraum X überwacht, die Audiodaten in einen Speicher geschoben und mit einem stabilen Clock erzeugten Takt versehen, Daten auslesen, fertig. Nennt sich Dante Netzwerk - hier bieten sich für das Heimnetzwerk z.B. solche Lösungen an: 2 Kanal Dante Break Out Box basierend auf Dante Ultimo von fouraudio. Grüße Micha

pelmazo hat gesagt…

@MW: Die Idee ist so alt wie die CD, denn in jedem CD-Spieler wird es ebenso gemacht. Die Daten von der Scheibe laufen in einen Pufferspeicher, und werden von dort mit einem sauberen Takt (direkt mit Quarzoszillator erzeugt) ausgespielt. Der Füllstand des Pufferspeichers dient als Ist-Signal für einen Regler, der den CD-Motor steuert, und versucht, den Füllstand auf halb-voll zu halten.

Insofern ist der CD-Spieler ein Streaming-System ohne Netzwerk. ;-)

Das von Dir erwähnte Dante ist also in dieser Hinsicht nichts Besonderes, sie machen im Grunde das was jeder so oder so ähnlich machen würde. Der "Clou" bei Netzwerk-Streaming mit sehr niedriger Latenz, wie z.B. bei Dante, ist mit möglichst wenig Puffer auszukommen. Dafür müssen die Oszillatoren untereinander synchronisiert werden, und wie das im Einzelfall gemacht wird kann sich unterscheiden.

Streaming im Heim-Netzwerk braucht aber in aller Regel keine besonders niedrige Latenz, daher kann der Streaming-Client mit relativ großen Puffern arbeiten, und mit freilaufenden Oszillatoren, ganz wie bei der CD. Es gibt keinen Grund, warum man da Jitter-Killer bräuchte, der Client macht das als Teil seiner Arbeit sowieso. Wenn man da immer noch Jitterprobleme kriegen sollte, hat man Schrott gekauft.

Schule INROCK hat gesagt…

Hallo pelmazo ,
ich möchte deine Meinung zu Folgendem:
ich habe einen DAC mit Vorstufe, der mir viel Freude macht (CYRUS DAC XP Signature). Der kann kein DSD und hat keine USB-Eingänge. Statt dessen zwei getrennte Trafos für PRE und DAC und zwei DAC's , pro Kanal einen. Also alles Mono-Konfiguration.
Auf Anfrage, warum kein USB und kein DSD bei einem 4000EUR Gerät neuster Bauart, antwortete CYRUS, DSD ist Unsinn und USB braucht man nicht, wenn die DAC's auf einem so hohen Niveau arbeiten, wie im CYRUS. Im Gegenteil: USB stelle für CYRUS eher eine weitere Störquelle dar, als ein Gewinn. Auch die asynchrone Variante.

Hier meine Frage:
ich habe derzeit einen Auralic mini Streamer am CYRUS. Der Auralic funktioniert super und hat alle erdenklichen Schnittstellen. Habe bei einem Freund auch mal USB (asynchron), S/P-Dif und TOS vergleichen - kein Unterschied.
Kann es sein, dass es ziemlich egal ist, welchen Streamer ich an den CYRUS DAC hänge, weil dieser eben hervorragend in der Lage ist, das S/P-Dif für eine gute Wandlung aufzubereiten? Und demzufolge kein Klangunterschied zu hören sein wird? Auch wenn ich einen 2000 EUR Streamer an den DAC hänge?

Vielen Dank!

pelmazo hat gesagt…

@Schule INROCK:
Es ist kein großes Problem, ein S/P-DIF-Signal für die Wandlung aufzubereiten. Es geht dabei in erster Linie um eine Taktrückgewinnung, die zur Qualität und den Eigenschaften des eigentlichen Wandlers passt. Dafür gibt es diverse Lösungen, man kann also gewissermaßen "ins Regal greifen", wenn man ein solches Gerät entwickelt. Das können auch Geräte, die weitaus billiger sind und einfacher aufgebaut als Dein Gerät.

Das bedeutet nicht daß es automatisch alle Geräte gut machen. Mist gibt's überall, gerade auch in der HiFi-Branche.

Ob ein Klangunterschied zu hören sein wird wenn der Streamer ausgetauscht wird, das hängt davon ab was die beiden Streamer mit dem Signal machen. Machen sie nichts weiter als das Signal 1:1 vom Stream an den S/P-DIF-Ausgang weiterzureichen (außer der nötigen Datenpufferung), dann sind keine Unterschiede zu erwarten. Ob das bei den von Dir genannten Geräten so ist, kann ich nicht sagen, ich habe sie nicht untersucht.

Die Behauptung des Cyrus-Vertreters bzgl. USB ist nicht schlüssig. Wenn sie mit den eventuellen Störungen aus USB nicht umgehen können spricht das nicht für sie. Ich halte das eher für eine Schutzbehauptung.

Schule INROCK hat gesagt…

Hallo pelmazo,
vielen Dank für die schnelle Antwort.
S/P dif : also alles andere, als die gelesenen Dateien in S/P Dif direkt an den Ausgang weiterreichen, wäre ne Katastrophe. Die Dinger sollen ja "nur" lesen und umsetzen. Ich glaube, da muss man wohl eher von umsetzen sprechen, oder? Digital in Digital. Flac in SP-dif.
Ich frage mich dann nur, wie die Hersteller die Preise rechtfertigen. Z.B. Kostet mein Auralic mini "nur" 500 EUR und hat noch dazu einen DAC eingebaut. Der große Bruder kostet als reine Streaming Bridge 1700 EUR. Sind das wirklich nur die Produkte, um die high end Leute zu verar.... ? Denn der Hersteller wirbt ausdrücklich mit Neutralität aller seiner Geräte. Und signifikanter klangverbesserung durch das teure Modell. Ich bin nicht nativ, habe auch Nachrichttechnik und E-Technik im Studium und stimme deiner Betrachtung und deinen Artikeln auch voll zu. Ich kann es bloß nicht fassen, dass man einem ein 2000 EUR anbietet, das nicht besser , als ein 500 EUR Gerät arbeitet... ...alles Autosuggestion? Wahrscheinlich...

Taktrückgewinnung - ja genau, das ist das Stichwort. Ich vermute, ein wirklich guter DAC kommt fast immer zurecht, fast egal, wir das Signal übergeben wird. In meinem Falle wird es der Auralic ohnehin schon so gut übergeben, so dass der Cyrus alles ohne Probleme
rückgewinnen und aufbereiten kann.

USB
Ich glaube nicht, dass die Cyrusleute nicht fähig sind, USB zu beherrschen. Deren Sreamer hat ja einen USB Eingang und auch Netzwerk. Eigentlich braucht man USB ja auch nur für DSD. Und das finden die eben überflüssig. Du doch auch, oder? Ich auf alle Fälle. Ich höre ja nicht nicht mal 24 Bit richtig....
Und dann haben die Cyrus Geräte ja diese halben Gehäuse . Wahrscheinlich haben sie sich dann das USB einfach aus platzgründen gespart. Aber wie gesagt, gute spdif Verarbeitung braucht das asynchrone USB nicht, soweit ich es überblicke.

pelmazo hat gesagt…

@Schule INROCK:
Ich würde nicht den Fehler begehen, die Preise über die technischen Eigenschaften zu erklären. Gerätepreise hängen in erster Linie vom Produktionsvolumen und dem Marketingkonzept ab. Im Luxussegment wahrscheinlich fast ausschließlich von Letzterem. Da geht's um Prestige und um Image, deswegen versucht man ja auch so intensiv, irgendwelche pseudotechnischen Eigenschaften herbeizufabulieren, die einer genaueren technischen Betrachtung nicht standhalten. Die Hersteller kennen ihre angepeilte Kundschaft und was die gerne glauben möchten. Die ganze Branche ist darauf ausgerichtet, der Kundschaft für irreale Vorteile reales Geld aus der Tasche zu ziehen. Das ist auch nicht anders als bei Cola. Auch da hat der Preis sehr wenig mit den Herstellungskosten zu tun.

Immerhin bekommt man für so einen Preis auch eine ansprechende Optik und aufwändige Konstruktion, ob die nun für die Funktion nötig oder auch nur nützlich sind oder nicht.

Wer so etwas des besseren Klangs wegen kauft macht fast immer einen Fehler. Wer auf edle Gerätschaften unabhängig vom Klang steht, der wird weniger enttäuscht. Untadeliger Klang kostet heutzutage sehr wenig. Damit sind keine schwierigen technischen Probleme verbunden, es handelt sich um bekannte und beherrschte Technologie, die in Massen gefertigt wird und dementsprechend billig zu kriegen ist. Man muß bloß wissen was man tut, und das ist auch bei Luxusmarken nicht automatisch besser. Oft ist da bloß die Überheblichkeit größer.

Schule INROCK hat gesagt…

Hallo pelmazo, du hast natürlich völlig Recht. Es ist wohl offenbar so, dass die meisten High End Fans sich verarschen lassen WOLLEN. Sonst könnte z.B. Cyrus nicht einen Streamer für 2000 EUR verkaufen. Einige HighEnder, wie ich, tun das, was du in deinem Artikel "Den Ohren trauen" beschreibst, ich vertraue meinem Urteil und meinem Verstand. Und kaufen dann diese Geräte nicht, oder gebraucht zum Bruchteil des originalen Preises, so wie ich.
Ich werde in den nächsten Tagen nochmal einen letzten Vergleichstest machen, indem ich zwei 2000 EUR Streamer gegen meinen "Billigen" antreten lasse. Internetkauf machts möglich. Dann ist Schluß.

Untadeliger Klang:
Du hast ja eigentlich in all deinen Artikeln alles gesagt, was nötig ist. Inkl. Blindtests, Hires-Lüge etc.
Daher kann jeder Mensch immer nur das benennen, was für ihn wichtig ist, ohne Anspruch auf Verallgemeinerung.
Insofern wurst du mir Recht geben, dass "Untadeliger Klang" einem anderen Individuum, als dir, auch nicht so viel hilft... (-:
Für mich ist Untadeliger Klang, Auflösung, Raumdarstellung (Soundstage), eine bestimmte Art, Bässe, Mitte und Höhen abzubilden und vor allem ein "ruhiger" Klang. Das habe ich bisher mit "wenig" Geld (was immer du damit meinst) noch hinbekommen, fand aber teure Sache nicht zwangsläufig erfüllend.
Für mich wäre es wenig Geld, für LS, AMP, Streaming (audio, video) insgesamt 1000 EUR. Ich habe jetzt 6000 EUR ausgegeben.
Das ist für mich viel, für andere HighEnder fast nichts...

AM ENDE, weswegen ich dich hier kontaktierte:
Ich dachte, du hast noch einen Tipp/eine Erklärung, die, jenseits deiner Ausführungen über Design und Marketing, aus rein technischer Sicht erhellend wären, bezüglich Streamer--Signal--DAC

Das war mein Ansinnen.

Vielen Dank und ein schönen Tag!

pelmazo hat gesagt…

@Schule INROCK:
Ich weiß gar nicht ob man das "verarschen" nennen soll wenn man der Kundschaft das sagt was sie hören will. Im Grunde bekommen sie geliefert was sie bestellt haben. Betrogen werden eher diejenigen, die lieber auf dem Boden der Tatsachen stehen.

Ich habe auch selber schon vergleichsweise teure Geräte gekauft, z.B. einen Funk MTX, wo man ebenfalls sagen könnte daß ich dafür relativ wenig Funktionalität bekommen habe. Es war aber dasjenige Gerät, das am besten zu meinem Einsatzgebiet passte, es ging da eher um Bedienung und um die vorhandenen Schnittstellen.

Mir geht's also nicht um's Geld, sondern um Aufrichtigkeit, auch gegenüber sich selber, was die Kaufmotive angeht. Wie ich sagte: Wer nur des Klangs wegen teuer kauft macht wahrscheinlich einen Fehler. Andere Gründe können es aber durchaus zu einem Erfolg machen.

Die D/A-Wandlung ist heutzutage eine eher triviale Angelegenheit, da es reichlich fertige Chips mit guter Qualität gibt. Ein Streamer kann daher problemlos einen guten DAC enthalten, ohne deswegen nennenswert teurer werden zu müssen. Ein externes Gerät ist demgegenüber immer im Nachteil, weil es eine eigene Stromversorgung und ein eigenes Gehäuse braucht, so daß die Kosten zwangsläufig höher sein werden. Es kann natürlich dennoch Sinn haben, z.B. wenn man weitere Quellen anschließen will, oder die Bedienung besser ist.