Getrennt Zusammen Proben Und Musizieren Mit Jamulus

Getrennt zusammen proben und musizieren mit Jamulus

David Kastrup

14. März 2021 I Internetausbau unterstützt Bandbreiten von Videokonferenzen und Telefonie, also liegt Computerunterstützung nahe I Technische Supportbesuche einer maskierten Einzelperson bei einzelnen Privathaushalten sind unter Einhalten der Hygienevorschriften praktikabel I relevante Technik ist bereits in abrufbarem Zustand einsetzbar

Probenbetrieb in der Pandemie

I Ensemble sind größere Gruppen → physische Zusammenkünfte nicht praktikabel I Technische Supportbesuche einer maskierten Einzelperson bei einzelnen Privathaushalten sind unter Einhalten der Hygienevorschriften praktikabel I relevante Technik ist bereits in abrufbarem Zustand einsetzbar

Probenbetrieb in der Pandemie

I Ensemble sind größere Gruppen → physische Zusammenkünfte nicht praktikabel I Internetausbau unterstützt Bandbreiten von Videokonferenzen und Telefonie, also liegt Computerunterstützung nahe I Technische Supportbesuche einer maskierten Einzelperson bei einzelnen Privathaushalten sind unter Einhalten der Hygienevorschriften praktikabel I relevante Technik ist bereits in abrufbarem Zustand einsetzbar I etablierte sequentielle Vorgehensweisen mit Multitracking I typischerweise Beginn mit „Click Track“ I danach Einspielung der Rhythmusgruppe (Schlagzeug, Baß) I Durchlaufverzögerungen zwischen Wiedergabe des bisherigen Materials und Aufnahme einer neuen Spur unproblematisch, da sie kompensiert werden können I Keine Interaktivität → wenig geeignet für Probenarbeit und „Jams“ I Betätigungsfeld für „Studiomusiker“, die ihre Beiträge praktisch „fertig“ ohne Rücksprache und Entwicklungsarbeit abliefern können.

„Studiomusik“

I zeitliche Trennung der Aufnahme einzelner Teilnehmer I typischerweise Beginn mit „Click Track“ I danach Einspielung der Rhythmusgruppe (Schlagzeug, Baß) I Durchlaufverzögerungen zwischen Wiedergabe des bisherigen Materials und Aufnahme einer neuen Spur unproblematisch, da sie kompensiert werden können I Keine Interaktivität → wenig geeignet für Probenarbeit und „Jams“ I Betätigungsfeld für „Studiomusiker“, die ihre Beiträge praktisch „fertig“ ohne Rücksprache und Entwicklungsarbeit abliefern können.

„Studiomusik“

I zeitliche Trennung der Aufnahme einzelner Teilnehmer I etablierte sequentielle Vorgehensweisen mit Multitracking I danach Einspielung der Rhythmusgruppe (Schlagzeug, Baß) I Durchlaufverzögerungen zwischen Wiedergabe des bisherigen Materials und Aufnahme einer neuen Spur unproblematisch, da sie kompensiert werden können I Keine Interaktivität → wenig geeignet für Probenarbeit und „Jams“ I Betätigungsfeld für „Studiomusiker“, die ihre Beiträge praktisch „fertig“ ohne Rücksprache und Entwicklungsarbeit abliefern können.

„Studiomusik“

I zeitliche Trennung der Aufnahme einzelner Teilnehmer I etablierte sequentielle Vorgehensweisen mit Multitracking I typischerweise Beginn mit „Click Track“ I Durchlaufverzögerungen zwischen Wiedergabe des bisherigen Materials und Aufnahme einer neuen Spur unproblematisch, da sie kompensiert werden können I Keine Interaktivität → wenig geeignet für Probenarbeit und „Jams“ I Betätigungsfeld für „Studiomusiker“, die ihre Beiträge praktisch „fertig“ ohne Rücksprache und Entwicklungsarbeit abliefern können.

„Studiomusik“

I zeitliche Trennung der Aufnahme einzelner Teilnehmer I etablierte sequentielle Vorgehensweisen mit Multitracking I typischerweise Beginn mit „Click Track“ I danach Einspielung der Rhythmusgruppe (Schlagzeug, Baß) I Keine Interaktivität → wenig geeignet für Probenarbeit und „Jams“ I Betätigungsfeld für „Studiomusiker“, die ihre Beiträge praktisch „fertig“ ohne Rücksprache und Entwicklungsarbeit abliefern können.

