Konsolenbau fürs (Simultan-)Dolmetschen

moeffju · 2020-01-30T15:47:00.007Z

Liebe Sendegate-Community, entschuldigt bitte mein ein bisschen Off-Topic-Post.

Ich bin Teil von c3lingo, der Dolmetscher*innen-Community, die u.a. bei Chaos-Events wie dem CCC Congress und Camp, aber auch bei anderen kulturellen und sozialen Veranstaltungen wie z.B. dem Fusion-Festival oder TIN-Solifest Simultanübersetzungen anbieten.

Das Projekt läuft seit vielen Jahren, aber besonders seit wir verstärkt außerhalb des C3 aktiv sind, haben wir häufig Probleme mit unserer Hardware. Außerhalb des Congresses gibt es häufig keine Infrastruktur und/oder wenig Budget fürs Dolmetschen. Deshalb möchten wir eigene Dolmetsch-Konsolen bauen, die möglichst offen und frei sind, günstig in der Anschaffung, und mit zugeschnittenen Features.

Dafür suche ich mehr Informationen und Unterstützung mit Wissen, Tipps, gerne auch aktive Mithilfe bei Planung und Bau. Mehr Details im Folgenden.

Auf dem Markt gibt es sowas meist nur als Systeme, Zielgruppe sind Konferenz-Center und Großveranstaltungen, entsprechend kostet eine Konsole vier- bis fünfstellig und braucht obendrein noch mehr Hardware für Signalverteilung und -verarbeitung. Mieten ist etwas günstiger, aber immer noch prohibitiv teuer für kleine, oft selbstorganisierte Veranstaltungen.

Was sollen solche Konsolen können?

Sprecher*innen-Audio einspeisen (per XLR) und auf 2-3 Kopfhörer/Headsets ausgeben, damit die Dolmetscher*innen den Vortrag hören können
Gedolmetschtes Audio von den 2-3 Headsets oder Mikros (per XLR, Klinke, oder Kombination angeschlossen) aufnehmen und nach außen leiten (üblicherweise zu einem Mischpult, FOH, etc. - aber “außerhalb unserer Verantwortung”); entweder schon vorgemischt oder einzelne Signale pro Mikrofon
Die Kopfhörerlautstärke sollte separat regelbar sein
Optional sollte man das eigene Mikrofonsignal bzw. das der Co-Dolmetscher*innen in den eigenen Kopfhörer mischen können zum Monitoring, dann sollten auch die Verhältnisse von Stage-Signal, eigenem Mikro und anderen Mikros einstellbar sein
Jedes Mikrofon sollte dauerhaft schaltbar (ein/aus) sein, ohne Störsignale abzugeben
Jedes Mikrofon (oder der gesamte Output) sollte eine Räuspertaste haben, um das Signal kurzzeitig zu ducken
Durch LEDs oder Leucht-Buttons sollte signalisiert werden, welche(s) Mikro(s) “on air” sind
Optional wäre eine von außen steuerbare Signal-LED schön, die anzeigt, ob das Signal “upstream” noch “on air” ist, d.h. ob es noch an Zuhörende ausgespielt wird oder schon “abgredeht” ist
Ebenfalls optional wäre eine einfacher Rückkanal schön, um der Upstream-Technik zu signalisieren, wenn es irgendwelche Probleme oder Fragen gibt, z.B. “Wir hören nichts, bitte Input prüfen”, “technisches Problem, bitte vorbeikommen”, und so.
Alles sollte gegen EM wie Mobilfunk, DECT und Wifi geschirmt sein, damit keine Störsignale reinkommen.

Bonus-Features, die extrem praktisch für unsere Anwendungsfälle wären:

Integriertes Pre-Mixing und Recording, so dass man nach der Veranstaltung schnell mehrsprachige Aufzeichnungen veröffentlichen kann (das könnte aber auch in einer Art Head Unit pro Saal stattfinden)
Optionales Auto-Ducking: Wenn kein Mikro an ist, sollte der O-Ton einfach durchgeschleift werden, wenn mindestens ein Mikro an ist, sollte der O-Ton auf einen einstellbaren Pegel “geduckt” werden
Monitoring- oder Recording-Ausgänge wären praktisch
Signaling zum Mixing Booth und zur Bühne wäre praktisch, um z.B. den Vortragenden ein “Slow Down”-Signal zu geben oder den Techniker*innen ein “Irgendwas geht nicht richtig, aber wir können auch nicht unterbrechen, bitte kommt vorbei”-Signal
Möglichkeit, auch eine externe “On Air”-Leuchte oder -LED zu schalten, wäre willkommen
Relais-Option, d.h. Mehrkanalfähigkeit, z.B. wenn das Stage Audio auf Deutsch ist, gibt es eine*n Dolmetscher*in, dx DE->EN übersetzen, und eine*n zweite*n, dx dann das Relais-Signal (EN) bekommt und EN->FR übersetzt.
Wenn man USB oder SD-Karte einstecken könnte um das Ding zu konfigurieren und z.B. auch Events an REST-APIs schicken könnte, wäre das ein sehr nicer Bonus, ebenso SSH-Zugang oder Web UI o.ä.

