Präzision im Netzwerk |  Audio-over-IP als Signalquelle für Line-Array-Lautsprecher Systeme

Akustische Kohärenz im Spannungsfeld zwischen Waveguide-Mechanik und Netzwerk-Synchronisation.

v1.1.1. | 2026-04-28 | © Bodo Felusch

Switch Language

Referenz: Anforderungen an die zeitliche Präzision von Line-Arrays

Die Anforderungen an die Konstruktions-Präzision von Line-Array Lautsprechern sind ein alter Hut. Der Waveguide ist hierbei das präziseste Bauteil. Mit seiner Hilfe wird die Energie der Hochtontreiber möglichst kohärent, d.h. phasenlinear, der Schallaustrittsöffnung zugeführt. Der Wettkampf um den optimalen Waveguide ist aufgrund patentrechtlicher Einschränkungen weitgehend ausgereizt. Warum also nicht ein neues Fass aufmachen?

Zunächst müssen wir eine Messlatte an die zu erreichende Präzision legen. Alles, was wir im Folgenden besprechen, machen wir bei 20kHz. Die akzeptable Phasendifferenz im Waveguide legen wir auf 1/4 der Wellenlänge, d.h. 90° Phasendifferenz und ein Summationsergebnis von +3dB von zwei kohärenten Schallquellen je 0dBr. Das bedeutet für die mechanische Konstruktion ein akzeptables Toleranzfenster von 4,3mm über die gesamte Betriebstemperatur. Die Ankopplung zweier Elemente blenden wir für unsere Betrachtung komplett aus, hierzu gibt es genug Abhandlungen. 

Ein gleiches Fehlerbudget auf der vorgelagerten elektronischen Ebene entspricht in etwa 12,5µs Zeitdifferenz zweier kohärenter Signale mit exakt 0dBr. Das ist etwas mehr als ein Sample bei 96 kHz, mit 10,4µs Dauer. Eine Relation zur Akustik möge uns ebenfalls als Vergleich dienen: Ein Temperaturunterschied von nur 1°C auf 10m verursacht eine Laufzeitdifferenz, die das gesamte elektronische Fehlerbudget (~12,5 µs) um den Faktor 4 übertrifft. Das unterstreicht sehr eindrücklich, dass die akustischen Randbedingungen in der Praxis oft der limitierende Faktor sind – nicht die Elektronik.

Neue Technologien wie Beam-Forming, mit denen das Abstrahlverhalten des Line-Array-Segmentes gezielt gesteuert werden soll, haben weit höhere Anforderungen an die Präzision – was der Hauptgrund für feste Winkel bei elektronisch justierten Systemen sein dürfte. Die limitierenden Faktoren durch die Verwendung von FIR-Filtern sind bei tiefen Frequenzen die Latenz. Bei 96kHz und 2048 Taps muss man mit 10,6ms Latenz leben und hat nur 46,9Hz Bandbreite pro Tap, Abhilfe können hier Allpassfilter schaffen. Bei hohen Frequenzen limitieren hingegen die Gehäuse und Treiber selbst: Um 180° bei 20kHz präzise in der Phase zu justieren, müssen 8,5mm unterboten werden. 

Im Bass limitiert uns also die Zeit und im Hochton der Raum.

Grundbegriffe der Synchronisation

Takt-Drift
Bevor wir uns mit Mobiltelefonen auf dieselbe Referenzzeit geeinigt haben, bestimmten freilaufende Uhren unsere individuelle, absolute, wenngleich immer falsche Zeit. Mechanisch konstruierte Zeitmesser und Quarzuhren zum Beispiel, sind von unterschiedlicher Präzision. Aber auch zwei identische Quarzuhren gehen nicht dauerhaft gleich. Nehmen wir an, ihr Quarz schwingt auf 32.768Hz mit einem Drift von +-10ppm. Wenn wir am 01. Januar diese zwei Uhren auf 00:00 Uhr einstellen und einen Monat liegen lassen, zeigen sie unterschiedliche Uhrzeiten an, sie driften auseinander. Im Worstcase laufen die beiden Uhren, mathematisch, nach einem Tag 1,7s und nach einem Monat 52s auseinander. Wer Video- und Tonaufnahmen auf unterschiedlichen Aufnahmemedien macht, weiß dass die beiden Aufnahmegeräte synchronisiert werden müssen, damit die Aufnahme über die gesamte Dauer Lippensynchron bleibt, denn das Problem ist genau das Gleiche wie bei den beiden Quarzuhren, sie sind nicht auf eine gemeinsame Referenz synchronisiert. Takt-Drift ist eine „Verstimmung“ der Frequenz, auf der der Taktgeber schwingen soll.

Interface-Jitter
Wenn wir zwei digitale Audiogeräte auf derselben Samplerate betreiben, digital in Reihe schalten aber beide auf ihren internen Taktgeber synchronisieren, passiert wiederum das gleiche, sie driften auseinander und es beginnt zu knacksen. Wir müssen einen Clock-Leader definieren und alle digital verkabelten Geräte als Clock-Follower auf diesen Leader synchronisieren. Hierbei wird der Takt auf einem physischen Medium übertragen und es entsteht Interface-Jitter, zwischen den digitalen Schnittstellen. Bei serieller Verkabelung kumuliert dieser Interface-Jitter und maskiert das Taktsignal. Verkürzt dargestellt passiert folgendes, die Taktflanken verschmieren zeitlich und der Empfänger hat Interpretationsprobleme, ob eine Eins oder eine Null anliegt, kann nicht länger treffsicher unterschieden werden. Ursächlich hierfür sind Fehler, die durch Kabel auftreten, z.B. Wellenwiderstand, Kapazität, Reflexionen, Länge oder schlicht Schäden und Alterungserscheinungen. Eine sternförmige Verkabelung hilft, den Interface-Jitter gering zu halten. Ein durch Interface-Jitter verschmierter Takt, kann durch Re-Clocking regeneriert werden. Das Signal wird in einem Buffer zwischengespeichert und von einem auf den Clock-Leader synchronisierten internen Takt neu generiert.

