Beiträge von TWOsider

Zitat von "marcoboy"

Er hätte den Controller Port mit der IDR Switch verbinden müssen.

... und sich damit grob in den Fuß geschossen.

Sorry, aber hättest du die Dokumentation aufmerksam gelesen, wäre dir dieser Absatz aufgefallen:
Please note bridging the iLive network over Dante is not supported with current firmware V3.4.x as it would drop the Primary link to 100Mbit/s.

Evtl. möchtest du diesen Hinweis auch in dein Posting im Audio-on-PC Brett einfügen ...

Zitat von "marcoboy"

Die Dante Karte hätte dann Adressen aus ihren Bereich an alle Geräte verteilt!

Wo hast du denn das gelesen? Seit wann hat die Dante-Karte einen internen DHCP-Server? Dein Rechner wird sich in Ermangelung einer Antwort von einem (nicht vorhandenen) DHCP-Server irgendwann "von selbst" eine Link-Local-Adresse (169.254.0.0/16) geben, dieses Verfahren nennt sich auch "Zero Config" bzw. "Bonjour". Hierzu schreibt die iLive-Dokumentation:
Because iLive devices do not support Zero Config auto addressing, on a network without DHCP you would need to manually assign each device (MixRack, Surface and TouchScreen) to a compatible address in the 169.254.xxx.xxx range.

Also: Entweder man hat richtiges DHCP und alles wird gut oder man hat kein DHCP und konfiguriert zumindest die iLive-Adressen manuell und alles wird auch gut. Aber kein DHCP und iLive "mal machen lassen" läuft nicht.

Zitat von "marcoboy"

32 Kanäle mit 24bit und 48KHZ macht einen Datenstrom von ca. 44Mb/s

Was für "Mb"? Megabyte? Dann ist das falsch. Deine 32 Kanäle mit 48 kHz und 24 Bit Wortbreite belegen 4,6 MB/s (bzw. 4,4 MiB/s, wenn dir das lieber ist) an Rohdaten. Und falls es Megabit gewesen sein sollten: Auch falsch, wären dann 36,9 MBit/s (bzw. 35,2 MiBits/s). Bitte ... vor dem Posten nochmal lesen und kurz drüber nachdenken ...

Rein von der Datenrate sind selbst hunderte Spuren für eine aktuelle Festplatte kein Problem, viel interessanter ist die Anzahl der einzelnen Ströme, die parallel verarbeitet werden können. Bedingt durch die (je nach Dateisystem und Fragmentierungsgrad) notwendigen Kopfbewegungen sind dieser Größe nämlich Grenzen gesetzt. Eine normale 7200er Platte schafft in der Größenordnung von 100 IOPS (Ein-/Ausgabe-Operationen pro Sekunde), selbst "schlechte" SSDs kommen hier schon auf 10.000 und die im High-End-Bereich auch schon über 100.000.

Wirklich notwendig ist eine SSD also nicht, aber die Vorteile in Form von (im Vergleich zu einer mechanischen Platte) höherer Vibrationstoleranz, schnellerem wahlfreiem Zugriff, schnelleren Transferraten und geringerem Stromverbrauch überweigen den Preisnachteil für diese Anwendung deutlich. Warum wegen 200 € die (unwiederbringliche) Aufnahme aufs Spiel setzen, weil durch eine Unachtsamkeit evtl. der Laptop/die externe Platte/das Case mit dem Recording-Rechner beim Abbau runterfällt? Nicht wirklich.

Hier läuft in älteren Thinkpads X60t eine Intel X-25 Postville mit 80 GB sowie eine weitere mit 160 GB tadellos, die Intel SSD Toolbox bescheinigt volle Gesundheit.

n'Abend

Kleines Digitalpult nehmen, (Sinus)-Signalgenerator als Quelle für entsprechend viele Kanäle routen. Direct-Outs dieser Kanäle post-Fader auf jeweils einen physikalischen Ausgang patchen, simple Diode zur Einweg-Gleichrichtung und passend dimensionierten Kondensator zur Glättung dran, Ausgang passend pegeln und ab damit auf den 0-10V-DMX-Konverter.

Für 2-3 Kanäle Frontlicht sowie Backdrop in rot oder blau kann man sowas sicher mal machen, für alles was darüber hinausgeht ist ein dediziertes Lichtpult eher angebracht. Der Platzvorteil ist ja sonst ob der vielen parallel im Zugriff benötigten Fader auch wieder dahin: für Kleinkunst im Kellertheater schlägt man ja nicht mit Vi6 vor Ort auf, bloß "weils geht" und ich "alles in einem Gerät" steuern kann.

Wobei: MY16-DMX für Yamaha bzw. M-DMX für A&H hätte sicher seinen Reiz

Ach ja, fast hätte ich es vergessen zu erwähnen: Die weiter oben im Thread angesprochene Problematik (Link zum Posting), dass es zwischen mehreren Gain-Stufen keinen Unterschied in der tatsächlichen Verstärkung gibt, existiert bereits auf der Ebene des Netzwerks.

Das heißt, der Preamp kann gar nicht unterscheiden, ob das Pult jetzt beispielsweise 36 oder 37 dB Gain haben möchte, denn die Bitfolge ist in beiden Fällen die gleiche.

Und klar: Prinzipiell könnte sich jetzt jemand mit Ahnung von ASIO und Konsorten hinsetzen und einen Treiber ähnlich der DVS schreiben. Bevor ich aber diesen Aufwand betreibe, kaufe ich mir eher die Dante-Karte und fange mit der gesparten Zeit etwas für mich persönlich sinnvolleres an ... nur bevor gleich die ersten Fragen nach dem Termin der Fertigstellung auftauchen

Edit: Absatz über ASIO-Treiber hinzugefügt.

wora: I/O-Port ist quasi der "Port B" der GLD, hier würde man die Kanäle von ACE, Dante, MADI, usw. patchen.