Beispiele für verschiedene Konsolen, mehr oder weniger fancy:

https://www.jts-europe.de/produkte/installation/dolmetscher-systeme/it-12d/ (auch als Enersound IC-12 verkauft, ~900€)
https://www.williamssound.com/catalog/ic-2 (~1500€)
https://www.shure.com/en-US/products/conference-discussion/mxc/mxcic
https://www.riedel.net/en/products/intercom/intercom-panels/commentary/ (~15000€)

Ihr seht, das ist alles recht teuer, häufig mit krassen Lizenzen belegt, und oft nicht mal als nicht-Unternehmen kaufbar. Wir möchte gerne etwas, was jede*r bauen oder bezahlen kann, wovon wir auch einfach mal ein paar im C3VOC haben können und verleihen können, was flexibel ist, unter offenen Lizenzen steht, etc.

Gerne würde ich mich mit Menschen, die von Audio-Hardware, insb. den Eigenbau davon, Ahnung haben, näher unterhalten. Ich bin eher in Konzept, Design und Software stark, aber habe die Hoffnung, dass heutzutage digital auch mit relativ niedrigen Hardwarekosten sowas gut (genug) lösbar sein sollte.

Mespotine · 2020-01-30T16:09:13.723Z

Hab Deinen Beitrag mal vertwittert.

Magste noch ne Kommunikationsadresse mit reinpacken, die Leute benutzen können, die sich hier nicht anmelden wollen? Mail oder so?

theTJ · 2020-01-30T16:48:49.423Z

Wow, das klingt verdammt interessant.
(Ich empfinde es auch nicht wirklich als off-topic, es geht um Audio-Hardware und zur CCC-Wolke gehören zumindest teile unserer Community hier ja auch)

Ich habe zwar noch keine konkreten Hardware-Vorschläge und oder -Ideen, würde das ganze aber gern beobachten und würde dann gern auch Know-How und Tatkraft mit einbringen, wenn es Leute mit Ideen gibt.

Ranthoron · 2020-01-30T19:07:25.868Z

Zwei (unsortierte) Ideen:

bei freeDSP finden sich selbstbau-Audiointerfaces in allen möglichen Größen
vielleicht kann ein AoE-Protokoll Hürden abbauen

moeffju · 2020-01-30T19:35:25.626Z

Guter Punkt! Interessierte können einfach hello@c3lingo.org mailen oder ins Rocket kommen @ https://rocket.events.ccc.de/channel/c3lingo-tech

moeffju · 2020-01-30T20:02:06.411Z

Außerdem werden wir beim Easterhegg in Hamburg dabei sein, sowohl dolmetschend als auch hoffentlich ein bisschen hackend und bastelnd!

alips · 2020-01-31T10:42:59.137Z

Hallo, als hauptberuflicher Konferenzdolmetscher interessiert mich das Thema auch sehr. Sehr spannend, was ihr da vorhabt!

_ff · 2020-02-01T15:51:32.595Z

Moin! Ich finde die Idee sehr gut. Macht bestimmt Spaß da mal was zu bauen.
Was meinst du denn mit “Konsole” käme anfangs auch etwas in Form eines (bspw.) 3HE Racks in Frage wo man sich einfach ein paar passende Geräte zusammenstellt oder soll es auf Jeden fall ein integriertes “Gerät” werden?

moeffju · 2020-02-01T17:27:24.057Z

Moin Felix! Konsole im Sinne von es sollte leicht portabel sein und am besten auf dem Tisch sein, die Dolmetscher*innen brauchen es in Griffweite und müssen dabei üblicherweise ihre Aufmerksamkeit auf die Sprecher*innen oder Bühne richten. Alles, was zu groß, klobig, schwer, nicht stabil oder schlecht zu bedienen ist, ist schwierig.

stephan · 2020-02-03T09:28:36.337Z

Dazu kurz ein paar Gedanken. Habe über Ähnliches im Zusammenhang mit Monitoring schon mal nachgedacht.

