Audio-Netzwerkprotokolle verstehen

Bevor wir ins Testen einsteigen, ist es wichtig, das verwendete Audio-Netzwerkprotokoll zu verstehen. Übliche Protokolle sind Dante, AVB (Audio Video Bridging) und AES67. Jedes Protokoll hat spezifische Anforderungen an Netzwerkkonfiguration, Latenz und Synchronisation. Zum Beispiel verwendet Dante eine Kombination aus Multicast- und Unicast-Streams und erfordert IGMP-Schnüffel AVB setzt auf gPTP (generalized Precision Time Protocol) für die Taktsynchronisation und erfordert Switches, die IEEE 802.1Qav und 802.1AS unterstützen. AES67 ist ein Interoperabilitätsstandard, der auf Standard-IP-Netzwerken laufen kann, aber eine sorgfältige Konfiguration des Paket-Timings und der Puffergrößen erfordert.

Wenn Sie diese Protokolldetails kennen, werden Sie Ihren Testplan leiten - was zu messen ist (Jitter, Latenz, Paketverlust) und welche Tools zu verwenden sind. Siehe die offizielle Dokumentation für Ihr Protokoll, wie z. B. die Audinate Dante Support Portal oder IEEE 802.1 AVB-Seite, für spezifische Testparameter und empfohlene Netzwerkdesigns.

Vorbereitung vor der Prüfung

Eine gründliche Vorbereitung verhindert Zeitverschwendung und unvollständige Diagnosen. Beginnen Sie mit der Erfassung eines vollständigen Bestands aller Netzwerk- und Audiogeräte: Mikrofone, Mischer, Verstärker, DSPs, Netzwerkschalter, Verkabelung (sowohl Kupfer-Ethernet als auch Glasfaser), Stromversorgungen und alle Medienkonverter. Stellen Sie sicher, dass Alle Firmware- und Softwareversionen sind auf dem neuesten Stand – veraltete Firmware auf Netzwerk-Switches oder Audiogeräten ist eine häufige Quelle für intermittierende Probleme. Erstellen Sie ein detailliertes Verbindungsdiagramm, das Gerätestandorte, IP-Adressen, Switch-Ports, VLAN-Zuordnungen und Clock-Sync-Master-Auswahl zeigt. Verwenden Sie ein Tabellenkalkulations- oder Netzwerkdokumentationstool, um MAC-Adressen, Gerätetypen und Konfigurationseinstellungen zu protokollieren.

Bereiten Sie auch Ihre Testumgebung vor: Wenn möglich, richten Sie das Netzwerk genau so ein, wie es in der Produktion verwendet wird, einschließlich des Kabeltransports durch Kabelschächte und der Platzierung von Geräteständerpositionen. Wenn dies nicht möglich ist, bauen Sie ein kleines repräsentatives Testgestell, das die Schlüsseltopologie repliziert (Kernschalter, Edge-Switches, Audio-Endpunkte), um Probleme frühzeitig zu erkennen. Legen Sie klare Testziele fest: zum Beispiel "Überprüfen, ob alle 48 Kanäle von Dante Audio ohne Paketverlust bei 48 kHz / 24-Bit geroutet werden können" oder "Bestätigen Sie, dass die AVB-Stre

Durchführung von grundlegenden Konnektivitätstests

Beginnen Sie mit dem OSI-Modell von Layer 1 aufwärts. Alle Ethernet-Kabel physisch prüfen: Suchen Sie nach Schäden, überprüfen Sie die feste Verbindung und verwenden Sie einen Kabeltester oder ein Verifizierungstool, um die richtige Pinout-, Kontinuitäts- und - für High-Speed-Leistung zu bestätigen. Cat5e oder Cat6 Für Faserverbindungen, reinigen Sie die Steckverbinder mit geeigneten Materialien und verwenden Sie einen Stromzähler, um den Verlust zu messen. Führen Sie eine einfache Ping-Test von jedem Audiogerät zum Core-Switch und zwischen Geräten auf demselben VLAN zur Bestätigung der IP-Konnektivität. Beachten Sie jedoch, dass Ping nicht garantiert, dass Audiostreams fließen; Firewalls oder VLAN-ACLs können Multicast- oder Echtzeittransport blockieren. Als nächstes überprüfen Sie den Linkstatus auf Netzwerk-Switches: Alle Ports sollten eine Verbindungsgeschwindigkeit von 1 Gbps (oder 10 Gbps für kritische Verbindungsleitungen) und Vollduplex aufweisen.