„Studiomusik“

I zeitliche Trennung der Aufnahme einzelner Teilnehmer I etablierte sequentielle Vorgehensweisen mit Multitracking I typischerweise Beginn mit „Click Track“ I danach Einspielung der Rhythmusgruppe (Schlagzeug, Baß) I Durchlaufverzögerungen zwischen Wiedergabe des bisherigen Materials und Aufnahme einer neuen Spur unproblematisch, da sie kompensiert werden können I Keine Interaktivität → wenig geeignet für Probenarbeit und „Jams“ I Betätigungsfeld für „Studiomusiker“, die ihre Beiträge praktisch „fertig“ ohne Rücksprache und Entwicklungsarbeit abliefern können. I Technologie etwa über WebRTC I Intendiert für Telefonie/Konferenzen mit jeweils einem aktiven Sprecher I Typische Techniken wie Echokompensation, „Ducking“ nicht aktiver Sprecher, Rückkopplungsunterdrückung, Lautstärkenormierung I Latenzen von 100ms und mehr weitgehend unproblematisch

Streamingtechnologien

I Bekannte Vertreter Skype, Zoom, Jitsi I Intendiert für Telefonie/Konferenzen mit jeweils einem aktiven Sprecher I Typische Techniken wie Echokompensation, „Ducking“ nicht aktiver Sprecher, Rückkopplungsunterdrückung, Lautstärkenormierung I Latenzen von 100ms und mehr weitgehend unproblematisch

Streamingtechnologien

I Bekannte Vertreter Skype, Zoom, Jitsi I Technologie etwa über WebRTC I Typische Techniken wie Echokompensation, „Ducking“ nicht aktiver Sprecher, Rückkopplungsunterdrückung, Lautstärkenormierung I Latenzen von 100ms und mehr weitgehend unproblematisch

Streamingtechnologien

I Bekannte Vertreter Skype, Zoom, Jitsi I Technologie etwa über WebRTC I Intendiert für Telefonie/Konferenzen mit jeweils einem aktiven Sprecher I Latenzen von 100ms und mehr weitgehend unproblematisch

Streamingtechnologien

I Bekannte Vertreter Skype, Zoom, Jitsi I Technologie etwa über WebRTC I Intendiert für Telefonie/Konferenzen mit jeweils einem aktiven Sprecher I Typische Techniken wie Echokompensation, „Ducking“ nicht aktiver Sprecher, Rückkopplungsunterdrückung, Lautstärkenormierung I Latenzen von 100ms und mehr weitgehend unproblematisch Sonobus Peer-to-peer-Architektur über WebRTC-Protokoll Jamulus Client/Server-Architektur über eigenes UDP-Protokoll

Ansätze Loops Man hört seinen eigenen Beitrag um eine „Looplänge“ versetzt. Kaum ohne Metronom/Clicktrack realisierbar, nicht für Proben geeignet, eher für längere Improvisationssessions geübter Musiker. Vertreter etwa „NINJAM“. Latenzoptimierung „Gaming“-Internetverbindungen mit hohem Durchsatz und konstant niedriger Latenz, Codecs mit hohem Durchsatz und niedriger Latenz, vorzugsweise kein WLAN sondern LAN, latenzarme Soundkarte, Verzicht auf Video. Beispiele:

Ansprüche für interaktives Musizieren

Grundproblem Interaktion mehrerer Teilnehmer, die aufeinander eingehen können Sonobus Peer-to-peer-Architektur über WebRTC-Protokoll Jamulus Client/Server-Architektur über eigenes UDP-Protokoll

Latenzoptimierung „Gaming“-Internetverbindungen mit hohem Durchsatz und konstant niedriger Latenz, Codecs mit hohem Durchsatz und niedriger Latenz, vorzugsweise kein WLAN sondern LAN, latenzarme Soundkarte, Verzicht auf Video. Beispiele:

Ansprüche für interaktives Musizieren

Grundproblem Interaktion mehrerer Teilnehmer, die aufeinander eingehen können Ansätze Loops Man hört seinen eigenen Beitrag um eine „Looplänge“ versetzt. Kaum ohne Metronom/Clicktrack realisierbar, nicht für Proben geeignet, eher für längere Improvisationssessions geübter Musiker. Vertreter etwa „NINJAM“. Latenzoptimierung „Gaming“-Internetverbindungen mit hohem Durchsatz und konstant niedriger Latenz, Codecs mit hohem Durchsatz und niedriger Latenz, vorzugsweise kein WLAN sondern LAN, latenzarme Soundkarte, Verzicht auf Video. Beispiele: Jamulus Client/Server-Architektur über eigenes UDP-Protokoll

