Chciałem podzielić się z wami moją przygodą w wskrzeszaniu transmisji Radia SAR na Politechnice Gdańskiej.
Radio SAR - Studencka Agencja Radiowa, to organizacja studencka na Politechnice Gdańskiej działająca od 1957 roku. Oryginalnie zajmowała się działalnością kulturalno-dziennikarską oraz propagandową. W latach 90’ chwilowo na falach radiowych jako Radio ARnet. W 2003 roku organizacja została wskrzeszona w postaci radia internetowego - Radio SAR.
Poniżej kilka linków z zasobami archiwalnymi:
- Archiwum 65 lecia SAR.
- Strona upamiętniająca historię SAR z czasu otwarcia Radia SAR.
- Archiwum SAR w Bibliotece PG.
Problem
Stacja po latach wciąż cieszy się zainteresowaniem studentów, a co roku dołączają nowe osoby zainteresowane prowadzeniem swoich audycji. Nie da się ukryć, że rola radia, a szczególnie radia internetowego przemija z czasem. W pierwszych latach działalności radio było szalenie popularne, nadając w ramach sieci SKOS (20 Urodziny SKOS! Relacja). W ostatnich latach, szczególnie po pandemii, radio upada od strony technicznej - zarówno wyposażenia studia, ale też części informatycznej.
Problemy z stabilnością sieci i komputerów znajdujących się w studiu sprawiły, że w ostatnich latach transmisja radia potrafiła być nieaktywna przez tygodnie.
Aby dać organizacji jak najlepszą szansę na wskrzeszenie się i odnalezienie swojego nowego ja, chciałem od dłuższego czasu zająć się aspektem techniczny. I w te wakacje znalazłem ten czas, odrywając myśli od innych aktywności.
Infrastruktura nadawcza
W ostatnich latach architektura radia była bardzo prosta. Na jednym z komputerów w reżyserce był uruchomiony serwer Icecast, do którego łączono się oprogramowaniem BUTT z innego urządzenia prowadzącego stałą transmisję. Na tym komputerze było uruchomione oprogramowanie AutoDJ grające ciągle muzykę, a w trakcie audycji można było przejść na strumień wychodzący z konsolety. Infrastruktury audio nie jestem w stanie opisać, bo nie mam w tym doświadczenia.
Wyglądało to mniej-więcej tak:
Prosto i działało przez większość czasu. Główny mankament tego rozwiązania jest taki, że kilka urządzeń musi pracować ciągle aby utrzymać transmisję. Lokalizacja nie pomagała, ponieważ w losowych momentach w akademiku potrafił być zresetowany prąd. UPS by nie pomógł, bo siadała też sieć SKOS. Zdarzyło się też, że konfiguracja SKOS była skopana i przez tygodnie nie było dostępu do internetu.
Zróbmy coś lepszego
Przede wszystkim chcemy wynieść się z piwnicy w Domu Studenckim nr 2. Fajnie by było mieć lokalizację poza akademikiem z której będzie prowadzona transmisja. Z tego powodu poprosiliśmy Centrum Usług Informatycznych PG o przyznanie Radiu jakiegoś małego VPSa na którym można by postawić serwer Icecast. Zapytanie wysłaliśmy w marcu 2023 i… proces został zamknięty dopiero w lipcu 2024.
Serwer dźwięku to jedna rzecz, drugim aspektem jest utrzymanie ciągłości strumienia dźwięku. Rozwiązanie z ciągłym połączeniem BUTTa jest ok, ale pozostawia wiele do życzenia w kwestii zarządzania zdalnego. Bez obecności w reżyserce zmiana utworów musi być prowadzona przez RDP czy innego Team Viewera. Słabo. W przypadku gdy chcemy przenieść transmisję np. w teren, transmisja musi być przerwana, i połączona z innego miejsca, co też powoduje rozłączenie słuchaczy w ich odtwarzaczach.
Aby to poprawić, chcemy wprowadzić jakąś formę cyfrowego mixowania dźwięku, nomen omen AutoDJ, działającego po stronie “serwera”, tak aby połączenie z reżyserki było odciążone i wymagane tylko kiedy chcemy poprowadzić audycję.
Pierwotnie miało być zastosowane rozwiązanie LibreTime, które jest forkiem profesjonalnego oprogramowania AirTime. Okazało się jednak straszne w utrzymaniu, a instalacja zawiła (jak teraz patrzę, dużo się poprawiło od mojego oryginalnego researchu, mogę jeszcze wrócić do tego tematu).
Alternatywą jest AzuraCast - o wiele prostsze w instalacji i zarządzaniu, a nawet posiadające więcej funkcji.
Obydwa rozwiązania pozwalają na wirtualne zarządzanie stacją radiową. Usługa wybiera utwory z playlist, uruchamia jingle, odtwarza powtórki programów zgodnie z harmonogramem etc. Kiedy przychodzi czas transmisji z reżyserki, oprogramowanie akceptuje połączenie i przekierowuje dźwęk bez przerywania strumienia słuchaczy. Sercem implementującym tą funkcjonalność jest Liquidsoap, język pozwalający na programistyczne definiowanie strumieni audio i video. Instancja Azuracast posiada również swoją instancję Icecasta, który może być traktowany jako backup.
Azuracast zostało zainstalowane na jednym z komputerów w radiu i przejęło rolę głównego urządzenia nadającego. Sygnał dźwiękowy z Azuracast jest przekierowany do zewnętrznego serwera Icecast, do którego łączą się użytkownicy. W przypadku gdy połączenie z Azuracast jest zerwane, serwer Icecast został skonfigurowany do odtwarzania sygnału zastępczego - powtarzającego się jingla radia.
Idealnie byłoby, gdyby cała instalacja Azuracast znajdowała się w “chmurze”, jednak dostępna przestrzeń dyskowa na VPSie nie pozwala na jej efektywne wykorzystanie. Bez możliwości trzymania utworów muzycznych na tej samej maszynie nie da się zmiksować sensownego sygnału.
Ostatecznie architektura prezentuje się następująco:
W tym układzie, połączenie z reżyserki jest opcjonalne. Cały sygnał stacji jest miksowany na jednej maszynie i replikowany na zewnętrznym serwerze Icecast. W przypadku awarii, reżyserka wciąż może połączyć się do zewnętrznego serwera Icecast, który w międzyczasie będzie grał dźwięk zastępczy.
Efekt końcowy
- play.radiosar.pl - Strona publiczna odtwarzacza radia internetowego Azuracast.
- play.radiosar.pl/podcasts - Podcasty/Audycje do odsłuchania poza anteną.
- play.radiosar.pl/schedule - Ramówka radia.
ToDo
Architektura cały czas ma wąskie gardło - instancja Azuracast znajduje się na jednej maszynie, która nie posiada nawet redundancji dysków. Mam nadzieję, że dzięki zakupom sprzętu uda się kupić coś na pokrój serwera NAS do trzymania utworów muzycznych i archiwum nagrań.
