AVB/TSN: soll das die Zukunft sein?

  • Der Thread zu den bühnentauglichen Switches entwickelt sich zum AVB-Thread.

    Marcoboys Thread beschreibt in erster Linie seine Entwicklung eines webkompatiblen AVB-Controllers.

    Dies darf der allgemeine AVB/TSN-Thread werden.


    Und ich möchte zu allererst das Wichtigste wiederholen - sind ja alles keine neuen Infos, nur in meinen Worten niedergeschrieben:

    AVB/TSN beschreibt Netzwerkstandards. Von Audioübertragung ist hier nicht die Rede.

    AVB/TSN kümmert sich darum, dass Daten zu einer definierten Zeit durch ein Netzwerk hindurch zugestellt werden und ist daher (nicht nur) für Echtzeit-Audio-Anwendungen besonders gut geeignet.

    Eine Besonderheit von AVB/TSN ist, dass die Nutzdaten im Datenframe transportiert werden und nicht im Datenpaket. Ergo AVB/TSN definiert Standards auf OSI Layer 2.

    Die Nutzdaten werden durch AVB/TSN nicht definiert, deshalb sind die Hersteller (noch) nicht kompatibel. Die erste Allianz für die Standardisierung ab Layer 3 aufwärts ist Milan.


    Als nächstes könnte ich anfangen die Vorteile von AVB/TSN zu predigen, aber auch das sind ja keine neuen Infos, sondern die üblichen Argumente dieser Hersteller. Bei konkreten Fragen kann ich versuchen zu antworten, meine letzte intensive Beschäftigung mit dem Thema ist aber etwa ein Jahr her.


    AVB/TSN Thread: let's fetz.

    Pragmatisch. Praktisch. Gut.

  • Hallo


    Meiner Meinung nach ist Milan eine Totgeburt.


    1. Wir wollen ja Netzwerktechnik damits günstiger wird. Das erreichen wir mit dem nutzen von IT Hardware. Diese ist so günstig weil sie millionenfach verkauft wird. Ein AVB Switch ist da leider mehr ein Audio/Video Gerät, und wir verlieren genau diesen Vorteil.

    2. Wenn wir uns das ganze mit Netzwerk schon antun, dann doch gleich Layer3 und nicht Layer2. Klar, momentan kann ich Dante noch nicht übers Internet verschicken, aber in 10 Jahren wird man es können. Die Layer3 Technologie hat hier keine Grenze, warum auf eine Layer 2 Technologie setzten die mich in 10 Jahren gegen eine Mauer laufen lässt?

    3. Ich hab das mit der Bandbreitenreservation mal getestet: Hat nicht funktioniert. Wir konnten die AVB Streams abschiessen. Da ist eine Layer3 Technologie (Dante/Aes67) mit korrektem QOS momentan wesentlich stabiler.

    4. Wieviele AVB Geräte gibt es? 15? Dante verkauft momentan ca 4000 Module täglich (!!).

    5. Dante Domain Manager: Wow. Security, Userverwaltung, Logs, Alerts. AVB ist in sachen Usability noch ca 3 Jahre vom Dante Controller und sicher 10 Jahre vom Dante Domain Manager entfernt.

    6. Ich möchte bestehende IT Netzwerke nutzen. Ich möchte Subnets und die ganzen Tools der IT Nutzen, für Überwachung und Control. Geht mit Layer3 Netzwerken. Mit Layer2 leider nicht.

    7. AES67 ist Teil von SMPTE2110. Video diktiert den Markt.


    Klar ein paar PA Hersteller schreiben AVB auf der Homepage, und vielleicht werden in den nächsten paar Jahren auch ein paar Verstärker durch Controller über AVB angesteuert, aber das wars dann auch....


    Liebe Grüsse

    Einmal editiert, zuletzt von gemini ()

  • Offenbar weißt du nicht alles :/..


    Nur QOS ist die Bandbreite nicht garantiert, die Möglichkeit das der Queue überläuft ist gegeben.


    Das behebt das SRP(Stream Reservation Protocol).. Bandbreite und Latenz ist somit garantiert !


    Es fällt natürlich leichter etwas zu entwickeln wenn man die Hardware kennt. So hat man nur mit seinen Bugs zu kämpfen. Ich sehe in Dante er die Gefahr das man sich abhängig macht von dessen Preis und Lizenzpolitik. Nun stelle sich einer mal vor das gleiche was Huawei passiert ist trifft eine Firma aus Deutschland.


    Was kostet denn der Dante Domain Controller ? Schon mal geschaut !? All das was mein Controller Projekt auch kann für 0€ .


    AVB/TSN wird sich durchsetzen wenn sich dafür in den Consumer Geräte Anwendung finden. Für Dante kein Markt wie die Anwendung in der Industrie. Dieser Markt ist bedeutend größer als dem in dem sich Dante je befindet. Man hat sich sich ja aus der IEEE auch nur das heraus gefischt was man gebrauchen konnte. So fremd sind die Protokolle eben doch nicht.


    Man hat AVB/TSN auch nachgebessert, z.bsp ist es möglich auch streams per real Time stream protocol(RTSP) per UDP zu versenden oder in einen Stream zu verpacken.


    Das ermöglicht mir z.Bsp einen Stream per (RTSP) an einen Browser zu senden ! Du kannst also in den Stream herein hören :huh:...

    Einmal editiert, zuletzt von marcoboy ()

  • Hey Marcoboy


    Nein sicher weiss ich nicht alles, würd ich nie behaupten, aber das Thema interessiert mich stark.


    QOS schützt nicht gegen gleichartige Streams, die Bandbreite ist nicht garantiert, aber gegen Filetransfers und andere Sachen im Netzwerk sind die Streams geschützt. Wenn ich ins Risiko laufe mehr als 500 Kanäle pro Link zu haben, dann muss ich auf 10Gig Links upgraden, bei Standard IT Switches keine teure Sache.


    Bezüglich AVB Switches: Klar ist es toll, eine genau definierte Umgebung zu haben, die Frage ist halt ob das soviel Wert ist. Denn eigentlich wollen wir ja genau keine Switches entwickeln, sondern die von der IT benutzen. Eine Audiomatrix ist auch was tolles, da muss ich mich nicht mal um Netzwerk kümmern und kann sogar ein und Ausfaden.


    Der Dante Controller ist Gratis, Dante Domain Manager gibts ab 2000 Euro.

    Wenn dein Controller Projekt Userverwaltung, InterSubnetRouting, Logging, Snmp, Email, Ldap und das alles in voll redundant und mit übersichtlichem Userinterface kann bin ich der erste der bestellt. (Soll nicht abwertend sein, ich verfolge den Thread mit deinem Controller Projekt mit grösstem Intresse, dein Effort und Wissen ist absolut bewundernswert, aber in Sachen usability ist hat Dante einfach ein paar Entwicklungsjahre Vorsprung)


    Wer hat was aus welchem IEEE Standard rausgefischt?


    Wir reden hier nicht nur von Dante, wir reden von jeglichen AES67 kompatiblen Layer3 Technologien. Einen AES67 Stream kann ich im VLC Player empfangen, sogar discovery funktioniert, weil hier einfach IT Standards verwendet wurde.


    Grüsse

  • Das meinte ich schon weiter oben ich packe dir ein AES67 als RTP mit rein. Das ist auch konform, wenn sich zwei finden die damit umgehen können.


    AVB ist die Mutter von allem :D... Das war ja der Sinn von AES67, mein einigt sich auf einen gemeinsamen Nenner...


    Nachzulesen hier http://www.aes.org/publication…dards/search.cfm?docID=96 und auch bedeutend günstiger.


    Es wäre kein Problem auch das discovery für AES67 Geräte aufzunehmen nur das Problem ist die Geräte sich in der AES67 Welt nicht einmal sehen ! Der Grund ist das sie unterschiedliche Discovery Verfahren verwenden. An der stelle bitte einmal laut lachen :D:D:D.. Es braucht einen Vermittler oder der Stream muss manuell initiiert werden.


    edit: ich nehme den Ansatz mal mit auf, ein Feld in der Antwort für den Typ das Gerätes -> AVB,AES67,Milan oder Dante.

    2 Mal editiert, zuletzt von marcoboy ()

  • Wieso soll AVB günstiger sein als AES67?


    Bezüglich Discovery: Korrekt, Discovery ist im AES67 Standard nicht definitiert, aber der Shakeout hat bereits stattgefunden, SAP und Bonjour sind die Gewinner, die meisten Geräte können beides, ansonsten gibts für den Notfall den RAV2SAP konverter.

    Mit NMOS ist sogar schon ein Steuerprotokoll für die ganze Geschichte am Horizont.

  • Ein weiteres Problem ist das die Steuerung der Geräte nicht wie in der IEEE 1722.1 standardisiert wurde.


    Es gibt hier mehre Richtungen, eine ist AES70 https://www.ocaalliance.com/ entsprechend hier nachzulesen https://www.ocaalliance.com/standards-specifications/


    Unter Dante gab es mal die Erwägung AVB kompatible zu sein, das wurde recht schnell wieder verworfen. Vermutlich wegen dem IEEE 1722.1 Problem.


    Selbst mit einem Dante AES67 Stream könnte ein AVB Gerät umgehen, das Problem ist nur wie finden sich die Geräte und initiieren den Stream !?


    In der IEEE 1722.1 ACMP initiiert der Listener den Stream, dessen Firmware müsste damit umgehen können. Technisch müsste der Controller eine Brücke bilden und prüfen ob sich die Geräte überhaupt verbinden lassen.

    Was müsste der Anwender wissen ? Der Hersteller müsste seine Konfiguration als AES67 konform kennzeichnen bzw. hinterlegen.


    Mein Controller und dessen API könnte mit unterschiedlichen Mechanismen umgehen...

  • Hmm also ich habe aus Interesse heraus diese Veranstaltung besucht https://www.proaudio.academy/index.php/naechstes-seminar.


    Wirklich informativ fand ich die Beiträge von Andreas Hildebrand (ALC) und Stefan Ledergerber (Simplexity).


    Zumal ich Festellen musste ich mich mit meinen Projekt der von NMOS https://amwa-tv.github.io/nmos/ nicht so weit entfernt liege.


    Daraus hat sich ergeben das ich darüber nachdenken werde die AVB Geräte in einer NMOS Node zu Verfügung zu stellen. Um Geräte auch außerhalb der AVB Wolke zu koppeln müssten diese aber ein Streamformat implementieren welches RTP Streams auf UDP Basis anbietet. Genau das lässt der AVB Standard ja zu und ich werde dies in den xmos Stack einbauen. Schauen wir mal, in wie weit es gelingt AVB und AES67 Geräte per Flow zu verbinden.


    Der Beitrag über AVB/Milan war er eine Enttäuschung, das man unter Milan gegen den IEEE Standard arbeitet ist von mir zu verurteilen. Milan sollte auf den Standard aufsetzen und in diesen zugelassene Erweiterungen nutzten. Für mich unklar warum man Header vom Protokoll eigenständig entgegen dem Standard verändert.


    Das Controller Projekt "Hive" wird hochgelobt und dessen stellt er einige Dinge gar nicht oder nur unzureichend zur Verfügung. Der Standard hat mehr zu bieten als "Audio" Nur mein Projekt scheint der einzige Controller zu sein der auch mit "Video und Sensor" Units klar kommt und außerdem "control" vollständig unterstützt. Da mögen die RME Geräte dies auch unterstützen, es bringt nichts wenn kein Controller die Descriptoren und die Möglichkeiten zur Verfügung stellt.


    Für mich war der Besuch der Veranstaltungen Motivation an dem Thema dran zubleiben und vor allen auch Ideen von Projekten aus der Praxis mitzunehmen. Um sie natürlich in mein Projekt umzusetzen :D..