Ansprüche für interaktives Musizieren

Grundproblem Interaktion mehrerer Teilnehmer, die aufeinander eingehen können Ansätze Loops Man hört seinen eigenen Beitrag um eine „Looplänge“ versetzt. Kaum ohne Metronom/Clicktrack realisierbar, nicht für Proben geeignet, eher für längere Improvisationssessions geübter Musiker. Vertreter etwa „NINJAM“. Latenzoptimierung „Gaming“-Internetverbindungen mit hohem Durchsatz und konstant niedriger Latenz, Codecs mit hohem Durchsatz und niedriger Latenz, vorzugsweise kein WLAN sondern LAN, latenzarme Soundkarte, Verzicht auf Video. Beispiele: Sonobus Peer-to-peer-Architektur über WebRTC-Protokoll Ansprüche für interaktives Musizieren

Grundproblem Interaktion mehrerer Teilnehmer, die aufeinander eingehen können Ansätze Loops Man hört seinen eigenen Beitrag um eine „Looplänge“ versetzt. Kaum ohne Metronom/Clicktrack realisierbar, nicht für Proben geeignet, eher für längere Improvisationssessions geübter Musiker. Vertreter etwa „NINJAM“. Latenzoptimierung „Gaming“-Internetverbindungen mit hohem Durchsatz und konstant niedriger Latenz, Codecs mit hohem Durchsatz und niedriger Latenz, vorzugsweise kein WLAN sondern LAN, latenzarme Soundkarte, Verzicht auf Video. Beispiele: Sonobus Peer-to-peer-Architektur über WebRTC-Protokoll Jamulus Client/Server-Architektur über eigenes UDP-Protokoll Jamulus — Benutzeroberﬂäche/Mixerboard

Abbildung: Mixerboard Jamulus — Benutzeroberﬂäche/Verbinden

Abbildung: Verbinden Jamulus — Benutzeroberﬂäche/Einstellungen

Abbildung: Einstellungen Jamulus — Benutzeroberﬂäche/Chat

Abbildung: Chat Jamulus — Benutzer

Abbildung: Klassische Windows-Laptops mit Mikrofon und Soundkarte Jamulus — Benutzer

Abbildung: Windows-PC mit Line-In, Mischpult als Vorverstärker Jamulus — Benutzer

Abbildung: Mac mini mit Mikrofonen im Monitor Jamulus — Benutzer

Abbildung: Linux-Laptop, Mischpult mit Firewire Jamulus-Server — Benutzeroberﬂäche

Abbildung: Server I Jeder Client sendet einen Audiostream vom lokalen Nutzer zum Server und empfängt einen individuellen Stream mit dem persönlichen Mix für den Nutzer I Optionale Aufzeichnung beim Server erfolgt trackweise (ungemischt) I Zentralserver unterhalten Verzeichnisse individueller öffentlicher Server I Öffentliche Server kommen im allgemeinen ohne explizite Portfreigaben aus I Nichtöffentliche Server und Zentralserver müssen in Router/Firewall den dedizierten eingehenden UDP-Port (typischerweise 22124) durchreichen

Jamulus — Architektur

I Client/Server-Architektur I Optionale Aufzeichnung beim Server erfolgt trackweise (ungemischt) I Zentralserver unterhalten Verzeichnisse individueller öffentlicher Server I Öffentliche Server kommen im allgemeinen ohne explizite Portfreigaben aus I Nichtöffentliche Server und Zentralserver müssen in Router/Firewall den dedizierten eingehenden UDP-Port (typischerweise 22124) durchreichen

Jamulus — Architektur

I Client/Server-Architektur I Jeder Client sendet einen Audiostream vom lokalen Nutzer zum Server und empfängt einen individuellen Stream mit dem persönlichen Mix für den Nutzer I Zentralserver unterhalten Verzeichnisse individueller öffentlicher Server I Öffentliche Server kommen im allgemeinen ohne explizite Portfreigaben aus I Nichtöffentliche Server und Zentralserver müssen in Router/Firewall den dedizierten eingehenden UDP-Port (typischerweise 22124) durchreichen

Jamulus — Architektur

