Online Proben Erfahrungen?

[draikin]

Die Latenzen hängen auch bei Sonobus stark von der Verbindungsqualität ab, sind aber bis auf wenige Ausnahmen durch ein offenbar ausgeklügeltes Management wirklich so, daß man sie nicht wahrnehmen kann - und ich bin da wirklich extrem empfindlich. Wir konnten jedenfalls die letzten Male problemlos rhythmische Elemente synchron spielen.

Erster Eindruck (es sind ja wirklich wenig Public-Server besetzt): Deutlich besser als Jamulus. Ob's wirklich vom Timing her so gut ist, wie das für mich hier klingt, weiß ich vermutlich erst wenn gleichzeitig die Gegenseite gehört habe.

Also ich habe gestern bei einem ersten Test die genau gegenteilige Erfahrung gemacht. Wir haben nur zu zweit sonobus probiert und die Verzögerungen waren unterirdisch. Das war gefühlt ein Delay mit 500ms oder so. Auch Änderungen der Einstellungen, was Audioqualität o.ä. betrifft brachten keinerlei Verbesserung.

Absolut unbrauchbar, bei gleichen Vorraussetzungen, wie bei den vergangenen Jamulus Sessions.
Das war um längen schlechter als Jamulus zu viert und da waren wir auch nicht zufrieden, deshalb der Blick über den Tellerrand zu sonobus.

Fazit: Wir werden am Wochenende wieder mit Jamulus proben. Und auf baldige "echte" Proben im Proberaum hoffen. Schade, denn die Software wirkt aufgräumt und intuitiv, auch die Aufnahmemöglichkeit wäre ggfs interessant gewesen.

 

[Gast264907]

auch die Aufnahmemöglichkeit wäre ggfs interessant gewesen.

Die hat Jamulus doch auch, nur eben anders. Wir schneiden unsere Proben immer mit. Allein schon, um beim Jammen entstehende Ideen gleich festgehalten zu haben.

 

[microbug]

Auch Änderungen der Einstellungen, was Audioqualität o.ä. betrifft brachten keinerlei Verbesserung.

Habt ihr auch den gleichen UDP Port eingestellt und diesen in Euren Routern für den angeschlossenen Rechner freigegeben?

 

[draikin]

Habt ihr auch den gleichen UDP Port eingestellt und diesen in Euren Routern für den angeschlossenen Rechner freigegeben?

Nein, denn in der Doku zu sonobus steht dazu folgendes:

SonoBus includes a Direct Tab for connecting to other devices in your local network, but this feature has only undergone limited testing...

und

These ‘direct’ connections are mutually exclusive with the group feature and connection server. Instead, You will need to fill in the ‘host’ field with the IP address of one of the ‘local’ SonoBus clients (for example, your own device) and, for example, UDP port 12000.

Das verstehe ich so, dass dieses experimentelle Feature für lokale Netzwerke gedacht ist und mit den Gruppen (privat oder nicht) nicht verwendbar ist. Noch dazu kann man nicht (mehr) bei allen Router solche Freigaben überhaupt vornehmen.

Und von den Kollegen ohne jegliche technische Kenntnisse rede ich da noch gar nicht

 

[.point]

Moin zusammen,

habt ihr in der Zwischenzeit andere Erfahrungen gemacht, welche Lösung zum online proben gut funktioniert?

 

[nasi_goreng]

Ich breche eine Lanze für Jamulus, da es einfach und übersichtlich zu konfigurieren ist. Wichtig ist ja die Latenz und die wird überwiegend durch die Leitungslängen bestimmt. Nachteil ist, dass man auf den öffentlichen Servern nicht alleine ist, aber man kann das Programm so einstellen, dass man nur die hört, die man auch hören will.
Man könnte sogar selber auch recht leicht einen Server aufsetzen.
Zudem ist es kostenlos.

 

[.point]

Danke dir - ich habe eben mal Jamulus installiert.

Ich war zwar nur über Wlan im Netz, aber ich konnte mich sowohl auf externen Servern einloggen, als auch auf dem dann von mir gestarteten Server einloggen.

Für mich sieht es aus, als bräuchte man also sein Instrument und ein Mikro, welches über sein Audio Interface angeschlossen eingespeist werden.

Ob ein eigener Server funktionieren würde, oder diese "Solo Funktion" auf öffentlichen Servern, kann ich noch nicht sagen.

Auf den ersten Blick würde ich jetzt sagen: Falls ich die Vorbedingungen richtig verstanden habe, wäre es einen Versucht wert, mit der Band eine Online-Probe zu versuchen.

So ein langes Lan Kabel und Mikro zzgl. XLR Kabel müsste man sich dann besorgen, falls nicht vorhanden.

 

[MarkSlowhand]

Ich hatte vor Jahren mit einer Band mal Sofasession und JamKazam benutzt und bei letzterem hatte ich, wenn es nicht richtig erinnere, eine Roundtrip-Zeit von mit 17 Millisekunden erreicht. Das ganze verbessert sich, wenn man nicht einen der Musiker als Taktgeber nimmt sondern ein Metronom, dass der Server zur Verfügung stellt. Das halbiert etwa den Versatz des eigenen Timings zu dem der anderen Musiker, weil alle nach einem halbwegs synchronen Metronom spielen und nicht nach dem Takt des anderen Musikers, der ja dann selbst schon verzögert bei den anderen Musikern ankommt.