Wenn Sie eine halbe Duplex- oder weniger als erwartete Geschwindigkeit sehen, untersuchen Sie das Kabel und die Netzwerkschnittstellenkonfiguration des Geräts. Bei PoE-Geräten wie Mikrofonen oder Verstärkern überprüfen Sie, ob der Switch ausreichend Strom liefert und dass das Gerät mit dem Netzwerk eingeschaltet ist. Verwenden Sie die Webschnittstelle oder die Controller-Software des Geräts, um zu bestätigen, dass es eine IP-Adresse erhalten hat (DHCP oder statisch) und kann mit anderen Geräten kommunizieren.

Überprüfung der Signalqualität

Die Qualitätsprüfung von Audiosignalen geht über das Hören hinaus, wenn es gut klingt. Verwenden Sie eine Kombination von Hardware- und Software-Analysatoren, um Pegel, Rauschuntergrund, totale harmonische Verzerrung plus Rauschen (THD + N) und Signal-Rausch-Verhältnis objektiv zu messen. Generieren Sie einen Referenzton (z. B. 1 kHz bei -20 dBFS) von einer bekannten guten Quelle und speisen Sie ihn über das Audionetzwerk in ein Empfangsgerät. Messen Sie den Ausgang mit einem Audioanalysator wie Audiopräzision oder ein Software-Tool wie Room EQ Wizard (REW). Zu den Schlüsselkontrollen gehören: Der Pegel sollte innerhalb von ±0,5 dB übereinstimmen (wenn die digitale Verstärkung nicht geändert wird); der Rauschpegel sollte nicht höher sein als der angegebene Rauschpegel des Geräts; und das Spektrum sollte keine unerwarteten Oberwellen oder Artefakte aufweisen. Bei Mehrkanalsystemen sollte die Kanalausrichtung überprüft werden (keine vertauschten Links-/Rechtskanäle).

Auch die Probenausrichtung in digitalen Netzwerken überprüfen: Bei Verwendung von AVB oder AES67 kann eine Fehlausrichtung Kammfilterung oder Audiofehler erzeugen. Verwenden Sie eine Phasenmessung zwischen zwei Kanälen einer Monoquelle, um sicherzustellen, dass sie kohärent sind.

Netzwerkleistungstests

Audionetzwerke sind echtzeit- und verlustsensibel. Latenz, Jitter, und PaketverlustEinrichten eines Traffic Generators im Netzwerk – wie die Iperf3 Tool – zur Simulation der erwarteten Audiostream-Last. Für Dante oder AES67 verbraucht jeder Kanal bei 48 kHz / 24-Bit etwa 2,8 Mbps IP-Multicast-Verkehr. Für ein 64-Kanal-System sind das etwa 180 Mbps. Senden Sie Traffic mit dieser Rate und überwachen Sie die CPU-Auslastung und Pufferabfälle.