Ich kann nach Analyse des Protokolls sagen, dass dSNAKE in der Tat 64 Kanäle vom Pult zur AR2412 schickt, und zwar in jedem Paket jeweils ein Sample aller 64 Kanäle. Hab mir auch bereits ein (derzeit noch sehr popeliges) Python-Script geschrieben, was mir quasi ein Multitrack-Recording der Ausgänge (und auch der besagten "Monitor"-Ports, die sich natürlich auch mit dem Direct-Out von Eingängen belegen lassen 8)) erlaubt, das Protokoll ist sehr einfach aufgebaut. Das Pult schickt auf dem dSNAKE- und dem Expander-Port jeweils die gleichen Audio-Daten raus. Unterschiede gibt es nur im Clocking, siehe unten. Sehr schick ist, dass man für die reine Netzwerk-Übertragung hier quasi (ohne die Puffer in den Geräten zu beachten) nur ein Sample Latenz hat.

Zitat von "marcoboy"

Man kann die AR2412 + AR84 auf beiden Ports betreiben.

Falsch. Am Expander-Port des Pults angeschlossen bekommt die AR2412 keinen Lock, d.h. die "Ready"-LED unten links im Output-Bereich geht nicht an und die Relais geben die Ausgänge auch nicht frei. Warum: Siehe unten.

Zitat von "marcoboy"

Die switch sorgt nur dafür das die AR84 als Expander erkannt wird.

Auch falsch. Das erste Datenbyte jedes Pakets wird für die das Clocking verwendet, anhand eines gesetzten oder nicht gesetzten Bits in diesem Paket erkennt die AR84, ob sie am Expander-Port des Pults oder am Expander-Port der AR2412 betrieben wird und greift sich entsprechend die richtigen Samples aus den Paketen für die Wandler heraus bzw. setzt die gewandelten Samples an den richtigen Stellen in den Paketen ein. Das ist auch der Grund, warum die AR2412 keinen Lock am Expander-Port bekommt: Das Bit ist hier schlicht "falsch" gesetzt.

Essenz des Ganzen: Mit ein wenig Software kann man sich (zumindest fürs Recording) eine Erweiterungskarte sparen. Wer genug Platz hat, schneidet einfach den kompletten Datenstrom über Wireshark mit und dekodiert anschließend die einzelnen Spuren heraus. Theoretisch kann man dann sogar im Nachhinein noch feststellen, wann man wie am Gain gedreht hat, Steuerdaten für die Preamps wandern nämlich (logischerweise) auch pro Paket immer in Gruppen zu je 8 Eingängen (also pro 8er-Modul) über die Leitung, für den Gain werden dabei 10 Bits verwendet, wie genau dabei welcher absolute "dB"-Wert kodiert ist kann ich im Moment aber noch nicht sagen, derzeit hab ich nur eine Werte-Tabelle.

Apropos Gain: Da dein Pult ja inzwischen da ist Marco, konntest du mit den Gain-Stufen schon etwas testen?

Grüße
Joern

n'Abend

Zitat von "marcoboy"

Das Eigentlich Audiosignal benötigt keine IP Adresse nur der Controller.

Falsch. Dante arbeitet auch für die Übertragung der Audio-Daten auf Layer 3 und damit auf IP-Ebene, ohne eine passend - per DHCP, als zeroconf link-local Adresse (das sind besagte Adressen aus dem Netz 169.254.0.0/16) oder eben manuell - vergebene Adresse läuft kein Audio. Die eigentlichen Samples werden in UDP-Paketen versandt, die passende Wahl für eine Echtzeit-Anwendung.

Zum Thema QoS (und bevor hier noch mehr nicht ganz richtige Pauschalaussagen verbreitet werden):
Die geforderte QoS-Unterstützung in Form von "Differentiated services" (oder kurz DiffServ) gestaltet sich auf den Switches vereinfacht so: Jeder Port hat mehrere Queues (Warteschlangen), in die Pakete nach ihrer Priorität geordnet einsortiert werden. Pakete, die in der ersten Schlange warten, werden bevorzugt behandelt. Wenn diese Schlange leer ist, kommt die nächste Schlange zum Zug und so weiter. Endgeräte (also z.B. die Dante-Karte) markieren nun ihre Pakete mit einem sog. PHB (per-hop behavior) und teilen damit jedem "Hop" mit, wie sie das Paket behandelt sehen wollen. Für Audio kommt hier eigentlich nur das PHB "Expedited Forwarding" (EF) in Frage, was einen schnellen Transport mit geringer Latenz sicherstellen soll.

Im Hinterkopf muss man behalten: Die ganze QoS-Geschichte ist eine "Bitte" des Absenders, mit seinem Paket so und so zu verfahren. Daran halten muss sich keine der Netzwerk-Komponenten. Je nach Preisklasse der Switches kann man die Zuordnung von DSCP auf Warteschlangen-Priorität auch komplett umkonfigurieren. Daher: Wenn man kann, für Audio-Netzwerke immer möglichst dedizierte Verbindungen schaffen. Sei es das eigene physisch direkt gesteckte Kabel oder das virtuell für die jeweiligen Ports konfigurierte VLAN, wenn man noch anderen Verkehr (Controller- bzw. Funkempfänger-Remote) über dasselbe Kabel schicken möchte oder muss.

Hier noch einige Probleme, die auf der Netzwerk-Ebene auftreten können und dann zu Paketverlust führen, der sich in Form von Dropouts bemerkbar macht. Auch wenn sich der Umstieg auf die Waves-Karte schon nach beschlossener Sache anhört: Vielleicht hilft es, diese Punkte mal abzuklopfen, denn auch Waves Soundgrid arbeitet auf Ethernet-Basis. Eine Liste mit zertifizierten Switches gibt es unter http://waveslive.com/html/soundgrid-switches.aspx, lustigerweise ist der Netgear GS108 (ohne QoS) zertifiziert, die Variante GS108E (mit QoS) ist hingegen nicht auf der Liste ...
Und aufpassen: Waves Soundgrid braucht Unterstützung für Jumbo-Frames auf dem Switch.