Insgesamt war das halbwegs brauchbar sofern man nicht den aller frickeligsten Funk spielt. Neben den Latenzen durch die IP Strecke durch Leitungslängen und natürlich insbesondere Pufferverzögerung in Routern und Switches kommen bei Keyboardern dann natürlich auch Latenzen des Audio Interfaces hinzu, falls Sie VST Sounds verwenden und natürlich auch grundsätzlich die Latenz des Audio Interfaces, mit der auch ein analoges Signal für den Transfer im Netz zunächst digitalisiert werden muss. Zur Messung habe ich mein Audiosignal einmal lokal auf eine Spur aufgezeichnet und zusätzlich das vom Mix auf dem Server zu mir zurückgeführte Summensignal auf eine zweite Spur. Und dann habe ich den zeitlichen Versatz des Signals auf diesen beiden Spuren gemessen.

 

[.point]

Da werde ich mal schauen, ob es dies Metronomen Feature auch bei Jamulus gibt.

Unser Schlagzeuger übernimmt sonst immer den Job des Metronomens

 

[MarkSlowhand]

Da werde ich mal schauen, ob es dies Metronomen Feature auch bei Jamulus gibt.

Unser Schlagzeuger übernimmt sonst immer den Job des Metronomens

Könnte sich wirklich positiv auswirken. Dafür gibt es dann Protokolle wie PTP (precision time Protokoll) mit denen durch Ping Pong Messung in beide Richtungen die Latenzen zwischen Endpunkten vorab ausgemessen werden und darüber die Endpunkte eine Art synchronisierte Uhr haben. Damit lässt sich auch ein verteiltes Metronom gut realisieren. Du spürst dann nur den Versatz den das Audio des anderen Musikers zu dir braucht weil er sein Audio nach dem gleichen Timing spielt wie du dein lokales Audio. Nimmst du das Audio des anderen Musikers als Takt dann spielt er es nach seinem lokalen Timing, dann braucht es ein Versatz bis zu dir, dann spielst du nach seinem beivdir versetzt angekommenen Timing und dein Audio hat dann nochmal einen zusätzlichen Versatz zu ihm zurück. Also hört er dich mit einem noch größeren Versatz (round trip delay) gegenüber sich selbst. Das ist der Hintergrund warum das Metronom hilft.

 

[.point]

klingt logisch - danke dir für den Input

Beitrag automatisch zusammengefügt: Gestern um 23:42

Es gibt zumindest auf Github ein Projekt für einen Client, der dann das Metronomen spielt.

GitHub - passing/jamulus-metronome: Jamulus Metronome Client

Jamulus Metronome Client. Contribute to passing/jamulus-metronome development by creating an account on GitHub.

github.com

Aber ein serverseitiges Metronomen direkt von Jamulus gibt es nicht:

FAQ – Jamulus Website

jamulus.io

 

[murmichel]

Rein theoretische Überlegung:

Ich glaube nicht, dass man ein serverseitiges Metronom haben will. Jedenfalls nicht in dem Sinn, dass wirklich periodisch ein Klick übertragen wird. Die beteiligten Geräte brauchen eine synchronisierte Uhr und dann muss ihnen der Server mitteilen, dass um eine bestimmte Zeit ein Metronom mit einem bestimmten Tempo gestartet wird/wurde. Die weiteren Klicks können die Geräte dann selbst berechnen. Im Ergebnis ist das dann ein globales Metronom. (Albert E. möge mir verzeihen.)

 

[MarkSlowhand]

In JamKazam hatte das mit dem Metronom ziemlich gut geklappt und das synchronisieren hatten Server und Clients untereinander automatisch gemacht. Und diese Uhren können ziemlich genau sein, bei Audiotransport über AVB mit gptp beispielsweise bis in den Nanosekundenbereich. Allerdings ist AVB auch nur für Transport im LAN, nicht über Router Grenzen hinweg geeignet.

Es gibt natürlich Musiker die das Spielen nach Metronom grundsätzlich ablehnen, das ist dann eine andere Sache. Aber wir spielen in einer meiner Bands beispielsweise auch bei Proben im Proberaum und bei Gigs auf der Bühne immer mit Klick also mit Metronom und das Timing ist dadurch sehr sehr sauber geworden.

Beitrag automatisch zusammengefügt: Heute um 00:38

Rein theoretische Überlegung:

Ich glaube nicht, dass man ein serverseitiges Metronom haben will. Jedenfalls nicht in dem Sinn, dass wirklich periodisch ein Klick übertragen wird. Die beteiligten Geräte brauchen eine synchronisierte Uhr und dann muss ihnen der Server mitteilen, dass um eine bestimmte Zeit ein Metronom mit einem bestimmten Tempo gestartet wird/wurde. Die weiteren Klicks können die Geräte dann selbst berechnen. Im Ergebnis ist das dann ein globales Metronom. (Albert E. möge mir verzeihen.)

Beitrag automatisch zusammengefügt: Heute um 00:44

Habe noch mal die KI gefragt wie JamKazam das aktuell genau macht:

JamKazam synchronisiert seine Metronome durch eine patentierte „Distributed Real-Time Metronome“-Technologie, die die Latenz zwischen den Musikern minimiert, indem der Metronom-Klick als dedizierter Audiostream direkt an alle Teilnehmer gesendet wird, was zu erstaunlich engen Klick-Clustern führt, auch bei hoher Latenz zwischen den Spielern, und so ein koordiniertes Zusammenspiel ermöglicht. Es funktioniert nicht über einen zentralen Master-Taktgeber, sondern jeder Teilnehmer erhält den Takt synchronisiert, was die Online-Sessions viel besser spielbar macht.

 

[.point]

Dann werde ich Jamkazam wohl auch mal in Betracht ziehen. Ich hatte noch eine alte Installation auf dem Rechner, die habe ich eben mal aktualisiert.
Sogar mein Account hat noch funktioniert.

(kleiner) Nachteil ist, dass man ohne Account nichts machen kann.