Beiträge von TWOsider

Vielen Dank an alle für die guten Rückmeldungen zum Thema!

Ich fang mal vorne an, der Reihe nach:

• Das das Yamaha RMio64-D auf dem Brooklyn II basiert ist mir beim Lesen der Anleitung tatsächlich durchgerutscht. Danke für den Hinweis, damit fällt das Gerät also raus. Meinen Post oben habe ich entsprechend um diese Information ergänzt.
• Digico Orange Box in Verbindung mit DMI Dante 64@96 und DMI MADI B hatte ich nicht auf dem Schirm, auch hier danke für den Tipp. Laut dem Handbuch [1] ist eine Ratenkonvertierung möglich in der DMI Dante, der Einbauort (linker oder rechter Slot) bestimmt welche Clock für wen zählt. Möglicher Modus für die Anwendung ist die DMI Dante im linken (Master) Slot und dort wählt man dann SRC mit 48k aus, die DMI MADI im rechten (Slave) Slot bekommt dann von links ihren (48k)-Takt und von dort ginge es ans Fireface. Für die Live-Richtung aus den Octamics ins Pult bräuchte man noch ein weiteres unabhängiges Gerät, aber ok, ist ja kein Nachteil das räumlich trennen zu können.
• 2 Laptops mit jeweils DVS - ja, das IT-Herz in meiner Brust sagt "das wird auch gehen", aber die Aufnahme ist essentiell wichtig und durch zwei Laptops hätte man die Ausfallwahrscheinlichkeit mindestens verdoppelt, von unbeabsichtigten Konfigurations- oder Routingfehlern mal abgesehen. Ich möchte an so vielen Stellen wie möglich (Pult-Ausgangsrouting, Dante-Controller, MADI, Fireface) einen simplen 1:1 Patch, den jeder verstehen kann.
• AHM64 hat nur einen Slot, da geht also leider keine Adaption Dante <> MADI, nur jeweils auf eines der Allen&Heath Protokolle über SLink oder? Ob man zwei AHM64 über den SLink koppeln kann und ob es eine MADI-Karte dafür gibt (SuperMADI scheint zu groß vom Formfaktor) weiß ich nicht.

Eine SQ5 ist vorhanden, auch bereits inkl. Dante-Karte, eine Avantis (als Upgrade von GLD80 und GLD112) hatten wir schon als Demo da und die ist so gut wie gekauft. Nach dem ich die Beiträge von Steffen R gelesen habe, ergeben sich für mich nun zwei Ansätze:

• Avantis, voll bestückt mit SuperMADI- und Dante-Karte. Aus der SuperMADI optisch oder mit BNC ins Fireface in der Nähe des Pults, als Bonus vier unabhängige Preamps dort gewonnen. Kupfer nach vorne für DX und Dante, eine der Spielstätten ist da hervorragend ausgestattet. Im Cut Sheet [2] steht "sample rate and redundancy are switchable per link pair", wie auch schon von Steffen R geschrieben wird damit alles möglich. Entweder man zieht nochmal MADI nach vorne für die Octamics oder es kommt noch einer der genannten Konverter dazu, der Fall 32 Kanäle bei 96k von MADI auf Dante zu adaptieren war ja nicht das Problem für die genannten Geräte oben.
• Doch eine dLive mit DM0, an beiden Enden je eine SuperMADI, in der DM0 zusätzlich eine Dante-Karte für die Ausspielwege. Fireface wie bei der Avantis, alles geht.

Preislich ist die Avantis-Lösung vermutlich noch vor der Orange Box, da wird es denke ich hingehen. Danke nochmals & viele Grüße

Joern

[1] https://digico.biz/wp-content/…4/OBC-User-Guide-V2.7.pdf

[2] https://www.allen-heath.com/media/superMADI-Cut-Sheet.pdf

Werte Kollegen,

gesucht ist eine Lösung, um vorhandene, verteilte MADI-AD-Wandler (RME Octamic XTC) in ein Live-Setup zu integrieren, das auf Dante basiert. Pulte (Allen&Heath SQ5 / Avantis), PA-Controller (Seeburg HDLM8) / Amps (Lab PLM12K44) laufen intern alle nativ auf 96 kHz, somit läuft auch das Dante-Netzwerk sinnvollerweise auf 96k. Gleichzeitig soll ein Recording von rund 45 "Live"-Kanälen sowie von ein paar wenigen "nicht-Live"-Spuren (Atmos, Kommentare, Regie) stattfinden. Dafür ist ein RME Fireface UFX+ vorhanden, das direkt auf eine per USB angeschlossene Festplatte aufzeichen kann ("DURec"). Eine Aufzeichnung in 96k ist aus mehreren Gründen nicht angesagt:

• Verwertung der Aufzeichnung erfolgt ohnehin in 48k (Internet bzw. tatsächlich noch DVD).
• Ins Fireface geht es per MADI, da gehen bei 96k bekanntermaßen nur 32 Kanäle -> zu wenig.
• Dante Virtual Soundcard für schmales Geld kann bei 96k ebenfalls nur 32 Kanäle -> zu wenig.

Die Lösung mit dem vorhandenen Fireface ist auch insofern unschlagbar, weil sie den Modus "Einschalten, Knopf drücken, Aufnahme läuft" ermöglicht und niemand sich mit einem Computer rumärgern muss. Ja, für Computer gäbe es natürlich Yamaha AIC128-D oder Focusrite, SSL, oder eine andere gebrandete Audinate PCIe-Karte mit 128 Kanälen bei 96k, aber ein Computer soll wenn möglich vermieden werden Soweit die Ausgangslage.

Grafisch dargestellt sieht es wie folgt aus: Es ist eine Hardware gesucht, die den großen Kasten in der Mitte ausfüllen kann. Eigene Recherche ergab folgende Liste an Geräten, leider ist keines davon vollständig geeignet. Im Folgenden steht immer <Kanäle>@<Samplerate> in Kurzform.

Appsys Multiverter (mit SRC-64)

Live MADI 32@96 -> Dante 32@96:

• Sollte gehen.

Recording Dante 64@96 -> MADI 64@48:

• SRC-64 kann grundsätzlich 64@96 nach 64@48 wandeln (Handbuch [1] Seite 16)
• Aber: Dante-Interface im Multiverter akzeptiert leider nur 32@96 (Handbuch [2] Seite 44) -> zu wenig
• 2x MADI 32@96 nach Dante 64@48 ginge, aber das ist die falsche Richtung

DirectOut EXBOX.MD

Ferrofish Verto MX / Pulse16 DX / A32 Dante

RME Digiface Dante

SSL MADI-Bridge

Live MADI 32@96 -> Dante 32@96:

• Sollte gehen.

Recording Dante 64@96 -> MADI 64@48:

• Geht nicht, kann nur 32 Kanäle bei 96k verarbeiten -> zu wenig.
• In der Regel keine SRC vorhanden.
• Überall wo ein Brooklyn II verbaut ist, geht es nicht. Die Beschränkung auf 32@96 kommt daher [3].

Yamaha RMio64-D

Recording Dante 64@96 -> MADI 64@48:

