ich werfe mal eine Idee von mir im Raum, wo ich eure Erfahrungswerte brauche:
Folgende Struktur:
mAirList Automation (Windows Server 24/7), Moderatoren verbinden sich über einen Icecast Server wenn Sie Livesenden und der Stream Reciever fängt dann an “zuzuhören”.
Da ja Icecast2 gewisse Latenz hat je nach Konfiguration (in meinem falle um die 6sec) wäre für mich ein GUI Objekt geil, wo derjenige sieht, wann er am besten das erste Playlist element bei sich abdrückt, um den Übergang zwischen Automation und Livesendung smooth zu gestalten.
Beispielsweise:
Es gibt in der Automation ein Platzhalter für eine Livesendung der mit einer (weichen) FIX Zeit versehen ist, um den aktuell laufenden Song noch ausspielen zu lassen.
Neues GUI Objekt anlegen: Fix Zeit anzeigen lassen.
Jetzt mein Gedanke: FIX Zeit minus 6 Sekunden = Ergebniss wird im GUI angezeigt.
Lässt sich das so einfach umsetzen? Ist Fix Zeit überhaupt der Anker den man hierbei verwenden sollte? (Driftet das nicht in der Praxis?)
Vorschlag von KI:
Besserer Ansatz
Nicht „FIX minus 6s“ anzeigen, sondern:
„JETZT drücken“
Also:
Livesendung startet in:
00:12
00:11
00:10
…
JETZT STARTEN
Moin,
ich vermute, dein Vorhaben wird schon alleine daran scheitern, dass die Latenz eines Icecast Streams warscheinlich nicht konstant sein wird.
Deshalb wurde der Stream monitor entwickelt, der faded zumindest den laufenden Titel sauber aus und nach der Live-Sendung startet eine frischer Titel von Anfang an.
klar, die Latenz eines Icecast-Streams ist nicht komplett statisch. Aber ich glaube, wir reden hier gerade von zwei unterschiedlichen Szenarien.
Ich meine keinen dauerhaft verbundenen Moderator über mehrere Stunden mit Browserplayer und ständig wachsendem Buffer, sondern eher folgendes Setup:
Moderator verbindet sich frisch zum Livesenden
Stream Monitor hört den Stream mit relativ stabiler Anfangsverzögerung
Man bekommt einen berechneten Countdown angezeigt
startet passend zum Songende bzw. zur Ramp abzgl. der Anfangsverzögerung
Gerade bei einer frischen Verbindung bleibt die Verzögerung bei stabilem Netzwerk oft erstaunlich konstant. Für meinen Zweck reicht da schon eine halbwegs stabile Orientierung, es geht nicht um samplegenaue Synchronität.
Der Stream-Monitor von mAirList löst das technisch natürlich sauber, weil er einfach den Titel ausfadet und danach einen neuen startet. Ich möchte aber bewusst den aktuell laufenden Titel sauber ausspielen lassen und dem Moderator einen besseren Einstiegspunkt geben, statt hart umzuschalten.
Deshalb kam die Idee mit:
„Restzeit aktueller Titel - geschätzter Streamdelay = GO-Zeit“.
Das Ganze ist eher als Komfort-/Timinghilfe gedacht und nicht als hochpräzise Broadcast-Synchronisation
Vielleicht hilft dir dieses Thema ja weiter (bitte auch den Hinweis von Torben beachten):
Wenn du weißt, dass das Delay bei einer frischen Verbindung wirklich immer gleich bleibt, kannst du von dem Script-Wert dann eine feste Zeit abziehen und das Ergebnis eben als Countdown anzeigen lassen (oder wie du es dir vorstellst).
Ja das habe ich schon so verstanden und trotzdem kann der Stream monitor und mAirlist als wiedergebende Instanz schwankende Latenzen haben.
Wie hast Du die latenz gemessen und wie hast Du gemessen, dass dieser Wert sich nicht ändert? Kennst Du interne Prozesse von mAirlist die wir anderen User nicht kennen?
Meines wissens nach gibt es keine öffentlich zugängliche Dokumentation die erklärt wie der der Streammonitor getriggert wird und wie viel zeit dann vergeht wenn die Wiedergabe startet.
Ich wage mal die Behauptung, Torben übergibt den Stream “einfach” an die bass.dll und hat nicht einmal selber Einfluss darauf wie viel Puffer aufgebaut wird. Sprich bei schwankender Netzanbindung wird die bass engine den Puffer selbständig erhöhen und schon passt deine Berechnung nicht mehr.
Wenn Du das so sekunden genau heben möchtest ist der Streammonitor das falsche Werkzeug, dann brauchst Du eine Alternative zu den Früher üblichen ISDN Lösungen wie Musiktaxi. Hat für Dich zusätzlich den Vorteil, dass Du Latenzen im unteren Millisekunden Bereich bekommst und jegliche Schwankung komplett vernachlässigbar ist.
Ich bin da bei @shorty.xs – wenn es jetzt und heute sechs Sekunden Latenz sind, können es übermorgen schon fünf und in einer Stunde dreißig Sekunden sein. Diese Werte werden variieren, auch je nachdem welcher Moderator gerade von wo sendet.
Ich empfehle folgendes – wenngleich unpopuläres – Vorgehen: Legt eine vernünftige Schaltpause ein. Der vorige Moderator fährt seine Sendung genau auf Zeit, sagen wir 15 Sekunden vor der vollen NTP-Stunde. Der nachfolgende startet pünktlich zur vollen (NTP-)Stunde. Natürlich erfordert das Diziplin (und Handwerk) bei allen Beteiligten. Aber Du wirst sehen: Erstaunlicherweise wird niemand deswegen sterben.
klar, komplett ausschließen kann man schwankende Latenzen natürlich nie. Gerade wenn BASS bzw. der Streammonitor intern puffert oder die Verbindung instabil wird, verschiebt sich das irgendwann.
Ich glaube aber, wir reden weiterhin von unterschiedlichen Genauigkeitsanforderungen
Ich muss nocheinmal betonen, dass es mir nicht darum geht, auf 100 ms genau einen satellitensynchronen Übergang hinzubekommen, sondern eher um eine praktische Orientierungshilfe für einen weicheren Einstieg in eine Livesendung.
Der aktuelle Workflow ist:
Moderator verbindet sich
Stream Monitor erkennt Audio
aktueller Titel wird direkt rausgefadet
Mein Gedanke war stattdessen:
laufenden Titel sauber ausspielen lassen
anhand der Restzeit + geschätzter Anfangslatenz einen „GO“-Zeitpunkt anzeigen
Moderator startet passend auf Ramp/Outro
Dass der Delay theoretisch schwanken kann, ist mir klar. Aber bei frischer Verbindung und stabilem Netzwerk habe ich in der Praxis bisher keine riesigen Sprünge festgestellt. Für meinen Zweck reicht vermutlich schon eine grobe Konstanz im Bereich ±1s.
Antwort hierzu:
liegt doch klar auf der Hand: (ein bisschen technisches Geschick vorrausgesetzt)
Messen via Stoppuhr, wann Signal gesendet und wann Signal da
Messen via parraleler Aufnahme, die Differenz = Delay (Oder auch mit sauberen Rückkanal z.B: StudioLink welches nur 40-150ms benötigt (EDIT: werde ich wohl mal spaßenshalber machen)
Messstation via Software einrichten um Latenz eines bestimmten Hz Signals zu messen
Oder einfach “On Air” testen: in den mAirList Playern beide Zeitangaben aktivieren (Rauf & Runterzählend), ein auf “Moderator” tun und den Song direkt abfeuern… Dann braucht man nur noch warten bis der Song bei mAirList ankommt und auf die Uhr zu schauen.
Ggf. 3-6 Tests machen und sich die Werte in einer Excel Tabelle zu einem Durschnitt berechhnen lassen. Oder direkt mit einem Team testen. Bis es eben passt.
Hier kommen ganz viele eigene Ansprüche zusammen, ich pers. habe mich nicht hingesetzt und jedesmal zwei Aufnahmen gestartet, gestoppt, und geschnitten. Für mich hat es einfach gereicht zu sehen: “Ok, meistens um die 6sek Verzögerung”, auch bei verschiedenen PCs/Moderatoren und damit war das Thema für mich gegessen.
Die Idee ist also eher:
„Timinghilfe für angenehmere Übergänge“ und nicht:
„präzise Synchronisation wie bei professionellen Codec-/Contribution-Lösungen“.
Dass man mit echten Low-Latency-Codecs oder Musiktaxi technisch sauberer unterwegs wäre, sehe ich absolut genauso Aber hier muss man auch ein wenig Rational denken bei einem ehrenamtlich finanziertem Web-Radioprojekt
[Disclaimer: nicht persönlich nehmen, ich musste das einfach mal loswerden]
Ich merke leider immer häufiger, dass Diskussionen hier im Forum (betrifft nicht nur dieses Thema und auch nicht immer mit mir im Zusammenhang) sehr schnell in Richtung „warum das theoretisch nicht perfekt funktionieren kann“ abdriften, statt erstmal auf die eigentliche Fragestellung oder den praktischen Anwendungsfall einzugehen.
Natürlich ist mir bewusst, dass ein Icecast-Stream keine professionelle Broadcast-Codecstrecke ersetzt und dass man über Latenzen, Buffering und Drift diskutieren kann. Aber manchmal habe ich das Gefühl, dass man sich hier erstmal fünfmal rechtfertigen muss, warum man etwas überhaupt umsetzen möchte, bevor überhaupt konstruktiv über mögliche Lösungen gesprochen wird.
Dabei hat doch fast jedes Setup seine eigenen Anforderungen, Einschränkungen und Workarounds — gerade im Webradio-Bereich. Nicht jeder hat ein vollwertiges Sendehaus mit DHD-Core, Studioverkopplung und dedizierter Contribution-Strecke im Hintergrund. Genau deshalb entstehen doch überhaupt solche Ideen.
Und am Ende beschreibt der Name „Community Forum“ doch eigentlich schon ziemlich gut, worum es hier gehen sollte. Ich fände es ehrlich gesagt echt schön, wenn man solche Themen hier gemeinsam konstruktiv weiterdenken und nach Lösungen oder kreativen Ansätzen suchen könnte — auch wenn diese vielleicht nicht dem klassischen Broadcast-Standard entsprechen.
Denn manchmal wirkt es leider eher so, als würde eine Idee erstmal technisch zerlegt werden, bevor überhaupt darüber gesprochen wird, ob sie für den jeweiligen Einsatzzweck vielleicht trotzdem sinnvoll sein kann . Es soll doch auch ein Miteinander statt gegeneinander sein. Das gilt für das Gesamte Forum!
Denn ehrlich gesagt wäre ich wahrscheinlich gar nicht erst auf die Idee gekommen, wenn ich in der Praxis nicht genau diesen Bedarf hätte
Die Frage ist halt: wo fängt die Perfektion an und wo hört die Schlamperei auf? Mit einer Sekunde hin oder her, errechnet aus irgendwelchen Durchschnittswerten, kann sich ein Übergang, wenn Du Pech hast, schon absolut versemmelt anhören, insbesondere da es bei ±1 Sekunde ja bis zu zwei Sekunden Ungenauigkeit sein können. Sowas würde ich nicht abliefern wollen. Insofern eben mein Rat, eine kleine Pause zu lassen, das ist allemal smoother.
Für das, was Du vorhast, reicht ein Blick zur Uhr, gepaart mit Pünktlichkeit bei den Beteiligten.
Habe festgestellt, dass gerade bei KEINEM Signal vom Zuspieler der Buffer extrem aufbaut. So bis zu 60 sek. Also immer kurz vor der Sendung Encoder einschalten oder auch Programm hochfahren. Dann stimmen die 5-6 sek. Plus 3-4 sek zum DAB+ Sender so halbwegs…
Mir ist unterwegs ein Gedanke gekommen, ich bin jedoch in der Icecasterei nicht sattelfest. Wenn es gelänge, (auf der gebenden Stelle) zusammen mit den Metadaten der Titel die aktuelle NTP-Zeit mitzuschicken, etwa jede Sekunde, und gleichzeitig in mAirList (im Stream Monitor) diese Information herauszulesen, dann ließe sich damit eine quasikontinuierliche Anzeige der aktuellen Latenz verwirklichen.
Ich als IT Admin will es aber den Moderatoren leichter machen
Die Moderatoren schauen ja sowieso per Stream auf den mAirList Server zu. Rechnen aber ggf, nicht mit der Icecast Latenz. Dem will ich vorbeugen, und eben einen Counter für Liveschalttungen einbauen der einem diesen Job abnimmt und man auf direktem Blick sieht, wann man das erste Element abdrücken soll. Es kann ja auch mal sein dass ich was an dem icecast buffering ändern will, dann müsste ich alle Moderatoren eine neue Latenz-Zeit verklickern die sie dann mit einrechnen sollen.
Webradio mit ehrenamtlichen Moderatoren überall in Deutschland verteilt
Es gibt einen Windows Server mit mAirList Automation drauf die 24/7 das Senden an LautFM übernimmt, sowie den Stream der Moderatoren empfängt, Soundprocessing beinhaltet usw.
Moderatoren die Live eine Sendung fahren wollen verbinden sich mit einem IC2 Server zur mAirList Automation und sind stand jetzt sofort Live On Air, indem der aktuell laufende Song ausgeblendet wird.
Liveschaltung ist hier in dem Falle nicht ganz der richtige Begriff, da sich das ja meistens auf Außenreporter oder sonstiges bezieht.
Aber das Prinzip ist fast das gleiche, denn jeder Moderator hat im Prinzip sein eigenes Studio und wir wollen diese Studios sauber in die Automation integrieren ohne einen Song abrupt ausblenden zu lassen. So eben, dass man fast den Übergang zwischen Automationsserver & Livesendung (von bspw. meinem PC) nicht hört.
Dass wir kein Zentrales Gebäude mit A & B Studio haben die direkt ein lückenfreies Umschalten bieten sind erschwerte Bedingungen aber ich glaube auch, dass ist im Webradio eher weniger Standard.
Die Moderatoren können live den Bildschirm sowie Ton vom Automationsserver sehen/hören.
Sie sehen also was mAirList macht, wenn sie sich verbinden. Aber einige haben ggf. nicht die 6 Sek. Delay auf dem Schirm. Wenn ich jetzt mAirList also dahingehend umstelle, dass der aktuelle Song normal ausläuft, sobald sich einer Verbindet, könnte sich das sehr Schräg anhören, wenn 6s Stille dazwischen ist.
Dafür will ich “einfach nur” (klingt immer gut) ein GUI Objekt auf dem Automationsserver einrichten der einen Timer anzeigt (bspw. EOF), wo die 6s oder wieviel auch immer mit abgezogen werden.
Als alter AFN Hörer kann ich nur sagen: Als Titel zur Schaltzeit ein Instrumental-Stück spielen, da ist es egal wann ausgeblendet wird.
Für alle, die das nicht mehr kennen:
Bei AFN starteten pünktlich zur vollen Stunde die Nachrichten live via Satelit aus den USA. Die Verzögerung des Sat-Strecke war auch nicht planbar - sozusagen der Vorläufer zur heutigen Internettechnik. Das laufende lokale Programm wurde von den News gnadenlos niedergebügelt, egal was da gerade lief. Also spielte man als Puffer was instrumentales.
aber ich glaube auch, dass ist im Webradio eher weniger Standard.