I Client/Server-Architektur I Jeder Client sendet einen Audiostream vom lokalen Nutzer zum Server und empfängt einen individuellen Stream mit dem persönlichen Mix für den Nutzer I Optionale Aufzeichnung beim Server erfolgt trackweise (ungemischt) I Zentralserver unterhalten Verzeichnisse individueller öffentlicher Server I Öffentliche Server kommen im allgemeinen ohne explizite Portfreigaben aus I Nichtöffentliche Server und Zentralserver müssen in Router/Firewall den dedizierten eingehenden UDP-Port (typischerweise 22124) durchreichen Aufnahme Codierung → Transfer → Decodierung Erstellen eines persönlichen Mixes Codierung ← Transfer ← Decodierung Wiedergabe

Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Codierung → Transfer → Decodierung Erstellen eines persönlichen Mixes Codierung ← Transfer ← Decodierung Wiedergabe

Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Aufnahme → Transfer → Decodierung Erstellen eines persönlichen Mixes Codierung ← Transfer ← Decodierung Wiedergabe

Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Aufnahme Codierung Decodierung Erstellen eines persönlichen Mixes Codierung ← Transfer ← Decodierung Wiedergabe

Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Aufnahme Codierung → Transfer → Erstellen eines persönlichen Mixes Codierung ← Transfer ← Decodierung Wiedergabe

Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Aufnahme Codierung → Transfer → Decodierung Codierung ← Transfer ← Decodierung Wiedergabe

Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Aufnahme Codierung → Transfer → Decodierung Erstellen eines persönlichen Mixes ← Transfer ← Decodierung Wiedergabe

Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Aufnahme Codierung → Transfer → Decodierung Erstellen eines persönlichen Mixes Codierung Decodierung Wiedergabe

Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Aufnahme Codierung → Transfer → Decodierung Erstellen eines persönlichen Mixes Codierung ← Transfer ← Wiedergabe

Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Aufnahme Codierung → Transfer → Decodierung Erstellen eines persönlichen Mixes Codierung ← Transfer ← Decodierung Jamulus — Architektur 2

Bearbeitung des Signals: Client Internet Server Aufnahme Codierung → Transfer → Decodierung Erstellen eines persönlichen Mixes Codierung ← Transfer ← Decodierung Wiedergabe I Kompression erfolgt mit OPUS-Codec, mit „custom“ encodings von 64 oder 128 Samples Größe bei 48kHz Samplefrequenz I Server arbeitet mit eigener von den Clients unabhängiger Taktung. Empfangene Pakete werden gepuﬀert, in festen Zeitintervallen dekomprimiert, in individuellen Mixes gemischt, komprimiert und gesendet I Soundsystem beim Client: Jack (Linux), ASIO (Windows), CoreAudio (Mac) I Bandbreitenbedarf Client: ein Sendekanal (Mono oder Stereo), ein Empfangskanal (ca 300kbit/s bis 900kbit/s, je nach Qualität und Stereo) I Bandbreitenbedarf Server: ein Empfangskanal und ein Sendekanal pro Client I Keinerlei Echokompensation → Kopfhörer notwendig bei Mikrofonierung

Jamulus — Implementation

I Transfer erfolgt über UDP-Pakete mit eigenem Protokoll I Server arbeitet mit eigener von den Clients unabhängiger Taktung. Empfangene Pakete werden gepuﬀert, in festen Zeitintervallen dekomprimiert, in individuellen Mixes gemischt, komprimiert und gesendet I Soundsystem beim Client: Jack (Linux), ASIO (Windows), CoreAudio (Mac) I Bandbreitenbedarf Client: ein Sendekanal (Mono oder Stereo), ein Empfangskanal (ca 300kbit/s bis 900kbit/s, je nach Qualität und Stereo) I Bandbreitenbedarf Server: ein Empfangskanal und ein Sendekanal pro Client I Keinerlei Echokompensation → Kopfhörer notwendig bei Mikrofonierung

Jamulus — Implementation

I Transfer erfolgt über UDP-Pakete mit eigenem Protokoll I Kompression erfolgt mit OPUS-Codec, mit „custom“ encodings von 64 oder 128 Samples Größe bei 48kHz Samplefrequenz I Soundsystem beim Client: Jack (Linux), ASIO (Windows), CoreAudio (Mac) I Bandbreitenbedarf Client: ein Sendekanal (Mono oder Stereo), ein Empfangskanal (ca 300kbit/s bis 900kbit/s, je nach Qualität und Stereo) I Bandbreitenbedarf Server: ein Empfangskanal und ein Sendekanal pro Client I Keinerlei Echokompensation → Kopfhörer notwendig bei Mikrofonierung