• Sollte gehen, zumindest das Blockschaltbild im Handbuch [4] auf Seite 22 legt nahe, dass das Gerät 64 Kanäle bei 96k per Dante am Eingang akzeptiert und die mittels SRC auf 48k bringen kann. Kann jemand bestätigen, dass diese Konversion mit dieser Kanalanzahl (64@96 am Eingang) geht? Wir hatten das Gerät schonmal vor ca. 2 Jahren im Einsatz bei einer Produktion, allerdings damals mit einem reinen 48k-Setup, sowohl auf der MADI- als auch auf der Dante-Seite und das lief natürlich.
  Information von schurik: Basiert auf Brooklyn II, d.h. nur 32 Kanäle bei 96 kHz.

Live MADI 32@96 -> Dante 32@96:

• Geht vermutlich nicht, wenn gleichzeitig die Recording-Konversion aktiv ist. Zwar schreibt das Handbuch [4] auf Seite 15 "you can output MADI with a different word clock than the MADI input", aber ich hätte gerne den MADI Ausgang (zum Fireface) auf 48k und den MADI Eingang (von den Octamics) auf 96k. Das Diagramm auf der gleichen Seite zeigt als mögliche Quellen für die Clock am Ausgang entweder "same as word clock source" (= Dante 96k, das will ich nicht) oder "same as input clock source" (= MADI 96k aus den Octamics, das will ich auch nicht).
• Es gibt noch einen extra Word Clock Eingang nur für die SRC, aber das sieht auf dem Bild so aus, als würden dann beide Richtungen der SRC mit dem gleichen Takt laufen, ich brauche die beiden Richtungen aber unabhängig bzw. in die Richtung MADI -> Dante eigentlich gar keine SRC. Und die Quelle für die Clock am Ausgang kann laut Handbuch nur per Remote Control umgeschaltet werden; dass möchte ich auch nicht, da wir keine Yamaha-Geräte haben, die das können.

Das Ergebnis der eigenen Recherche ist im Moment leider, dass es zweierlei Gerät bedarf. Den Yamaha für die Recording-Richtung und einen zweiten oder ein anderes Gerät für die Live-Richtung.

Habe ich irgendwo einen Denkfehler? Sieht jemand noch eine Alternative oder hat andere sachdienliche Hinweise?

Danke & viele Grüße
Joern

[1] http://www.appsys.ch/downloads/SRC-64/SRC-64_en.pdf

[2] http://www.appsys.ch/downloads/MVR-64/MVR-64_en.pdf

[3] https://assets.audinate.com/wp…ooklyn_II_6-july-2016.pdf

[4] https://usa.yamaha.com/files/d…2662/rmio64d_en_om_d0.pdf

Zitat von &quot;audi&quot;

Mit dem GLD wären immerhin auf der Bühne 40 Inputs möglich AR2412 + 2xAR84. Damit könnte ja man sogar Dinge machen wie links 24 Inputs und rechts halt die 16 Inputs aufstellen

Richtig. Du musst dafür wie gesagt zwei CAT-Strecken vom Pult zur Bühne legen. In deinem Beispiel eine nach links zur AR2412 (Kanäle 1-24) und eine nach rechts zur AR84 (Kanäle 33-40). Für die zweite AR84 (Kanäle 25-32) auf der rechten Seite benötigst du eine weitere, kürzere CAT-Strecke von der linken zur rechten Bühnenseite.

Je nach konkretem Bedarf kann das GLD-System hier durch die in kleinen Häppchen absetzbaren Preamp/Wandler-Boxen einen Vorteil haben, evtl. ist man aber mit analogen Submulticores und einer zentralen iDR aber schneller auf Sendung. Auch für die iLive gibt es Expander namens xDR-16, falls du auf analoge Submulticores verzichten möchtest.

Zitat von &quot;audi&quot;

4 Inputs wären drahtlos, man könnte also die Empfänger direkt am FOH aufstellen und am GLD auflegen.

Auch richtig. Bedenke aber: Falls du ein Talkback benötigst, verringert sich die Anzahl der am Pult nutzbaren Eingänge effektiv auf 3. iLive-Pulte haben dafür einem zusätzlichen Eingang auf der Bedienoberfläche, GLD nicht. Hier musst du einen der regulären Eingänge "verbraten" (krumme Konstruktionen wie externer Preamp an einen der Line-Eingänge mal ausgenommen).

Zitat von &quot;wora&quot;

abhörmöglichkeiten innerhalb des kanalzuges per Sel-tasten

Das geht auch bei der GLD. Die anderen Punkte sind teilweise abhängig von der gewählten iDR/AR bzw. dem Surface. Eine iDR-16 mit T80 hat z.B. weniger (physikalische) Eingänge als GLD80 mit AR2412 und auch weniger Bedienelemente, aber das sollte klar sein. Nur der Vollständigkeit halber :wink:

Preamps und Wandler sind sicherlich andere als im iLive-T bzw. als in der modularen iLive, ich verweise da mal quer auf meinen eigenen Betrag:
http://www.paforum.de/phpBB/viewtopic.php?p=720901#p720901
Qualitativ wird man da im Live-Betrieb keinen wesentlichen Unterschied feststellen; andere Faktoren haben einen viel größeren Einfluss. Man muss auch sehen, dass die GLD das jüngste Produkt im Vergleich ist, da hat man bestimmt andere Bauteile genutzt. Wir haben kürzlich auch mit der noch kleineren Qu16 und einer AR2412 als Preamp und Wandler ein Live-Recording mit Analog-Split durchgeführt, da gab es beim Mixdown später im externen Studio auch keine Klagen was die Qualität der Aufnahme angeht.

Falls du beim Thema "Mixbusse" auf die Summierung hinauswillst und auf die Frage, wie viel Headroom da ist: Unter normalen Betriebsbedingungen bekommst du die nicht in Sättigung, weder wir selbst noch Fremdtechniker hatten diesbezüglich mit unserer GLD in den letzten gut 18 Monaten ein Problem. Und da war alles von der kleinen Konferenz über die 24-Kanal RnR-Nummer bis zum 40-Kanal Musical und Theater dabei.

Thema Inputs: Du möchtest 48 (bzw. 44) Eingänge und 16 Ausgänge haben. Das ist beim GLD zwar möglich aber etwas "hässlich", wenn man die alle auf der Bühne braucht: 24+8=32 Eingänge und 12+4=16 Ausgänge bekommst du über die erste CAT-Leitung, weitere 8/4 über eine zweite CAT-Strecke. Die letzten 4 Eingänge sind direkt an der Konsole, d.h. um die auf der Bühne verfügbar zu haben ist Analogstrippe fällig. Die beiden CAT-Strippen kann man über entsprechende Switches auch auf eine reduzieren (haben wir mit Redundanz schon realisiert, das Setup kann ich demnächst bei Interesse auch mal hier vorstellen) aber das ist dann nicht mehr grade Plug&Play. Für mehr als 40 Eingänge auf der Bühne willst du daher eigentlich iLive haben mit der iDR-48 bzw. iDR-64 oder halt iDR-10 mit entsprechend vielen Modulen.

Zitat von &quot;marcoboy&quot;

Es geht noch einfacher mit Kill

In der Tat, das ist wahrscheinlich die geschickteste Lösung. In Verbindung mit der Option "Kill With Off Time" (zu finden im Setup unter Show, Playback + MIB Timing) kannst du dann dafür sogar eine Zeit angeben (Kill Executor x.y.z Time 5), damit dein Off nicht springt sondern ausblendet. Gleiches funktioniert selbstredend auch für die Effekte, Off Effect Thru Time 5 z.B. und im Programmer, ClearAll Time 5.