Takt-Wander & Takt-Jitter
Neben dem grundsätzlichen Langzeit Drift, den jede Uhr hat – sei sie noch so präzise, gibt es auch kurzfristige Schwankungen des Taktes. Stellen wir uns vor, wir haben den Kopfhörer auf, hören ein anspornendes Mixtape, joggen seit 30min und sind voll im Flow. Plötzlich müssen wir niesen, stolpern und sind raus aus dem Takt, aber nur kurze Zeit später sind wir wieder voll synchron zum Takt der Musik. Nach ungefähr 4 bis 5 Stunden, in der glühenden Sommerhitze, werden unsere Muskeln langsam schwach und wir beginnen zum Takt zu eiern. Dasselbe passiert – wenngleich mit viel geringerer Abweichung, in jedem Taktgeber. Neben dem Drift gibt es niederfrequente „Gleichlaufschwankungen“ bzw. Phasenrauschen, bedingt durch Umwelteinflüsse wie Temperaturschwankungen, Stabilität der Versorgungsspannung oder mechanische Spannungen. Dieses „Eiern“ unterhalb von 10Hz nennen wir Clock-Wander. Hochfrequentes Phasenrauschen über 10Hz nennen wir Takt-Jitter. Von ihm gibt es wiederum zwei Sorten unterschiedlicher Ursache. Materie steht grundsätzlich nicht still, die Reinheit und Eigenschaften von Halbleitern sind von unterschiedlicher Güte. Hierdurch entsteht Random-Jitter, der einer unvorhersehbaren Gauß Verteilung folgt, fast so, als wäre die Materie selbst ein übergeordneter Taktgeber, quasi das Grundrauschen der Zeit. Deterministischer-Jitter wiederum ist konstant, er ist die Folge unserer Entscheidungen. Elektronische Konstruktionen beinhalten Übersprechen, Restwelligkeit der Versorgungsspannung, Elektromagnetische Interferenzen oder schlicht Fehlanpassungen. Takt-Jitter ist ein „Zittern“ um die Abstimmungsfrequenz, auf der der Taktgeber schwingen soll.

Synchronisationsgenauigkeit
Jedes digitale Übertragungssystem benötigt einen gemeinsamen Taktgeber als Referenz. Dieser Clock-Leader ist die verbindliche Zeitreferenz für alle Clock-Follower, die sich auf den Leader synchronisieren. Hierzu nutzen die Follower eine PLL (Phase-Locked Loop) Schaltung, die den eigenen Taktgeber anschiebt oder abbremst. Wie gut das dem System gelingt, beschreibt die Synchronisationsgenauigkeit. Bei Dante mit PTPv1 beträgt die angestrebte Synchronisationsgenauigkeit 1µs bei einem Empfänger und 2µs bei mehreren Empfängern. Verschlechtern sich die Netzwerkbedingungen wird eine Synchronisationsgenauigkeit von einer Samplelänge garantiert.

Wie spät ist es genau und wenn ja wie viele Sekunden?
Die präziseste Uhr, die wir kennen ist eine Atomuhr. Sie leitet den Zeittakt aus Strahlungsübergängen von Elektronen freier Atome ab. Caesium, Rubidium, Wasserstoff und neuerdings Strontium sind die gängigsten Atome, mit denen Atomuhren betrieben werden, sie haben einen Drift von ungefähr 1 Sekunde in 300 Millionen Jahren. Was für uns Menschen ausreichend viel erscheint, um eine Verabredung einzuhalten ist für die hochpräzise Technik, die wir erfunden haben, jedoch nicht ausreichend. Bereits nach ca. 110 Tagen driftet diese Atomuhr um 1 Nanosekunde. Wenn wir uns jedoch weltweit auf 1ns Präzision synchronisieren wollen, um z.B. Satelliten basierte Positionsdaten auf 1m Präzision zu ermitteln, müssen wir uns etwas überlegen. Wir nehmen also 400 Atomuhren an 60 Instituten und mitteln deren historischen Messwerte zur internationalen Atomzeit TAI, woraus wir die koordinierte Weltzeit UTC bilden. Das ist im Grunde unsere Leader-Clock Nummer Eins.
Dann schießen wir GPS-Satelliten ins All, die ebenfalls Atomuhren an Board haben und zu Bodenstationen synchronisiert sind und machen innerhalb dieses GPS-Verbundes dasselbe und haben eine Leader-Clock Nummer Zwei. Diese sind nicht synchronisiert und laufen in der Präzision der Atome frei nebeneinanderher, was zumeist mit einer Abweichung von etwas 20ns gelingt. Die UTC-Zeit spielt für unseren weiteren Verlauf keine Rolle, man muss aber noch eine Sache verstehen, durch die Erdrotation werden Schaltsekunden erforderlich, um die UTC daran anzupassen. Die GPS-Zeit hingegen läuft seit 1980 durch. Die GPS-Zeit geht daher, stand heute, genau 18 Sekunden voraus. Die TAI hatte zum Systemstart 1972 bereits 10s Vorsprung zur UTC und zum GPS-Start am 06. Januar 1980 um 00:00:00 genau 19s Vorlauf, was bis heute konstant durchgeschleppt wird, ansonsten laufen GPS und TAI ohne Schaltsekunden frei durch. TAI zu UTC sind Stand heute, im Mai 2026, 37s (18s + 19s), was bei der Umrechnung von PTP/TAI zu UTC berücksichtigt werden muss.