• Überlauf einer Queue. Je nach Kapazität der Backplane kann ein Switch mehr oder weniger geeignet für große Paketraten sein. Audio-Netzwerke kommen durchaus auf Raten von 50.000 Paketen pro Sekunde, bei Dante hat man 2400 Pakete pro Sekunde je 4 Kanäle bei 48 kHz und 24 Bit Wortbreite, für 64 Kanäle also grob 38.400 Pakete pro Sekunde. Gleiches gilt natürlich für den Ethernet-Controller im Rechner sowie den Treiber. Die vielen kleinen Pakete erzeugen auf dem Rechner u.U. eine hohe Interrupt-Last, die dann nicht bewältigt werden kann. Aus der Erfahrung meide ich daher jeglichen Realtek-Controller sondern nehme immer Intel bzw. Konsorten. Und natürlich weitere unnötige Hardware abschalten sowie Dienste deaktivieren. Der Recording-Rechner braucht kein Bluetooth/WLAN/Infrarot. Evtl. helfen die SAC-Tuning-Tipps hier weiter.
• Broadcast-Storm-Detection und andere Sicherheitsfeatures. Manch ein Switch glaubt in den großen Paketraten von Audio-Netzwerken einen Angriff auf die Infrastruktur zu erkennen und begrenzt dann die Rate künstlich, um anderen Datenverkehr nicht zum Erliegen kommen zu lassen. Daher: Solche Features ausschalten wenn vorhanden.
• Begrenzung der absoluten Raten von EF-Traffic. Auf machen Switchen (z.B. bessere Cisco) kann man einstellen, dass Pakete mit EF-PHB nur maximal z.B. 50% der effektiven Bandbreite belegen dürfen, damit sich der bevorzugte Verkehr nicht gegenseitig behindert und der Jitter stabil bleibt. Was für den üblichen VoIP-Verkehr in Unternehmens-Netzwerken noch Sinn macht (wo die Telefonie nur ein Dienst unter vielen ist), ist in Audio-Netzwerken eher kontraproduktiv. Daher auch hier: Feature abstellen, volle Bandbreite freigeben.
• Spanning-Tree. Das Spanning-Tree-Protocol (STP bzw. heutzutage eher Rapid-STP) verhindert, dass Schleifen in der Netzwerk-Topologie dazu führen, dass Pakete ständig im Kreis reisen und das Netz auslasten. Dazu senden Switches periodisch (standardmäßig alle 2 Sekunden) sog. BPDUs um ihre Nachbarn kennenzulernen und die Topologie zu bestimmen. Redundante Pfade werden dann automatisch abgeschaltet um im Fehlerfall (z.B. Kabeldefekt) umgeschaltet werden zu können. Diese Pakete sind wichtig für das Funktionieren des Netzes, werden daher bevorzugt behandelt und können dazu führen, dass der Switch andere Pakete einfach wegschmeißt, z.B. wenn die Warteschlage dann zu voll wird. In der vom Thread-Starter beschriebenen Topologie gibt es keine redundanten Pfade und ich denke auch nicht, dass er sich welche bauen möchte, von daher: Spanning-Tree auf dem Switch abschalten.
• Broadcast-Traffic. Wenn möglich, jeglichen Broadcast-Traffic auf dem Netzsegment vermeiden. Pakete an Broadcast-Adressen werden vom Switch auf allen Ports ausgegeben und belegen damit wertvollen Platz in den Warteschlangen sowie Bandbreite und Zeit auf der Leitung. Die Windows Datei- und Druckerfreigabe erzeugt z.B. regelmäßig solchen Verkehr im Netzwerk um andere Rechner und ihre Freigaben schnell anzeigen zu können. Unnötig, abschalten.

Meiner Ansicht und Erfahrung nach lohnt sich eine QoS-fähige Infrastruktur nur dann, wenn man vorhat, in großem Maße auch noch anderen Verkehr über das gleiche Netzwerk zu schicken und priorisieren muss. Ansonsten ist das eher nur eine Fehlerquelle mehr und damit kontraproduktiv.

Viel Erfolg & Grüße
Joern

Zitat von "Jens Droessler"

Praktisch fände ich auch eine Schublade für eine Tastatur

Kann man sich sparen, denn (zumindest bei dem Pult hier und in der aktuellen Firmware 1.02) funktioniert weder eine Cherry G80 noch eine Logitech K120, d.h. ich bin mir nicht sicher, ob der Linux-Kernel in der GLD überhaupt was anderes außer der Mass Storage Device Class unterstützt. Ist aber nicht sooo tragisch: der Dialog zur Namenseingabe hat unten 15 frei belegbare Preset-Felder, die auch Teil der Showfile sind und abgespeichert werden.
Edit: Ein anderer User hat eine Logitech K120 an seiner GLD laufen: Link zum Beitrag.

Zusätzliche Rackplätze für CD-Player und USV machen die Kiste für das Pult nur unnötig groß und schwer, ein großer Vorteil der GLD ist ja grade ihr geringes Gewicht. Bei größeren Pulten gerne, aber bei der GLD bleibt das bei uns auch extern.

Kabelfach mit Deckel vergrößert die Kiste natürlich auch, ob man sowas als Schutz vor Publikumsfingern und -Getränken braucht muss jeder selbst entscheiden. Und wen das penetrante blau der Power-LED hinten am Pult stört, kann dem auch mit einem Deckel beikommen

Es gibt ein paar Sachen, die verhindern, dass man mal eben eine Show von der iLive auf die GLD schieben könnte, u.a.:

• iLive hat 64 (bzw. 128 bei Dual-Rack) Kanäle, GLD hat 48 (FX-IPs jeweils nicht mitgerechnet)
• iLive kann benachbarte Input-Kanäle flexibel zu Stereo-Kanälen verknüpfen (MIX RACK Hardware-Taste, Mixer Config, IP Stereo). GLD hat eine feste Aufteilung auf 44 Mono- und 2 Stereo-Kanäle
• iLive hat 32 Mix-Busse, GLD hat 20