Ergänzung: ClearAll Time 5 scheint doch nicht so wie erwartet zu funktionieren (warum eigentlich nicht?), aber man kann dafür den Weg über die "Program Time", wenn die ungleich 0 ist, blendet auch ein ClearAll aus (was auch der Grund ist, warum ich das oben geschrieben habe, die war noch drin ... Oops)

Viele Grüße
Joern

Zitat von &quot;alexanders&quot;

Die Park-Lösung kommt meinem Ideal da schon deutlich näher. Hier kann ich zwar dann den Wert des Frontlichts mit dem Fader auch nicht mehr verändern, was aber wohl eine annehmbare Einschränkung wäre.

Falls es nicht allzu viele Executors sind, die du schützen möchtest und die verknüpften Sequenzen alle nur aus einem Cue ohne Fades o.ä. bestehen, funktioniert evtl. folgender Workaround. In deinem Makro programmierst du folgende Befehle:

• Park Executor 1
• Off Effect Thru
• Off Page Thru
• ClearAll
• On Executor 1
• Unpark Executor 1

Damit wird der Executor nach erfolgtem Off Page Thru sofort wieder neu gestartet. Sofern keine Fades programmiert sind, steht der nach dem Unpark also genau so wieder (im ersten Cue) da, wie er vor dem Ausführen des Makros war. Falls du Fades programmiert hast, müsstest du mit der Ausführung des Unpark solange warten, bis der alte Zustand wieder erreicht ist.

Klappt das?
Joern

Ein interessanter Aspekt ist sicher in diesem Zusammenhang auch noch: Was ist eigentlich mit dem Personenschutz auf der Sekundärseite einer USV? Ein auslösender RCD auf der Primärseite sieht ja für die USV nicht anders aus als ein echter Stromausfall, ergo wird sie wohl auf Batteriebetrieb umschalten und damit wird auf der Sekundärseite auch weiterhin eine Spannung anliegen.

Zu den folgenden Überlegungen möchte ich vorausschicken, dass das nicht mein Fachgebiet ist. Ich bitte also darum, Fehler (die beim Thema Strom auch schnell gefährlich werden können) möglichst mit Erklärung aufzuzeigen und zu korrigieren.

Kleine USV-Anlagen (über die wir hier ja sicherlich reden), die über Steckkontakte (also Kaltgeräte oder fest angeschlossene Leitung mit Schuko am Ende) versorgt werden, trennen bei Ausfall der primären Versorgung die Verbindung zwischen Ein- und Ausgang zweipolig (N und L), um einen Rückspeiseschutz zu gewährleisten. Damit besteht - abgesehen vom Schutzleiter - keine galvanische Verbindung mehr zum Netz auf der Eingangsseite sobald die USV auf Batteriebetrieb läuft. In diesem Fall habe ich, wenn mich nicht alles täuscht, sekundärseitig nun die Netzform IT mit zwei Außenleitern, die 230 V gegeneinander führen und keinen Bezug zur Erde haben. Hab ich an einer kleinen APC-USV auch nachgemessen, im Batteriebetrieb schätz-messe ich jeweils etwa 110 V gegen Erde, wohl über die Entstörkondensatoren.

Nach dem Funktionsprinzip (Differenzstrommessung) eines RCD zu urteilen, sollte also das Einbringen eines weiteren RCD auf der Sekundärseite der USV hier den Personenschutz gewährleisten können. Ein erster Fehler im IT-Netz erdet ja den betroffenen Außenleiter. Abhängig von den Leitungskapazitäten fließt auch hier ein kleiner Fehlerstrom, ob der ausreicht ist natürlich die Frage. Da das Netz hinter der USV wahrscheinlich sehr klein ist, ist der Fehlerstrom wegen der geringen Kapazität wahrscheinlich auch entsprechend klein. Die Spannung des anderen Außenleiters ist natürlich gegenüber Erde erhöht, aber das muss die Isolation der Komponenten im Normalbetrieb (TN-S) ja ohnehin abkönnen.

Ich habe auch schon einen befreundeten Elektromeister befragt, dieser meinte daraufhin "interessante Frage", war aber auch der Meinung, dass das so (mit dem nachgeschalteten RCD) grundsätzlich gangbar sein sollte.

Fundierte Meinungen bzw. Einwände dazu?
Joern

Hallo alexanders,

das geht z.B. über die Park-Funktion. Wenn dein Frontlicht z.B. auf Executor 1 liegt, kannst du den über "Park Executor 1" einfrieren, auf der Konsole 2x Pause (der kleine Hardkey in der Command Section, nicht der große neben den Executor-Fadern), dann Exec, die 1 und Please. Ein anschließendes Off Page Thru hat dann keinen Einfluss mehr auf diesen Executor. "Ausparken" kannst du den Executor über "Unpark Executor 1", 2x Go+ (das rechts neben Pause), Exec, 1 und Please.

Alternativ kann man auch 2x Pause bzw. 2x Go+ und dann einen der Executor Buttons des gewünschten Executors drücken, hat den gleichen Effekt.

Viele Grüße
Joern

Hallo zusammen!

Zitat von &quot;marcoboy&quot;

Beim GLD passiert folgendes. Das Pult denkt es wäre abgestürzt, weist einen freundlich darauf hin das man es vor dem Ausschalten herunterfahren soll. Nach Bestätigung lädt es die default Show aber nicht das letzte Showfile. [...] Wenn man den Stecker zieht ist alles nach dem Speichern der Show futsch.

Das ist nicht ganz korrekt. Die GLD-80, die ich hier stehen habe, lädt auf jeden Fall die zuletzt aktive Show und darin offenbar eine Art unsichtbare "Sicherungsszene". Diese enthält zwar nicht den blutig absolut letzten Stand in der Millisekunde des Ausfalls, aber immerhin auch nicht den Stand zum Zeitpunkt der letzten expliziten manuell ausgelösten Speicher-Aktion, die ggf. schon ein paar Stunden zurückliegt. Das Pult speichert also in bestimmten (wahrscheinlich festen) Zeitabständen intern den aktuellen Status.

Hab das grade mal kurz getestet: Meine Fader-Änderung, die ich innerhalb von etwa 10 Sekunden vor dem "Ausfall" getätigt habe, war nach dem Wieder-Einschalten nicht wieder da, die Änderung in einem anderen Kanal etwa eine Minute zuvor aber schon. Ich tippe daher auf "60 Sekunden" beim automatischen Speicherinterval. Ist nur aber eine Vermutung, keine Tatsache! Wenn ich richtig informiert bin, liegen alle Daten und das Betriebssystem des Pults intern auf einer SSD. Ich kann mir in diesem Fall gut vorstellen, dass zur Verlängerung der Lebensdauer eben nicht alles immer und sofort gespeichert wird, sondern in Intervallen.

Im Handbuch auf Seite 17 steht außerdem: "If the system is not powered down correctly there is a possibility recent changes may be lost." Das deckt sich in meinen Augen ziemlich gut mit meinem Kurz-Test Es wäre interessant vom A&H Support zu erfahren, wie groß das Intervall tatsächlich ist und ob die Annahme eines solchen überhaupt richtig ist.

