Digitale Verteilung von Audiosignalen

In einem vorherigen Beitrag hatte ich über die Möglichkeit geschrieben, eine synchrone Audioausgabe über mehrere Boxen zu gewährleisten. Anfangs hatte ich das nur über meine Teufel Rockster Air und das JBL Connect+ Universum angedacht. Da ich mit der Zeit bzw. nach einigen CMs die strahlenden Gesichter derjenigen beobachten konnte, welche sich mit meinem Stream verbinden konnten, wollte ich ich mehr. Also besorgte ich mir die JBL Boxen der nächsten Generation und ab diesem Zeitpunkt fingen meine Probleme an. Die neuen Boxen verfügten nicht mehr über eine Line-In Buchse. Also musste ich mir wohl oder übel eine Möglichkeit einfallen lassen, Audiosignale über Bluetooth, WLAN bzw. Internet zu verteilen.

Nach diversen Tests und massiven Verzögerungen in der Audioverarbeitung der neuen JBL Boxen, in Verbindung mit Bluetooth und bei aktiviertem PartyBoost, baute also noch eine Verzögerungsstufe auf meine ursprüngliche Audioverteilung (s.o. -> vorheriger Beitrag). Somit konnte ich in Gänze eine Gesamtverzögerung von ca. 600ms ausgleichen, dies sollte auch für zukünftige WLAN bzw. Internetverbindungen genügen. Das System fand bei dem ein oder anderen Zuhörer anklang und man kam ins Gespräch. Auf den diversen Demos und Events an denen ich mittlerweile Teilnehme, trifft man den ein oder anderen der auch Erfahrungen mit diesem Thema hat und dann auch noch die passende Idee hat die man adaptieren kann.

Ich unterhielt mich also mit jemanden von eventbike zero und diese für solche Anlässe Mumble und Mumla nutzen, um die Signale entsprechend zu verteilen. Bei einer Demo in Potsdam unterstützte ich die Truppe mit meinem Soundbike, konnte mir die Idee genauer anschauen und die Probleme entsprechend aufsammeln. Die Jungs und Mädels benutzen das System über eine Internetverbindung, folglich ernteten wir mitunter harte Verzögerungen, leichte Unterbrechungen und damit auch eine Absenkung der Audioqualität, wenn wir in Bewegung waren. Wir sind halt in Deutschland, dass sollte man bei solchen Experimenten immer bedenken. Bei uns gibt es halt nicht überall und flächendeckend Internet, wie es andere europäische Länder bereits haben. Könnten wir Audiosignale faxen, wir Deutsche würden es tun.

Zurück zum Thema

Nachteilig empfand ich, dass man keine Möglichkeit hatte die Verzögerungen etwas anzupassen. Aber dafür hatte ich bereits eine kleine Audioverteilung gebaut, die ich bis dato immer brav benutzte. Es ging also nur darum, sich der Umgebung anzupassen, den Audioverteiler etwas zu erweitern, eine eigene Funkstrecke aufzubauen, welche eine zuverlässige lokale Verteilung ermöglicht und auch die Leute mitnehmen kann, welche keine große Mobilfunkflatrate haben.

Als IT-Futzi habe ich genügend Technik hier herumzuliegen, die ich dafür missbrauchen könnte. Also schnell ein altes Notebook mit Debian ausgestattet und Mumble (Client und Server) installiert und schon konnte es losgehen. Allerdings fehlten mir ein paar 3,5 mm Y-Stereo-Klinkenverteiler. Ich konnte also nur erstmal die grundsätzliche Funktion testen. Da ich Testen wollte, ob mein alter Raspberry Pi damit zurande kommen würde, bestellte ich gleich noch eine USB-Soundkarte mit. Mein Raspberry verfügt über keinen entsprechenden Line-In-Eingang. Nach ein paar Tagen waren alle Teile da, also konnte ich das System erstmalig so aufbauen, wie ich es in der freien Wildbahn tun würde.