Also, als IEEE-Standard gibt es AVB (Audio Video Briding), also ein nicht proprietäres Protokoll, für Audio-Streams übers Netzwerk. Auf Layer 2, also so weit unten, dass die Switches das unterstützen müssen. Dazu gibt es eine OpenSource-Implementierung. Damit sollten sich Audiostreams per Netzwerk verteilen lassen. Hab die Software noch nicht ausprobiert, aber es gibt da was.

Wenn man jetzt auf einer eigenen Platine den Analogteil und einen Analog-Digital-Wandler (ADC) implementiert und das zusammen mit einem Raspberry-Pi (oder anderem Einplatinencomputer) in eine Kiste baut, hat man die Dolmetscherkonsole.

Vom Raspberry-Pi aus lassen sich auch Knöpfe zur Signalisierung einbinden und LEDs oder auch Displays ansteuern. Der Audio-Stream kommt per SPI, I2C oder I2S relativ roh zum Pi. Das beschränkt den Aufwand auf der Platine quasi aufs Analoge.

Da alles ohnehin per Netzwerk verbunden ist, können auch Konfigurationen etc. übers Netzwerk verteil werden und nicht im ersten Anlauf, aber später könnte man z.B. das Einpegeln auch digital von zentraler Stelle aus machen, damit sich die Dolmetscher, auch darum nicht mehr kümmern müssen. Im Endausbau, könnte man statt einem ausgewachsenen Pi das Compute-Modul in die Platine eindesignen, dann wird das Ganze noch günstiger und die Steckverbindung ist maximal solide. Evtl. ist das aber auch der Punkt, an dem man drüber nachdenkt die Teile selbst teuer zu vekaufen ; )

Sind wie gesagt alles theoretische Überlegungen. Ich hatte von MOTU mal das AVB-Ultralite, bei dem es teilweise gedauert hat, bis der Rechner das Interface gesehen hat. Anfangs gab es auch Timing-Probleme, so dass sehr fiese Artefakte zu hören waren. Ist also wahrscheinlich eine Herausforderung, dass fluffig ans Laufen zu bringen.

moeffju · 2020-02-03T17:27:25.945Z

Hmm, RasPi & Co haben natürlich den Vorteil, dass sie extrem leicht zu programmieren sind, ohne dass man sich mit Embedded Programming rumschlagen muss. Andererseits ist man dann beim BOM direkt bei 40€ und hat noch nichts sonst…

stephan · 2020-02-03T23:37:08.401Z

Naja, wenn das als eingebettetes System realisiert werden soll, kommt auch einiges auf die BOM, was sonst auf dem Pi ist (Netzwerk, Flash-Speicher, Prozessor, …). Aber stimmt schon, das wird unter 40€ liegen. Wenn ich mir im Vergleich aber die Konsolen aus deiner Liste anschaue, die bei 800€ pro Platz anfangen, dann finde ich die 40€ pro Platz für den Pi relativ gemütlich.

Die Idee AVB zu nutzen find ich halt sexy, weil man nur Netzwerkkabel ziehen müsste. Das eingebettet zu implementieren, ist aber so weit aus meiner Komfortzone, dass ich das einfach nicht auf dem Schirm hatte. Kommt sicherlich auch auf die Leute an, die das Umsetzen und wo deren Komfortzone so liegt.
Ich glaube aber nicht, dass ich mich sehr weit aus dem Fenster lehne, wenn ich sage, dass die Idee das Projekt eingebettet umzusetzen extrem sportlich ist. Audio mit halbwegs sinnvollen Latenzen hinzubekommen ist nicht trivial. Den Netzwerkfoo dafür ordentlich zu bauen und nebenbei noch Signaling zu machen ist ein richtiger Brocken, auch wenn man weiß, was man tut.

Wäre aber der Hammer, wenn das frei zugänglich realisiert würde. In beiden Fällen (mit oder ohne Pi) sehe ich die Hardware nicht als großes Hindernis.
Auch nicht trivial, immerhin hat man den Analogteil, in dem man Störungen sofort hört und 48V Phantomspeisung fürs Tim-Pritlove-Gedächtnis-Headset dürfen wahrscheinlich auch nicht fehlen. Naja und auch hier ist im Embedded-Fall (ohne Pi) der Aufwand mit µC und eigener Netzwerkschnittstelle deutlich höher.

Ich zweifle ein bisschen, dass die Kostenersparnis der embedded Version das mehr an Zeit aufwiegt, die man für die Entwicklung von Soft und Hardware mehr braucht. Klar ist das ein Freizeitprojekt und Gegenrechnen ergibt keinen Sinn, aber sollte es an 1-2 Pis scheitern, spende ich die gerne und dafür wird das Projekt dann in 12 Monaten realisiert und nicht in 36