Zum Thema USV: Online-USV hatten wir mal. Die ist dann eines schönen Tages beim Einschalten (ohne Last) mit einem lauten Knall ausgestiegen (diverse Halbleiter im Ausgangswandler hat es regelrecht zerrissen) ... in ihrem Case steckt seit dem 'ne Endstufe und Stromausfälle sind auch noch keine vorgekommen, bei denen eine USV einen Unterschied gemacht hätte. Das pro-USV Argument des (unwissend) von einem Helfer zum Einschleifen einer weiteren "Dreifach-Kleinstverteilung" gezogenen FOH-Stroms kaufe ich, ist aber letztlich und objektiv betrachtet ein Ausfall, den man sich selbst auf die Kappe zu schreiben hat. Wenigstens dieses Kabel kann man so ausführen (CEE blau wurde ja genannt), verlegen und markieren, dass das nicht passiert. Und wenn doch, dann sollte die 3er-Dose wahrscheinlich am FOH nach der USV eingeschoben werden :? ... Pech gehabt.

Grüße
Joern

SSDs komplett und sicher löschen geht einfach, schnell und ohne Verschleiß über ein Feature namens "Secure Erase". Überschreiben mit Nullen oder Zufall ist aufgrund von Wear Leveling und der nicht-1:1 Zuordnung der logischen Adressen auf die physischen Zellen wie schon von anderen erwähnt überhaupt nicht zielführend.

Eigentlich alle SSDs die ich kenne verschlüsseln (i.d.R. AES) alle Daten die sie im Flash ablegen transparent im Controller mit einem vom Hersteller für jede SSD zufällig und individuell vergebenen Schlüssel. Das restliche System bekommt davon gar nichts mit, die Daten werden beim Lesen genauso transparent wieder entschlüsselt. Das muss man auch nirgendwo explizit anschalten, ist ab Werk aktiv.

Löst man über ein spezielles Programm (bei Intel heißt das z.B. "SSD Toolbox") den Secure Erase aus, weist das Programm den Controller an, den aktuellen Schlüssel zu "vergessen" und einen Neuen zu erzeugen. Die Daten auf der SSD sind damit zwar prinzipiell alle noch da, aber mangels Kenntnis über den korrekten Schlüssel wertlos und nicht zu rekonstruieren. Das ganze geht einfach (ein paar Klicks), schnell (wenige Sekunden) und ohne Verschleiß (auf die eigentlichen Flash-Zellen wird nicht geschrieben).

Teilweise gibt es auch Festplatten mit diesem Feature, damit man sich das langwierige Überschreiben mit Nullen oder Zufall sparen kann. Findet man aber eher im Enterprise-Bereich wo man Platten nicht "ungelöscht" entsorgen möchte.

Implementiert ist das meistens auch standardkonform über das sog. ATA Password, ggf. einfach mal die Suchmaschine der Wahl befragen.

Grüße
Joern

Den Begriff Bitrate würde ich mal mit "Bits pro Zeiteinheit" interpretieren, z.B. die 128 kBit/s für einen Stream ist seine Bitrate. Bitbreite ist schon "richtiger", finde ich aber etwas unglücklich gewählt denn Bits haben wie schon erwähnt keine intrinsische Breite, es gibt nur zwei Zustände ("binary digit").

Vielleicht möchte man sich auf Wortbreite einigen? Im Sinne von "die Breite (in Bits) eines Datenworts (also z.B. ein Sample)". Das korrespondiert auch schön mit dem Begriff der "Wordclock", die ja auch den Takt für die Verarbeitung einzelner "Worte" (= Samples) angibt und nicht etwa die Bitrate bei einer seriellen Übertragung. Alternativ ginge auch noch Bittiefe, analog zum Begriff der "Farbtiefe" im Bereich der Computergrafik.

Grüße
Joern

Zitat von &quot;billbo&quot;

Nutzt Du als FOH - Pult ein gängiges Digitalgerät? Dann verzichte auf SPL o. ä. und route einen Eingangsverstärker/ Wandler auf 2 Kanäle.

Soweit absolut richtig und auf jeden Fall die praktikabelste Lösung - wenn es nur um den Vorverstärker geht.

Wenn der TrackOne aber wegen De-Esser, Dynamaxx und/oder EQ verwendet wird (wovon ich ausgehe, oben steht nämlich "heftig komprimiert"), muss vorher irgendwie analog verteilt werdem. Bei einem Digipult könnte man ohne Split noch den Umweg über eine zusätzliche DA-AD-Wandlung gehen, erkauft sich damit aber auch zusätzliche Latenz. Bei einem Analogpult kann man wie schon beschrieben den Direct-Out des (Monitor)-Kanals als Eingang für den TrackOne nehmen. Dann bringt der Preamp natürlich nix mehr aber die restlichen Blöcke bleiben für die Signalbearbeitung erhalten. Ist eben die Frage, was man will und ob den Aufwand lohnt.

Einen günstigen Trafo-Split mit 2+1 Ausgängen gibts für rund 50 EUR oder noch weniger pro Kanal, wer will kann natürlich - wie so oft - auch mehr Geld ausgeben, z.B. Radial JS3 und Konsorten

Grüße
Joern

Es driftet hier zunehmend in eine Netzwerk-Diskussion ab, will ich eigentlich nicht, aber soviel möchte ich noch sagen:

Zitat von &quot;Jan&quot;

[...] Die passive sendet keine Pakete. Beide Links sind aktiv.. die Datenströme werden gemäß dem was du sagst aufgteilt.

Schon klar das es den passiven Modus gibt. Aber: LACP auf den entsprechenden Switches an beiden Enden jeweils im passiven Modus zu betreiben ist nicht sonderlich sinnvoll oder? Denn so weiß ja keiner der Switches, das am anderen Ende der beiden Leitungen auch einer (und zwar derselbe) hängt und man die beiden Leitungen zu einer logischen zusammenfassen könnte, denn schließlich halten sich im passiven Modus beide über ihre Fähigkeiten bedeckt. In diesem Fall wird dann auch nichts aufgeteilt, denn ohne Wissen über die Anzahl der parallel nutzbaren Verbindungen geht das nicht. Und wenn beide Links ohne Bündelung (und ohne STP) aktiv sind, endet das spätestens mit dem ersten Broadcast (und dSNAKE sendet ausschließlich Broadcast) im Desaster. Also: Mindestens eine Seite muss schon im aktiven Modus betrieben werden, sonst wird keine Bündelung ausgehandelt.

Zitat von &quot;Jan&quot;

LACP ist gar nicht erforderlich. Nimm die selbe Switchmarke, z. B. HP und Trunk die Ports einfach. Ist wesentlicih robuster als LACP, sendet auch keine Pakete und geschieht auf absolut unterste Ebene.

Was ja nun nichts anderes ist, als die statisch konfigurierte und proprietäre Variante von LACP. Klar kann man das machen, hab ich auch nicht anders behauptet. "Robuster" ist das ganze auch nur deswegen, weil es fest konfiguriert ist. Und wenn der einfache Trunk keine "Hello"-Pakete sendet, sondern die Datenströme stumpf auf die Menge der konfigurierten Verbindungen verteilt, hat man spätestens bei der oben schon beschriebenen Adaptierung mittels Medienkonverter und Faserbruch ein Problem, diese Art von Fehler wird nämlich ohne aktive Überwachung nicht erkannt. Klar wird wahrscheinlich niemand seine GLD redundant per Glasfaser mit der AR2412 verbinden, aber in größeren Installationen mit anderen Pulten kann sowas schonmal vorkommen, daher hier die "Warnung" vor dieser Stolperfalle. 802.1ax funktioniert als Standard (hoffentlich) herstellerübergreifend.