Verwenden Sie Wireshark oder dedizierte Netzwerktester, um Multicast-Streams zu erfassen. Duplikatpakete (Sturmmeldungen anzeigen) oder fehlende laufende Nummern (Paketverlust angeben): Jitter messen: die Variation der Paketankunftszeiten. Bei Audionetzwerken sollte Jitter unterhalb der Empfangspuffergröße des Geräts liegen (oft 0,25–2 ms). pktgen Tool oder Wireshark’s eingebaute I/O Graphen um Jitterstatistiken zu sehen. Führen Sie einen Konvergenztest durch: Führen Sie einen temporären Linkausfall ein (Kabel ziehen) und sehen Sie, wie schnell das Netzwerk ausfällt (z.B. mit STP/RSTP oder einem redundanten Pfad). Die Konvergenzzeit muss kleiner als die Audiopuffergröße sein, um Ausfälle zu vermeiden – typischerweise unter wenigen Millisekunden.

IGMP-Schnüffel Ein paar kleine Budget-Switches haben kleine Puffer, die unter starkem Multicast-Verkehr überlaufen können. Eine nützliche Faustregel: Die Summe aller Stream-Bandbreiten auf einem Port sollte nicht mehr als 80% der Portgeschwindigkeit betragen, um den Datenverkehr zu ermöglichen.

Netzwerksegmentierung und Traffic Priorisierung

Richtig gestaltete VLANs und QoS-Richtlinien (Quality of Service) sind unerlässlich. Erstellen Sie dedizierte VLANs für Audio-Datenverkehr, getrennt von IT- oder Kontrolldaten. Testen Sie die VLAN-Isolation, indem Sie bestätigen, dass Geräte auf dem Audio-VLAN keine Ping-Geräte im IT-VLAN anpingen können (es sei denn, ein Router ist explizit konfiguriert). Verwenden Sie Ping-basierte Tests zur Verifizierung der Segmentierung. Markieren Sie für QoS Audio-Pakete mit hoher Priorität (DSCP EF oder AF41, je nach Protokoll).

Verwenden Sie einen Paketanalysator, um sicherzustellen, dass der Switch die DSCP-Markierungen ehrt und den Audio-Datenverkehr in die Prioritätswarteschlange stellt. Führen Sie einen Stresstest durch: Fluten Sie das Netzwerk mit Hintergrund-Datenverkehr (Dateiübertragungen, Videostreams) auf demselben VLAN und überprüfen Sie, ob Audio-Streams ihre Qualität mit Nullfehlern beibehalten. Messen Sie den Jitter vor und nach der Hintergrundlast; ein Nicht-QoS-Netzwerk zeigt einen merklichen Anstieg.

Validierung unter realen Bedingungen

Labortests sind notwendig, aber die Validierung in der realen Welt fängt das Unerwartete. Richten Sie das System am tatsächlichen Veranstaltungsort oder im Studio ein, wobei alle Geräte vorhanden sind. Führen Sie eine vollständige Kanalanzahl (z. B. 64 Kanäle mit Leerlauf-Audio) aus und überwachen Sie mehrere Stunden. Suchen Sie nach Paketverlusten, Uhrendrift oder einem Gerät, das aus dem Netzwerk ausfällt. Simulieren Sie die Lastbedingungen, die dem tatsächlichen Anwendungsfall so nahe wie möglich kommen: Lassen Sie Musiker mindestens eine Stunde lang Musik spielen oder aufgezeichnete Tracks durch das System spielen.

Bewegen Sie das Personal, öffnen Sie Türen, bedienen Sie Beleuchtungssysteme und erstellen Sie minimale Bewegung der Geräte, um zu sehen, ob dies Interferenzen einleitet. Verwenden Sie eine WiFi-fähiges Gerät (in den Händen der Bedienungsmannschaft) auf 2,4 GHz Interferenzen an drahtlosen Mikrofonen oder In-Ears bei Verwendung drahtloser Verbindungen zu prüfen – obwohl das Netzwerk selbst auf isolierten kabelgebundenen Verbindungen liegen sollte. Überprüfen Sie auf elektromagnetische Interferenzen (EMI) von großen Leistungstransformatoren, Dimmerpaketen oder Bühnenbeleuchtung, indem Sie ein Diagnosewerkzeug in der Nähe dieser Quellen platzieren. Wenn das System Geräte mehrerer Hersteller enthält, testen Sie die Interoperabilität: z. B. eine Yamaha-Konsole, die über Dante an einen Focusrite RedNet I/O und dann AES67 an einen L-Acoustic-Verstärker gespeist wird. Stellen Sie sicher, dass alle Paketformate, Sampleraten (und Sampleratenwandler, falls erforderlich) und Taktquellen übereinstimmen.