moeffju · 2020-02-04T00:21:49.623Z

Klar, im Zweifelsfall will ich auch eher einen Proof of Concept machen, der auch ruhig was mehr kosten kann, das wäre nicht das Ding. Dennoch sehen z.B. der Teensy und so ganz nice aus. Auf “mehr” embedded als sowas hätte ich eh keine Lust

alips · 2020-02-04T07:07:44.559Z

Noch eine Anregung (die hoffentlich den Rahmen des Projektes nicht sprengt). Seit einigen Jahren tummeln sich vermehrt Tech-Unternehmen auf dem Dolmetschmarkt, die Remote-Interpreting via Internet anbieten, bspw. Kudo oder Voiceboxer. Ich könnte mir gut vorstellen, dass die auch Interesse an einer solchen Konsole hätten, die sie ihren Dolmetscher:innen (vermutlich gebrandet) anbieten könnten. Ginge dann aber wohl eher in Richtung Audio-Interface für den heimischen Computer.

stephan · 2020-02-04T09:48:07.287Z

Ich hab der Idee AVB + RaspberryPi mal hinterhergegoogelt und es scheint keine gute zu sein

AVB hat relativ harte Echtzeitanforderung:

Timestamp accuracy has to be on the order of 50 nanoseconds for 802.1AS to work correctly.

Die erfüllt auch der Pi4 nicht (https://github.com/AVnu/OpenAvnu/issues/656). Das im Thread vorgeschlagene Board (PICO-PI-IMX7) wird mit Display für 150$ angeboten und dürfte auch ohne Display deutlich über dem Pi liegen.

moeffju · 2020-02-04T11:39:23.865Z

Ok, ich hab mich jetzt ein paar Tage durch mögliche Komponenten gewühlt, aber das Gesamtbild kommt noch nicht zusammen, daher würde ich mal eine abgewandelte Frage stellen -

Wenn ihr so ein Setup an einen Laptop bauen müsstet, welche Komponenten würdet ihr nehmen? Gehen wir mal von einer sprechenden Person pro Laptop aus. Ich möchte also Ton von meinem Computer hören, die Lautstärke davon regeln können, in ein per XLR oder Klinke angeschlossenes Mikrofon sprechen können, das ich einfach an- und ausschalten kann (inklusive eines Unterbrechungsschalters, der es nur kurzzeitig - während gedrückt wird - runterregelt). Das ganze sollte so digital wie möglich sein, und mein Input wie auch Output sollten idealerweise irgendwo geroutet werden können (um z.B. Relay zu realisieren).

moeffju · 2020-02-04T11:41:32.513Z

Ok, das hatte ich befürchtet, aber danke fürs Bestätigen Ich denke, Latenz ist nicht so mega-wichtig, d.h. eine TCP-Verbindung via WebRTC oder sollte auch reichen, auch eine XLR-Verkabelung wäre wohl ok. Ich sag mal, wenn da irgendwo 250-500ms Latenz rausfallen, ist das okay, weil die Dolmetscher*innen ja eh erst mal “nachsprechen” müssen, man ist also sowieso nie synchron (und muss das auch nicht sein).

theTJ · 2020-02-04T14:48:54.968Z

was man für einen Proof of concept versuchen könnte wäre:
das Behringer X301 mit nem HMC 660 X an einen Laptop zu knubbern und man hätte eine Kombi die für unter 100 € die AD und DA wandlung macht, mit Headset und könnte sich auf den Softwareteil konzentrieren einen Knopf für die Räuspertaste (“push to mute”) ließe sich z.B. so (Drahtlose Räuspertaste) realisieren

Ansonsten könnte man als Host u.U. eine Leistungsfähige Maschine mit Ultraschall nehmen und die könnte dann Viel vom Routing übernehmen (und Reaper die Basis von Ultraschall kann mit LUA gescriptet werden um z.B. verschiedene Routings vor zu konfigurieren)
Und die Clients könnten dann mit Studio Link angebunden werden (per SIP/WebRTC)

Nur ein spontaner Einfall auf deine Idee mit Was bräuchte man wenn man Rechner am ende der Leitung hätte…

Ranthoron · 2020-02-04T19:28:18.519Z

Für Sprecher, die sich nicht in so einem “Reglermonster” einarbeiten wollen/können, könnte evtl. das ZOOM U-22 statt dem X301 die Einstiegshürde absenken.

StudioLink ist ja eigentlich für Ferngespräche, da “reicht” ein kleiner lokaler Server.
Also eigentlich eine kleine SIP-Telefonanlage…