Jamulus — Implementation

I Transfer erfolgt über UDP-Pakete mit eigenem Protokoll I Kompression erfolgt mit OPUS-Codec, mit „custom“ encodings von 64 oder 128 Samples Größe bei 48kHz Samplefrequenz I Server arbeitet mit eigener von den Clients unabhängiger Taktung. Empfangene Pakete werden gepuﬀert, in festen Zeitintervallen dekomprimiert, in individuellen Mixes gemischt, komprimiert und gesendet I Bandbreitenbedarf Client: ein Sendekanal (Mono oder Stereo), ein Empfangskanal (ca 300kbit/s bis 900kbit/s, je nach Qualität und Stereo) I Bandbreitenbedarf Server: ein Empfangskanal und ein Sendekanal pro Client I Keinerlei Echokompensation → Kopfhörer notwendig bei Mikrofonierung

Jamulus — Implementation

I Transfer erfolgt über UDP-Pakete mit eigenem Protokoll I Kompression erfolgt mit OPUS-Codec, mit „custom“ encodings von 64 oder 128 Samples Größe bei 48kHz Samplefrequenz I Server arbeitet mit eigener von den Clients unabhängiger Taktung. Empfangene Pakete werden gepuﬀert, in festen Zeitintervallen dekomprimiert, in individuellen Mixes gemischt, komprimiert und gesendet I Soundsystem beim Client: Jack (Linux), ASIO (Windows), CoreAudio (Mac) I Bandbreitenbedarf Client: ein Sendekanal (Mono oder Stereo), ein Empfangskanal (ca 300kbit/s bis 900kbit/s, je nach Qualität und Stereo) I Keinerlei Echokompensation → Kopfhörer notwendig bei Mikrofonierung

Jamulus — Implementation

I Transfer erfolgt über UDP-Pakete mit eigenem Protokoll I Kompression erfolgt mit OPUS-Codec, mit „custom“ encodings von 64 oder 128 Samples Größe bei 48kHz Samplefrequenz I Server arbeitet mit eigener von den Clients unabhängiger Taktung. Empfangene Pakete werden gepuﬀert, in festen Zeitintervallen dekomprimiert, in individuellen Mixes gemischt, komprimiert und gesendet I Soundsystem beim Client: Jack (Linux), ASIO (Windows), CoreAudio (Mac) I Bandbreitenbedarf Client: ein Sendekanal (Mono oder Stereo), ein Empfangskanal (ca 300kbit/s bis 900kbit/s, je nach Qualität und Stereo) I Bandbreitenbedarf Server: ein Empfangskanal und ein Sendekanal pro Client Jamulus — Implementation

I Transfer erfolgt über UDP-Pakete mit eigenem Protokoll I Kompression erfolgt mit OPUS-Codec, mit „custom“ encodings von 64 oder 128 Samples Größe bei 48kHz Samplefrequenz I Server arbeitet mit eigener von den Clients unabhängiger Taktung. Empfangene Pakete werden gepuﬀert, in festen Zeitintervallen dekomprimiert, in individuellen Mixes gemischt, komprimiert und gesendet I Soundsystem beim Client: Jack (Linux), ASIO (Windows), CoreAudio (Mac) I Bandbreitenbedarf Client: ein Sendekanal (Mono oder Stereo), ein Empfangskanal (ca 300kbit/s bis 900kbit/s, je nach Qualität und Stereo) I Bandbreitenbedarf Server: ein Empfangskanal und ein Sendekanal pro Client I Keinerlei Echokompensation → Kopfhörer notwendig bei Mikrofonierung In der Cloud Ist sinnvoll, um Engpässe bei Bandbreite und Latenz beim Nadelöhr des Servers zu vermeiden und im Problemfall die Serverleistung erhöhen zu können.

Jamulus-Server: wohin damit?

In-house Macht im wesentlichen dann Sinn, wenn alle Musiker im lokalen Netzwerk sind. Eine sozial isolierte Musikschule mit getrennten Übezellen? Eine Probesession mit sauber getrennter akustischer Aufnahme aller Beteiligten? In der Cloud Ist sinnvoll, um Engpässe bei Bandbreite und Latenz beim Nadelöhr des Servers zu vermeiden und im Problemfall die Serverleistung erhöhen zu können. I Ein Ansatz: öffentliche Serverliste nach guten Kandidaten guter Pingzeit durchsehen, Verbindung aufmachen, mit lsof -i UDP in einem Terminalfenster den Server identifizieren und mit tracepath seine geografische Lage und den Provider einkreisen. I Cloudprovider anschauen und ping zur Webseite probieren. Nicht notwendigerweise aussagekräftig, falls die Webseite in einem anderen Rechenzentrum ist I Für Probenbetrieb größerer Ensembles sind stundenweise abgerechnete Server praktisch. Achtung: genau prüfen, welche Kosten weiterlaufen!