Zitat von &quot;Jan&quot;

Bandbreiten verdoppelung ist hier gar nicht erforderlich und gar nicht sinn des Vorschlags von mir gewesen und ja es würde auch nicht funktionieren, weil der Datenstrom immer konstant ist (Audio), wie du bereits gesagt hast.

Weiß ich, dass das nicht der Sinn deines Vorschlags war Ich wollte auch nur herausstellen, dass der primäre Zweck von LACP nicht die Schaffung einer Redundanz sondern eher die Vergrößerung der Bandbreite ist. Wenn eine der physischen Verbindungen ausfällt, ist die logische Verbindung dadurch als positiver Nebeneffekt noch nicht völlig tot, aber eben nur noch mit weniger Bandbreite nutzbar, die aber hier für den Transport der Audio-Daten natürlich immer noch ausreicht.

Zitat von &quot;Jan&quot;

Letztendlich gibts noch die Möglichkeit zwei Kabel zu legen, an der Bühne beide einstecken am Switch (ohne spezielle Switch Einstellungen) und am FOH bei Bedarf manuell umstecken, wenn die Leine reißt.

Das ist eine gute Idee, die es dem Anwender ohne viel zusätzliche Hardware und vorallem ohne Konfiguration erlaubt eine Kabel-Redundanz herzustellen und im Fall der Fälle die Veranstaltung weiterzuführen, ohne sich einmal quer durchs Publikum quetschen zu müssen. +1 dafür :wink:

Grüße
Joern

Zitat von &quot;Jan&quot;

[...] Fällt ein Kabel aus, merkt der Switch das und schickt die Daten über das andere Kabel.

Und genau hier liegt der kleine Schönheitsfehler in diesem Verfahren für die Anwendung "Audio-Netzwerk". Du meinst sicherlich 802.1ax (Link Aggregation Control Protocol, früher 802.3ad, je nach Hersteller auch mit den Begriffen Trunking, Bonding, Teaming, Bundling usw. bezeichnet). Switches, die entsprechend konfiguriert sind, schicken sich sog. LACPDU zu und "merken" dadurch, ob die Verbindung noch da ist oder nicht und schalten erst dann entsprechend um. Das Interval zwischen zwei solchen "Hello"-LACPDUs ist mindestens das Short Timeout von 3 Sekunden, d.h. wenn das Kabel kaputt geht, schaltet der Switch nicht sofort alles auf den anderen Link, sondern erst, wenn er nach drei Sekunden kein "Hello" bekommen hat. Dieses aktive "ich bin noch da" ist auch sinnvoll, denn wenn z.B. zwischen zwei Switches ein Teil der Strecke mit einem Medienkonverter auf Glasfaser überbrückt wird, merken die Switches sonst nicht wenn die Faser bricht, da die jeweilige Verbindung zum Konverter ja noch ok ist. Um sowas zu erkennen muss also ein aktives Verfahren über solche "Lebst du noch?"-Pakete zum Einsatz kommen.

LACP wird eingesetzt, um zum einen die verfügbare Bandbreite zwischen zwei Knoten durch Bündelung bestehender Verbindungen und damit ohne den Austausch von Hardware zu erhöhen und dabei gleichzeitig eine Redundanz zu schaffen, die gegenüber dem Ausfall einzelner Verbindungen des Bündels (mit einer kleinen MTTR) tolerant ist. Es ist auch nicht so, dass man durch das Zusammenschalten von zwei 100 MBit/s-Ports quasi einen 200 MBit/s-Port bekommt. Die Verteilung der Pakete auf die beiden Verbindungen geschieht nämlich nicht einfach abwechselnd "wo grade was frei ist" sondern pro Datenstrom. Wie ein Datenstrom definiert ist, hängt dabei vom auf dem Switch eingesetzen Algorithmus ab. Der Grund dafür ist, dass der Standard vorsieht, dass die Reihenfolge der Pakete in einem Strom nicht durcheinandergebracht werden darf und das geht nur, wenn alle Pakete die logisch zusammengehören nacheinander immer über dieselbe Verbindung geschickt werden.

Das Verfahren ist für "normale" Netzwerke auch sinnvoll, wo es primär um die Erhöhung der Bandbreite geht und eine kurze Unterbrechung durch weiter oben arbeitende Protokolle wie TCP ausgeglichen werden kann. Eine z.B. Dateiübertragung "hängt" kurz zeitlich, geht aber dann weiter. Beim Live-Ton ist in diesem Fall kurz Ruhe und die Aufnahme an dieser Stelle defektiös. Zugegeben, in den meisten Fällen läuft keine Aufnahme und ein kurzer Ausfall ist sicher zu verkraften, daher ist die Absicherung per LACP einem manuellen Umstecken was den Zeitfaktor angeht immer noch vorzuziehen, eine wirkliche Lösung wenn man keinen Ausfall dulden kann ist es aber nicht. Preislich redet man jetzt auch nicht mehr über die 30 EUR-Kategorie an Switch-Hardware sondern schon eher über 130+ EUR-Kategorie. Dazu kommt der nicht unwesentlich gestiegene Konfigurationsaufwand. Richtig bescheiden wird es, wenn aufgrund von welchen Umständen auch immer die Switches anfangen immer mal wieder zu glauben, einer der beiden Links tot sei und dann ohne ersichtlichen Grund (mit Unterbrechung) auf den Reserve-Link umschalten, nur um dann kurze Zeit später (wieder mit Unterbrechnung) zurückzuschalten. Wird dann ein Fall für den I don't need that-Thread ...

Die hier geforderte Redundanz für das Audio-Netzwerk will man also eher so haben, dass die Daten parallel immer über beide Verbindungen geführt werden. Quasi die True-Diversity im Empfänger wie man sie von Drahtlosanlagen kennt - nur eben für das Netzwerk. Der Empfänger verarbeitet den Datenstrom, den er "am besten" empfängt. Sowas bietet in dieser Form um bei A&H zu bleiben nur der große Bruder iLive (T) mit einer redundanten ACE-Verbindung zwischen Pult und MixRack. Oder eben MADI. So gesehen ist mein Satz zwei Beiträge weiter oben also auch nicht ganz präzise, ich muss ergänzen, dass die Netzwerk-Redundanz keinen nahtlosen Failover ermöglicht sondern dieser mit einer kurzen Unterbrechnung einhergeht, während der die in dieser Zeit gesendeten Audio-Daten mit einer gewissen Wahrscheinlichkeit verloren gehen.

Grüße
Joern

So, hier zunächst mal das Bild zur Erklärung, was da jetzt wo wie gesteckt und konfiguriert wird:

Wofür das alles? Wir fassen den Verkehr auf den roten und blauen Kabeln auf ein grünes Kabel zusammen. Die Pakete aus den verschiedenen Systemen (Dante & dSNAKE) werden dazu von den Switches für den Versand auf dem grünen Kabel mit einem kleinen "Bapperl" (engl. "Tag", daher auch die Worte tagged und untagged) versehen, damit der andere Switch die Pakete beim Empfang auseinanderhalten kann. Abstrakt gesprochen bauen wir auf die physische Netzwerkstruktur - in der alle Geräte in einem gemeinsamen, physischen Netzwerk miteinander verbunden sind - eine logische Struktur oben drauf, in der es zwei getrennte, logische Netzwerke gibt. Pult, AR2412, Dante-Karte im Pult und der Rechner mit der DVS wissen nichts von dieser Abstraktion, da sie jeweils an einem "untagged"-Port hängen. Für sie sieht es so aus, als seinen sie direkt über die entsprechend farbigen Kabel mit ihrem jeweiligen Partner verbunden, also das Pult mit der AR2412 und die Dante-Karte mit dem Rechner.

Nach kurzer Durchsicht des Handbuchs sollte die oben gezeigte Konfiguration z.B. mit dem Netgear GS105E zu realisieren sein. Das stellt keine Empfehlung dar und ich schreibe deswegen "sollte", weil ich keine Ahnung habe, wie krepelig die zur Konfiguration notwenige Windows-Software ist und ich diese Switches selbst nicht habe.

Zitat von &quot;Jan&quot;

Ich denke nicht das VLANs etwas bringen, wenn der Switch nicht auf QoS kann um die VLANS zu priorisieren.

Was für ein QoS willst du denn machen? DiffServ? Ist Layer 3 und damit für dSNAKE nicht anwendbar, da das ein reines Layer 2-Protokoll ist. Manche Switches bieten ein Feature namens "Voice-VLAN". Aber sowohl dSNAKE als auch Dante sind nunmal beides Echtzeit-Anwendungen ohne den Luxus, senderseitig mal kurz anhalten zu können, daher müsstest du eigentlich beide gleich priorisieren und hast damit nichts gewonnen: Wenn Dante und dSNAKE die einzigen Gäste sind, bringen VIP-Ausweise für beide wenig, falls der Laden nur einen Barkeeper hat.

Bleibt also die Lösung mit "mehr Hubraum" übrig, sprich: die Verbindung zwischen den Switches muss einfach dick genug sein, um beide Datenströme ohne Einschränkung parallel transportieren zu können. Mit Gigabit-Ethernet ist das für die hier zu erwartenden Setups sicher gegeben. Wer jetzt noch Endstufen- und Funkstrecken-Remote, Medienserver, Artnet usw. über die gleiche Leitung machen will, kann das auch noch machen, Stichwort hier wäre dann 802.1p, damit kann man vereinfacht gesprochen verschiedenen VLANs verschiedene Prioritäten zuweisen. Beispielsweise: Dante- und dSNAKE-VLAN = wichtig, Artnet = weniger wichtig, Medienserver = noch weniger wichtig, Rest = am unwichtigsten. Für die allermeisten Aufbauten und das Personal vor Ort ist es aber sicherlich praxistauglicher, einfach ein zweites Kabel zu ziehen. Das kann jeder und es gibt keine zusätzlichen Geräte, die kaputtgehen oder falsch konfiguriert werden können.

Zitat von &quot;mike j.&quot;

Version = v1.02, Tastatur = Logitech K120

Lustig, bei der GLD hier hat es mit eben diesem Modell nicht geklappt :cry: Hab meinen vorherigen Beitrag mit deiner Information korrigiert. War die Tastatur schon beim Hochfahren angeschlossen oder hast du die erst nachträglich angesteckt? Dem Kernel sollte das eigentlich egal sein, aber vielleicht ist die A&H-Software da wählerisch

Grüße
Joern

Zitat von &quot;mike j.&quot;

Der Anschluss einer Tastatur funktioniert (man kann auch die Ebenen von Linux mit ALT+Fx umschalten) oder Channelstrips benamseln.

Das würde mich interessieren. Welche Tastatur (Modellbezeichnung) hast du da angesteckt? Sowohl eine Cherry und eine Logitech die ich hier hatte haben beide nicht funktioniert. Firmware-Version deiner GLD? Achso: Das was du eine "Ebene" nennst heißt korrekt "virtuelle Konsole", mehr Infos z.B. hier.

Zitat von &quot;mike j.&quot;

Das kann aber auch daran liegen, dass sie NTFS formatiert war.

Sehr wahrscheinlich. Der im Kernel integrierte NTFS-Treiber hat nur eingeschränkte Unterstützung für Schreiboperationen. Es gibt zwar einen externen FUSE-Treiber namens NTFS-3G, aber das wird A&H sich sicher nicht ans Bein gebunden haben. Warum auch. Ist schließlich ein Mischpult mit Media-Player-Feature und kein Media-Player mit Mischpult-Feature.

Zitat von &quot;mike j.&quot;

dSnake => Dante Karte Primary Slot => vom Secondary übers Core auf die Bühne in die Stagebox - funktioniert überhaupt nicht. Hintergedanke dabei war, Dante und dSnake über ein Kabel zu übertragen. Das geht wohl nur mit Layer 3 Switches.

Da der dSNAKE-Port an der GLD mit an Sicherheit grenzender Wahrscheinlichkeit kein Gigabit spricht, ziehst du dir mit dieser Aktion die Dante-Karte auch auf Fast-Ethernet runter. Da dSNAKE die Verbindung bereits nahezu sättigt, gehen jetzt durch den zusätzlichen Dante-Verkehr massiv Pakete verloren. Folge: Es geht nichts. Getestet habe ich das selbst nicht, aber das ist für mich die logische Erklärung. Mit sog. "Layer 3 Switches" hat das nichts zu tun. Möglich wäre dein Vorhaben mit je einem VLAN-fähigen Switch sowohl am Pult als auch an der AR2412, darauf je einen Port untagged in das GLD-VLAN bzw. das Dante-VLAN, einen dritten tagged für beide VLANs konfigurieren und die beiden Switches über diesen verbinden. Grafik zur verständlichen Erklärung wird nachgeliefert.

Zitat von &quot;mike j.&quot;

[Ausfall der Kabelverbindung] Macht es hier Sinn ein 2. Kabel mitzunehmen als Ersatz (kosten ja nicht die Welt)

Wenn die Zeit dafür da ist, du es vorher auf einem anderen Weg verlegt und vorbereitet hast, warum nicht? Umstecken und es geht weiter. Wenn es so wichtig ist, kann man natürlich die Redundanz ohne Umstecken auf Netzwerk-Ebene mit Switches für die GLD einrichten, sowas ist aber jetzt nicht grade Plug&Play und auch kein Feature der ganz billigen Switch-Hardware. Dann doch eher ein anderes System, was die Redundanz bereits drin hat. Geht für iLive z.B. mit ACE oder auch MADI (mit separatem Netzwerk) um mal zwei Beispiele zu nennen.

Grüße
Joern

Zitat von &quot;Mister.Lange&quot;

Der [Master] war am Pult mit +6dB bei Peaks zu sehen. In dem File liegt der Peak bei -16dB.

Willkommen in der Welt der verschiedenen Bezugspegel. Die Differenz zwischen -16 und +6 dB ist 22, sprich du kannst den Bus, den du auf den USB-Rekorder aufnimmst scheinbar auf bis zu +22 dB auf der Pultanzeige (die nur bis +18 dB geht) aussteuern, ohne das die Aufnahme dadurch clippt.