Referenz: GPS-Jitter

Das GPS-System ist hervorragend geeignet, eine hochpräzise Zeitinformation, weltweit synchronisiert zu empfangen. Die Höhe des Jitters hängt hierbei stark von der Qualität des Empfängers ab, dessen Präzision des internen Taktgebers den GPS-Jitter unterdrücken muss. Er liegt bei wenigen Nanosekunden bis hin zu 50 oder 100ns, der Takt kommt dann im Grunde vom Oszillator des Empfängers und wird nur vom GPS abgeleitet.

Referenz: Wordclock-Jitter

Das Datenblatt einer über jeden Zweifel erhabenen Wordclock gibt uns folgende technische Angaben:

• Drift:    Clock frequency leader mode:       44.1 or 48 kHz ± 25 PPM, -5 +50 °C.
• Jitter:    Intrinsischer Clock-Jitter:             <0,6ps RMS (>10Hz)
  
  

GPS hat einen geringeren Drift, die Wordclock geringeren Jitter. Daher kombiniert man diese beiden Verfahren in Broadcast Umgebungen.

Referenz: Wahrnehmungsschwelle von Jitter bei der digitalen Audioübertragung.

Auf der 105ten AES Convention am 26.-29. September 1998 in San Francisco haben Eric Benjamin und Benjamin Gannon von den Dolby Laboratories Inc. Im AES Preprint 4826 (P-1) ihre Untersuchungsergebnisse zur Wahrnehmung von Jitter in der digitalen Audio-Qualität präsentiert. Über verschiedene Versuchsgruppen und Audiosignale ergaben sich Hörschwellen, die zwischen 20-330ns lagen.

Referenz	Toleranzfenster
Waveguide (Lamda/4) Bedingung bei 20kHz	< 12,5µs
Jitter Wahrnehmungsschwelle in Digital Audio Systemen	20-330ns

Referenz	Intrinsic-Jitter
Atomuhr	1fs
Crystal-Oszillator	2ps
GPS-System als Grandmaster Clock	10-100ns
Wordclock	0,5ps – 5ns
Wordclock Extreme Jitter	50ns
AES3	± 270ns
DARS Grade 1 Clock	± 20ps
DARS Grade 2 Clock	± 520ps
MADI [125MHz]	80ns

Leader-Clocks und intrinsischer Jitter in der Systemkette

Die eingangs erwähnte Präzision von 12,5µs bezieht sich auf das Konstruktionssystem Line-Array „Banane“. Ein Takt Jitter in dieser Größenordnung ist völlig inakzeptabel. Die absolute Hörschwelle von Jitter über verschiedene Signale und Versuchspersonen liegt bei 20-330ns. Die über jeden Zweifel erhabenen Wordclock erlaubt eine Präzision mit einem Jitter von: <0,6ps RMS (>10Hz). Die Peakwerte liegen üblicherweise um den Faktor 10 darüber, sie entsprechen dem oben erwähnten niesen und stolpern beim Joggen.

Eine solche Taktquelle als Leader zu definieren, lohnt sich nur, wenn zwei Bedingungen erfüllt werden:

1. Die Taktrückgewinnung im Follower gewinnt relevant an Präzision.

2. Die Taktübertragung gelingt ohne relevante Präzisionsverluste.

Es ist eine Tatsache, dass eine präzise Clock der entscheidende Qualitätsparameter eines jeden digitalen Audioübertragungssystems ist.

So konnten noch Anfang der 2000er Jahre führende digitale Mischpulte durch eine hochwertige, externe Wordclock-Synchronisation ein klangliches Update erfahren. Bei einem groß angelegten Vergleich im Jahr 2019 konnte dies jedoch nicht mehr reproduziert werden. Es gab im Blindversuch keinen einzigen Treffer über – wirklich alle, namhaften Pulte und Tonschaffenden hinweg. Die technische Evolution hat die interne Takterzeugung mittlerweile so überzeugend präzise werden lassen. Leider kenne ich kein einziges Mischpult, keinen Systemcontroller oder Endstufe, deren interner, intrinsischer Takt-Jitter im Datenblatt konkret angegeben ist. Daher bleibt nur die Vermutung, er bewegt sich irgendwo im Bereich von 20ns bis 1ps. Falls der Leser hierzu bessere Informationen hat, freue ich mich über einen Austausch.

Synchronisation im IT-Netzwerk

Betrachten wir das ganze mal von der anderen Seite und springen in die IT. Mediensignale werden vom Sender in Netzwerkpakete verpackt, über das Netzwerk verteilt und vom Empfänger entpackt und als Mediensignal wieder ausgespielt. Ob wir Audio- Video-oder Licht- und Steuerdaten verschicken, spielt zunächst keine Rolle. Es gibt konkurrierende Lösungen, wie die Mediendaten verpackt werden, die Pakete selbst sind Standards.

Wenn ein Paket übertragen wird, muss die Übertragung beendet werden, bevor das nächste Paket dran ist. Alles passiert nacheinander. Über 1Gbit/s Schnittstellen schneller als über 100Mbit/s Schnittstellen und in 10Gbit/s Schnittstellen schneller als mit 1Gbit/s, aber immer erfolgt jede Übertragung nacheinander. Hierzu müssen Pakete in Warteschlangen von Buffern zwischengespeichert werden, bis sie in die Übertragung rausgehen. Mittels Quality of Service (QoS) werden wichtigere Pakete, wie Synchronisationsdaten zum Clocking, markiert und durch optimal konfigurierte Switches vorrangig durch die Warteschlangen weitergeleitet. Während einer Übertragung selbst kann jedoch auch das wichtigste Paket sich nicht vordrängeln, zunächst muss die Übertragung beendet werden, dieser Vorgang wird auch Blocking-Delay genannt. Übergroße Pakete wie Jumboframes benötigen hierfür entsprechend länger. Ethernet selbst kennt keine garantierten Übertragungszeiten, es arbeitet einfach der Reihe nach alles ab. Hierdurch entstehen Variationen der Übertragungszeit von Paketen, der Fachausdruck hierfür ist PDV (Packet delay variation).

