Zwei Pulte, ein Protokoll und trotzdem unterschiedliche CAT-Kabeleigenschaften erforderlich?

    Mal ne Zwischenfrage an die Netzwerkexperten: Macht es hier eigentlich einen Unterschied ob Traffic auf dem Kabel ist, also wirklich aktive Kanäle wo Audiodaten drüber laufen, oder reicht es für so einen Test einfach nur Alles zusammen zu stecken und quasi im "Leerlauf" zu testen? Oder simuliert das Pult für diesen Test selbst einen Datenstrom? Fände ich mal interessant zu wissen.

    Wenn ich halt an meine Koax-welt damals beim Kabelfernsehen zurück denke, da macht es sehr wohl einen Unterschied, wie viele Kanäle und Nutzer da gerade aktiv sind, was sich dann auf den max. Pegel, Grundrauschen usw. auswirkte. Mit Netzwerk / Cat kenne ich mich halt nicht wirklich aus, daher die Frage.

    Jede aktivierte Verbindung erzeugt auch Traffic. Digital sollte der pro Verbindung gleich sein. Mehr Verbindungen = mehr Traffic... so wie beim Kabelfernsehen. Würde mich wundern, wenn das bei AES 50 anders wäre.

    Mit anderen Worten, Du mußt schon die Kanäle miteinander verbinden und erzeugst dann damit eine Last.

    Gruß
    Marcus

    Zitat von Marcel

    Mal ne Zwischenfrage an die Netzwerkexperten: Macht es hier eigentlich einen Unterschied ob Traffic auf dem Kabel ist, also wirklich aktive Kanäle wo Audiodaten drüber laufen, oder reicht es für so einen Test einfach nur Alles zusammen zu stecken und quasi im "Leerlauf" zu testen? Oder simuliert das Pult für diesen Test selbst einen Datenstrom? Fände ich mal interessant zu wissen.

    Wenn ich halt an meine Koax-welt damals beim Kabelfernsehen zurück denke, da macht es sehr wohl einen Unterschied, wie viele Kanäle und Nutzer da gerade aktiv sind, was sich dann auf den max. Pegel, Grundrauschen usw. auswirkte. Mit Netzwerk / Cat kenne ich mich halt nicht wirklich aus, daher die Frage.

    Interessante Fragestellung.

    Aus dem Bauch heraus würde ich bei AES50 aber darauf tippen, dass die Audiodaten aller 48/24 Kanäle immer als vollständiger serieller Stream geschickt werden, unabhängig davon ob die Kanäle Nutzdaten enthalten oder nicht. Die Bandbreite ist ja fix - man spart also nichts, wenn nur die realen Nutzdaten geschickt werden und ein erneutes Senden von fehlerhaften Daten findet auch nicht statt.

    Ich würde mich freuen, wenn jemand dazu genaueres beisteuern könnte.

    Hinweis: Alle Fehler in diesem Beitrag sind KI-generiert.

    Zitat von HenrySalayne

    Interessante Fragestellung.

    Aus dem Bauch heraus würde ich bei AES50 aber darauf tippen, dass die Audiodaten aller 48/24 Kanäle immer als vollständiger serieller Stream geschickt werden, unabhängig davon ob die Kanäle Nutzdaten enthalten oder nicht. Die Bandbreite ist ja fix - man spart also nichts, wenn nur die realen Nutzdaten geschickt werden und ein erneutes Senden von fehlerhaften Daten findet auch nicht statt.

    Ich würde mich freuen, wenn jemand dazu genaueres beisteuern könnte.

    Soweit ich mich erinnern kann, wird bei AES50 ein PCM Stream gesendet und keinerlei Kompression verwendet. Daher würd ich jetzt auch meinen, dass das Signal keinen Einfluss auf den Traffic hat. Die Größe einer PCM Datei ändert sich ja auch nicht egal ob Stille, Rauschen oder sonst irgendwas. Interessant ist aber ob die Bandbreite der 24/48 Kanäle immer reserviert ist, auch wenn nicht alle Kanäle gepatcht sind. :/

    Hier

    AES Standard » AES50-2020: AES standard for digital audio engineering - High-resolution multi-channel audio interconnection

    gäbs sicherlich mehr Informationen, aber halt nur gegen Geldeinwurf

    Ich zitier mal die genannte Norm zumindest aus der Fassung AES50/2011 - Kapitel 6.2,

    Each frame data payload (see 5.8) shall contain 352 consecutive and concurrent bits of all 26 LC*s.

    *LC - logical Channel

    Wobei es 24 Audio Kanäle und 2 Kanäle mit Zusatzinformationen sind.

    24 of the LCs shall be allocated for audio data transfer, and the remaining 2

    LCs shall be allocated for auxiliary data transfer

    Wenn ich das aus dem richtigen Zusammenhang gerissen habe dann scheint tatsächlich immer die gleiche Anzahl Bits/Bytes je Frame übertragen zu werden, unabhängig von deren Inhalt (ggf. Stille weil nicht genutzt).
    Also volldigital - spielt mit einer Kabelverbindung, oder eben nicht,
    unabhängig von der genutzten Kanalanzahl.

    Trust it - tilt it! Der universlle Neigeadapter für AV-Geräte auf Traverse: http://www.trusstilt.de
    Analog über Cat Lösungen und Anschlussfelder für Ampracks: http://www.cat-core.deNächster Messeauftritt: 6.-8.10.26 in Hamburg: https://leatcon
    PA-Forums-Treffen: täglich 13:00 bei mir am Stand A2/F06

    ganz vereinfacht:

    ...wenn nix angesteckt is, was Töne erzeugt, rasen lauter Nullen durch den reservierten Audio-Kanal im Kabel - wenn Ton reingeht sind's halt Nullen und Einsen...

    "geht nicht" ? - gibt's nicht !

    ...ja, das war schon immer mein Avatar :evil:

    "Mit der Dummheit kämpfen Götter selbst vergebens" (Friedrich Schiller, "Jungfrau von Orleans" )

    Also so oder so - sobald so eine AES50-Verbindung steht, fließen da Daten für 48 Kanäle in jede Richtung (bei 48kHz jedenfalls, bei 96kHz halt 24 Kanäle - ist aber die gleiche Datenmenge).

    Das Gleiche gilt auch für viele andere Verbindungen. MADI hat immer 56 oder 64 Kanäle. Bei DANTE läuft immer das, was im Dante Controller gepatcht wurde.

    Je nachdem, was dann am anderen Ende dran hängt, gibt's dann echtes Signal (also Grundrauschen oder gar Nutzsignal) oder tatsächlich digital 0. Bei ner S32 z. B. müssten die letzten 16 Kanäle erst mal digital 0 sein. Bei den Returns halt je nachdem, wie die Outs im Pult gepatcht sind.

    Je nach Kanalkodierung kann das vielleicht mal einen Unterschied machen, wobei die meisten Kodierungen versuchen, das Signal gleichspannungsfrei zu übertragen, und schon von daher ein mehr oder weniger regelmäßiger Wechsel zwischen Nullen und Einsen auf dem Kabel auch bei einem Digital-0-Signal passiert. Ich würde auch eher davon ausgehen, dass ein Signal mit wenig Zustandswechseln auf dem Kabel problematischer ist, da dort die Synchronisierung zwischen Sender und Empfänger tatsächlich schwieriger ist (waren das jetzt 11 oder 12 Nullen?).

    Wie auch immer - der Unterschied dürfte, wenn es denn überhaupt einen gibt, nur im absoluten Grenzbereich eine Rolle spielen. Da sollte man seine Systeme eh nicht betreiben.

    Zitat von MiFa1969

    8 Stunden Test mit 70m + 20m, verbunden mit dem billigen Neutrik:

    Ich habe heute morgen auf die Firmware 3.0.6-27 aktualisiert.

    Jetzt bekomme ich mit dem Aufbau vom 29.04.25 innerhalb einer Stunde unglaublich viele Fehler.

    Ich habe an dem Aufbau nichts verändert, da ich das Pult seither nicht gebraucht habe.

    Ist das jetzt Zufall? Mit den 90m Kabel + einem Verbinder bin ich ja aus der Spezifikation raus.

    Aber warum hat dass das letzte mal ohne ein Problem funktioniert?

    Ich habe dann mal die 20m und den Verbinder weg gemacht. Also nur mit den 70m am Stück getestet. Da ist jetzt seit 2 Stunden alles gut.