Von GLD auf iLive wäre in der Theorie so natürlich kein Problem, ist ja quasi eine Teilmenge. Da diese Dinge alle irgendwie mit dem jeweils in der Hardware verbauten DSP verbunden sind, lässt sich das wahrscheinlich auch nicht per Software-Update kompatibel machen.

Eine Konverter-Software von iLive auf GLD müsste aber unter Umständen zwangsweise sagen: "Sorry, du hast da drei Stereo-Kanäle definiert, einen davon kann ich dir nicht konvertieren und die Kanäle 35/36 gehen nicht als Stereo. Und von deinen Mix-Bussen musst du auch 4 opfern, welche dürfen es denn sein? Ach ja: Deine für Monitor-vom-FOH gesplitteten Kanäle über 48 sind leider jetzt auch futsch". Bevor ich mir mit einer so "runtergequetschten" Show ein Ei lege, ziehe ich mir lieber die relevanten Kanäle und EQs, Kompressoren usw. als Library-Preset raus und versuche das auf der GLD zu importieren oder fange komplett mit blankem Pult an, das ist sicherer und kostet aber leider Zeit.

Ist übrigens hiermit als Anregung für eine der nächsten Software-Versionen notiert (falls nicht jetzt schon möglich, kann ich grade leider nicht testen): Import/Export-Kompatibilität von auf USB-Stick gespeicherten Gate/PEQ/Kompressor/Kanalzug-Presets aus der Library zwischen iLive und GLD, die Features der einzelnen Blöcke sind ja identisch und damit austauschbar.

Ich möchte bezweifeln, dass es von Allen&Heath für die GLD eine solche Software geben wird, die Shows zwischen den Pulten konvertiert. Auf der Messe wurde außerdem die Aussage verbreitet, dass es keinen Editor ähnlich wie bei iLive für den Rechner geben wird, allenfalls evtl. eine iPad/iPhone-App. Diese Aussagen müssen natürlich nicht in Stein gemeißelt sein, vielleicht überlegt man es sich in England auch nochmal anders.

Man sollte iLive und GLD als zwei verschiedene Produktlinien sehen, sonst hätte man das System auch "iLive-GLD" nennen können. Ich sehe die GLD positioniert als System hauptsächlich für Bands als eigenes Pult, als festes "Haus"-Pult für kleinere Veranstaltungsstätten sowie als Mischsystem für die kleineren Jobs im Tagesgeschäft der Beschaller, jeweils immer mit eigenem Personal. Wer für den Job z.B. ein dediziertes Monitorpult mit parallelem Zugriff auf den DSP, Setup per Rechner, Showfile-Spielchen mit Fremd-Mischerinnen und -Mischern, mehr Fader, mehr Kanäle und mehr I/O braucht, soll sich (um bei Allen&Heath zu bleiben) eine iLive kaufen, da sind diese Dinge integriert bzw. einfach möglich.

Sicher hätte ich auch gerne einen Offline Editor um den Job schonmal trocken vorbereiten zu können, ohne das Pult aus dem Lager holen zu müssen, aber irgendwo muss Allen&Heath die Pulte auch voneinander abgrenzen. Wer sich ein Showfile von der GLD aber mal angeschaut hat sieht, dass ein mehr oder weniger vollständiger Offline-Editor mit überschaubarem Aufwand selbst zu schreiben ist. Das Showfile ist ein gepacktes Archiv, darin stehen im wesentlichen Klartext-Dateien. Zum Beispiel gibt es eine "MixConfig.dat", darin stehen z.B. die Zahlen 1, 0, 2, 8, 0, 6, 1, 1, 2, 2. Bedeutet LR, 0 Mono-Gruppen, 2 Stereo-Gruppen, 8 Mono-FX, 0 Stereo-FX, 6 Mono-Aux, ...

Zitat von "oton"

bei der normalen iLive sind mir solche "Artefakte" [...] noch nie in irgend einer Form aufgefallen

Laut einem Beitrag im iLive-Forum (Link) hat die iLive-T einen anderen Preamp als die modulare iLive. Auch die DA-Konverter unterscheiden sich zwischen den Serien.

A&H schreibt in der auf der Webseite selbst zum GLD Konzept "[...] with a new high-end mic preamp [...]", daher gehe ich davon aus, dass es sich hier um ein weiteres, drittes Design handelt, dass sich von dem der iLive-T und der modularen iLive unterscheidet.

Auf einer T112 (mit 64er iDR) habe ich dieses Verhalten auch nicht beobachten können, explizit darauf geachtet habe ich aber nicht. Gäbe es das Phänomen auf den großen Serien, bin ich mir aber sicher, dass das mittlerweile schon irgendwem aufgefallen sein müsste. Die Pulte sind ja nun schon ein paar Jahre auf dem Markt und auf der Straße unterwegs.

Wenn bei Gelegenheit jemand den Sachverhalt mal an ihrer/seiner GLD nachvollziehen/nachmessen könnte, hätte man mal einen Anhaltspunkt ob es evtl. ein "Fehler" der Hardware ist (quasi der Fall "Montagspult", glaub ich aber nicht) oder ob evtl. meine Messungen nicht ganz grün sind (glaub ich eigentlich auch nicht, aber: nobody is perfect). Freiwillige vor :wink:

In der dicken (16 MB oder so) Broschüre steht auf Seite 2 auch:

Zitat von "Allen&Heath GLD Broschüre"

GLD-80's FX engines are taken directly from the iLive system

Sieht auf dem Bildschirm auch sehr ähnlich wenn nicht sogar identisch aus im Vergleich zur iLive, daher würde ich auch davon ausgehen, dass die Effekt-Algorithmen in beiden Produktlinien gleich sind.

Zitat von "marcoboy"

Also verstehe ich das richtig. Du hast das Signal immer wieder auf 0dbu zurück geregelt oder nur wenn es zu groß wurde oder bei jeden Messpunkt?