Mumble auf dem Raspberry?!

Das Notebook hatte keine Probleme die Audiosignale entsprechend zu verarbeiten, bei dem Raspberry sah die Sache schon etwas anders aus. Da ich möglichst stromsparend und CPU schonend fahren wollte, installierte ich Debian erstmal ohne GUI. Leider stellte ich dann fest, dass es keinen brauchbaren Mumble-Clienten für den Textmodus gab. Mit GUI, brachte ich den Raspberry des Öfteren in Bedrängnis und die Latenz stieg in nicht nutzbare Bereiche an. Folglich ist dieser Raspberry Pi B+ nicht nutzbar für mein Vorhaben. Was ich schade fand, denn ein Notebook ist halt nicht so handlich. Auch ist die Stromversorgung eines Notebooks etwas größer, bei einem Raspberry braucht man nur eine entsprechende Powerbank. Da es im Moment noch keinen brauchbaren Mumble-Clienten im Textmodus gibt, werde ich erstmal auf das Notebook setzen. Zumal ich hier auch gleich bequem in die Konsole wechseln kann, ohne mir auf meinem Smartphone die Hände zu brechen.

Mumble im Labor

In meiner Werkstatt hatte ich bisher keine Probleme mit der Synchronisierung. Allerdings muss man darauf achten nicht zwischen verschiedenen Clients zu wechseln. Als Beispiel nenne ich mal Mumble auf dem Rechner und Mumla auf dem Smartphone, hier können leichte bis schwere Laufzeitunterschiede auftreten. Je nachdem wie hoch der Leistungsunterschied zwischen den Geräten ist. In Mumble kann eine Verzögerung eingestellt werden, Mumla bietet diese Funktion nicht an. Auch sollte darauf geachtet werden, dass die Boxen über einen ähnliche Wege angeschlossen werden. Im Klartext, habt ihr überwiegend Line-In-Verbindungen zu euren Boxen, nutzt diese und wechselt nicht von Empfänger zu Empfänger evtl. zu Bluetooth. Ich denke in freier Wildbahn sind die Unterschiede nicht so extrem wahrnehmbar, dies gilt es jetzt bei der nächsten CM heraus zu finden.

Sollte der Test fehlschlagen, müsste ich eine weitere Verzögerungsstufe einziehen und ein Bluetooth-Empfänger in die nächste Verzögerungsstufe umziehen. Somit hätte ich nochmal nach unten hinaus die Möglichkeit eine größere Latenz auszugleichen. Bisher hatte ich sozusagen Glück, dass die per Mumble angeschlossenen Geräte ca. 200ms ± 50ms benötigt haben, um das Signal auszugeben. Diesen möglichen Unterschied kann man immer noch verknüsen, ist nicht optimal und bringt einen leichten Halleffekt.

Messungen

Was mich jedoch nachdenklich stimmte, war eine Laufzeitmessung zwischen Mumble-Server <- WLAN -> Smartphone (Mumla) -> Bluetoothempfänger. Bei dieser Messung kamen satte 630ms Verzögerung zustande, dieser Messwert sprengte die Grenzen meiner Schaltung um 30ms und ist mit der bisherigen Schaltung nicht synchronisierbar. Ursprünglich bin ich von 50ms zusätzlich für die Bluetooth-Verbindungen und 50ms für die Smartphones ausgegangen, 420ms sind ne halbe Ewigkeit. Die Dritte Messung zeigte auf, welche mit Mumble-Server <- WLAN -> Smartphone (Mumla) -> Line-In getätigt wurde, dass auch das Gerät bzw. Software einen gewissen Faktor haben. Hier lag die Verzögerung des Signals bei 500ms, welche gut in das bisherige Konstrukt passt. Diese Unterschiede bei den Laufzeiten machen es praktisch unmöglich einen Mix der Übertragungswege und Geräteklassen zu akzeptieren.

