Es sind bald 6 Jahre, daß ich in der Folge eines Besuchs bei der Münchner High-End einen Blogartikel über Strassner und seine Firma HMS schrieb. HMS steht nach wie vor mit dem WWW auf Kriegsfuß, weswegen man sich schwer tut, im Internet auch nur einen Überblick über das Produktspektrum zu gewinnen. Man muß sich dies, und auch Infos über die dahinter stehende "Theorie", auf anderen Webseiten zusammensammeln. Eine dieser Seiten gehört zum "Fidelity Magazin", auf deren Online-Auftritt seit Kurzem eine Artikel-Serie mit einem Strassner-Interview zu lesen ist, die in der gedruckten Ausgabe schon vor Längerem erschienen war.
Ich habe schon in meinem damaligen Artikel hier im Blog dargestellt, wo mein Problem mit der Darstellung von Strassner ist. Strassner's neuere Darstellung ist in mancher Hinsicht "verfeinert", aber immer noch falsch, weswegen ich meine Erwiderung ebenfalls überarbeite.
Nun fällt es zwar leicht, sich klar zu machen weshalb Strassner die Darstellung so wählt, schließlich hat er ein finanzielles Interesse zu wahren - er will ja Kabel und entsprechendes Zubehör verkaufen. Seine Darstellung wird aber wohl vielen Lesern recht plausibel vorkommen, darum lohnt es vielleicht, sich damit etwas genauer zu beschäftigen.
Wie schon bei meinem alten Artikel geht die Diskussion von der Frage aus, was denn ein Meter Netzkabel noch ausrichten soll, wenn davor in der Wand und im Stromnetz schon viele Meter Standardkabel im Spiel sind. Strassner argumentiert, es käme auf den letzten Meter deswegen an, weil es um Differenzspannungen zwischen den Komponenten einer Anlage gehe, und die entstünden erst ab dem Punkt, an dem sich die Wege für Stromversorgung der Geräte trennen, also z.B. ab der gemeinsamen Steckerleiste. Siehe Abbildung 1 im Artikel des Fidelity-Magazins.
Der Interviewer des Fidelity-Magazins wendet dasselbe ein wie ich damals, nämlich daß die Differenzspannung wegen der galvanischen Trennung durch die Netztrafos in den Geräten gar nicht direkt mit der Netzspannung zusammen hängen kann. Dieser entscheidende Punkt blieb bei Strassner's Vortrag damals auf der High-End unerwähnt; diesmal liefert er einen Versuch einer Erklärung, der jedoch komplett fehl geht.
Schauen wir uns mal seine Abbildung 2 an, die zur Erklärung dienen sollte. Da wird sichtbar, daß die parasitären Kapazitäten zwischen Primär- und Sekundärseite für Störströme verantwortlich sein sollen. Wenn diese Störströme zu Differenzspannungen zwischen den Massen zweier Geräte führen sollten, dann führen sie in der Tat zu Audiostörungen, wenn man unsymmetrische Verbindungen benutzt, die sich auf diese Masse als Referenz beziehen. So weit so gut.
Nur, wieso und unter welchen Umständen kommt es dazu? Da muss man etwas genauer hinsehen als es Strassner tut. Wir werden sehen, daß sich die Sache ganz anders darstellt, als man es aus Strassner's Darstellung erwarten würde.
Der erste Punkt: Wenn die parasitären Kapazitäten tatsächlich für die Störströme verantwortlich sind, dann ist es praktisch egal welche Impedanzen oder Widerstände das Netzkabel hat, denn die Spannungen, die über diese Kapazitäten abfallen sind davon fast unabhängig. Die Netzspannung fällt über einen der beiden Kondensatoren C1 oder C2 ab, über den anderen fällt eine geringe, praktisch vernachlässigbare Spannung ab. Die Impedanz der Netzleitung sorgt selbt im extrem unvorteilhaften Fall nur für wenig Spannungsabfall, in der Praxis sind die immer vorhandenen Spannungsschwankungen im Netz wesentlich stärker. Entsprechend unerklärlich wird dann, was man von einem teuren Netzkabel mit extra niedriger Impedanz haben soll.
Strassner hat recht wenn er darauf hinweist, daß es insbesondere die höherfrequenten Anteile der Störströme sind, die in einem solchen Fall relevant werden, denn je höher die Frequenz, desto geringer die Impedanz der parasitären Kapazitäten. Daraus resultiert schon das nächste Problem in Strassner's Erklärung: Eine besonders niedrige Impedanz der Zuleitung verstärkt sogar tendenziell diese höherfrequenten Anteile. Wenn es überhaupt etwas ändert, ein besonders impedanzoptimiertes Kabel einzusetzen, dann sogar zum Schlechteren. Warum?
Nun, Strassner erklärt das mit Hilfe seiner Abbildung 3, wo beschrieben ist wie es wegen der Gleichrichtung und Siebung in jedem Gerät zu impulsförmigen Ladeströmen kommt. Das erzeugt Oberwellen im Netzstrom, also genau die höheren Frequenzen, die Strassner zufolge problematisch sind. Nur werden die umso stärker, je niedriger die Impedanz des Primärstromkreises ist.
Wollte man dagegen etwas unternehmen, dann müßte man die Impedanz der Stromleitung vergrößern, und nicht etwa verringern! Strassner's eigene Produkte wären kontraproduktiv!
Kurz gesagt, wenn der Mechanismus der Störung so sein sollte wie von Strassner dargestellt, dann müßte man eigentlich eine möglichst "schlechte" Netzleitung benutzen. Schlecht in dem Sinn, daß die Impedanz hoch wäre. Die höhere Impedanz dämpft die Stromimpulse, und verringert dadurch die Oberwellen, die besonders gut über die parasitären Kapazitäten einkoppeln.
Immerhin, in der Praxis wird der Trafo selbst dominieren, mit seinen Wicklungswiderständen, und die Widerstände irgendwelcher 2m Netzkabel samt Steckern werden demgegenüber vernachlässigbar sein. Strassner vermeidet es wohlweislich, ein quantitatives Beispiel durchzurechnen, sonst würde offensichtlich, daß es hier um heiße Luft geht. Stattdessen erweckt er den Eindruck, als käme es darauf an, daß wegen der Stromimpulse möglicht wenig Spannung über die Netzkabel und Stecker abfällt. Dabei geht es bei diesem Spannungsabfall gar nicht um die von ihm in die Diskussion eingeführte Differenzspannung zwischen den Geräten. Im Gegenteil, je mehr Störspannung über das Netzkabel abfällt, desto weniger bleibt für die Kopplung über die parasitären Kapazitäten übrig.
Strassner widerspricht sich also im Grunde selbst, was einem aber nur auffällt, wenn man genug von der Sache versteht, und sich die Verhältnisse im Detail durchüberlegt.
Bis hierher sind wir implizit davon ausgegangen, daß es keine Schutzleiterverbindungen gibt. Auch Strassner's Zeichnungen haben bis hierhin keine gezeigt. In diesem Fall fließen die Störströme, insoweit sie durch die parasitären Kapazitäten auf die Sekundärseite geleitet werden, natürlich durch die Massen der Cinch-Leitungen, also das von Strassner unterstellte Störszenario. Einen anderen Weg gibt's üblicherweise nicht, es sei denn man hat die Geräte extra über Massekabel miteinander verbunden. Wenn es aber Schutzleiterverbindungen gibt, dann können diese Störströme genausogut über diese fließen, und die Argumentation verändert sich fundamental.
Das ist ein weiterer meiner Kritikpunkte an Strassner's Ausführungen: Die Unterscheidung zwischen Geräten mit Schutzleiterverbindung, und Geräten ohne, ist hier absolut zentral. Strassner geht darüber hinweg.
In Abbildung 5 kommt dieses Thema in den Fokus. Hier erfährt man explizit, welches Gerät Schutzleiterverbindung hat und welches nicht. Warum nicht schon früher? Hier geht es aber nicht um die kapazitive Störeinkopplung, sondern um Brummschleifen. Ein übliches Szenario: Wir haben eine Masseschleife über eine Antennenverbindung, und ein Netzkabel mit Schutzleiter. Wenn eine Audioleitung Teil der Schleife ist, dann brummt's. Das ist ein völlig anderer Mechanismus, als der vorher beschriebene.
Auch hier ist die von Strassner präsentierte Abhilfe kontraproduktiv: Wenn man es mit so einer Brummschleife zu tun hat, dann kommt es darauf an, den Strom durch die Massen der Audioleitungen zu minimieren, um den Spannungsabfall (also die Differenzspannung) zu minimieren. Wenn man die Impedanzen der anderen Leitungen in der Schleife minimiert, dann kann das genau den umgekehrten Effekt haben, je nachdem wie die Störung eingekoppelt wird. Es wäre dann wieder einmal erfolgversprechender, wenn man die Impedanzen der Netzleitungen erhöhen würde. Wobei es in diesem Fall um die Impedanz der Schutzleiterverbindung geht, und nicht um die stromführenden Leitungen im Netzkabel.
Es zeigt sich, daß man ein paar Dinge säuberlich auseinander halten muß, die Strassner vermischt: Störströme durch kapazitive Kopplung in den Geräten, Störströme die in Brummschleifen umlaufen, und die Wege, die diese Störströme nehmen (können). Mehr noch, es geht auch noch um Störungen durch Funk, was die Sache weiter verkompliziert. Wer das nicht säuberlich trennt, der verwirrt sich selbst.
Im Grunde kommt es zu der ganzen Problematik deswegen, weil man im Hifi-Bereich noch immer auf breiter Front unsymmetrische Audioverbindungen benutzt. Die vertragen sich schlecht mit Geräten, die über den Schutzleiter geerdet werden, weil man dadurch fast unvermeidlicherweise Brummschleifen kriegt. Alles was man da an den Netzkabeln oder generell der Stromversorgung "herumoptimiert" ist ein Herumdoktern an den Symptomen. Falls man dieses Problem hat, dann ist durchaus plausibel, daß sich die Situation hörbar verändert, wenn man andere Kabel nimmt, oder irgendwelche Filter einbaut. Es ist aber weder klar ob die Änderung hin zum Positiven ist, noch hat man sich das Problem damit vom Hals geschafft. Man hat nur ein paar Parameter geändert, und das meist recht planlos und ohne eine objektive Erfolgskontrolle.
Die "klassische" Strategie ist noch immer die am weitesten verbreitete: Alle Geräte haben Stromversorgungen ohne Schutzleiteranschluß, dann kann man auch eine Erdverbindung über den Antennenanschluß haben, ohne daß man sich dadurch eine Brummschleife durch's ganze Haus einhandelt. Die Geräte in der Anlage haben dann zwar untereinander Masseverbindung über die (unsymmetrischen) Audiokabel, aber das ergibt höchstens lokale und entsprechend harmlose Schleifen. Die Ausgleichsströme (die über die oben diskutierten parasitären Kapazitäten zustande kommen) fließen mangels Alternative über die Audiokabel, aber in den meisten Fällen sind sie schwach genug um keine hörbaren Probleme zu machen. Verbessern kann man die Situation, indem man zusätzliche Masseverbindungen zwischen den Geräten schafft. Wohl dem, dessen Geräte dafür eine Masseklemme haben, andernfalls muß man eine geeignete Gehäuseschraube zweckentfremden.
Haben die Geräte Schutzleiteranschluß (es fängt schon an wenn es nur ein Gerät ist), dann tritt sofort die Problematik aus Strassner's Abbildung 5 auf den Plan. Hat man einen Anschluß an eine geerdete Antennenanlage, dann gibt es nun eine Brummschleife quer durch's Haus, über die meist getrennten Erdungen der Antennenanlage und des Stromnetzes. Die darin fließenden viel stärkeren Ausgleichsströme fließen zum Teil wieder durch die Audiokabel, und verursachen hörbare Probleme. Nur nutzt es wenig, wenn man hier an der Impedanz des Netzkabels herumoptimiert. Man müßte die Impedanz des Schutzleiters schon bei 50 Hz so hoch machen, daß die Störungen deutlich vermindert werden, und dann hätte der Schutzleiter seine eigentliche Funktion, nämlich zu schützen vor Stromschlag, verloren.
Strassner geht daher in die völlig falsche Richtung, wenn er sich mit Kabelimpedanzen und Übergangswiderständen beschäftigt, denn dadurch löst er das tatsächliche Problem nicht.
Wenn man schon mit unsymmetrischen Verbindungen leben muß, und nicht auf die in dieser Hinsicht weitaus unproblematischeren symmetrischen Verbindungen umsteigen kann, was bei Geräten mit Schutzleiteranschluß eigentlich nötig wäre, dann muß man sich um die "topologischen" Probleme kümmern, nämlich um die Schleifen selbst, und muß versuchen, sie entweder aufzutrennen, oder sie so zu legen, daß der Störstrom nicht über die Audioleitungen fließt.
Eine Möglichkeit besteht darin, die Masse des Antennenanschlusses am Steckdosenverteiler der Anlage mit dem Schutzleiter zu verbinden. Damit entsteht ein Massesternpunkt an der Vielfachsteckdose, und die vorherige große Masseschleife wird zweigeteilt, wobei die Audiogeräte nur noch kleine, lokale, relativ harmlose Schleifen bilden. Manche Vielfachsteckdosen haben integrierte "Filter" und/oder Blitzschutz für Antennenleitungen, aber leider ist meist unklar wie die intern aufgebaut und verschaltet sind. Filter bräuchte man eigentlich keine, es kommt eher auf die interne Masseführung an. Falls das in Ordnung ist, sind solche Leisten wirksam, falls die ganze Anlage darüber versorgt wird, und die Anlage nirgendwo eine weitere Erdverbindung hat. Es braucht wohl kaum erwähnt zu werden, daß so etwas recht billig sein kann, denn auf irgendwelche besonders niedrigen Impedanzen, oder hochwertige Materialien kommt es hier nicht an. HMS könnte sich hier verdient machen, indem sie in die angebotenen Vielfachsteckdosen noch Antennenbuchsen einbauen würden, für diejenigen Kunden, die so teure Vielfachsteckdosen kaufen.
Die andere Möglichkeit besteht in der Auftrennung der Brummschleife. Die Herausforderung besteht darin, die geeignetste Stelle dafür zu finden. An der Seite der Stromversorgung kommt man dabei sehr schnell mit den Sicherheitsvorschriften in Konflikt, es sei denn man verwendet Trenntrafos, aber deren parasitäre Kapazitäten sind auch nicht umbedingt vernachlässigbar. Am einfachsten und billigsten ist in der Regel eine Massetrennung in der Antennenleitung, also ein galvanisch getrennter "Mantelstromfilter". Aber auch die Audioleitungen kann man galvanisch trennen, nämlich mit einem Übertrager oder einem Trennverstärker.
Strassner's "Lösung" scheint dagegen auf der Überlegung zu beruhen, daß die Schutzleiterverbindung ja auch eine Masseverbindung zwischen den Komponenten schafft, und je niederimpedanter diese ist, desto kleiner wird auch die Differenzspannung zwischen den Geräten. Wenn das so sein sollte, dann wäre immer noch der direktere (und billige) Weg, eine Masseverbindung zwischen den Geräten auf dem kürzesten Weg, durch ein extra Massekabel, anstatt durch die Netzkabel und die Verteilerleiste zu schaffen. Wenn die Geräte direkt beieinander stehen, dann ist das viel kürzer und niederimpedanter als durch die Netzkabel. An der Brummschleife durch das ganze Haus ändert sich daran aber nichts.
Es ist einfach so: Die unsymmetrischen Audioverbindungen sind umso ungünstiger, je weiter eine Anlage wächst, also je mehr Komponenten untereinander verbunden werden, besonders wenn auch noch Antennenanlagen ins Spiel kommen. Irgendwann bekommt man die entscheidende Erdverbindung zu viel. Mit den entstehenden Brummschleifen und anderen Störproblemen kann der Laie oft nicht vernünftig umgehen, und ein Teil davon neigt dann zur Anschaffung von teurem Firlefanz, wovon solche Firmen wie HMS profitieren. Dabei wäre die "richtige" Lösung hier oft ziemlich einfach und billig, aber die Überlegung, die dahin führt, ist nicht einfach. Abhilfe bestünde darin, daß man konsequent auf symmetrische Audioverbindungen umsteigt. Das würde den Laien von der Last befreien, daß er Probleme lösen muß, die ihm die Hersteller aufgehalst haben. Aber was würde dann aus Firmen wie HMS?
Besonders obskur in der Beschreibung von Strassner ist das Thema "Netzfilter". Da wird behauptet, die Spannungsschwankungen, die ein Verstärker im Stromnetz erzeugt, indem er eine mit der Musik wechselnde Last darstellt, hätten einen "möglichen Dynamikverlust" in anderen Komponenten zur Folge. Das ist blanker Unfug. Spannungsschwankungen im Netz sind völlig normal, auch ohne einen Verstärker, und wenn ein Gerät darauf mit Dynamikverlust reagiert, dann hat sein Entwickler etwas falsch gemacht. Da rettet man auch nichts mit einem zusätzlichen Filter. Strassner erfindet hier schlicht und einfach eine zu seinem Verkaufsziel passende Story.
Wer mir das nicht glaubt, dem sei in Erinnerung gerufen, daß die Geräte ja ohnehin die Wechselspannung aus dem Netz gleichrichten und filtern, und meist noch regeln, so daß sie einerseits gegen Schwankungen aus dem Netz immun sind, andererseits ihren eigenen impulsförmigen Strombedarf aus dem internen Filter (den Siebelkos) bestreiten. Die sich nach außen mitteilenden Lastschwankungen aufgrund der Musik sind folglich recht niedrig in ihrer Frequenz, und entsprechend leicht auszuregeln. Es ist nicht zu erkennen, wie Strassner auf die Idee kommen kann, damit könnte irgend ein Geräteentwickler ein Problem haben.
Mein Fazit aus diesen Erklärungen bleibt also weitgehend das Gleiche wie in meinem vorigen Artikel: Strassner verbreitet nur die halbe Wahrheit, und unterschlägt alles, was gegen seine Erklärungen spricht. Seine Produkte lösen entweder Probleme, die erst herbeiphantasiert werden, oder er löst tatsächliche Probleme auf eine sehr teure Art, deren Lösung ganz einfach und billig sein könnte, oder er ändert nur die Symptome eines Problems, das ganz anders gelöst werden müßte, als durch den Einsatz eines seiner teuren Produkte. Er versucht so seriös wie nur irgend möglich zu wirken, aber was er vorträgt ist eben nicht seriös, sondern es ist Marketing, wo ja die selektive Darstellung zu den am weitesten verbreiteten Tricks gehört.
Sonntag, 17. April 2016
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.
Streaming ist das Übertragen von Audio in "Echtzeit" über ein Computernetzwerk. Oder eigentlich nicht bloß Audio, sondern beliebige Mediendaten, also z.B. auch Video.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.