Real werden es nicht die 22 sein sondern eher nur 21 (oder laut Spezifikation sogar nur 18), denn wie ich am Ende von diesem Beitrag schonmal geschrieben habe, scheint der DSP intern seine 0 dBFS bei umgerechnet +21 dB zu haben (zumindest ist das der Headroom des dSNAKE-Protokolls), das würde ja sehr gut mit deiner Beobachtung hier korrelieren.

Grüße
Joern

Edit: Trotz Korrekturlesen vergessene Wörter ergänzt ...

n'Abend

Zitat von &quot;marcoboy&quot;

Unicast zu verwenden führt dann zu Störungen wenn Teilnehmer im Netz nicht mehr erreichbar sind.

Das ist so nicht ganz korrekt. Unicast bedeutet zunächst erstmal nur, dass genau ein Empfänger angesprochen wird. Die Adressierung und damit die Unterscheidung zwischen Uni-/Broad-/Multicast läuft auf dem "Netzwerk"-Layer 3 (und aus verschiedenen Gründen teilweise auch noch auf Layer 2). Das Konzept einer "Verbindung" und eine Zusicherung von bestimmten Eigenschaften (z.B. Zuverlässigkeit der Übertragung, Einhaltung der Reihenfolge, usw.) ist jedoch auf Layer 4 - "Transport" - angesiedelt.

Ich kann z.B. UDP-Pakete per Unicast in die Welt schicken soviel ich will, ob die ankommen oder nicht stört meinen Sende-Prozess überhaupt nicht. Erst wenn beide Kommunikationspartner ein Protokoll sprechen, dass die gegenseitige Bestätigung von Paketen eingebaut hat (z.B. alles was über TCP abgewickelt wird) kommt es zu Problemen, wenn eine Seite der Verbindung plötzlich verschwindet. Da wird der TCP-Stack dann irgendwann sagen: "Hey, warte mal einen Augenblick bevor du weiter sendest, ich hab von der Gegenseite noch keine Bestätigung über den Empfang der letzten paar Pakete."

Bei einem Multicast-Protokoll erwartet man üblicherweise gar keine Bestätigung der einzelnen Empfänger, folglich kommt es hier also auch nicht zu Problemen, wenn einer der Empfänger aussteigt.

Richtigerweise müsstest du also oben einschränken: "Unicast mit TCP/IP"

Zitat von &quot;bernd häusler&quot;

[...] sollte der iDR-Switch an dessen IP auch kein Dante in den Tunnel schicken. Es sei denn die M-Dante sendet Multicast.

Nah dran. Zunächst: Ein Switch sendet an keine "IP" (Layer 3), er sendet an MAC-Adressen (Layer 2). Der IPv4-Stack eines jeden Geräts muss sich über ARP erstmal die MAC-Adresse der Ziel-IP besorgen, bevor er ein Paket auf die Reise schicken kann. Weiterhin: Wenn die Dante-Karte Broadcast senden würde, muss der iDR-Switch das in den Tunnel schicken. Sendet sie aber Multicast, hängt es von der Intelligenz des Switches ab. Das heißt: Selbst wenn keine DVS am anderen Ende hängt, kann es sein, dass der Dante-Verkehr in den Tunnel gespült wird, muss aber nicht.

Erklärung dazu: Switches arbeiten allgemein auf Layer 2 - "Data Link" - und treffen die Entscheidung, an welchem Port sie welche Pakete rausschicken (bei Ethernet) anhand der Empfänger (MAC)-Adresse in jedem Paket. Damit geht also erstmal nur Unicast, es sei denn man widmet "besondere" Adressen für Zwecke wie Broadcast oder Multicast um. Ein Switch wird z.B. ein Paket für den Empfänger FFFFFF-FFFFFF auf allen Ports ausgeben, denn diese Adresse ist die Broadcast-Adresse.
Bei Multicast gestaltet sich das etwas schwieriger, denn jetzt sind ja nicht mehr "alle" sondern nur noch "bestimmte" Empfänger mit den Paketen zu versorgen. Die eigentliche Multicast-Adressierung findet aber im Layer 3 statt, d.h. auf einer Ebene wo der Switch selbst erstmal nichts zu suchen hat. Wie bekommt man die Pakete nun trotzdem an alle Empfänger? Man macht einen Broadcast daraus. Der Sender schickt die Multicast-Pakete also auf Layer 2 (vereinfacht gesagt) an einen Pseudo-Empfänger mit der Adresse 01005E-xxxxxx raus und Switches sehen solche Adressen auch als Broadcast-Adressen an, werden die Pakete also auf allen Ports ausgeben. Das ist zwar jetzt etwas blöd, aber als Folge der Aufgabentrennung zwischen Layer 2 und 3 leider erstmal nicht zu umgehen.
Zur Rettung des Tages kommt nun IGMP Snooping daher. Multicast-Verkehr wird in Gruppen abgewickelt; ein Client, der Multicast einer bestimmten Gruppe empfangen will, meldet sich dazu per IGMP beim nächstbesten Router (und jetzt wirklich Router und nicht bloß Access-Point) an, dass er da bitte auch mit-empfangen möchte. Wenn der Switch jetzt hinreichend intelligent ist, diese IGMP-Nachrichten zu "erschnüffeln" (= zu snoopen), kann er entscheiden, ob die entsprechenden Multicast-Pakete auf einem Port ausgegeben werden müssen oder nicht. Das heißt: Nur wenn die Switches IGMP Snooping können, wird aus dem Layer 3 Multicast auch auf dem Layer 2 ein echter Multicast und die unnötige Übertragung von Metering und/oder Dante-Audio vermieden, sofern iLive und/oder Dante im Multicast-Modus betrieben werden.

Zitat von &quot;bernd häusler&quot;

[...] Das sind dann 9,7MB/s, also 78Mbit/s.

Die 100 MBit/s gehen in der Regel im Vollduplex, d.h. in jede Richtung jeweils 100 MBit/s, nicht zusammengenommen. Aber spielt auch keine Rolle, es funktioniert so und damit ist gut

Zitat von &quot;bernd häusler&quot;

weil der iDR-Switch [...] einfach Layer3 ist

Nur um das klarzustellen: Auf Layer 3 wird nichts geswitcht. Ein "Layer 3 Switch" heißt nur deswegen so, weil er gegenüber seinen "dummen", reinen Layer 2-Kollegen über zusätzliche Software verfügt, die ihm über seine eigentlich Kernkompetenz (nämlich das Switching) hinaus erlaubt, in höhere Protokoll-Ebenen zu schauen und darauf basierend "bessere" Entscheidungen zu treffen, um den Paket-Fluss zu optimieren, z.B. über das besagte Feature IGMP Snooping oder die automatische Erkennung und Priorisierung von VoIP. Geroutet wird auf Layer 3. Aber: Wahrscheinlich ausnahmslos alle hier im Feld-, Wald- und Wiesenbetrieb befindlichen iLive/Dante-Installationen bewegen sich in genau einem gemeinsamen IP-Netzwerk, es wird also nichts nirgendwohin geroutet.

Grüße
Joern

Sorry, viel Text

markus maier
Stell dir das mit der Attack- und Release-Zeit mal eher wie folgt vor:
Du bist der Kompressor und hast ein Potentiometer als Regelelement. Die Zeitangaben bestimmen jetzt, wie schnell du an deinem Rad drehen kannst, um den gewünschten Zielwert in der Absenkung zu erreichen. Also wie eine Art Dämpfung, die deine Drehbewegung am Poti mehr oder wenig hemmt. Kurze Zeiten = schwache Dämpfung, lange Zeiten = starke Dämpfung, für beide Drehrichtungen verschieden einstellbar.

