Erster Satz mag sein - die Überschrift sowie der weitere Text sind allerdings viel allgemeiner gehalten und dass dieser Thread auch nicht im Board "Audio-Netzwerke" zu verorten ist tut sein Übriges. 
Eigentlich müsste man aus der letzten Hälfte einen Extra-Thread "Wie baue ich redundante IP-Netzwerke auf" im o.g. Board machen...
wie gesagt, bei Schoeps wird eine pegelanhebung von 3dB für grenzflächen angegeben.
nach meinen bisherigen erfahrungen mit Schoeps, vor allem auch weil ich einen ehemaligen entwickler persönlich kenne und auch weiß, was der mann für ein physikalisches wissen hat, würde ich mal behaupten wollen das dies so stimmt.
Achtung: Die 3dB beziehen sich auf das Bündelungsmass, die Pegelanhebung gesamt beträgt jedoch 6dB.
Schon klar, deswegen sollte man bei einer echten Portbündelung eben diese auch redundant halten, gell.
Das dachte ich mir dass du dir dessen bewusst bist - in der öffentliche Forumstruktur mit etlichen Mitlesern konnte ich deine (mit gutem Grund auch von vielen anderen praktizierte) Herangehensweise allerdings nicht ohne erweiternden Kommentar so stehen lassen
zur "Ring Topologie" hätte ich eine frage:
wie realisiert man sowas mit glasfaser?
auf was muss man aufpassen?
gibt es geräte, die dafür nicht geeignet sind (vornehmlich switche), bzw. wie werden die konfiguriert?
kann ich da einfach am ende die zwei enden der ringleitung auf einen switch stecken?
1. Du verwendest (am besten baugleiche) Switche die über eine (eingeschaltete) RapidSpanningTree-Funktion verfügen
2. Die Switche verbindest du so dass es für dich Sinn ergibt, es pro Gerät immer mehr als eine Verbindung zum Netzwerk gibt und kein Port (auch im Havariefall) mit zu viel Daten überlastet wird.
3. Du besucht vorher einen Netzwerk-Workshop wie z.B. den vom Bodo
P.S.: zum schnellen Einlesen über die Funktionsweise tut es aber auch schon ein Wikipedia-Link: https://de.wikipedia.org/wiki/Spanning_Tree_Protocol
und beim Backbone am besten gleich über 2 Leitungen und diese mittels Loadbalancing bzw. Trunkports koppeln. Wenn dann eine Leitung wegbricht ist die andere noch da
Vorsicht bei der Nutzung von LinkAggregation als Redundanz: Das funktioniert solange man seinen Traffic im Griff hat und garantiert nicht über 1GB/s kommt. Da die gekoppelten Port in der Lage sind die doppelte Datenmenge zu übertragen könnte genau der Wegfall eines Kabels plötzlich zu Störungen führen.
wora : du bist da bei deinem bevorzugten Mischsystem dank Processing direkt in der Stagebox ja eh weniger betroffen ?
Ich meine natürlich Situation 1.
Die würde ich nicht anders lösen wollen, allein schon aufgrund des Platzbedarfes.
Tatsächlich fallen in meiner Welt ca. 70-80% aller „Vorkommnisse“ auf analoge Fehler zurück. Seien es die mittlerweile langsam auseinander fallendenden XLR-Unterverteilungen, der falsch gesteckte (weil schief abgelesene) XLR-Stecker hinten im Dockhouse oder am Stagerack, der tief im Rack beim umstecken versehentlich betätigte Mic/Line-Pegelschalter des Funkempfängers usw.
Im Verhältnis schneidet da übrigens der analoge Bereich vor allem wesentlich schlechter ab wenn es um konkrete technische Fehler geht, wogegen sich der digitale Gegenpart viel besser über die persönliche Lernkurve steuern lässt.
Benutzt hier noch jemand Netzwerke mit Ring Topologie und damit ohne "single point of failure", oder legt sein IP Netzwerk so aus (z.B. Spanning Tree)?
jep
guma : Definiere komplex.
Situation 1 ist definitiv als solche anzusehen, dort werkelten insgesamt 44 Dante-fähige Geräte (ohne DVS, ohne Switches) in einem Netzwerk, redundant (über den SecondaryPort) verkabelt waren davon 13. Auslieferungszustand der Gerätekonfigurationen seitens der Dry-Hire-Bude war... sagen wir einfach: Interessant 
Situation 2 war ein eher einfaches Setup mit Pult und Stagebox, allerdings gehen dort jeweils noch zusätzliche Steuerdaten über den primären Anschluss, weswegen 2 kleine Switches (ohne QoS) in den Cases verbaut sind. Normalerweise kein Problem, erst die DVS (aufgrund spontanem Aufnahmewunsch) hat da aus irgendeinem Grund Ärger provoziert, was von der Stagebox (welche seltsamerweise eh etwas empfindlich ist) mit Aussetzern quittiert wurde. Ich bin mir ziemlich sicher, dass dies vom sekundären Netzwerk aufgefangen worden wäre.
Wenn man sich einmal vor Augen führt was man da für Setups aufbaut und was dies in einer analogen oder P2P-basierten Welt an Aufwand bedeutet, so ist klar, dass man mit dem ein oder anderen Problemchen rechnen muss.
Vor allem wenn man mit vorab unkonfiguriertem Dry-Hire-Material arbeitet - in einer Zeit in der in einem Jahr pro Gerät teilweise 2-3 Firmware-Updates veröffentlicht werden.
Stell dir einfach vor, jemand hätte damals alle 4-6 Monate an seinen Analogsplittern die Groundlift-Optionen verändert
Hinzu kommen scheinbar immer kürzere Aufbauzeiträume bei eher aufwendigeren Anforderungen.
Wenn man Dante jedoch nur als P2P-Verbindung (vergl. AES50, MADI, etc.) ohne Extras zwischen Pult und 1-2 Stageboxen einsetzt, kann man es im Grossen und Ganzen auch genau wie solche Protokolle handhaben.
In Bezug auf Festinstallationen muss ich übrigens vermerken: Einerseits ist Dante dafür ein extrem mächtiges Werkzeug, andererseits kenne ich mittlerweile viel zu viele Installationen, die es eigentlich dadurch verbockt haben dass man tatsächlich nur über Dante auf's System kommt. I.d.R. bedeutet dies aufgrund veralteter Firmware oder geschützter Netzwerke, dass man IMMER mit einem Analogkabel auf die Mikrofonvorverstärker des Hauspultes stöpseln muss, also im Zweifel eine mögliche Fehlerquelle mehr hat 
.
Was ich bei diversen Versuchen aber auch festgestellt habe: die grösste Latenz verursachen Consumer-Flachbild-TV-Geräte, weil die eine Million Bildoptimierungsfunktionen haben und das einfach Zeit benötigt. Manchmal kann man diese abschalten. Computer-Bildschirme sind da von Grund auf schon schneller. Allerdings haben auch diese Panels prinzipbedingt Latenzen bis in den zweistelligen ms-Bereich. Röhre ist immer schneller.
Jein. Es kommt auch auf das übertragene Format an.
Wenn man Analog und Digital vergleicht nutzt man meist dieselbe Signalquelle, meist die noch installierte analoge Kamera oder meinetwegen auch schon eine digitale, allerdings den Ausgang im schön kompatiblen Interlaced-Format eingestellt.
Wären Flachbildschirme an und für sich langsam würden tausende von Gamern heutzutage noch an ihren Röhren hängen. Und auch diverse Trainingssimulatoren z.B. für Piloten oder gar Drohnensteuerungen dürfen durchaus als latenzkritische Systeme angesehen werden.
Die grösste Problematik ist, dass nirgendwo anständige Latenzwerte angegeben werden.
Aber wenn die Kamera HD-SDI mit 720p nativ ausgibt, keine Formatwandlung stattfindet und der Bildschirm das ohne irgendwelche Glättung/Weichzeichnung etc. darstellt gibt es keinen triftigen Grund für eine merkliche Latenz ausser evtl. diesbezüglich technischer Unzulänglichkeiten.
Tatsächlich haben sich in der Vergangenheit etliche Orchester-Musiker mit dem sogenannten „Gaming-Modus“ am Flachbild-TV bei analogem FBAS-Signal recht zufrieden gezeigt. Leider findet man diesen Modus nicht an jedem TV.
Beispiel 1 - Aktionärshauptversammlung:
Volle technische Redundanz. Verstromung (Hausstrom+Aggi), Beschallung, Projektion, Pulte, Operator, etc. im Saal doppelt ausgeführt.
Beispiel 2 - Aktionärshauptversammlung:
Havarie-Veranstaltungsort in einem anderen Stadtteil
Beispiel 3 - Internationales Funktionärsmeeting:
Digitales Sprechstellensystem mit zusätzlich analog ausgeführtem Direktsignal an jedem Vorstands-Tischmikrofon, falls z.B. das Mainframe versagen sollte.
Beispiel 4 - Beschallung Sportevent:
Hälfte der Beschallung an Feststrom, andere Hälfte an Aggregat, Notfall-Schaltermikrofon direkt im Amp zum eigentlichen Beschallungssignal hinzugemischt.
Allgemein/diverses:
Redundanz-Cat- oder Glaskabel gehört wenigstens ins Auto/Kabelcase, bei umständlicher Verlegung über Traversen oder durch Kabelbrücken bereits verlegt (und auch dann gerne wiederum plus 1x Spare in der Kiste).
Ob man sogenannte "heisse" (angeschlossen mit automatischer Umschaltung) oder eher "kalte" (Kabel liegt bereit zum umstecken) Redundanz fährt ist abhängig vom System, Aufwand und Anforderung.
Dante finde ich da übrigens aufgrund der offenen Struktur noch einen recht speziellen Fall:
Mir ist es mittlerweile schon 2 mal passiert dass ein Rechner mit DVS zu Clocking-Problemen geführt hat. Das erste Mal war im (etwas komplexeren) Aufbau eh noch einiges nicht richtig dank ordentlich verkurbelter Switch- und Pulteinstellungen, das andere Mal (Rechner während der VA zum aufnehmen angeschlossen) versuche ich demnächst irgendwann einmal nachzustellen - allerdings weiss ich auch dass das betroffene Gerät sowieso gerne mal etwas zickig reagiert.
Beide Male lief das System ohne SecondaryPort, beim zweiten Mal tatsächlich wegen des fehlenden 2. Kabels...
Grundsätzlich versuche ich Secondary vom Primary getrennt zu halten, d.h.:
- keine gemeinsame SpanningTree-Umschaltung
- Secondary - wenn möglich - einfacher gehalten als den Primary = Verzicht auf nicht-Showrelevante Geräte im sekundären Netzwerk, weniger Switches (z.B. Stagebox direkt auf Pult ohne FoH-/Stage-Switch, wenn die Länge für ein Kupferkabel noch passt).
Jedenfalls kriegen wir am Ende der Leitung quasi konstant schon mal 75% Aussteuerung ohne nennenswerten Input im Raum, Netzbrumm und hochfrequentes Zirpen. In allen Räumen dieser Art = ein Fehler im System.
Und darüber möchtest du jetzt ein Dante-Signal schicken?
Und ja diese Beobachtung kann ich oft genug bestätigen:
- zu geringe Beachtung möglicher (technischer) Fehlerquellen in Reihe (viele Steckkontakte)
- zu geringe Beachtung möglicher Layer 9 - Stolpersteine (viele verschiedene Systembestandteile, viele Patchpunkte, kein 1:1-Patch)
- zu wenig Unterteilung der Systemblöcke (= Kombination o.g. Punkte). PA ist PA, Pult ist Pult - Solange man keine aufwändigen Mehrkanalbeschallungen produziert, gibt es keinen sinnvollen Grund warum man die Signale per Dante/AVB oder ähnliches vom Pultsystem ins Beschallungssystem schicken muss. 2x AES3 mit SRC oder analog und gut ist.
Was mir aber immer wieder auffällt ist das zu oft das Konzept des „weniger ist mehr“ völlig außer acht gelassen wird, statt dessen werden unnötig komplexe setups gebaut
Wir sind halt Techniker, lieben das herumspielen mit Technik...
Ob ich ihm nicht einfach ein analoges Signal geben soll wollte ich wissen, aber die Gesichter sprachen Bände, das kurze „klingt nicht gut genug“ machte den Rest.
... und suchen uns gute Gründe warum dies unbedingt notwendig ist.
Mein Fazit: bei aller Planung immer mal wieder hinterfragen ob es nicht einfacher geht!
Wenn's einfach wäre könnte es ja jeder - It's a fucking rocket science, not only rock'n'roll 
Was für ein Abgriff genau ist das denn? Input, CH Pre-EQ, CH Pre-Fade, CH Post-Fade...?
Ahhh, eine sprachlich einwandfreie Version ist geboren.
Was SQ7 betrifft. Der Text für SQ5/SQ6 ist noch unverändert.
Völlig klar, mir bekannt und zweifelsohne ist 'dedicare' der lateinische Worstamm für 'to dedicate'. Es verhält sich allerdings so, dass der lateinische Wortstamm als solcher im Englischen sehr viel häufiger vorkommt als im Deutschen und der Schluß, dass es immer eine deutsche Entsprechung zum Wortstamm geben muß, nicht zutrifft und keinesfalls eine Übersetzungshilfe darstellt. Im Kontext meiner kleinen "Analyse" habe ich mir daher erlaubt, als virtuellen Stamm von 'dediziert' von
...
zu sprechen und fühle mich im Rahmen dieser Verhohnepiepelung in meinen Mutmaßungen völlig frei, solange es das Lateinische hergibt.
Bist du sicher dass du mich damit ansprechen wolltest? Ich habe nichts geschrieben zum lateinischen Ursprung, könnte ich auch nicht da ich Latein nach dem ersten Jahr abgewählt habe. War mir etwas zu weltfremd in meinem jugendlichen Dasein.
Ehrlich gesagt ist es mir auch wurscht. Ich bin kein Sprachforscher, habe grundsätzlich jedoch einmal einmal gelernt dass es Nachschlagewerke für solche Themen gibt, welche von Fachleuten erarbeitet werden. Und wenn man ein Problem mit dem Inhalt hat kann man das gerne kundtun, aber an der richtigen Stelle.
Genau wie der werte Herr Sengpiel seinen Studenten gegenüber und in seinen Unterlagen stets betont hat dass ORTF eine Mikrofonbasis von 17cm hat, nicht wie vielfach publiziert 17,5cm. Er hat dabei allerdings stets in seinem Fachbereich (und den entsprechenden Foren) agiert.
Für mich verhält es sich so: Sprache verändert sich (hat sie schon immer), die Herkunft ist mir persönlich vergleichsweise egal (solange einem Gossensprache oder Dialekt nicht als ordentliche Hauptsprache verkauft wird), ich muss in den angesehenen Nachschlagewerken (zu denen der Duden nun mal zählt) die Existenz und Bedeutung verifizieren können.
Und auch wenn der Einsatz des Wortes für eindeutig zweckbestimmte Gegenstände vielleicht dort nicht direkt aufgeführt wird, so ist es durch die Alternativverben "bestimmen" und "vorsehen" doch zumindest nachvollziehbar.
auch wenn das wiki behauptet, es wäre deutsch, beim Beispiel 'dedizierte Server' handelt es sich ebenfalls um eine Bedienungsanleitungsübersetzung mit albernem pseudoakademischem Anglismus mit lateinischem Wortstamm, der bei Unfähigkeit, ihn ins Deutsche zu übersetzen und der phonetischen Nähe zu 'dezidiert', einfach mal schnell "eingedeutscht" wurde.
Ich fürchte, hier bist du ausnahmsweise mal auf dem Holzweg.
Auch der Duden kennt "dedizieren" nicht als "verweigern", sondern als "zuordnen, widmen, für ihn (oder halt etwas) bestimmen".
-> https://www.duden.de/suchen/dudenonline/dediziert
Der Sinn von "dezidiert" würde sich mir in diesem Zusammenhang auch nicht recht erschliessen wollen:
Aber dafür haben sie mal eben den allseits gewünschten Offline Editor programmiert
Wieso unterschiedlich? Beide Artikel beziehen sich auf das selbe Stadion - einmal Festinstallation, einmal Temporärinstallation für‘s Rahmenprogramm. Keine Seltenheit bei solchen Anlässen, siehe Superbowl.