Wohin in der Cloud?

I In „Pingnähe“ statt geograﬁscher Entfernung I Cloudprovider anschauen und ping zur Webseite probieren. Nicht notwendigerweise aussagekräftig, falls die Webseite in einem anderen Rechenzentrum ist I Für Probenbetrieb größerer Ensembles sind stundenweise abgerechnete Server praktisch. Achtung: genau prüfen, welche Kosten weiterlaufen!

Wohin in der Cloud?

I In „Pingnähe“ statt geografischer Entfernung I Ein Ansatz: öffentliche Serverliste nach guten Kandidaten guter Pingzeit durchsehen, Verbindung aufmachen, mit lsof -i UDP in einem Terminalfenster den Server identifizieren und mit tracepath seine geografische Lage und den Provider einkreisen. I Cloudprovider anschauen und ping zur Webseite probieren. Nicht notwendigerweise aussagekräftig, falls die Webseite in einem anderen Rechenzentrum ist I Für Probenbetrieb größerer Ensembles sind stundenweise abgerechnete Server praktisch. Achtung: genau prüfen, welche Kosten weiterlaufen! I Direkter Klangeindruck verleitet zum Unterschätzen der „Entfernung“ → Verschleppen I Schwankungen in Synchronizität und in Server-, Netzwerk-, und Clientleistung führen zu Aussetzern: „Knuspern“ I Technikprobleme können zumindest anfangs die Unterhaltung dominieren I Kopfhörer und Kabel gewöhnungsbedürftig. Funkkopfhörer sollten wegen Latenzen nur mit Analogtechnik (FM) verwendet werden. Tragekomfort ist wichtig!

Probleme

I Latenz: Faustregel für Angelsachsen: 1ms entspricht 1Fuß. 60ms entsprechen 20m Entfernung im Freien I Schwankungen in Synchronizität und in Server-, Netzwerk-, und Clientleistung führen zu Aussetzern: „Knuspern“ I Technikprobleme können zumindest anfangs die Unterhaltung dominieren I Kopfhörer und Kabel gewöhnungsbedürftig. Funkkopfhörer sollten wegen Latenzen nur mit Analogtechnik (FM) verwendet werden. Tragekomfort ist wichtig!

Probleme

I Latenz: Faustregel für Angelsachsen: 1ms entspricht 1Fuß. 60ms entsprechen 20m Entfernung im Freien I Direkter Klangeindruck verleitet zum Unterschätzen der „Entfernung“ → Verschleppen I Technikprobleme können zumindest anfangs die Unterhaltung dominieren I Kopfhörer und Kabel gewöhnungsbedürftig. Funkkopfhörer sollten wegen Latenzen nur mit Analogtechnik (FM) verwendet werden. Tragekomfort ist wichtig!

Probleme

I Latenz: Faustregel für Angelsachsen: 1ms entspricht 1Fuß. 60ms entsprechen 20m Entfernung im Freien I Direkter Klangeindruck verleitet zum Unterschätzen der „Entfernung“ → Verschleppen I Schwankungen in Synchronizität und in Server-, Netzwerk-, und Clientleistung führen zu Aussetzern: „Knuspern“ I Technikprobleme können zumindest anfangs die Unterhaltung dominieren I Kopfhörer und Kabel gewöhnungsbedürftig. Funkkopfhörer sollten wegen Latenzen nur mit Analogtechnik (FM) verwendet werden. Tragekomfort ist wichtig! I Ob der Server leistungsfähig genug ist (Bandbreite, Rechenleistung), merkt man erst mit allen Teilnehmern I Deswegen: anfangs mehrere Cloudserver verschiedener Leistungsfähigkeit stundenweise parallel aufsetzen und mit allen Teilnehmern testen I Dafür praktisch: vom Serverbetreiber unabhängiger DynDNS-Betreiber → auch bei wechselnden Servern und Betreibern können Nutzer immer zum selben Namen verbinden

