Allen & Heath SQ-5-6-7-Rack - Fragen, Tipps und Tricks

  • Kann sein, weis ich nicht, hat funktioniert. Ob das sicher war, Zufall oder nur Fahrlässig von mir ... keine Ahnung. Deshalb stand ja ein Rechner an der Bühnenkante. Nachdem die alternative war von neben der Bühne zu mischen haben wir das damals auf einen Versuch ankommen lassen. War in dem Fall kein Problem.


    Seither war ich nicht mehr in der Situation. Mittlerweile hat aber auch schon fast wirklich jede Venue ein Netzwerkkabel verbaut.

  • Wenn man sich mal das Hardware-Layer von AES50 / sLink und co anschaut arbeitet da faktisch einfach ein stink-normales 100 MBit/s Ethernet drunter. Die Kommunikation findet aber halt auf unterster Ebene direkt mit Ethernet-Frames statt anstatt da noch weiteres wie IP-Protkoll etc. zu machen.


    Das ist sowohl bei AES50 als auch bei dem dSnake Protokoll etc. so. Behringer / Allen&Heath verwenden da stink-normale Ethernet-Chips zur Kommunikation von Marvell, Microchip und co. Von daher tue ich mir schwer wenn jemand schreibt "dSnake ist viel robuster als AES50 etc." - das glaube ich nicht.


    Der zusätzliche Unterschied bei AES50 ist einfach, das Behringer zwei weitere Adernpärchen noch nutzt um die Audio-Clock mit drüber zu senden, während Allen&Heath die Audio-Clock indirekt in der Ethernet-Kommunikation einbettet ähnlich wie bei Dante.

    Normale Ethernet-Kabel haben standardmäßig 100 Ohm Wellenimpedanz. DMX-Kabel sind bei 110. Das ist nicht so der große Unterschied. Daher glaube ich das gerne, wenn man mit einem Ethernet-XLR Adapter so ein 100 MBit Netzwerk über ein altes Multicore senden kann... Grad 100 MBit Ethernet verzeiht da doch verdammt viel.

    Meines Erachtens gehört die Signalverarbeitung aber einfach wirklich auf die Bühne inzwischen. Verstehe nicht warum man die Audio-Signale immer noch zwischen FOH und Bühne hin- und hersendet...

    Auch das ACE aus der iLive war einfach nur normales 100 MBit Ethernet... Es gab da sogar Versuche von Hobbyisten das Protokoll zu entschlüsseln wo man inzwischen Dokumentation dazu auf GitHub findet
    GitHub - PatrLind/ah_ace_protocol: ACE protocol description for Allen & Heath digital mixing systems

  • Von daher tue ich mir schwer wenn jemand schreibt "dSnake ist viel robuster als AES50 etc." - das glaube ich nicht.

    glaube und erfahrungswerte differieren von zeit zu zeit ;)


    es ist ja mittlerweile durchaus bekannt, dass AES50 durchaus wählerisch ist, welche kabel da verwendet werden. diese "zickigkeit" ist von S-Link nicht bekannt.

    und mit GigaACE habe ich selbst sogar mal die erfahrung gemacht, dass es selbst über völlig gegen jede norm verkabelte netzwerkverkabelungen (das hatte der russische maler installiert :) ) funktionieren kann.

    so gesehen stehe ich zu meiner aussage: wenn eine kabelverbindung mit AES50 funktioniert, dann geht es definitiv auch mit S-Link.

    mit kollegialen Grüßen
    Wolfgang

  • Es ist bekannt, dass AES50 besonders anspruchslos gegenüber den Kabeln ist, auch wenn ein einzelner Forianer hier das anders sieht, allerdings ist die Wahrscheinlichkeit, dass die typische Anwendergemeinde von x32 mit ungeschirmter 'Haushaltsware' hantiert, besonders groß. ;)

  • Das ist sowohl bei AES50 als auch bei dem dSnake Protokoll etc. so. Behringer / Allen&Heath verwenden da stink-normale Ethernet-Chips zur Kommunikation von Marvell, Microchip und co. Von daher tue ich mir schwer wenn jemand schreibt "dSnake ist viel robuster als AES50 etc." - das glaube ich nicht.

    Mag ja sein, dass du es nicht glaubst, es ist aber trotzdem so.
    Und ich will damit nicht sagen, dass AES50 nicht robust ist.
    Aber damit hatte ich noch keinen Erfolg bei Kabellängen über 100 m, mit GigaACE schon.

  • Es ist bekannt, dass AES50 besonders anspruchslos gegenüber den Kabeln ist, auch wenn ein einzelner Forianer hier das anders sieht,

    Es zickt mehr und öfter als das ganze andere Zeug.
    Aber trotzdem wird es seltener, man hat sich darauf eingestellt.

  • Ok - fairerweise muss ich zugeben, dass ich das mit AES50 schon öfters gehört habe.

    Ich bleibe aber dabei, das ich sagen würde es liegt nicht an der eingebetteten Ethernet-Verbindung bei AES50 sondern vermutlich eher an der Art und Weise wie bei AES50 das Clock-Signal noch über die anderen Adernpärchen gelöst ist und -ich vermute- dort die Probleme mit Abschirmung und co stattfinden weil die Synchronisation kaputt geht.


    Ich für meinen Teil hätte mal gerne verstanden wozu Behringer überhaupt die Word-Clock separat übertragen muss bei AES50, wenn das A&H auch ohne separate Clock-Verteilung hinbekommt.

  • Es ist bekannt, dass AES50 besonders anspruchslos gegenüber den Kabeln ist, auch wenn ein einzelner Forianer hier das anders sieht, allerdings ist die Wahrscheinlichkeit, dass die typische Anwendergemeinde von x32 mit ungeschirmter 'Haushaltsware' hantiert, besonders groß. ;)

    im letzten frühjahr hatten wir in einer unserer hallen ein konzert mit fremdmischer. der hatte versucht, seine AES50 verbindungen über die im saal verlegten CAT6 kabel zu machen - doch es hat nicht funktioniert.

    da ich selbst an diesem tag nicht da war kann ich allerdings nicht sagen, ob er hierzu eigene "haushaltsware"-patchkabel benutzt hat. er hat dann auf jeden fall eigene CAT kabel verlegt, mit denen es dann klappte.

    also irgendwas ist an der geschichte schon dran.

    mit kollegialen Grüßen
    Wolfgang

  • Es liegt einfach daran, dass die Grenzfrequenz für Cat 5 eigentlich zu hoch ist. Von Midas wurde hier mal ne Spec gepostet. Bei Gigabit verteilen sich die Daten auf mehrere Paare. AES50 dagegen überträgt den Stream über ein Paar.

    ?

    100Base-TX, was als Basis bei AES50 und dSnake z.B. dient hat spektral eine Bandbreite die bis 31.25 MHz geht. Es gibt ein Adernpärchen in je eine Richtung. Also Full-Duplex.
    Würde man mal grob die Bandbreite ausrechnen die da drüber läuft (Ohne den Overhead von z.B. Pre-Amp-Steuerung etc.), also 48Ch*24Bit*48000 kommt man da bei ca ~ 55 MBit/s raus. Das ist jetzt noch gemütlich weit entfernt von der maximalen Kapazität des Links.
    Normales CAT5 glaube ich kann ja spektral bis 100 MHz Bandbreite.

    Was über die anderen zwei Adernpärchen gesendet wird, weiß ich nicht ganz, da ich es nie gemessen habe, aber ich vermute es ist einfach ein 48 kHz Rechteck-Signal was als Synchronisations-Referenz dient.
    Ich denke, dass es da die Schirmung braucht, weil eventuell das Rechteck-Signal sonst zu stark einstreut auf die Eth-Datenpärchen einstreut oder es irgendwie Ground-Offset-Probleme gibt.

    Wäre eigentlich mal interessant, dem nachzugehen.