Machen Switches einen klanglichen Unterschied?

Die kurze Antwort lautet: Nein. Ein funktionierender Switch verändert weder Bits noch Frequenzgänge. Dennoch ist die Frage berechtigt, da das Netzwerkdesign die Stabilität des Gesamtsystems bestimmt.

Das Gedankenexperiment: Datei vs. Stream

Um zu verstehen, ob ein Switch den Klang beeinflusst, hilft ein Blick auf die digitale Tonaufzeichnung. Ein bei der Aufnahme entstandener Jitter ist „eingebrannt“. Weder ein Re-Clocking noch ein Switch können ihn später herausrechnen. Ob eine Datei nun auf einer lokalen Festplatte liegt oder über komplizierte IT-Traceroutes von einem Server gestreamt wird, spielt keine Rolle – solange das PCM-Format bit-identisch am Wandler ankommt. Die Samples müssen lediglich in der richtigen Reihenfolge unter der Taktung des D/A-Wandlers ausgespielt werden.

PTP und Wall-Clock, die Nanosekunden Zeitreferenz im Netzwerk.
Im Netzwerk nutzen wir das Precision Time Protocol (PTP), um eine „Wall Clock“ mit Nanosekunden-Auflösung als gemeinsame Zeitreferenz zu etablieren. Diese PTP-Zeit startete am 01.01.1970 um 00:00:00, ihre absolute Referenz entspricht der TAI. Seitdem werden Sekunden hochgezählt, wofür 48 Bit zur Verfügung stehen, was für ca. 8,9 Mio. Jahre ausreicht. Mit weiteren 32 Bit werden Nanosekundenbruchteile dargestellt. Dies ist die generelle Funktionalität seit dem ersten Protokollstandard IEEE1588-2002 (PTPv1). Mit der Revision PTPv2 kam 2008 ein 16 Bit langes Korrekturfeld hinzu, was PTPv2 fähige Switches (PTP Aware Switches) ermöglicht, die Verweildauer der PTP-Pakete im Switch zu notieren und eine präzisere, Peer-to-Peer basierte Synchronisation zu ermöglichen. PTPv2 ist nicht abwärtskompatibel zu PTPv1. Wer Netzwerke von noch höherer Synchronisationspräzision benötigt, kann sich Switches zulegen, die PTPv2.1 unterstützen. Diese Revision des Standards, aus dem Jahr 2019, ist wiederum abwärtskompatibel zu PTPv2, sie nimmt weitere 16 Bit, um auf bis zu 15 Femtosekunden aufzulösen. Das CERN White Rabbit Project ist der Motor hinter dieser Revision, um die Anforderungen an die Synchronisation in Quantennetzwerken zu präzisieren. Wer es also ganz genau haben möchte, sollte sich PTPv2.1 fähige, White-Rabbit- Low-Jitter-Switches zulegen – was für den internationalen und automatisierten Hochfrequenz-Börsenhandel gut ist, kann für die HiFi-Anlage nicht schaden.

RTP und RTCP: Die Ordnung im Chaos
Die Audiosamples werden via RTP (Real-time Transport Protocol) in Pakete verpackt, die Sequenznummern und Zeitstempel erhalten. Das RTCP (RTP Control Protocol) stellt dabei sicher, dass jedes Paket exakt der PTP-Walltime zugeordnet werden kann. Da Layer-2-Ethernet sich naturgemäß nicht für die exakte Reihenfolge interessiert, kommen diese Pakete oft „würfelig“ im Empfänger an. Hier entscheidet ein Jitter-Buffer: Er speichert die Pakete zwischen und spielt sie in der korrekten Reihenfolge aus, getaktet vom lokalen Taktgeber des Empfängers, der via PTP auf die gemeinsame Wall-Time synchronisiert ist.

Die PLL als Schwungrad

Da der Netzwerk-Paket-Jitter (PDV) immer wesentlich höher ist als der akzeptable Media-Clock-Jitter, ist die PLL (Phase-Locked Loop) im Empfänger entscheidend. Man kann sie sich wie ein schweres Schwungrad vorstellen. Ein geringer Paket-Jitter der Switches hilft diesem Schwungrad, ruhig zu laufen. Eine gut konstruierte PLL reagiert nur sehr träge auf Schwankungen („Low-Corner-Frequency“) und lässt sich nicht von jedem „Zucken“ im Netzwerk aus der Ruhe bringen.

Ein „leichtes“ Schwungrad, das unmittelbar auf Netzwerkschwankungen reagieren würde, wäre eine Fehlkonstruktion.

Der Switch macht also keinen Klangunterschied durch die Daten, die er liefert, sondern beeinflusst die Güte der Synchronisation durch die ‚Ruhe‘ (geringer PDV), mit der die PLL im Empfänger arbeiten kann. Ein stabiles PTP-Netzwerk ist somit das Fundament für einen jitterarmen Medientakt.

IT-System-Architektur: Synchronisations-Standards im Vergleich

Als nächstes wollen wir IT-Netzwerke als Transportmedium für verschiedene Audio-over-IP Standards benutzen. Audinate verkauft uns mit Dante ein System, das zwischen unterschiedlichen Empfängern optimalerweise mit 1 µs synchronisiert ist (Clock Offset), mind. jedoch mit samplegenauer Synchronisation. Wenn man bedenkt, dass dies seinen Ursprung im Jahr 2006 hat und PTPv2 erst 2008 definiert wurde, ist das dank Hardware Timestamping in den Dante Nodes keine schlechte Lösung.

