Echtzeit Audio und MIDI übers Internet

...vielen Dank für die Rückmeldung - es geht ja doch viel weniger um Nachsicht als mehr um die Beschränkung der möglichen Nutzer: die Mehrheit kann eher halt nicht sich alle notwendigen libraries zusammensuchen und Kompilieren bzw. wenn dabei Fehler auftreten diese auch selbst korrigieren...

...so ein Server könnte in unserem Colocation-Rack auf einer unserer Serverhardwares laufen - wenn die Hardware und Anbindung zuhause im Keller nicht ausreicht...
Das Angebot nehme ich an! Derzeit geht viel Zeit in den KnobKraft Orm Librarian, mein anderes OpenSource Projekt, aber ich nehme mir mal die Feiertage für JammerNetz vor. Wir bauen auch gerade Skripte, mit denen man bei AWS automatisiert einen Server hochfahren kann, aber da braucht es dann ein AWS Konto, hat ja auch nicht jeder. Und wenn da was schiefgeht...
 
War in DSL Anfängen mit Fastpath möglich.
Heute sinds eher 50-70ms
Hier mal ein paar Zeiten, die bei unserem wöchentlichen, realistischen Fall gemessen wurden:

* ASIO Treiber, Buffergröße 128. A/D Wandlung des Instruments -> ca 3-4 ms bei 48 kHz Samplefrequenz
* Senden von 128 Samples zum Server nach AWS Frankfurt -> 10 ms (ein UDP Paket mit weniger als 1400 Bytes)
* Server hat Eingangswarteschlange, Länge ca 1-5 Buffer -> ca 4 bis 20 ms
* Daten gehen zurück an Client -> 10 ms
* Client hat Warteschlange bei der Audioausgabe, ca 5 Buffer -> 20 ms
* D/A Wandlung im Interface, auch nochmal 3-4 ms durch Buffergröße 128, manche Audiointerfaces brauchen auch zwei Buffer.

Man bekommt also einen vollen Roundtrip von Analog nach Analog über einen Server im Internet mit 50-70 ms hin, manchmal für einzelne Teilnehmer beser (durch bessere Warteschlangenposition).

Dabei geht die meiste Zeit nicht durch die Wandlung oder die Netzwerkübertragung verloren, sondern durch die notwendigen Warteschlangen Warum sind die notwendig? Um den Paket-Jitter auszugleichen, die Pakete brauchen unterschiedlich lange, um durch das Internet zu reisen. Hier ist der größe Hebel zur Beschleunigung, und wie oben schon gesagt sollte tunlichst kein Wifi verwendet werden, und kein Cable-Internet sondern VDSL oder Glasfaser. Dann bekommt man 50 ms Gesamtlatenz hin. Wenn das Internet gurkt, sind das schnell 80 bis 100ms, und das geht dann unserer Erfahrung nach nicht mehr wirklich.

Jitter ist aber nicht das gleiche wie Ping-Zeit!
 
Naja, zeitverzögert ist dann aber nicht wirklich Echtzeit. :agent:
So eine "definierte Zeitspanne" heißt für unsere Zwecke dann 3-6 ms oder so, oder? :agent:
Mach mal einen ping zu einem gut angebundenen Server, der schnell antwortet. Ich würde mal vermuten, mindestens die Hälfte davon, eher mehr, je nachdem, wie das ganze Protokoll aufbaut sein soll. (Ich habe es mir nicht angesehen bisher, man möge mich berichtigen, wenn ich mich irre).
 
Wozu braucht es überhaupt Echtzeit, wenn es eh nicht ohne große Verzögerungen möglich ist?
Da kann man dann "einfach" Daten mit Zeitstempeln versenden, dann weiß man bzw. die Software, wo die Daten auf die Zeitachse hingehören.
Die Bandbreite muss halt ausreichen, um Daten in ihrer Gesamtheit in akzeptabler Zeit übertragen zu können.
 
Wozu braucht es überhaupt Echtzeit

...na, weil man miteinander spielen möchte - alles andere kann man auch durch den Austausch von Aufnahmen und overdubs hinbekommen...das fühlt sich aber ganz anders an als sessions bei bspw. NINJAM - da war ich vor ein paar Jahren öfter mal an echt tollen jams beteiligt...
 
Wozu braucht es überhaupt Echtzeit, wenn es eh nicht ohne große Verzögerungen möglich ist?
Genau, wurde oben schon gut beantwortet von fairplay. Stell dir einfach vor, 2 Leute spielen miteinander, und bei einem braucht die Signalverarbeitung vom Ohr ins Gehirn 100ms länger. Meinst du da kommt am Ende Musik raus, bei der man zuhören möchte? :xenwink:
Das kannst du auch an einem Gerät deiner Wahl (DAW mit mehreren Spuren, Multitracker) ausprobieren, einfach eine der Spuren um 100ms nach hinten verlagern ...
 
Leute, Leute. Wenn ich schreibe "wenn es eh nicht ohne große Verzögerungen möglich ist", dann meine ich die Unmöglichkeit ohne deutliche Verzögerungen die Daten zu übertragen. Wenn die verwendete Technologie (Internet mit deutlichen, unmusikalischen Verzögerungen) es nicht zulässt, dann ist es halt so. Von welcher Echtzeit wollt ihr dann sprechen?
 
...zum Beispiel von der um einen Takt versetzten Echtzeit von NINJAM - drehen wir uns im Kreis?...
Naja, ich hatte eine Vorstellung von Echtzeit, wenn man wirklich zusammen gleichzeitig performt.
Aber so, wenn die Daten im Hintergrund übertragen und dann im Sequencer des anderen dann auch platziert werden ...
In dem Sinne, dass die Software es übernimmt und man nicht selber irgendwelche Loops irgendwo hochlädt ...
Wenn das "Echtzeit" heißt – ok ...
 