Wie ich schrieb: "Den Ausgangspegel des Generators habe ich aller paar Messungen [...] angepasst". Genauer: Alle 10 dB Pegelzunahme um diese 10 dB zurückgeregelt und dann (bei gleichem Gain) eine Vergleichsmessung gemacht, damit ich nicht den Versatz durch die Änderung am Generator mitmesse. Abweichung durch das Zurücknehmen des Generators: max. 0,06 dB, hab ich vernachlässigt.

Hier mal ein 440 Hz Sinus mit Änderungen des Gains: Link.
Zugegeben: Live wird man nicht mit reinen Sinus-Signalen arbeiten. Habe aber grade kein anderes Material was veröffentlicht werden möchte. Bei Gesangspassagen (aus einem Mehrspurmitschnitt) hört man eine Gain-Änderung aber schon (klingt ein wenig wie ein leichtes Tremolo in der Stimme), mit dem Trim passiert das eher nicht. Wenn man einen ungünstigen Zeitpunkt erwischt, könnte ich mir schon vorstellen, dass das im InEar als "störend" empfunden wird.

Der Vertrieb wurde bisher nicht kontaktiert, weil ich es im Moment nicht als kritisches Problem sondern vielmehr als eine Eigenart des Systems sehe. Ich möchte auch nochmal betonen, dass ich das System durch die Schilderung des Sachverhalts hier keineswegs in ein schlechtes Licht stellen möchte. Im Gegenteil: Ich bin ein großer Fan des Konzepts, ob in Form der "großen" iLive mit Mixrack oder der "kleinen" GLD mit Signalverarbeitung im Pult, sonst hätten wir das System nicht gekauft.

Es geht mir auch nicht um die letzte Nachkommastelle, weil das Live schlicht egal ist. Ich hab mich beim Testen nur schlicht gewundert und bin dem aus Interesse genauer auf den Grund gegangen. Jetzt weiß ich (und kann falls nötig Fremdpersonal vorher darauf hinweisen), dass:

• ... die Anzeige auf dem Bildschirm nicht exakt mit der tatsächlichen Verstärkung übereinstimmt.
• ... wenn ich den Gain während der Show anpassen möchte, ich dafür den Trim verwenden sollte, oder - wenn es sein muss - einen Zeitpunkt abwarte, der dafür günstig ist.
• ... alle Kanäle im Pult und im Rack dasselbe Verhalten zeigen (soweit ich das Stichprobenartig untersucht habe), es sich also deterministisch verhält.

Nach dem Soundcheck einmal kurz global alle Preamps auf "Trim on Surface" umgeschaltet "löst" die Problematik auch, danach steuert der Gain-Encoder nämlich den Trim und ich kann ggf. nach der Show die Anpassungen im Trim auf den echten Preamp "umschreiben" und für die nächste Show so in der Session abspeichern.

Von meiner Seite aus hat sich das Thema "Gain" damit erledigt, Danke für die Beteiligung.

Zitat von "marcoboy"

Wie hast du denn gemessen? den Ausgang Belastet?

Sagen wir mal so: Ich bin in der Lage, den Datenstrom nach dem Preamp rein digital abzugreifen und daher meine Pegel-Analyse auf rein digitaler Ebene durchzuführen, eine nachgeschaltete Verarbeitung im Pult und DA-Wandlung auf einen physischen Ausgang war also nicht im Spiel.

Zitat von "marcoboy"

Mit dem 15dbu ich kann nur das sagen was im Datenblatt steht

Im Datenblatt steht "Input Sensitivity: ‐60 to +15dBu", mit den +15 dBu ist das Aufleuchten der Pk-LEDs gemeint. Steht auch weiter unten: "Meter Peak indication: -3dBFS" (+18 dBu - 3 dB = +15 dBu). Für einen Anwender aus der potentiellen Zielgruppe des Pults, der bislang auf einem Analogpult geschraubt hat, ist der plötzlich einsetzende Digital-Clip wahrscheinlich ein Grund zur Sorge, daher kann ich mir gut vorstellen, dass man sich bei A&H hier für 3 dB Sicherheitsabstand entschieden hat. Im Datenblatt steht auch +18 dBu = 0 dBFS. Wenn ich mir den Datenstrom anschaue, scheint das aber nicht ganz richtig zu sein. Die Samples kann ich nämlich nochmal um 3 dB (quasi ein halbes Bit) hochfahren, bevor sie Überläufe haben. Insofern muss ich meine Aussage von oben ("Der DSP hat über +18 dBu noch Luft") etwas relativieren: Ich weiß nicht, ob der DSP tatsächlich noch den Headroom hat, die noch nicht voll ausgesteuerten Samples die ihm angeliefert werden, legen das aber Nahe.

Zitat von "marcoboy"

Die 60db werden auch auch erreicht. 53,1 dB + 5db die immer da sind.

Mein Mathelehrer hat mir da aber was anderes beigebracht, oder ich runde einfach noch nicht hart genug

Zitat von "marcoboy"

Ich glaube das deine Quelle nicht stabil war.

Mal ehrlich: Welchen derart krass in der Amplitude schwankenden Sinus-Generator würdest du für eine Messung einsetzen, wenn es dir im unteren Bereich um ein paar Millivolt geht? Hoffentlich keinen, es sei denn du möchtest unnötig Zeit verschwenden, weil deine Messwerte dann genau nichts Wert sind. Ich habe zu jedem Gain-Wert dreimal mit verschiedenen Frequenzen gemessen, die maximale Abweichung zwischen zwei Messungen lag bei 0,03 dB. Den Ausgangspegel des Generators habe ich aller paar Messungen immer so angepasst, dass ich mit dem Pegel vor dem AD-Wandler immer so im Bereich um 0 dBu lag, einen Quantisierungsfehler aufgrund der geringen Zahl an Bits bei kleinen Pegeln kann ich also meiner Ansicht nach daher ausschließen.

Zitat von "marcoboy"

Es sieht so aus als Ob der Digitale Gain ist ja nichts anderes wie ein Widerstandsnetzwerk