Überraschung!

Erstens kommt es anders, zweitens als man denkt. I Ob alle Teilnehmer eine konstant verläßliche Verbindung haben, merkt man erst beim Test mit Jamulus I Deswegen: anfangs mehrere Cloudserver verschiedener Leistungsfähigkeit stundenweise parallel aufsetzen und mit allen Teilnehmern testen I Dafür praktisch: vom Serverbetreiber unabhängiger DynDNS-Betreiber → auch bei wechselnden Servern und Betreibern können Nutzer immer zum selben Namen verbinden

Überraschung!

Erstens kommt es anders, zweitens als man denkt. I Ob alle Teilnehmer eine konstant verläßliche Verbindung haben, merkt man erst beim Test mit Jamulus I Ob der Server leistungsfähig genug ist (Bandbreite, Rechenleistung), merkt man erst mit allen Teilnehmern I Deswegen: anfangs mehrere Cloudserver verschiedener Leistungsfähigkeit stundenweise parallel aufsetzen und mit allen Teilnehmern testen I Dafür praktisch: vom Serverbetreiber unabhängiger DynDNS-Betreiber → auch bei wechselnden Servern und Betreibern können Nutzer immer zum selben Namen verbinden I Andere Kommunikationsdynamik als bei Sprecherselektion einer Konferenzschaltung, etwa „beipﬂichtendes Murmeln“ I Diﬀerenzierteres Klangbild als live, wo die Sitznachbarn dominieren I Aufnahmen erlauben Detailanalyse von Problemen I Spontane Einbindung von zusätzlichem „Musikerkram“, den man nicht so eben zu einer Probe mitnimmt und der eigentlich einen Verstärker bräuchte

Unerwartete Pluspunkte

I Erhebliche Reduzierung von Probenausfällen und Abwesenheiten (teilweise vermutlich pandemiebedingt) I Diﬀerenzierteres Klangbild als live, wo die Sitznachbarn dominieren I Aufnahmen erlauben Detailanalyse von Problemen I Spontane Einbindung von zusätzlichem „Musikerkram“, den man nicht so eben zu einer Probe mitnimmt und der eigentlich einen Verstärker bräuchte

Unerwartete Pluspunkte

I Erhebliche Reduzierung von Probenausfällen und Abwesenheiten (teilweise vermutlich pandemiebedingt) I Andere Kommunikationsdynamik als bei Sprecherselektion einer Konferenzschaltung, etwa „beipﬂichtendes Murmeln“ I Aufnahmen erlauben Detailanalyse von Problemen I Spontane Einbindung von zusätzlichem „Musikerkram“, den man nicht so eben zu einer Probe mitnimmt und der eigentlich einen Verstärker bräuchte

Unerwartete Pluspunkte

I Erhebliche Reduzierung von Probenausfällen und Abwesenheiten (teilweise vermutlich pandemiebedingt) I Andere Kommunikationsdynamik als bei Sprecherselektion einer Konferenzschaltung, etwa „beipﬂichtendes Murmeln“ I Diﬀerenzierteres Klangbild als live, wo die Sitznachbarn dominieren I Spontane Einbindung von zusätzlichem „Musikerkram“, den man nicht so eben zu einer Probe mitnimmt und der eigentlich einen Verstärker bräuchte

Unerwartete Pluspunkte

I Erhebliche Reduzierung von Probenausfällen und Abwesenheiten (teilweise vermutlich pandemiebedingt) I Andere Kommunikationsdynamik als bei Sprecherselektion einer Konferenzschaltung, etwa „beipﬂichtendes Murmeln“ I Diﬀerenzierteres Klangbild als live, wo die Sitznachbarn dominieren I Aufnahmen erlauben Detailanalyse von Problemen I Spontane Einbindung von zusätzlichem „Musikerkram“, den man nicht so eben zu einer Probe mitnimmt und der eigentlich einen Verstärker bräuchte „Musikerkram“ aus den 90er Jahren

Abbildung: Arranger/Midi-Expander/Rhythmusgerät Solton MS40 I Mehrere eigene Mixerstrips pro Benutzer I Verwendung von Codec-Parametern, die direkte Aufzeichnung von Opus-Dateien erlauben

Wünschenswerte Erweiterungen

I Unterschiedliche Qualitäten/Kanalzahl für Aufnahme und Wiedergabe. Besonders sinnvoll für Mono-In/Stereo-Out, für Zuhörer und für elektronische Instrumente I Verwendung von Codec-Parametern, die direkte Aufzeichnung von Opus-Dateien erlauben