Eine Attack-Zeit von 50 ms würde bedeuten, dass du (ab dem Zeitpunkt, an dem die Schwelle überschritten wird) 50 ms brauchst, um die durch Ratio (z.B. 2:1) und relativen Pegel über der Schwelle (z.B. um 6 dB überschritten) benötigte Absenkung zu erreichen. Hier müsstest du also (wenn es ein idealisiertes Sinus-Signal mit konstantem Spitzenpegel ist) um 3 dB zurückregeln. Mit welcher Kurvenform du das jetzt erreichst, ist dir überlassen.

Mit der Release-Zeit verhält es sich ähnlich, nur bestimmt man hier eben Geschwindigkeit, mit der aus der Absenkung wieder zurück zur einfachen 1:1 Durchleitung des Signals zurückgekehrt wird.

Du musst dich außerdem von der Vorstellung lösen, dass diese Zeiten immer "ablaufen". Wenn du den Schwellwert nur kurz aber drastisch (z.B. für 1 ms um 20 dB) überschreitest, deine Attack-Zeit aber bei sagen wir 100 ms liegt, führt das logischerweise nicht dazu, dass ein Kompressor dann trotzdem nach den 100 ms um 20 dB runterkomprimiert hat. Er wird vielleicht (je nach Ausgestaltung der Regelkurve) um 1-2 dB runterziehen und dann im Rahmen der Release-Zeit wieder freigeben.

In dem Bild mit dem gedämpften Poti kannst du dir die Hold-Zeit wie eine Sperre vorstellen. Hast du das Poti einmal in Richtung Absenkung gedreht, ist der Rückweg für die Dauer der Hold-Zeit gesperrt, d.h. bevor du dass Signal wieder anheben kannst, musst du mindestens die Hold-Zeit abwarten.

Und wo du auch aufpassen musst bei deiner Sample-Arithmetik: Das Ohr reagiert (näherungsweise) logarithmisch, d.h. wenn du die absoluten Sample-Werte betrachtest und die Skala als linear annimmst, wirst du nicht die erwarteten Ergebnisse bekommen. Beispiel: 16 Bit-Samples, max. positiver Wert 32767, entsprechend 0 dBFS, der Dynamikbereich ist 96 dB. Man könnte jetzt annehmen, dass die Hälfte (also 48 dB) auch beim halben Maximalwert liegt, d.h. bei 16383, dem ist aber nicht so. Vielmehr entsprechen -6 dBFS dem halben Maximalwert (oder einem Bit weniger), -12 dBFS sind dann 8191 als Samplewert usw.

Idee zur Implementierung in deinem Programm: Ich nehme an, dass du jeweils Sample für Sample durchgehst. Nimm eine Variable als dein Poti, jeder Sample-Wert wird mit dem aktuellen Wert der Variable multipliziert, um die Absenkung zu erreichen (z.B. x = 0,5 entsprechend 6 dB Reduktion). Je nach Höhe des aktuellen Sample-Werts kannst du jetzt deine "Poti"-Variable entsprechend größer oder kleiner machen, in jedem Schritt aber immer nur ein kleines bißchen, entsprechend deiner Drehung am Poti. Beispiel: Attack-Zeit 50 ms entsprechend 2400 Samples bei 48 kHz, gewünschte Reduktion 6 dB. Dein Poti ist zunächst auf "Rechtsanschlag", d.h. keine Reduktion, x = 1. Pro Schritt müsstest du jetzt also jeweils x mit exp(-0,0003) multiplizieren, um dann nach 2400 Schritten bei etwa 0,5 zu landen. Dabei sei natürlich vorausgesetzt, dass der Signalpegel in diesen 50 ms konstant ist, d.h. die gewünschte Absenkung auch weiterhin konstant bei 6 dB bleibt.

Der Exponent (also hier die -0,0003) ist die Größe, die du mit deiner Pegel-Erkennung regelst. 0 bedeutet keine Änderung an der Reduktion, sie bleibt wo sie ist. Negative Werte lassen den Kompressor zunehmend eingreifen, und zwar um so mehr je negativer der Wert ist. Positive Werte hingegen verringern die Reduktion. Abhängig vom Eingangspegel im Verhältnis zum Threshold würdest du also den Exponenten wählen: Signalpegel unter dem Threshold = Exponent positiv, Signalpegel über dem Threshold = Exponent negativ. Eine Einschränkung gibt es noch: Dein Sample-Skalierungsfaktor x darf niemals größer als 1 werden, sonst verstärkt dein Kompressor. Einen Make-Up-Gain würde man danach z.B. als konstanten Faktor implementieren.

Ich hoffe das klärt einige Fragen. Viele Grüße & Erfolg
Joern

Ahoi!

Zitat von &quot;bernd häusler&quot;

Was muß man dann am Accesspoint alles einstellen?
Der Accesspoint ersetzt ja nur ein CAT-Kabel, gibts da was zu routen?

Wie schon richtig erkannt, funktionieren alle hier immer mit dem Begriff "Router" bezeichneten Geräte in Wirklichkeit in so gut wie 100% aller Pult-Remote-Anwendungsfälle als reine "Bridge" zwischen einem Kabel- und einem Drahtlos-Teil des Netzwerks. Da gibt es nichts zu routen, das wäre nur der Fall, wenn mehrere verschiedene IP-Netze am Start wären.

Wichtig wäre die Unterstützung für IGMP Snooping seitens des Access Points, damit Multicast-Pakete (sofern das iLive-System in diesem Modus betrieben wird) nicht zwangsweise auch auf dem WLAN übertragen werden, selbst wenn sie dort nicht gebraucht werden.

Und ja, Dante läuft sicher auch mit weniger Kanälen auf einem 100er Ethernet, allerdings werden die Leute von Audinate schon ihre Gründe haben, warum sie durchgehend Gigabit empfehlen. Und bei A&H steht es in rot sogar mehrfach in der Dokumentation, dass diese Brücke zwischen Dante Control-Port und iDR-Switch eben nicht unterstützt wird (= sie stehen nicht dafür grade, dass das problemlos funktioniert), grundlos schreiben die das sicher auch nicht dort hin. Mit 100 MBit/s-Hardware kommt man durch nebenläufigen Krams u.U. schnell an den Punkt, wo so ein Switch auch mal ein Paket wegschmeißt, weil grade einfach nicht mehr geht wegen Puffer voll oder irgendwas anderem. Und da hier UDP gesprochen wird, sind die Audio-Daten dann einfach weg. Bei Gigabit ist die Standspur zum Ausweichen einfach deutlich breiter ...

Ich seh das so: Es war noch nie so günstig möglich, qualitativ hochwertige Mehrspur-Live-Aufnahmen zu machen. Wenn man überlegt, dass man früher mit Analog-Split, separaten Preamps, Wandlern und dann einem irgendwie gearteten digitalen Aufnahmesystem am Start sein musste (und das auch bezahlt bekommen musste), sind die heutigen Kosten für einen eigenen Rechner - der ausschließlich die Mehrspuraufnahme macht - doch geschenkt. Da muss ich doch auf der gleichen Kiste nicht auch noch die Editor-Software laufen lassen, bloß "weils geht" ...