„Die Neukoms“ spielten wir einige Konzerte wobei über Mobiltelefone Live Musik gestreamed wurde. In unseren spielerischen Experimenten konnten wir beobachten, wie sich durch die Verwendung der mobilen Geräte des Publikums auch eine eigene Hörsituation manifestierte. Durch die Verwendung persönlichen mobilen Geräte konnten wir eine Verbindung zu dem von E.T. Hall in seiner Proxemics Theory genannten Intimate Space aufbauen. Der Zuhörer hatte selbst Kontrolle uber sein Gerät und fing an damit zu spielen. Dies ergab wiederum eine soziale Kommunikation mit anderen Zuhörern. Wir als Musiker reagierten auf das räumliche und partizipative Feedback. Es entstand ein social space im Konzert. Zum anderen beobachteten wir, dass durch die räumliche Verteilung und die zeitlichen Verzögerungen sich ein eigener Gestus der Spatialisierung entwickelte. Diese Hörsituation erinnert an einen Wald und wir haben sie Sonotope benannt. Dieser Gestural Space evoziert einen Ansatz, der den Raum als die primäre musikalische Ausdrucksform in den Vordergrund stellt. Daraus entstand die Idee den Klang auf mobilen Lautsprechern zu generieren, die mittels Kontrolldaten per Netzwerk zu bedienen, um damit eine mehr Einfluss auf die Spatialisierung zu bekommen. Wir nannten das Cloudspeaker.]]>
hardware
Lautsprecher + Raspberry Pi + WIFI = Cloudspeaker
Die Idee von Cloudspeaker ist es ein System von frei aufstellbaren (=ohne Kabel) Lautsprecher zu haben, welche von einem Zentralrechner kontrolliert und konfiguriert werden können, und auch die Möglichekeit von Interaktion mit dem Publikum bieten. Mittels Sensoren oder Messungen der Wifi-Feldstärke könnte die Position in einen Raum ermittelt werden.
Alle Lautsprecher in Cloudspeaker sind ausgerüstet mit einem Raspberry Pi3. Diese MicroRechner haben einen hochwertiges Cirrus Logic AudioShield, es ist ein Headless Realtime Linux OS installiert, worauf Supercollider-server scsynth als Audio-server funktioniert. Diese Server kann angesprochen werden per Wifi mittels dem OSC Protokoll. Alle Lautsprecher sind eingebunden in ein privates Wifi-Netzwerk. Um dieses Netzwerk optimal konfigurieren und kontrollieren zu können werden sowohl ein Wifi-Access-Point (Unifi AC/AP) als auch eine Router (Alix – pfSense) in Industrie-Qualität benutzt. Auch ein kleiner Webserver ist eingebunden um damit Interaktionen durchführen zu können.
Welche Problemzonen haben wir bis jetzt geortet?
Netzwerk-Stabilität
Auf welche Adresse kann ein Lautsprecher-Node gefunden werden
Netzwerk-Latenzzeiten
Netzwerk-Jitter
Zeitsynchronizität der Einzelrechner
Lautsprechermodelle
Linux-Kernel Modelle
Jack-kompatibilität mit Soundkarten
Software Verwaltung
Bei der Einbindung vom Publikume:
Verortung von mobile Devices
OSC-Communication Mobile Devices/Musikprogramm
Implemtierung/Webanwendung
Latenzzeiten
Links
network
Netzwerk-Stabilität
Wir haben einen DHPC/DNS Router eingesetzt auf Basis vom Open-Source Programm pfSense, einen Bundle die die Konfiguration dieser Funktionalität sehr vereinfacht.
Netzwerk-Latenzzeiten
Das pfSense bietet auch die Möglichkeit zur Einrichtung eines NTP-Servers. Damit die einzelne Lautprecher-Nodes den Klang am gleichen Moment starten können und so Synchronizität zu erzeugen, ist es äusserst wichtig das sie alle den gleichen Uhrzeit haben. Den NTP server auf dem Router kann dafür sorgen. Die Latenzzeiten zwischen den einzelnen Nodes betragt in unserer Testumgebung etwa 4-8ms
Netzwerk-Jitter
Die hiervor genannte Latenz ist in einem Wifi Netzwerk auch nicht stabil. Sie ändert sich ständig. Die von uns gemessene Latenzzeiten per Node varierten in unser Testumgebung zwischen 0.5ms und 9ms im Schnitt. Es ist für uns wichtig zu wissen in welchem Bereich sich diese befindet, weil Supercollider uns mittels timestamped OSC die Möglichkeit bietet Ereignisse in die Zukunft zu plazieren. Wir setzen diese oberhlab der Latenz plus den Jitterzeit an.
Zeitsynchronizität der Einzelrechner
Obwohl die einzelne Nodes über den NTP-Server etwa den gleichen Zeit zugeteilt bekommen, mit einem Unterschied von unter 10mS, kann den Unterschied zwischen den einzelnen Nodes in ein paar Stunden ziemlich auseinander laufen. Auch wird NTP sich erst nach einen Unterschied von etwa 1000mS wieder neu ausrichten, was für unsere Zwecke selbstverständlich zu gross ist. Wir schauen deswegen nach andere Lösungen, wo PTP eine sehr viel genauere Lösung bieten würde. Wegen den grösseren Hardware Aufwand (den Router sollte dies auch verwalten können) konnten wir das noch nicht verfolgen
Lautsprechermodelle
Zuerst haben wir experimentiert mit Bluetooth Lautsprechern (Bluetooth haben wir nicht gebraucht), aber die automatische Abschaltung wegen den Stromsparmodus war nicht optimal. Denn haben wir gesucht nach einem Lautsprecher mit grossem Batterie, und eventuell genug Platz die Raspis auch noch ein zu bauen. Wir haben diese gefunden in die hier benutzt Modelle, die Soundbuckets. Sie schalten nicht ab, haben ein gutes Volume, eine saftige Batterie, und eventuell genug Platz den Raspi noch ein zu bauen.
Jack-kompatibilität mit Soundkarten
Die Wahl für RaspberryPi3 war eingegeben, obwohl es schnellere Rechner in dieser Landschaft gibt, weil es wenig MicroComputer (SoC) gibt die die Einbindung einer Soundkarte mit Jackd erlauben. Da Supercollider unter Linux dies standard macht waren wir daran gebunden, und fanden in den Wahl für Cirrus Logic Audio in Kombination mit Raspi3 das was wir brauchten.
Software Verwaltung
Initiell haben wir ein Image gemacht vom linux, aber schon schnell kam der Frage wie wir skalierbar mehrere RaspberryPis verwalten können. Mit Ansible haben wir eine leichtgewicht Software gefunden dei nicht nur Software verwalten kann, aber auch ab einem Ort Applikationen starten kann, eine grosse Skalierbarkeit hat, und sehr einfach zu konfigurieren.
Verortung von Mobile Devices/Zuschauer:
Aircrack – Messung der Wifi-Stärke