Wünschenswerte Erweiterungen

I Unterschiedliche Qualitäten/Kanalzahl für Aufnahme und Wiedergabe. Besonders sinnvoll für Mono-In/Stereo-Out, für Zuhörer und für elektronische Instrumente I Mehrere eigene Mixerstrips pro Benutzer I Verwendung von Codec-Parametern, die direkte Aufzeichnung von Opus-Dateien erlauben I Der Einstieg in Jamulus erfordert zunächst nicht viel mehr als Kopfhörerzwang (P.S.: digitale/Bluetooth-Kopfhörer verursachen zusätzliche Verzögerung) I Verwendung von LAN-Kabel, externen Mikrofonen (u.U. auch USB-Mikrofon mit Kopfhörerausgang), externen USB-Soundinterfaces etc erfolgt dann bei Bedarf und gruppendynamisch I In Jamulussessions auf öﬀentlichen Servern kann man recht zwanglos reinhören (Stummschalten!)

Diverse Nachträge

Das wichtigste Problem bei einem solchen technikaﬃnen Projekt ist es, eine kritische Masse ins Boot zu kriegen. I Nicht mit Jamulus und Technik anfangen, sondern mit einfacher webbasierter Videokonferenz (heutzutage hat ja praktisch jeder Webcam und Mikro im Rechner) über Jitsi, um zunächst das Interesse am Sozialkontakt wiederaufzubauen I Verwendung von LAN-Kabel, externen Mikrofonen (u.U. auch USB-Mikrofon mit Kopfhörerausgang), externen USB-Soundinterfaces etc erfolgt dann bei Bedarf und gruppendynamisch I In Jamulussessions auf öﬀentlichen Servern kann man recht zwanglos reinhören (Stummschalten!)

Diverse Nachträge

Das wichtigste Problem bei einem solchen technikaﬃnen Projekt ist es, eine kritische Masse ins Boot zu kriegen. I Nicht mit Jamulus und Technik anfangen, sondern mit einfacher webbasierter Videokonferenz (heutzutage hat ja praktisch jeder Webcam und Mikro im Rechner) über Jitsi, um zunächst das Interesse am Sozialkontakt wiederaufzubauen I Der Einstieg in Jamulus erfordert zunächst nicht viel mehr als Kopfhörerzwang (P.S.: digitale/Bluetooth-Kopfhörer verursachen zusätzliche Verzögerung) I In Jamulussessions auf öﬀentlichen Servern kann man recht zwanglos reinhören (Stummschalten!)

Diverse Nachträge

Das wichtigste Problem bei einem solchen technikaﬃnen Projekt ist es, eine kritische Masse ins Boot zu kriegen. I Nicht mit Jamulus und Technik anfangen, sondern mit einfacher webbasierter Videokonferenz (heutzutage hat ja praktisch jeder Webcam und Mikro im Rechner) über Jitsi, um zunächst das Interesse am Sozialkontakt wiederaufzubauen I Der Einstieg in Jamulus erfordert zunächst nicht viel mehr als Kopfhörerzwang (P.S.: digitale/Bluetooth-Kopfhörer verursachen zusätzliche Verzögerung) I Verwendung von LAN-Kabel, externen Mikrofonen (u.U. auch USB-Mikrofon mit Kopfhörerausgang), externen USB-Soundinterfaces etc erfolgt dann bei Bedarf und gruppendynamisch Diverse Nachträge

Das wichtigste Problem bei einem solchen technikaﬃnen Projekt ist es, eine kritische Masse ins Boot zu kriegen. I Nicht mit Jamulus und Technik anfangen, sondern mit einfacher webbasierter Videokonferenz (heutzutage hat ja praktisch jeder Webcam und Mikro im Rechner) über Jitsi, um zunächst das Interesse am Sozialkontakt wiederaufzubauen I Der Einstieg in Jamulus erfordert zunächst nicht viel mehr als Kopfhörerzwang (P.S.: digitale/Bluetooth-Kopfhörer verursachen zusätzliche Verzögerung) I Verwendung von LAN-Kabel, externen Mikrofonen (u.U. auch USB-Mikrofon mit Kopfhörerausgang), externen USB-Soundinterfaces etc erfolgt dann bei Bedarf und gruppendynamisch I In Jamulussessions auf öﬀentlichen Servern kann man recht zwanglos reinhören (Stummschalten!)