Hab ich auch schon vermutet, zwei auf dem Board je Kanal aufgelötete HCT4051 (8-fach Analog-Multiplexer) umgeben von einer Horde an Teilen, die so aussehen, als seien es SMD-Widerstände könnte das nahelegen. Ich habe die Box aber nicht aufgemacht, sondern nur von außen durch die Lüftungsschlitze reingeschaut, daher kann ich grade nicht direkt sagen, welcher AD-Wandler verwendet wird.

Zitat von "marcoboy"

Das Umschalten ist bei Musik bestimmt nicht zu hören oder? So schlimm ist das nicht.

Kann man so sehen. Fällt für bei entsprechend dichtem Programm-Material wahrscheinlich dem Zuhörer im Publikum auch nicht auf. Die bösen Blicke kommen aber mit Sicherheit von der Bühne, wenn du Leuten während der Show lustige Knackser und hörbare Sprünge im InEar-Monitoring produzierst, wo sie ihren (Gesangs)-Kanal, den du grade nach-gainst, laut und präsent direkt im Ohr haben. Und den Einzelspur-Mitschnitt hat es in dem Moment natürlich auch getroffen. Nach der Show ist dann vor der Nächsten - aber u.U. mit anderem Personal am Pult.

So, ich hab da mal im Rahmen meiner eher bescheidenen Messtechnik etwas vorbereitet:

Das Verbinden der Punkte mit Linien macht eigentlich keinen Sinn, ich habs der besseren Übersicht wegen aber trotzdem gemacht. Der größte Sprung mit 2,5 dB tritt beim Wechsel von 49 dB auf 50 dB Gain auf, hört man auch deutlich. Der nächstkleinere Sprung ist dann 2,1 dB zwischen 43 dB und 44 dB. Danach kommt 1,9 dB zwischen 7 dB und 8 dB usw.
Relativ safe ist der Bereich zwischen 15 und 35 dB, darüber hinaus wirds eher ruppig. Das Input-Metering auf dem Bildschirm stellt die uneinheitliche Zunahme der Verstärkung auch näherungsweise korrekt dar, d.h. es ist kein Problem der Anzeige. Die Pre-Amps im Pult (von denen ich hier einen gemessen habe) und in der AR2412 verhalten sich soweit ich das beurteilen kann was den Gain-Aspekt angeht auch identisch, wäre auch verwunderlich wenn nicht.

Meine Theorie ist ja, dass der mit dem Encoder eingestellte Gain-Soll-Wert im Pult viel feiner als 1 dB aufgelöst ist und dann eine (scheinbar mehr oder weniger gelungene) Umrechnung auf die dazu passende Einstellung der Hardware durchgeführt wird. Es ist nämlich auch so, dass die runde "Balken"-LED-Anzeige oben links z.B. die von einer auf die nächste LED wechselt, obwohl der numerische Wert im Display gleich bleibt, wenn man sehr langsam am Encoder dreht.

Der Regelbereich der im Preamp möglichen Verstärkung erstreckt sich (bei dem Pult, das ich hier habe) über 53,1 dB.

Ob der angezeigte Wert auf der Oberfläche jetzt wirklich 100% der tatsächlichen Analog-Verstärkung entspricht interessiert ja im Tagesgeschäft eher nur tertiär. War ja auf komplett analogen Kisten auch nicht so, dass man der Skalenbeschriftung unbedingt Glauben schenken konnte. Bei einer digitalen Anzeige ist man natürlich in einer ganz anderen Situation: Sie suggeriert, dass der angezeigte Wert auch tatsächlich exakt ist. Deshalb möchte ich es dem System auch gar nicht ankreiden, dass die Anzeige "nicht stimmt". Was ich (ein klein wenig) kritisiere sind die (hörbaren und vor allem uneinheitlichen) Sprünge. Andererseits: Ein analoger I/O-Port in der AR2412 kostet brutto runtergerechnet unter 40 EUR, da rufen andere Hersteller ganz andere Preise für ihre Analog-auf-Netzwerk-Umsetzer-ohne-DSP-Boxen auf.

Viel wichtiger ist die "Rasterung" der einzelnen Stufen (aus Gründen die Klauston bereits angesprochen hat) und da macht die GLD leider nicht ganz das, was drauf steht. Jede Änderung des Gains ist zudem auch mit hörbaren kleinen Klicks verbunden, was sich wahrscheinlich aber prinzipbedingt in der Hardware nicht vermeiden lässt. Wenn man also in einer Live-Situation den Gain "unhörbar" nachführen möchte, sollte man hier besser den Trim verwenden, das geht ohne hörbare Artefakte. Man kann sich alle Preamps gleichzeitig umschalten, dann steuert der Gain-Encoder fortan den Trim und man muss nicht mehr darüber nachdenken.

Zitat von "marcoboy"

Beim GLD ist bei +15dbu Schluss

Das ist so nicht ganz korrekt. Den Vorverstärker selbst bekommt man auf der Analog-Seite nicht sinnvoll übersteuert (zumindest nicht im Rahmen meiner Messmöglichkeiten was THD angeht). Vorher clippt nämlich der AD-Wandler und das passiert bei ziemlich exakt +18 dBu (mit dem Preamp auf Unity-Gain). Vorher geht aber schon bei +16 dBu die Pk-LED an. Der Wert von +18 dB ist auch der "obere Anschlag" aller Pegelanzeigen auf dem Bildschirm. Der DSP selbst hat hier aber noch Luft nach oben, 0 dBFS werden bei umgerechnet +21 dBu erreicht.

Zeit fürs Bett.

Edit: Bild verkleinert, denn horizontales scrollen nervt.

Nach einer ausgiebigen Test-Session scheint es mir so, als gäbe es einen Bug beim digital kontrollierten Analog-Gain. Zwischen den Faktoren

• 5, 6
• 11, 12
• 30, 31
• 36, 37
• 41, 42
• 48, 49

besteht kein Unterschied, d.h. es ist unerheblich ob ich z.B. 30 oder 31 dB Gain einstelle, am Vorverstärker ändert sich dadurch nichts. Erst beim Schritt auf 32 dB ändert sich die tatsächliche Verstärkung. Alle Angaben ohne geschalteten Pad.