Hier müssen wir streng unterscheiden: Die Synchronisationsgenauigkeit von Dante liegt bei 1µs (bei PTPv1 im End-to-End-Modus). Der physikalische Paket Jitter (PDV – Packet Delay

Variation) auf dem Netzwerkkabel ist oft deutlich höher. Bei PTPv1 wissen die Switches nicht, was die Endgeräte (Nodes) untereinander aushandeln, sie sind „Non PTP Aware“). Was den Vorteil hat, keine besonderen Anforderungen und Kosten an die Auswahl der Switches stellen zu müssen und auch 100Mbit/s Switches und Ports kein KO-Kriterium darstellen. Der Nachteil ist jedoch, dass die PDV im Netzwerk mit bis zu 1ms recht hoch ist und im Empfänger durch große Jitterbuffer und die Taktrückgewinnung unterdrückt werden muss.

Erst PTPv2 mit Transparent Clocks (TC) in den Switches drückt die Synchronisations-Abweichungen auf unter 100 Nanosekunden und kann durch Boundary Clocks (BC) sogar auf unter 50 Nanosekunden optimiert werden.

Ein AVB/TSN/Milan Netzwerk erreicht nochmals präzisere PDV-Werte, die Synchronisationsgenauigkeit der Listener auf die Talker kann aber nur unter Laborbedingungen weiter erhöht werden als mit PTPv2(BC) für z.B. AES67.

Wohlgemerkt reden wir hier über die Präzision der Netzwerk-Synchronisation, nicht über Media Clock Jitter. Der Paket Jitter des Netzwerks (PDV) wird durch Jitter-Buffer in den Eingängen des Empfängers und der Taktrückgewinnung durch die PLL (Phase-Locked Loop) im Empfänger unterdrückt. Hier entstehen im Wesentlichen die viel diskutierten „Klangunterschiede der Clock“ – nicht durch die Netzwerkpakete selbst. Den Paket Jitter in IT-Netzwerken durch gutes Design gering zu halten, ist dennoch eine gute Idee, da es die Jitter-Buffer in den Empfängereingängen und die PLL entlastet.

Die Mathematik der Summation: Das +6 dB Paradoxon

Kommen wir nun zu etwas völlig anderem, das an Kleinlichkeit kaum zu unterbieten ist.

Wir addieren zwei kohärente Signale mit je 0dBr, wie hoch ist der Summenpegel? 

+6dB? Falsch! 

Es sind exakt +6,0206dB!  [20 × log₁₀(2) ≈ 6,0206 dB]

Jetzt könnte man sagen „stell dich nicht so an“ Aber heute bin ich mal kleinlich und drehe den Spieß einfach um. Wir runden auf exakt 6,0000dB ab und müssen bei 20kHz nun mathematisch eine Phasenverschiebung von 7,89° akzeptieren, das entspricht exakt 1,09µs, in dieser Zeit legt der Schall in Luft etwa 0,37mm zurück. Das entspricht der optimalen Synchronisationsgenauigkeit von Dante, die sich allerdings mit Verschlechterung der Bedingungen, wie z.B. hohe Netzwerklast, Jumboframes und 100Mbits/s Trunks auf bis zur Länge eines Samples verschlechtern lässt.

Stress-Test

Als nächstes wollen wir mal einen Stresstest machen, ein Dante PTPv1 basiertes Line-Array-System soll unter Netzwerk-Jitter leiden. Wir bauen uns ein Testsystem und können letztendlich 2dB Pegeldifferenz Fehler über die Beschallungsdistanz eines Line-Array-Systems nachweisen (also +4 dB statt +6 dB Summe). Wenn wir absolut kohärente Signale und gleiche Pegel unterstellen sind das bei 20kHz gewaltig 75° Phasenverschiebung. Anders ausgedrückt: Gute 10µs Clock Offset oder ziemlich genau einer Samplelänge bei 96kHz – was genau innerhalb der maximalen Dante-Systemspezifikation liegt.

Da die Taktrückgewinnung im Empfänger stattfindet und mehrere Empfänger aufeinander synchronisiert werden müssen, macht es Sinn möglichst viele Line-Array-Module aus einem Audio-over-IP-Empfänger mit gemeinsamer Taktrückgewinnung zu speisen. So wie man das bei einem Mischpult auch macht. In einem aktiv-selfpowered Line-Array-Modul mit Dante Platine reden wir also über exakt diesen möglichen Maximalfehler unter schlechten Bedingungen bei PTPv1, der bei Verwendung von PTPv2 und Boundary Clocks in die o.a. Präzision reduziert werden kann. Eine Endstufe mit Audio-over-IP Eingang, die z.B. 3 Line-Array-Module speist hat für diese 3 Module auch unter den ungünstigsten Bedingungen den gleichen Takt. 

Die 1-Sample Falle | Evolution von der Legacy Schnittstelle zu Audio-over-IP

Bevor Systemendstufen mit internem DSP Processing ausgestattet waren, hat ein zentraler Systemcontroller die Rechenaufgaben zur Ansteuerung analoger Endstufen (meint Endstufen ohne DSP, unabhängig ihrer Bauform Class-AB/D/H/TD etc.) übernommen. In einem solchen System gab es also nur einen Taktgeber und die Frage der Synchronisation zu einem einzigen Clock-Leader erübrigte sich oft.

Die nächste Generation System-Endstufen wurde mit DSPs ausgestattet und konnte die Aufgaben des zentralen Systemcontrollers selbst übernehmen. Was passiert, wenn ein solches System, mit analogen Eingangssignalen angesteuert wird?