Michael will wohl Datenübertragung mittels verschränkter Elementarteilchen...
 
Naja, man könnte vielleicht vom Echtzeit-Management (klar, mit etwas "Latenz") von kollaborativen Projekten sprechen. Oder so ähnlich ...
D.h., ich bastle an meinem Part in der DAW, und wenn ich der Meinung bin, dass ich das für die anderen freigeben kann bzw. möchte, dann klicke ich auf Freigabe, und mein Part steht für alle anderen oder für eine Teilmenge der Beteiligten zur Verfügung, und wer da noch was ändern möchte, erzeugt seine alternative Version, die dann auch für alle oder für eine Teilmenge der Beteiligten zur Verfügung gestellt werden kann. Wir haben so was Ähnliches mal in einem Online-Projekt um die Jahrtausendwende manuell gemacht. Das war keine Echtzeit. Und das war mit 56k-Modems. :P
 
plonk

zurück zum Thema. um die 50ms Latenz in Kontext zu setzen: ab welcher Latenz wird Videokonferenz unnatürlich? Das ist ja eine ähnliche Situation aus hören und reagieren.
 
...ich verstehe die Frage nicht: geht es um den Versatz zwischen Ton und Bild? - das wäre ein ein technischer Fehler und technisch reparierbar...

Neee, entschuldige, Bild ist unerheblich für meine Frage.

ich meine ab welcher Latenz man sich nicht mehr flüssig unterhalten kann. Man spricht, wartet kurz auf eine Antwort, die nicht kommt, spricht weiter. Dann unterbricht einen die Antwort - die Latenz hatte sie einfach einen Hauch zu lange verzögert.
Ich könnte mir vorstellen, dass das bei Musik ähnlich sein kann.
 
Ich denke das ist verschiedenen von Person zu Person, aber deutlich höher als 50ms.
Bei VoIP geht man in der Regel davon aus das bis zu 150ms für jeden erträglich ist, 150-300ms sind für viele noch tolerierbar, ab 300ms wird's schwierig.
 
Ich denke das ist verschiedenen von Person zu Person, aber deutlich höher als 50ms.
Bei VoIP geht man in der Regel davon aus das bis zu 150ms für jeden erträglich ist, 150-300ms sind für viele noch tolerierbar, ab 300ms wird's schwierig.
Sehe ich auch so. Und beim zusammen Musizieren ist es auch für jeden etwas anders, wir kommen mit 50 ms klar. Der Trick ist mit Synths (oder auch E-Gitarre) sich selber nur das Signal auf die Kopfhörer zu geben, das vom Server kommt. Alle Beteiligten hören also exakt das Gleiche. Dann kann man mit etwas Antizipation auch zusammen spielen. Tight is natürlich anders, aber Spaß machen tut es, und in 50 ms kommt der Schall ja auch nur 15 Meter weit... etwas großer Probenraum.
 
Ich habe mal ein Tutorial gemacht, wie man den Client unter Linux installiert

Jamulus Client Installation unter Kubuntu 20.04 (Deutsch)
 
Naja, zeitverzögert ist dann aber nicht wirklich Echtzeit.
Doch zeitverzögert kann Echtzeit sein. Bei Echtzeit muss nur garantiert sein, dass das System IMMER innerhalb einer bestimmte Zeitspanne antwortet, das kann auch 1 Minute sein.
Zeitverzögerung hat man auch in der Anlalogen Welt, sofern man nicht Kopfhörer nutzt, dank der Schallgeschwinedigkeit macht das ein paar ms pro Meter. Was selbst das Spielen am Piano nicht verzögerungsfrei ermöglicht. Hier stellt sich immer die Frage wieiviel ms wir noch als verzögerungsfrei akzeptieren.

Eine E-Gitarre per Kopfhörer wird verzögerungsfreier sein als eine Akustische Gitarre ohne Kopfhörer. Echtzeit hat man bei beidem. Genauso könnte der Sound eines SoftSynth per Kopfhörer schneller am Ohr sein, als ein Analog Synth wo die Boxen zwei Meter weit weg stehen.

Alles unter 11ms geht wohl für die meisten in Ordnung, bei mir sind es so 15ms, ab dann merke ich eine Latenz. Gitarristen sind da wohl deutlich emfindlcher als so Leute wie ich, die mal ne lahme Melody und ein paar Akkorde drücken.

 
Zuletzt bearbeitet von einem Moderator:
...vielen Dank für die Rückmeldung - es geht ja doch viel weniger um Nachsicht als mehr um die Beschränkung der möglichen Nutzer: die Mehrheit kann eher halt nicht sich alle notwendigen libraries zusammensuchen und Kompilieren bzw. wenn dabei Fehler auftreten diese auch selbst korrigieren...

...so ein Server könnte in unserem Colocation-Rack auf einer unserer Serverhardwares laufen - wenn die Hardware und Anbindung zuhause im Keller nicht ausreicht...
So, ein bisschen spät, aber wir sitzen ja sowieso immer noch im Lockdown... ich habe jetzt einen Installer für Windows auf github, der Client und auch ein Server Executable installiert, auch zum Testen mit einem "localhost" Server. Meine Lösung ist ja nach wie vor Server-basiert, aber wer damit mal ein bisschen rumprobieren möchte, ich helfe gerne. Die Anleitung auf github ist eigentlich recht vollständig.

Die 2.1.2 Release findet sich hier:

Das ist übrigens auch ganz spannend, Raspi-basiert und mit virtuellem 3D Audio:
 


Neueste Beiträge

News

Zurück
Oben