Testmethode: Signal-Generator mit Sinus-Ton und passendem Pegel geroutet auf einen beliebigen Ausgang, diesen per kurzem XLR-Patch an einen beliebigen Eingang und dann die Pegel-Anzeige auf dem Bildschirm beobachten, während man den Gain hochschraubt. Bei Zeiten werde ich auch nochmal Messtechnik da dran halten. Ich gehe aber davon aus, dass es nicht bloß ein Fehler in der Anzeige auf dem Bildschirm ist, sondern da tatsächlich irgendwo etwas nicht ganz passt.

Mir ist klar, dass der analoge Gain bei diesem System nur in 1 dB-Schritten digital einzustellen ist und ich will auch keine Pfennigfuchserei wegen einem dB mehr oder weniger betreiben. Es interessiert mich aber durchaus, ob hier einfach ein Bug in der Software ist, oder ob der Preamp gar nicht die spezifizierten 55 dB Einstellbereich hat sondern "nur" 50 dB.

Mit der Bitte um Verifizierung bei anderen GLD / AR2412, die Firmware hier ist 1.02:
Evtl. kann das jemand auch mal auf seiner iLive (T) mit iDR testen, ist ja verwandt.

n'Abend

Trennen der Verbindung zwischen GLD und AR2412 während des laufenden Betriebs ist problemlos. Es passiert genau das, was man auch bei einem analogen Pult beim Trennen des Multicores erwarten würde: Musik ist aus. Ohne Knackser.

Und wenn man das Kabel wieder steckt dauert es ca. 1-2 Sekunden und dann läuft Audio ganz normal weiter. Ohne Knackser.

Die AR2412 hat Relais in den Ausgängen. Diese fallen sofort ab, wenn das Rack den Sync zum Pult verliert. Hat man keine direkte Verbindung zwischen Pult und Rack (sondern geht über einen Switch), sollte man am Besten direkt Gigabit und darauf ein dediziertes VLAN mit Priorität schalten denn die 100 MBit/s werden nahezu 100% ausgelastet. Hier im Test mit einem HP Procurve hat schon das Einschalten von STP (Spanning Tree) auf dem Switch ausgereicht, um im Abstand von 2 Sekunden Dropouts in Form von Knacksern auf den immer gleichen Kanälen zu erzeugen, der Sync geht aber dadurch noch nicht verloren. Gefährlich ist auch Broadcast-Traffic auf dem gleichen Netzwerk-Segment. Pult und Rack kommunizieren soweit ich das analysieren konnte auf Layer 2 über LLC per Broadcast miteinander, d.h. nicht IP-basiert. Das Pult selbst kann man über eine Art MIDI-over-IP fernsteuern, dazu gibts bei A&H auf der Seite eine PDF mit den möglichen Befehlen.

An Kabeln funktioniert hier 60m "Siemens" S/UTP auf Trommel mit Ethercon sowie 20m "Baumarkt" FTP bzw. SF/UTP mit Standard-RJ45 jeweils problemlos. Aufgerollt, abgerollt, egal. Neben dem dicken CEE/Harting wurde es jetzt noch nicht getestet, aber da mache ich mir wenig Sorgen.

Ein guter Indikator für die Qualität der Verbindung zwischen Rack und Pult sind die Lnk/Err-LEDs direkt neben den Buchsen. Wenn ich hier testweise eine Strecke von gut 130m aus der 60m Trommel, mehreren 20m Patchkabeln und dazu der Hausverkabelung zusammenstückele (und damit die A&H-Spezifikation von 120m überschreite und dazu mit mehreren Kupplungen und Steckverbindungen hantiere) kommt die Verbindung trotzdem zu Stande, Audio läuft mit vereinzelten Dropout-Knacksern (einer etwa alle 10-20 Sekunden) und die Lnk/Err-LEDs leuchten rot. Tausche ich ein 20m gegen ein 5m Patchkabel (also jetzt etwa 115m) klappts ohne Dropouts und mit gelb blinkenden LEDs, also Normalzustand.

Gutes System

Phantomspeisung geht dank dem Gesamtschirm, man muss allerdings darauf achten, dass die ganze Strecke durchgängig einen Schirm hat und alle verwendeten RJ45-Stecker und -Buchsen diesen auch durchverbinden. Bei Ethercon ist das gegeben und die kurzen Patch-Kabel gibts auch mit Metall-Stecker.

djobi: Recht so, gilt natürlich auch für das in Kongresszentren und anderen Lokalitäten deutlich häufiger auf RJ45 anzutreffende ISDN (3/6 und 4/5).

Grüße
Joern

Das geht sehr problemlos und die Schirmung macht auch keine Probleme, wenn es nicht grade "nur" ein UTP-Kabel ist. Wir haben hier 60 m S/UTP (also nur Drahtgeflecht-Gesamtschirm und sonst nix) auf Trommel und können nicht klagen.

Übersprechen zwischen den Paaren ist auch kein Thema, ich habe das grade mal mit den besagten 60 m getestet (Sinus-Signal auf einem Weg, gemuteter Ausgang auf dem anderen Weg, entfernte Enden jeweils an Eingängen angeschlossen) und messe hier eine Übersprechdämpfung in der Größenordnung von 80 dB.

Mit dem D-Gehäuse von Neutrik haben wir uns Adapter von XLR5 auf RJ45 gebaut (und die Belegung mit 4/5 und 7/8 so gewählt, das grade die Paare verwendet werden, die nicht von (Fast)-Ethernet genutzt werden, damit - sollte sich jemand mal "verstecken" - nichts schief geht). Dazu dann Kabel-Adapter von 2x XLR3 auf 5 und zurück:

An den RJ45-Neutrik-Teilen muss man zwar vor dem Einbau noch ein wenig rumfräsen (sind eigentlich nicht zum Einbau in dieses D-Gehäuse gedacht) aber dann passt das und ist robust.

Grüße
Joern