Jede Endstufe hat einen freilaufenden Taktgeber, unterstellen wir mal eine interne Verarbeitung in 96kHz und einen Drift von +/-10ppm, gegen eine perfekte Referenz.. Der Taktgeber von Endstufe A schwingt mit 95.999,04Hz und der von Endstufe B mit 96.000,96Hz. Nach 1,04s driften die beiden Endstufen um ein Sample (10,4µs) auseinander, wenn eine der beiden perfekt schwingt und die andere maximalen Drift hat, im Worstcase, wenn beide gegenläufig schwingen halbiert sich dieser Zeitraum entsprechend. Nach knapp 28 Stunden beträgt der Drift 1s. Aber keine Sorge, das Signal kommt keinesfalls links 1s später als rechts heraus, denn in diesem „Echtzeitsystem“ gibt es keine absolute Referenzzeit. Der maximale Fehler beträgt immer eine Samplelänge (10,4µs bei 96kHz), die „LFO-Geschwindigkeit“, mit der er innerhalb dieses Fensters wandert, hängt von der Präzision der Taktgeber ab. Da die Periodendauer von 20 kHz lediglich 50 µs beträgt, führt dieser Versatz von einem Sample bereits zu einer Phasenverschiebung von bis zu 75° bei 20kHz. Dieser Fehler entspricht genau dem Worstcase-Szenario von Dante mit PTPv1 unter schlechtesten Bedingungen und führt zu den besagten 2 dB Pegeldifferenz im HF. Das System erreicht zwar dank der analogen ‚Leitplanke‘ niemals die totale Auslöschung (180° bei 25 µs), zappelt aber permanent in einem Bereich, der die akustische Kopplung instabil macht. Unter diesem Aspekt kann man sagen, je mehr Module von einem Amp betrieben werden können, desto besser. Demgegenüber stehen Leistungsreserven und Beam-Steering Anforderungen, die Einzelansteuerungen nötig machen. Die analoge Zuspielung schützt uns zwar vor dem totalen Zeit-Chaos un-synchronisierter Netzwerke, lässt uns aber in der ‚1-Sample-Falle‘ gefangen. Erst moderne Standards wie Milan oder PTPv2 sprengen diese Fessel und synchronisieren die Wandler so präzise, dass Phasenfehler selbst bei 20kHz physikalisch irrelevant werden.

Interessant wird der Vergleich beim Blick auf den digitalen Klassiker AES3. Die Spezifikation AES11-2009 (r2014) erlaubt hier eine Input-Toleranz (Jitter-Mask) von etwa 2,6 % = +/-270ns (540ns totales Jitter-Fenster) des Sample-Intervalls, was bei 96 kHz einer Abweichung von ca. 0,5 µs entspricht. Wir addieren wieder unsere beiden kohärenten Signale und erreichen einen Summenpegel von +6,01633dB statt +6,0206. Das entspricht einer Phasenverschiebung von 3,59° bei 20kHz Ich hoffe jetzt wird klar, warum wir mit den 6dB kleinlich werden mussten.

Die interne PLL der Endstufen filtert diesen Jitter und ermöglicht eine phasenstarre Wiedergabe. Dieser Wert ist die technologische Messlatte: Wer heute Milan oder PTPv2 (BC) einsetzt, liefert dem Endgerät ein Taktsignal, das bereits am Eingang um den Faktor 5 bis 10 präziser ist als das absolute Limit der klassischen AES3-Schnittstelle.

Als nächstes statten wir aktiv-selfpowered Line-Array-Module mit Audio-over-IP Eingängen aus. Die Synchronisationsgenauigkeit hängt nun vom verwendeten AoIP-Standard ab, sowie den Rahmenbedingungen, unter denen das System arbeitet, also im Grunde mit Stress oder ohne?

Eine weitere Variante ist es, die AoIP-Eingänge in die Systemendstufen zu integrieren. Hierbei tritt der Phasenfehler und die daraus resultierende Level Modulation an den Modulübergängen auf, die von der nächsten Endstufe betrieben werden.

Zusammenfassung der PDV und Synchronisationsgenauigkeit verschiedener Audio System Szenarien

System-Szenario	Jitter / PDV (Input)	Sync Accuracy (Node)	Summenpegel @ 20 kHz	Akustisches Verhalten
AES3	~500 ns (0,5 µs)	< 20 ns (PLL)	6,02 dB	Phasenstarr (Referenz)
AVB/TSN Milan (gPTP)	< 50 ns	~50 ns	6,02 dB	Absolut kohärente Wellenfront
AES67 (BC Mode)	< 100 ns	~50 ns	6,02 dB	Referenz-Klasse (Phasenstarr)
AES67 (TC Mode)	< 1.000 ns (1 µs)	~100 ns	6,02 dB	Sehr stabil
Dante (Best Case)	< 1.000.000 ns (1 ms)	~1.000 ns (1 µs)	6,00 dB	Industriestandard
Dante (Worst Case)	< 1.000.000 ns (1 ms)	~10.420 ns (1 Sample)	~4,01 dB	HF-Level (statisch)
Analog-In (DSP)	n.a. (Kupferkabel)	~10.420 ns (1 Sample)	6,02 – 4,01 dB	HF-Level (modulierend)

Die ASRC-Falle

