Radio stojące na parapecie odbiera program niemal w chwili, gdy nadajnik wysyła falę. Tymczasem ta sama audycja uruchomiona w telefonie potrafi być opóźniona o kilka, kilkanaście, a czasem kilkadziesiąt sekund. Gdy w studiu pada sygnał pełnej godziny, odbiornik FM już go odtwarza, a głośnik sieciowy wciąż kończy poprzednią piosenkę.
Winna nie jest powolna podróż dźwięku przez internet. Najwięcej czasu zajmują czynności wykonywane po drodze: kodowanie, porcjowanie danych, przesyłanie ich przez serwery i gromadzenie zapasu w odtwarzaczu. Opóźnienie jest więc w dużej mierze ceną za to, że transmisja ma grać płynnie mimo zmiennej jakości łącza.
Najpierw dźwięk musi stać się strumieniem danych
W studiu audycja istnieje jako ciągły sygnał audio: głosy z mikrofonów, muzyka z systemu emisyjnego, dżingle i wiadomości. Do tradycyjnego nadajnika można skierować go niemal bezpośrednio. Internet potrzebuje natomiast danych cyfrowych ułożonych w sposób zrozumiały dla serwera i odtwarzacza.
Enkoder pobiera próbki dźwięku i kompresuje je przy użyciu kodeka, na przykład AAC, MP3 albo Opus. Nie wysyła każdej próbki osobno. Zbiera krótką porcję materiału, analizuje ją i tworzy ramki danych. Taka operacja wymaga niewielkiego zapasu dźwięku, a kolejne elementy toru mogą dołożyć własne kolejki. Pojedyncze opóźnienia bywają małe, lecz ich suma staje się słyszalna.
Warto też odróżnić kodek od przepływności. Niższa przepływność oznacza zwykle mniej danych do przesłania, ale nie gwarantuje automatycznie mniejszego opóźnienia. Duże znaczenie mają długość ramek, ustawienia enkodera, sposób transportu i zachowanie odtwarzacza. Dwa strumienie o podobnej jakości mogą więc docierać do słuchaczy w różnym czasie.
Serwer nie jest nadajnikiem w klasycznym znaczeniu
Po zakodowaniu program trafia do serwera strumieniowego. Dokumentacja projektu Icecast rozdziela tu dwie role: klient źródłowy dostarcza treść, a serwer przekazuje ją słuchaczom. To ważna różnica wobec nadajnika radiowego. Jedna antena emituje sygnał, który może odebrać dowolna liczba urządzeń znajdujących się w zasięgu. W typowej transmisji internetowej serwer obsługuje osobne połączenia odbiorców albo korzysta z dodatkowej infrastruktury rozprowadzającej dane.
Gdy słuchacz wybiera stację w serwisie takim jak Radio Biz, kliknięcie przycisku odtwarzania jest dopiero początkiem. Odtwarzacz musi odnaleźć właściwy adres strumienia, zestawić połączenie, otrzymać dane i zgromadzić ich wystarczająco dużo, aby rozpocząć odtwarzanie. Przekierowania, szyfrowanie połączenia czy geograficzna odległość od serwera również mogą dodać ułamki sekund.
Bufor: mały magazyn przeciwko przerwom
Internet nie dostarcza danych w idealnie równym rytmie. Pakiety mogą przychodzić szybciej lub wolniej, a połączenie mobilne zmienia jakość wraz z przemieszczaniem się telefonu. Odtwarzacz nie chce dopuścić, aby każda chwilowa zwłoka powodowała ciszę. Dlatego przed włączeniem dźwięku napełnia bufor, czyli niewielki zapas przyszłego programu.
Jeśli w buforze znajduje się dziesięć sekund audycji, krótkie spowolnienie sieci może pozostać niezauważone. Odtwarzacz nadal zużywa zgromadzone dane, podczas gdy następne są pobierane. Ten zapas oznacza jednak, że słuchamy wydarzeń sprzed co najmniej kilku sekund. Im większa odporność na wahania łącza, tym dalej od chwili „na żywo” może znaleźć się odbiorca.
Ten kompromis dobrze opisuje Europejska Unia Nadawców w materiale z 30 marca 2026 roku o radiu w samochodach połączonych z siecią. Odtwarzacz utrzymuje bufor, aby przeżyć zmienny czas pobierania kolejnych części transmisji. Większy zapas zmniejsza ryzyko przerw, ale o zbliżoną wartość zwiększa opóźnienie wobec programu nadawanego na żywo.
Ciągły strumień i audycja podzielona na odcinki
Internetowe radio może być dostarczane na kilka sposobów. W prostym, ciągłym strumieniu serwer wysyła kolejne bajty audio przez utrzymywane połączenie. Odtwarzacz zaczyna dekodować je po zgromadzeniu zapasu. Icecast ma nawet mechanizm szybkiego przekazania początkowej porcji danych nowemu słuchaczowi, opisany w dokumentacji konfiguracji serwera jako pomoc w napełnieniu bufora odtwarzacza.
Inny model dzieli transmisję na pliki lub fragmenty. W HLS odtwarzacz pobiera listę dostępnych części, a następnie kolejne segmenty. Specyfikacja RFC 8216 wyjaśnia, że lista multimedialna składa się z segmentów o podanym czasie trwania, odtwarzanych po kolei jako jedna prezentacja. To rozwiązanie dobrze współpracuje ze zwykłymi serwerami HTTP i sieciami CDN, ale odtwarzacz musi poczekać, aż odpowiednie fragmenty zostaną utworzone, opublikowane i pobrane.
Jeżeli segment ma kilka sekund, a program napełnia bufor kilkoma segmentami, zwłoka rośnie skokowo. Dlatego dwa odtwarzacze tej samej stacji mogą nie być zsynchronizowane: jeden uruchomił transmisję przy innej granicy segmentu, drugi zgromadził większy zapas, a trzeci po chwilowej utracie łącza odtworzył dane, które już miał.
Dlaczego nie ustawić bufora na zero?
Teoretycznie można próbować odtwarzać każdą porcję natychmiast po jej nadejściu. W praktyce oznaczałoby to trzaski, pauzy i częste zatrzymywanie transmisji przy najmniejszym spadku przepustowości. Radio jest medium ciągłym, dlatego dla większości słuchaczy kilka sekund zwłoki jest mniej dokuczliwe niż regularnie urywany dźwięk.
Nadawca dobiera zatem punkt równowagi. Serwis przeznaczony do rozmów telefonicznych na żywo, transmisji sportowej albo wspólnego słuchania może stawiać na małą latencję. Program muzyczny odbierany w samochodzie częściej wybierze większą stabilność. Znaczenie ma też skala: rozwiązanie musi działać nie tylko w dobrym domowym Wi‑Fi, lecz również przy przeciążonej sieci komórkowej i dla tysięcy równoczesnych odbiorców.
Istnieją technologie zmniejszające zwłokę bez całkowitej rezygnacji z odporności. Low-Latency HLS firmy Apple wprowadza między innymi częściowe segmenty i mechanizm oczekiwania na aktualizację listy. Dzięki temu odtwarzacz nie zawsze musi czekać na ukończenie całego dużego fragmentu. Nie usuwa to jednak wszystkich etapów: dźwięk nadal trzeba zakodować, dostarczyć i bezpiecznie odtworzyć.
Skąd biorą się różnice między urządzeniami?
Opóźnienie nie jest jedną stałą zapisaną przy stacji. Aplikacja w telefonie może stosować inny bufor niż strona w przeglądarce. Telewizor lub głośnik sieciowy może ostrożniej rozpoczynać odtwarzanie, aby później nie przerywać. Połączenie Bluetooth dodaje własne kodowanie i magazynowanie krótkiej porcji dźwięku, choć zwykle jest to mniejsza część całej zwłoki niż bufor transmisji internetowej.
Znaczenie ma również chwila dołączenia do strumienia. Po przerwie odtwarzacz może wrócić do najnowszego dostępnego miejsca albo kontynuować z zachowanego zapasu. Niektóre aplikacje delikatnie przyspieszają odtwarzanie, aby zbliżyć się do krawędzi transmisji na żywo; inne pozostają na wcześniej wybranym dystansie. Dlatego dwa telefony leżące obok siebie nie muszą grać równo.
Opóźnienie jako ślad całej drogi programu
Różnica między odbiornikiem FM a aplikacją nie świadczy sama w sobie o awarii. Pokazuje, że internetowe radio wykonuje znacznie więcej pracy pomiędzy studiem a głośnikiem. Program jest kompresowany, przekazywany do serwera, czasem dzielony na segmenty, rozprowadzany przez sieć i magazynowany na urządzeniu słuchacza.
Każdy z tych etapów dokłada trochę czasu, ale też rozwiązuje konkretny problem: ogranicza ilość danych, pozwala obsłużyć wielu odbiorców albo chroni dźwięk przed przerwami. Najlepsza transmisja nie zawsze jest więc tą z absolutnie najmniejszym opóźnieniem. Dla codziennego słuchania ważniejsze bywa, aby audycja dotarła płynnie — nawet jeśli do internetowego głośnika przyjdzie kilka chwil później niż do radia stojącego obok.