Bezüglich der Latenzen und Puffergrößen habe ich grade mal die Folgende kleine Messreihe mit einer Motu Ultralite MK3 angestellt. Zeiten jeweils für die Strecke AD - Input-Kanal in einer DAW - Direktes Monitoring auf einen Ausgang der DAW - DA. Die Puffergröße wurde so gewählt, dass innerhalb von zwei Minuten keine hörbaren Klicks zu vernehmen waren. Auf beiden Systemen läuft die gleiche DAW-Software.

Thinkpad X60 mit Core2 Duo 1,5 GHz, beide Kerne ca. 90% ausgelastet, Windows 7 32-bit, Ricoh Firewire-Chipsatz, Motu-Treiber 4.0.4.6150:

• Firewire: 128 Samples Puffergröße, gemessene Latenz: 10,2 ms.
• USB2: Selbst bei 1024 Samples nicht ohne Klicks möglich, reduziert man die CPU-Last auf unter 50% läuft es auch mit 128 Samples.

MacBook Pro Quad-Core i7 2,3 GHz, alle Kerne auch ca. 90% ausgelastet, OS X 10.6.8, Motu-Treiber 1.6 45936:

• Firewire: 128 Samples Puffergröße, gemessene Latenz: 7,8 ms.
• USB2: 64 Samples Puffergröße, gemessene Latenz: 5,8 ms.

Im Leerlauf bzw. wenig Last arbeiten beide Systeme problemlos mit 64 Samples, weniger kann man im Motu-Windows-Treiber leider nicht einstellen.

Zugegeben, der Vergleich ist alleine wegen der doch sehr unterschiedlichen Rechenleistungen nicht fair. Was mich wundert ist (1) die größere Latenz unter Windows trotz gleicher Puffergröße im Treiber und (2) dass USB auf dem Mac scheinbar "besser" läuft als Firewire, das hätte ich bis eben (unabhängig von der Plattform) noch anders vermutet. Unter Windows kommen die Pufferleerläufe auch eher sporadisch, auf dem Mac ist der Unterschied zwischen "reicht" und "reicht nicht" sofort recht drastisch zu hören.

Zitat

Was 1x64 Sampels bedeuten hängt von einigen Faktioren ab: Hardware, Software, Modell der Wandler usw...grob fahrlässig kann man so mit 5-7ms Sekunden rechnen.

Bestätigt

Möglicher FOH-Einsatz bei leisen Veranstaltungen war der Grund für die Powerware, deren Lüfter ist nämlich bei Netzbetrieb in der Drehzahl stark reduziert und dreht erst bei Netzausfall mit voller Leistung. Wenn die Netzversorgung dann wieder hergestellt war, dauerte es je nach Last u.U. 2-3 Miuten bis wieder Ruhe eingekehrt ist. Und wenn die Temperatur zu hoch wurde, hat der Lüfter aber auch schonmal Gas gegeben, passierte aber nur draußen im Sommer. Die 9125i wird nicht mehr hergestellt, ob die Nachfolge-Serie auch noch diese Art von Lüftersteuerung hat, weiß ich nicht.

Die beiden großen Rackmount APC haben permanente Lüfterkühlung, für leisere Sachen also eher nichts. Die kleinen APC haben keine Lüfterkühlung und sind still (von einem wirklich minimalen Sirren mal abgesehen).

Grüße
Joern

Mit APC macht man nichts falsch, hier laufen bisher unauffällig und ohne Probleme:

• Smart-UPS 1500VA, ~3 Jahre
• Back-UPS RS 800VA, ~2 Jahre
• Back-UPS Pro 550VA, ~6 Monate

Die kleinen Back-UPS sieht man auch sehr häufig an diversen Supermarkt-Kassen oder anderen POS-Systemen. Aus der 800VA wird ein Rechner mit etwas älterer 1,8 GHz AMD-CPU, unspektakulärer Grafikkarte, 2 GB RAM, 3x Festplatte, TFT-Monitor, 19" 24-Port HP-Switch, WLAN-AP sowie 2x Motu 828MK2 versorgt. Die USV meldet für diese Konfiguration eine Auslastung von 30% im Leerlauf und etwa 35% bei ausgelasteter CPU.

Bis vor etwa einem halben Jahr hatten wir auch eine Powerware 9125i verwendet, bei der sich allerdings dann mal beim Anschluss ans Netz im Ausgangsteil mit einem lauten Knall ein Halbleiter verabschiedet hat (der Anschluss war vorher geprüft und auch in Ordnung). Das Gerät war zu dem Zeitpunkt etwa 4 Jahre alt, ich kann nicht ausschließen, ob es über die Zeit nicht auch mal unvorteilhaft vom Netz versorgt wurde. Einen Überspannungsschaden hatte aber bisher keines der jemals angeschlossenen Geräte, daher: Job erfüllt.

Aus Erfahrung sollte man die Akkus in einer USV bei Gelegenheit auch mal vor dem Ablauf der angegebenen Standzeit tauschen. Wenn sich so ein Akku mal aufgebläht hat, geht er nämlich nur noch schwer oder gar nicht aus dem Schacht raus - kürzlich bei beiden 1500er Smart-UPS erlebt.

Auch wenn ich es objektiv nicht begründen kann, würde ich keine Steckerleisten-USV wie die angesprochene BE700 kaufen. Dann lieber direkt z.B. die preislich auch nicht wesentlich teurere Back-UPS Pro BR900 [1], durch die eingebaute Anzeige hat man direkt auch einen Überblick über die Netzspannung sowie die aktuelle Auslastung und Restlaufzeit im Falle eines Ausfalls. Etwas blöd ist natürlich die Adapteriererei von Kaltgeräte zurück auf Schuko, aber dafür gibt es auch passende Dreierdosen. Ganz schlecht ist Kaltgeräte aber auch nicht: Man verhindert effektiv, dass sich dritte mit ihrem Bratgerät an die USV stecken

Grüße
Joern

[1] http://www.apc.com/products/resou…ase_sku=BR900GI