In der Realität müssen wir oft unterschiedliche Taktraten unter einen Hut bringen. Hier kommen Samplerate Converter (SRC) ins Spiel. Während synchrone SRCs den Drift starr durchreichen, interpolieren asynchrone Wandler (ASRC) den Drift permanent. Da sie faktisch eine Clock Domain Boundary bilden, gehören sie zwingend an den Rand des Systems. Werden sie mehrfach und in Reihe innerhalb eines Line-Array-Segments eingesetzt, induzieren sie unkontrollierbare Latenz-Versatze, die unsere mühsam erkämpfte akustische Kohärenz im Hochton schlicht zerstören. Aus diesem Grund macht man das auch nicht, sondern achtet penibel darauf, dass jedes Array in sich synchron aus einer Clock-Domain gespeist wird. Zudem beschränkt man die Menge der Links, um Interface-Jitter-Akkumulation gering zu halten. Systemendstufen, die in den AES3-Eingängen SRCs verbaut haben, die sich im Menü nicht abschalten lassen und unpräzise dokumentiert sind, was ihre Bauform SRC oder ASRC angeht, sind weitere Fehlerquellen, die die Synchronisationsgenauigkeit einschränken.

Obwohl moderne ASRCs eine deterministische Latenz aufweisen, bleiben sie eine Takt-Grenzbrücke: Da jedes Modul im Array das Verhältnis zwischen Eingangs- und Ausgangstakt eigenständig schätzen und regeln muss, können kleinste Abweichungen in den Tracking-Algorithmen und Filter-Laufzeiten zu Phasen-Inkonsistenzen führen. In einem System, das auf Mikrosekunden-Präzision angewiesen ist, ist diese dezentrale Taktrückgewinnung ein unnötiges Risiko. Ein Systemdesign, das kaskadierte ASRCs in Mediensignal-Clustern vorsieht, ist daher der falsche Ansatz. Aufeinanderfolgende Interpolationsvorgänge mit jeweils eigenen Filter-Artefakten und Jitter-Transferfunktionen „verschleifen“ das Signal zeitlich. Man stelle sich einen ASRC als eigenständigen „Entscheider“ vor – ein Line-Array-System benötigt jedoch eine einzige, systemweite „Wahrheit“.

Zusammenfassung:

Kriterien für ein phasenlineares Audio-over-IP Systemdesign

Gegenüber PTPv1 mit Hardware Timestamping in Dante Modulen (<1 µs Synchronisationsgenauigkeit) ist PTPv2 bis zu 10x präziser bei Transparent Clock (<100𝑛𝑠) oder 20x präziser bei Boundary Clock (<50𝑛𝑠). Ich wiederhole es nochmal Netzwerk-Paket Jitter (PDV) ist nicht gleich Media-Clock-Jitter! Die Klangqualität entsteht durch die Taktrückgewinnung im Empfänger, diese ist der entscheidende Punkt. Wir benötigen im Jahr 2026 keine „Wunder-Switches“, sondern ein sauberes Systemdesign: Einen präzisen Takt-Leader, eine sternförmige Verteilung und den konsequenten Verzicht auf freilaufende Taktgeber oder asynchrone Samplerate-Converter innerhalb eines Line-Array-Lautsprecher Segmentes. Wenn diese Hausaufgaben gemacht sind, bietet Audio-over-IP eine Präzision, die der mechanischen Konstruktion moderner Line-Arrays in nichts nachsteht und die Nachteile einer Interface-Jitter behafteten, seriellen AES3-Verkabelung überflüssig macht. AES3, Milan, AES67 mit TC oder BC sowie Dante unter Best Case Bedingungen sind alle gleichermaßen geeignet Line-Array-Lautsprechersysteme mit präzisen Audiosignalen zu versorgen. Lediglich Dante mit PTPv1, unter Worst Case Bedingungen, tritt in die gleiche 1-Sample Falle wie freilaufende DSP-Endstufen mit analogen Eingangssignalen. Allerdings moduliert im letzten Fall der 75° Phasenfehler (2dB Pegeldifferenz) relativ schnell zwischen den idealen +6dB und gedämpften +4dB, im Vergleich zum recht statischen Fehler mit Dante und dies auch nur, wenn die Empfangsplatinen direkt in die Line-Array Module verbaut sind. Wer also die Präzision eines modernen Waveguides elektronisch nicht verspielen will, muss die Synchronisation der Wandler zur obersten Priorität machen.

Kalkulator:
PTP-Zeit, Drift, Jitter, Sync, Signallaufzeit in Kabeln

Die hier getroffenen Aussagen müssen natürlich auch mathematisch plausibel und nachvollziehbar sein. Hier findest Du einen Kalkulator, mit dem Du folgende Berechnungen durchführen kannst:

• UTC Zeit in PTP Zeit umrechnen
• PTP Zeit in UTC Zeit umrechnen
• Signallaufzeit über Kabellänge berechnen
• Clock Drift berechnen, Drift bis 1 Sample und Drift bis 1s Differenz, Phasendifferenz des Clock Drift bei wählbarer Frequenz
• Jitter im Nano- und Mikrosekundenbereich berechnen
• Synchronisationsgenauigkeit berechnen
• Umrechnung: Frequenz und Phasendifferenz eingeben und Latenz Offset und Summenpegel berechnen
• Umrechnung: Summenpegel zweier kohärente Signale je 0dBr eingeben und Phasendifferenz berechnen, sowie Latenz und Sample Offset
  

Excel Kalkulator – PTP-Zeit – Jitter – Signallaufzeit

1 Datei(en)

90KB

Mit Paypal kaufen 5,99€

Tiefer einsteigen?

Präzision im Netzwerk ist kein Zufall — sie ist das Ergebnis von Systemverständnis. Wer weiß warum ein Line-Array bei 20kHz aus dem Takt gerät, kann es verhindern.