Nach dieser Messung, werde ich wohl noch eine Verzögerungsstufe einsetzen müssen, um alles synchron zu halten, sollten meine Mitspieler auf Bluetooth setzen. Die Messung macht deutlich, dass es durchaus notwendig sein kann, mit einer Verzögerung von mehr als 600ms zu rechnen. Zusätzlich zeigt sich an diesem Beispiel, wie wichtig Kabelverbindungen in der Signalübertragung sind. Bei einigen Smartphones ist mir ein massiver Einbruch der Performance aufgefallen, dies äußerte sich dann in stark verzögerten Audioausgaben (1-2 Sekunden!), die sich nicht mehr fingen. Hier muss ich noch Ursachenforschung betreiben. Mit der Kompilierung der Software (Ver. 1.5) für den Mumble-Clienten bzw. -Server sind diese Probleme nicht mehr ganz so stark ausgeprägt. Auch habe ich durch die neue Version ca. 50ms in der Signalverarbeitung gewonnen.

Nutzt man den Mumble-Clienten auf dem Rechner, muss man den Mumble-Server über die 1. Verzögerungsstufe anbinden. Bei Mumla und den Smartphones (Line-In) muss man die Einspeisung des Mumble-Servers über die Basisebene (0) vornehmen.

Weitere Betriebsmodi

Möchte man die Audiosignale ohne meinen Klimbim unter den Mumble-Clients verteilen, ist das auch kein Problem. In der Beitragsgrafik habe ich sozusagen die unterschiedlichen Betriebsmöglichkeiten farbig hinterlegt. Natürlich kann auch ein Mumble-Server aus der Cloud herhalten. Hierfür muss, wie im Singlebetrieb, die Audioquelle entsprechend angepasst werden. Möchte man die Audioausgabe vom Notebook verteilen, hilft es, unter Debian, manchmal PulseAudio neben Alsa zu installieren. Hiermit kann das Audiosignal per Software abgefischt werden und per Mumble-Client an den Server gesendet werden. Für selbiges unter Windows, muss der Stereomix aktiviert werden. Allerdings kann man unter Windows die Lautsprecher nicht stumm stellen, da andernfalls die Einspeisung auch stumm geschaltet wird. Aber man kann einen Kopfhörer anschließen, um das Notebook stumm/leise zu bekommen.

Für diesen Modus empfiehlt es sich, dass niemand direkt am Quellsignal sitzt und auch der “DJ” über einen separaten Client das Audiosignal abgreift. Möchte man eine größere Fläche beschallen, ist der Weg über einen Internetserver der Beste. Beim WLAN denke ich, wird es vermutlich nur einen maximalen Radius von ca. 80m – 100m geben (bei Bewegung). Auch wenn diverse Hersteller eine maximale Reichweite von 300m im Freien angeben. Die maximale Reichweite wird an der Menge der Störungsquellen hängen. Und da sind durch die ganzen Metallrahmen und Smartphones ne ganze Menge bei einer CM. Ist man stationär und kann eine gewisse Festinstallation vornehmen, müsste man die Accesspoints per Netzwerkkabel verbinden.

Die folgenden Einstellungen haben sich, für die Signalempfänger, als gut herausgestellt. Der Sende Modus sollte auf Tastendruck aktiviert werden. Beim Mumla unter Audio -> Sendemodus -> Zum Sprechen drücken. Die TCP-Netzwerkübertragung könnt ihr unter Allgemein -> Nur TCP aktivieren. Wollt ihr keine wilden Textbotschaften mitbekommen, deaktiviert die Text-zu-Sprache Option, auch unter Allgemein.

Aktuell existieren für die einzelnen Betriebssysteme unterschiedliche Stable-Versionen. Debian z.B. nutzt noch die Version 1.3.4. Für Windows gibt es die Version 1.4.287, welche eine Steigerung der Bitrate über 96kb/s zulässt.