Eine typische Validierungs-Checkliste für die reale Welt ist in der Audinate Trainingsvideos und die AES-Technikausschuss für Network Audio.

Stresstest und Redundanzfehler

Ein professionelles Audionetzwerk muss Fehler anmutig überstehen. Testen Sie Ihre Redundanzsysteme: wenn Sie ein primäres/sekundäres Dante-Netzwerk verwenden (Dante Redundant-Modus), trennen Sie den primären Switch und bestätigen Sie, dass Audio innerhalb von Millisekunden weiter auf dem sekundären Switch läuft. Verwenden Sie eine Wireshark-Erfassung, um die Umschaltzeit zu sehen - sie sollte nahtlos sein (keine Audiolücken). Wenn Sie eine Ringtopologie mit einem belastbaren Protokoll verwenden (wie MRP oder R‐STP), brechen Sie den Ring an einem Punkt auf und überprüfen Sie, ob Pakete mit Nullverlust umgeleitet werden. Für die Taktredundanz sollten Sie mehrere Grandmaster-Kandidaten einrichten (z. B. Switch verwendet PTP-Grenztakt) und dann den aktiven Master deaktivieren.

Das System sollte einen neuen Master auswählen, ohne dass Neuverhandlung Audio-Ausfälle verursacht. Schalten Sie einen Switch in der Mitte einer Daisy-Chain aus und überprüfen Sie, ob die Endpunkte weiter unten in der Kette noch funktionieren (wenn sie in einem anderen Pfad verdrahtet sind). Testen Sie die Stromversorgungs

Fortgeschrittene Fehlerbehebungstechniken

Wenn Probleme auftreten – Aussetzer, Störungen oder hohe Latenz – gehen Sie über grundlegende Pings hinaus. Fluke Networks OptiView bei physikalischen Schichtproblemen, Wireshar mit Fangfiltern für spezifische Geräte-MAC-Adressen oder Multicast-Gruppen und Rauch für Langzeitlatenz-Monitoring, für Jitter-Analysen Jperf oder Wireshark’s I/O graph mit einem < 1 ms resolution sample. If you see periodic packet loss patterns, check for clock mismatches: all devices must be synchronized to the same clock reference (e.g., PTP or Word Clock). In a Dante network, use the Dante Controller’s “Clock Status” panel to verify that all devices are synced to the designated leader. If a device shows a different sample rate or latency offset, reconfigure it. Use the Geräteinformationen Seiten auf jedem Gerät, um Echtzeitstatistiken anzuzeigen: Anzahl der abgesetzten Pakete, Resends und Clock-Offsets. Für AES67 überprüfen Sie den PTP-Clock-Status auf jedem Gerät mit dem IEEE 1588PTP-Timing-Monitor Ein weiteres wertvolles Werkzeug ist es, Geräte schrittweise vom Netzwerk zu trennen und zu sehen, ob Probleme verschwinden – das kann ein problematisches Gerät identifizieren, das Multicast-Stürme oder eine hohe CPU-Auslastung des Switches verursacht. Wenn alles andere fehlschlägt, erfassen Sie eine vollständige Paketspur während eines Fehlerereignisses und analysieren Sie sie in Wireshark. Wireshark Benutzerhandbuch enthält Anweisungen zum Filtern von Audioprotokollen.

Dokumentation und Berichterstattung