IT For AVs® — Netzwerktechnik für Veranstaltungstechniker vermittelt in drei Tagen die IT-Grundlagen die du als Veranstaltungstechniker wirklich brauchst. Und wer noch weiter will: Mastering Event IT kommt als Zusatzmodul — ein Tag, der es auf den Punkt bringt: Mediennetze und ihre Anforderungen an die IT, PTP und Synchronisation, Routing-Grundlagen. Internet einspeisen und gezielt an einzelne Gewerke verteilen — auch in Kundennetzen wo du keinen Zugriff auf den Router hast. Medienserver im Video-VLAN mit dem Lichtpult im Licht-VLAN verbinden. Gewerkeübergreifend denken, gewerkeübergreifend handeln.

Wenn du dabei sein möchtest wenn es losgeht — trag dich ein. Kein Spam, keine Tricks. Nur ein Signal wenn es relevant wird

→ Ich bin dabei:

Quellenverzeichnis

Perception & Psychoacoustics

[1]  E. Benjamin, B. Gannon (Dolby Laboratories): „Audibility of Jitter in Digital Audio Transmission“        AES Preprint 4826, 105th AES Convention, San Francisco, September 1998        https://www.aes.org/e-lib/browse.cfm?elib=8174

[2]  B. C. J. Moore: „An Introduction to the Psychology of Hearing“        6th Edition, Brill Academic Publishers, 2012. ISBN 978-9004252424        (Auditory threshold and temporal resolution)

Clock & Synchronisation Standards

[3]  IEEE: „IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems – PTPv1“        IEEE Std 1588-2002        https://doi.org/10.1109/IEEESTD.2002.94144

[4]  IEEE: „IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems – PTPv2“        IEEE Std 1588-2008        https://doi.org/10.1109/IEEESTD.2008.4579760

[5]  IEEE: „IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems – PTPv2.1“        IEEE Std 1588-2019        https://doi.org/10.1109/IEEESTD.2020.9120376

[6]  BIPM / IERS: „Coordinated Universal Time (UTC) and International Atomic Time (TAI)“        Bureau International des Poids et Mesures        https://www.bipm.org/en/time-ftp/tai

[7]  U.S. Space Force: „IS-GPS-200: NAVSTAR GPS Space Segment/Navigation User Segment Interfaces“        GPS Interface Specification, current revision        https://www.gps.gov/technical/icwg/

Audio Interface & Digital Audio Standards

[8]  AES: „AES standard for digital audio – Serial transmission format for two-channel linearly represented digital audio data“        AES3-2009, Audio Engineering Society        https://www.aes.org/publications/standards/search.cfm?docID=2

[9]  AES: „AES recommended practice for digital audio – Synchronization of digital audio equipment in studio operations“        AES11-2009 (r2014), Audio Engineering Society        https://www.aes.org/publications/standards/search.cfm?docID=17

[10]  AES: „AES standard for audio applications of networks – High-performance streaming audio-over-IP interoperability“        AES67-2018, Audio Engineering Society        https://www.aes.org/publications/standards/search.cfm?docID=96

AVB / TSN / Milan

[11]  IEEE: „IEEE Standard for Local and Metropolitan Area Networks – Timing and Synchronization for Time-Sensitive Applications (gPTP)“        IEEE Std 802.1AS-2020        https://doi.org/10.1109/IEEESTD.2020.9121845

[12]  IEEE: „IEEE Standard for Local and Metropolitan Area Networks – Bridges and Bridged Networks (includes AVB/TSN)“        IEEE Std 802.1Q-2022        https://doi.org/10.1109/IEEESTD.2022.9870098

[13]  IEEE: „IEEE Standard for Local and Metropolitan Area Networks – Forwarding and Queuing Enhancements for Time-Sensitive Streams (Credit-Based Shaper)“        IEEE Std 802.1Qav-2009        https://doi.org/10.1109/IEEESTD.2010.5390974

[14]  IEEE: „IEEE Standard for Local and Metropolitan Area Networks – Enhancements for Scheduled Traffic (Time-Aware Shaper / TSN)“        IEEE Std 802.1Qbv-2015        https://doi.org/10.1109/IEEESTD.2016.7479742

[15]  AVNU Alliance: „Milan: A Pro AV Standard Based on AVB/TSN – Milan Specification“        AVNU Alliance / Milan Open Specification        https://www.milanspec.org

RTP / Network Transport

[16]  H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson: „RTP: A Transport Protocol for Real-Time Applications“        IETF RFC 3550, July 2003        https://datatracker.ietf.org/doc/html/rfc3550

[17]  H. Schulzrinne, S. Casner: „RTP Profile for Audio and Video Conferences with Minimal Control“        IETF RFC 3551, July 2003        https://datatracker.ietf.org/doc/html/rfc3551

Dante / Audinate

[18]  Audinate Pty Ltd: „Dante Audio Networking – Technical Overview and Whitepapers“        Audinate, https://www.audinate.com/resources        https://www.audinate.com/resources        (Herstellerreferenz / Manufacturer reference – not an open standard)

CERN White Rabbit Project

[19]  M. Lipiński, T. Włostowski, J. Serrano, P. Alvarez: „White Rabbit: a PTP Application for Robust Sub-Nanosecond Synchronization“        ISPCS 2011, IEEE, September 2011        https://doi.org/10.1109/ISPCS.2011.6070148

Line Array Acoustics

[20]  M. Ureda: „Line Arrays: Theory and Applications“        AES Preprint 5304, 110th AES Convention, Amsterdam, May 2001        https://www.aes.org/e-lib/browse.cfm?elib=9888

[21]  D. Gunness, W. Tenney: „Optimized Polar Patterns for Steerable Arrays“        AES Preprint 6757, 121st AES Convention, San Francisco, 2006        https://www.aes.org/e-lib/browse.cfm?elib=13853        (Reference for waveguide tolerance and phase coherence in line arrays)