Jedes Testergebnis muss systematisch aufgezeichnet werden. Erstellen Sie ein Testprotokoll, das Folgendes enthält: Datum, Testziel, erwartetes Ergebnis (z. B. null Paketverlust für 1 Stunde), tatsächliche Ergebnisse (numerische Daten, Screenshots), Pass/Fail-Status und alle ergriffenen Korrekturmaßnahmen. Führen Sie für jedes Gerät eine Aufzeichnung seiner MAC-Adresse, Firmware-Version und Konfiguration (IP, VLAN, Kanalnamen). Verwenden Sie ein Tool wie Microsoft Excel oder ein spezielles Asset-Management-System für Großprojekte. Wenn ein Test fehlschlägt, dokumentieren Sie die Schritte zur Fehlerbehebung: was geändert wurde (z. B. ersetztes Kabel, angepasste Puffergröße, geänderte QoS-Priorität) und das Ergebnis des erneuten Tests.

Diese Dokumentation ist von unschätzbarem Wert für die zukünftige Wartung und für die Reproduktion identischer Setups an mehreren Orten. Fügen Sie einen Abschnitt über bekannte Einschränkungen oder Vorbehalte bei - zum Beispiel: "Dieser Switch kann 64 Kanäle von Multicast bei 96 kHz wegen begrenzter Puffergröße nicht verarbeiten." Nachdem alle Tests abgeschlossen und validiert sind, erstellen Sie einen Abschlussbericht, der die Leistung des Netzwerks, etwaige Abweichungen vom Design und eine Abmeldung zusammenfasst das System erfüllt die Anforderungen. Stellen Sie diesen Bericht dem Kunden zur Verfügung und bewahren Sie eine Kopie für Ihre eigenen Aufzeichnungen auf.

Letzte Tipps für effektives Testen

  • Testen Sie immer mit dem maximale Kanalanzahl und Abtastrate Tests mit nur wenigen Kanälen können Pufferprobleme verbergen.
  • Verwendung a dedizierte Testschnittstelle (ein Laptop mit einem richtigen Ethernet-Port und einer Analysator-Software) - nicht die Konsole selbst - um Verfälschungen zu vermeiden.
  • Incorporated Automatisierte Testskripte für wiederholte Tests (z. B. kontinuierlicher Ping oder iperf) über mehrere Stunden über Nacht.
  • Regelmäßig Firmware aktualisieren auf allen Netzwerk-Switches und Audiogeräten, und nach jedem Update erneut testen. Neue Firmware behebt häufig Fehler, die intermittierende Probleme verursachen.
  • Trainieren Sie Ihr Team in den Test-Tools und -Verfahren, lassen Sie sie Fehlerszenarien üben (Kabel ausstecken, Schaltstromverlust simulieren), damit sie während eines Live-Events schnell reagieren können.
  • Führen Sie Tests für Außen- oder Mobilgeräte zu verschiedenen Tageszeiten durch, da sich Umgebungstemperatur, Luftfeuchtigkeit und EMI-Quellen ändern.
  • Wenn Sie drahtloses Zubehör verwenden (z. B. drahtlose IEM-Systeme über das Netzwerk), verwenden Sie einen Spektrumanalysator, um auf Interferenzen auf 2, 4 / 5 GHz zu prüfen und Frequenzen zu koordinieren.
  • Berücksichtigung Auftragsprüfungen für kritische Installationen; Unternehmen wie Systemintegration & Testing bieten spezialisierte Netzwerk-Audio-Validierung mit Enterprise-Grade-Tools.

Durch die Befolgung dieser erweiterten Schritte und Empfehlungen können Sie Ihr Audionetzwerk gründlich testen und validieren. Die Kombination aus Vorbereitung, systematischen Konnektivitätsprüfungen, Signalqualitätstests, Netzwerkleistungsanalysen, realen Szenarien, Stresstests, erweiterter Fehlersuche und gründlicher Dokumentation stellt sicher, dass Ihr Audionetzwerk zuverlässig, robust und bereit für jede Live-Veranstaltung oder Aufnahmesitzung ist.