2022-09-27 o 15:35 +0200, J.F napisał:
> A tak swoja drogą - te radia działają na TCP ?
> Bo chyba powinny na UDP ...

Z reguły jednak TCP. Co gorsze - nierzadko z dodatkową warstwą TLS.
Przykłady streamów:

https://31.192.216.10/RMF2
https://radiovassiviere.ice.infomaniak.ch/radiovassi
viere-128.aac
http://stream3.nadaje.com:9000/;stream/1

> Dawniej podawali jakies parametry do bezposredniej transmisji,
> dzis wszystko pochowane. Wyswietl nasza strone www.

Da się znaleźć, np. tu:
https://online-radio.eu/

W domu mały NAS Linuksowy z VLC robi za radio, podaję mu URLe
skopiowane właśnie z powyższej strony.

Mateusz

do góry

On 27/09/2022 14:35, J.F wrote:
> On Sat, 24 Sep 2022 17:58:49 +0200, Atlantis wrote:
>> Chciałem ostatnio popchnąć trochę do przodu jeden ze swoich poprzednich
>> projektów - sprzętowe radio internetowe o którym pisałem już wcześniej,
>> tylko tym razem w wersji ze zaktualizowaną częścią hardware'ową.
>> Poprzednia wersja była tworzona na PIC32, teraz powoli chciałem
>> przenieść go na STM32.
>
> A tak swoja drogą - te radia działają na TCP ?
> Bo chyba powinny na UDP ...

Wszysto idzie po TCP. UDP jest cięzkie do implementacji po stronie
klienta bo trzeba ogarnąć:
- jitter
- packet loss
- out of order packets

Oczywiście da się to ogarnąc bo tak działa cały VoIP...
Myślę że łatwość implementacji klienta tutaj wygrała - większość
streamów to TCP (HTTP)




> Kolejna sprawa - jak te radia działają?
> Dawniej podawali jakies parametry do bezposredniej transmisji,
> dzis wszystko pochowane. Wyswietl nasza strone www.
>
> A radia (te niby "sprzetowe") jakos działają ... maja jakies serwery
> z listami parametrów ?

do góry

On 27.09.2022 15:35, J.F wrote:

> A tak swoja drogą - te radia działają na TCP ?

Działają na TCP, a konkretnie na zwyczajnym protokole HTTP. Otwierasz
połączenie z serwerem i wysyłasz GET-a, prosząc o udostępnienie
konkretnego streamu. W odpowiedzi dostajesz odpowiedź i nagłówki. Jeśli
jest to 200 OK, możesz zacząć odbierać i dekodować przychodzące dane
audio. Oczywiście trzeba też obsłużyć inne sytuacje, jak np.
przekierowanie pod inny adres.

> Bo chyba powinny na UDP ...

Po co? Strumień audio nie potrzebuje niskiej latencji - wszystko i tak
jest buforowane po stronie serwera. Można się o tym dość łatwo przekonać
włączając jednocześnie dowolne radio FM i jego sieciowy odpowiednik,
albo jeszcze lepiej - Jedynkę na falach długich i tę samą stację
nadawaną on-line.


> Kolejna sprawa - jak te radia działają?
> Dawniej podawali jakies parametry do bezposredniej transmisji,
> dzis wszystko pochowane. Wyswietl nasza strone www.

Niektóre stacje nadal podają bezpośrednie URL-e do swoich streamów. Jest
też trochę różnych zestawień w Internecie. W przypadku stacji
narzucających własną aplikację na stronie i tak bardzo często pod spodem
mamy zwyczajne połączenie HTTP - wtedy wystarczy wyłuskać adres
analizując ruch, np. za pomocą narzędzi deweloperskich Chrome'a.


> A radia (te niby "sprzetowe") jakos działają ... maja jakies serwery
> z listami parametrów ?

Tak. I to jest właśnie głównym powodem dla którego zabrałem się za ten
projekt. Wkurzał mnie fakt, że większość dostępnych komercyjnie
rozwiązań będzie działała tak długo, jak długo producent raczy
utrzymywać infrastrukturę. Tutaj sam wpisuję URL-e stacji, które chcę
słuchać.


> Na moj gust, gdzies musisz sobie założyc bufor odpowiedniej dlugosci,
> wpychac tam dane które przyszly, i potwierdzac otrzymanie, lub
> poczekac jak sie bufor konczy ... aby zatrzymac transmisje.

No właśnie tutaj jak na razie rozbijam się o szczegóły. W przypadku
stosu MLA z PIC32 po prostu pobierałem sobie z bufora odbiorczego tyle
danych, ile w danym momencie potrzebowałem. Stos robił pod spodem całą
resztę - jeśli w buforze było miejsce, prosił serwer o więcej danych.
Efekt był taki, że dekoder MP3 z automatu narzucał prędkość transmisji i
nawet przy stosunkowo niewielkich buforach wszystko działało płynnie.

Tutaj sprawa jest trochę bardziej skomplikowana. Dane nie są buforowane
w taki sposób i nie mogę po prostu pobrać dowolnej ilości w dowolnym
momencie. Jeśli zostanie wywołany callback odbiorczy, mam obowiązek
odebrać całą paczkę, zwolnić pamięć i wywołać tcp_recved. Jednak z tego
co rozumiem ta ostatnia funkcja jedynie zwiększa rozmiar okna
odbiorczego, więc nawet pomimo braku jej wywołania nie mam gwarancji, że
jeszcze przez chwilę nie przyjdą kolejne callbacki - być może uda mi się
uzyskać taki efekt odpowiednio manipulując ustawieniami stosu.

Przerobiłem wczoraj nieco swoją aplikację, implementując bufor cykliczny
do którego trafiają dane ze strumienia. Serwer jednak wysyła je nieco
szybciej niż wynikałoby to z bitrate'u strumienia audio - ma to sens, bo
nadmiarowe dane w normalnych warunkach mogą zostać użyte do uzupełniania
bufora. Tak więc jeśli po prostu odbieram dane, wrzucam je do bufora i
potwierdzam otrzymanie, to dość szybko dochodzi do przepełnienia bufora
- dźwięk jest, ale postrzępiony. Próbowałem wywoływać tcp_recved() w
innym miejscu dopiero wtedy, gdy w buforze była dostatecznie dużo
wolnego miejsca, jednak jak na razie nie udało mi się uzyskać poprawnego
działania. Będę jeszcze eksperymentował.

Eksperymenty z zewnętrzną pamięcią SPI RAM 128 kB jak na razie też nie
przyniosły idealnych rezultatów. Nawet przy maksymalnej
dostępnej prędkości (18 MHz) wydaje się ona zwyczajnie zbyt wolna.
Trochę mnie to zaskoczyło, bo karta SD przy dwa razy wolniejszej
transmisji spokojnie wyrabiała z dostarczaniem danych z pliku MP3. Z
drugiej strony jednak tutaj mam operacje odczytu i zapisu, występujące
naprzemiennie w krótkich odstępach czasu.

Zaczynam zastanawiać się czy faktycznie dobrym pomysłem nie będzie
zastosowanie FreeRTOS-a i socketów. Nie wiem tylko czy problemem nie
będzie niewielka ilość RAM-u mikrokontrolerze (64kB).

do góry

On 27.09.2022 17:12, Mateusz Viste wrote:

> W domu mały NAS Linuksowy z VLC robi za radio, podaję mu URLe
> skopiowane właśnie z powyższej strony.

Moje pierwsze podejście do tematu autonomicznego radia internetowego
polegało właśnie na wykorzystaniu Raspberry Pi (Zero) z zewnętrznym
DAC-iem i standardowym oprogramowaniem do odtwarzania audio (MPD) pod
spodem. Otwierało to sporo dodatkowych możliwości, jednak trochę
absurdalny wydawał mi się fakt, że urządzenie musi najpierw załadować i
uruchomić cały system operacyjny, żeby zacząć odbierać stację. W celach
edukacyjnych postanowiłem więc złożyć wersję na mikrokontrolerze. ;)

do góry

2022-09-28 o 09:35 +0200, Atlantis napisał:
> On 27.09.2022 17:12, Mateusz Viste wrote:
>
> > W domu mały NAS Linuksowy z VLC robi za radio, podaję mu URLe
> > skopiowane właśnie z powyższej strony.
>
> Moje pierwsze podejście do tematu autonomicznego radia internetowego
> polegało właśnie na wykorzystaniu Raspberry Pi (Zero) z zewnętrznym
> DAC-iem i standardowym oprogramowaniem do odtwarzania audio (MPD) pod
> spodem. Otwierało to sporo dodatkowych możliwości, jednak trochę
> absurdalny wydawał mi się fakt, że urządzenie musi najpierw załadować
> i uruchomić cały system operacyjny, żeby zacząć odbierać stację. W
> celach edukacyjnych postanowiłem więc złożyć wersję na
> mikrokontrolerze. ;)

Chwalebnie... i ambitnie - bo trzeba samemu obsłużyć TCP, HTTP,
kilka popularnych kodeków, TLS... sporo warstw do przebicia.
Niemniej doceniam i rozumiem myśl. Też mnie denerwuje, że po włączeniu
"radia" muszę czekać niemal minutę na dźwięk.

Mateusz

do góry

On 28.09.2022 10:52, Mateusz Viste wrote:

> Chwalebnie... i ambitnie - bo trzeba samemu obsłużyć TCP

Od tego jest stos. Generalnie projekt zaczynałem jeszcze na PIC24, potem
przeniosłem go na PIC32. W obydwu przypadkach korzystałem już z nieco
leciwych, ale całkiem fajnych bibliotek MLA (w ostatnich latach
Microchip przestał je wspierać, zastępując środowiskiem Harmony). Ich
obsługa jest bardzo prosta, trzeba tylko potrafić napisać odpowiednią
maszynę stanów, ale taki sposób programowania mikrokontrolerów jest dla
mnie najbardziej naturalny.


> HTTP

Tak naprawdę nie potrzeba pełnej obsługi HTTP. Inicjując połączenie za
każdym razem wysyłamy takiego samego GET-a, z kilkoma podmienionymi
polami (adres serwera i lokalizacja streama na serwerze). Dostajemy
odpowiedź, którą trzeba przeparsować. Tutaj też nie ma konieczności,
żeby implementować jakąś pełną bibliotekę do obsługi klienta HTTP.
Wystarczy uwzględnić kilka odpowiedzi. Najważniejsze to 200 OK oraz
przekierowanie pod inny adres. Wszystkie inne można uznać za błąd
oznaczający konieczność zamknięcia połączenia (i ewentualnie podjęcia
kolejnej próby).


> kilka popularnych kodeków

To w całości załatwia sprzętowy dekoder VS10xx. W przypadku
software'owego podejścia de facto można by się ograniczyć do MP3
(zdecydowana większość stacji nadaje właśnie w tym formacie) i tutaj
sprawę załatwia popularna biblioteka libmad. Większość współczesnych
32bitowych mikrokontrolerów powinna ją udźwignąć (u mnie nie miało z tym
najmniejszych problemów Raspberry Pi Pico) jednak w przypadku tego
projektu nie chciało mi się z tym bawić. Bibliotekę najwygodniej
obsługuje się za pomocą wysokopoziomowego API, które wymaga RTOS-a (to
znaczy nie wymaga, ale bez niego będzie nam blokowało pętlę główną) a
niskopoziomowego jeszcze nie rozgryzłem.


> TLS...

To jest właśnie plan na dalszą rozbudowę projektu. W wersji na PIC32
było to trochę kłopotliwe, bo biblioteka TLS z MLA jest dość leciwa. Da
się ponoć wykorzystać wolfSSL-a, jednak jeszcze się w to nie wgryzłem. W
przypadku STM32 dodanie tej funkcjonalności ogranicza się do wyklikania
MBEDTLS-a w STM32CubeMX. To był jeden z powodów dla których w ogóle
zacząłem eksperymenty z przeniesieniem projektu na STM32. Niestety nie
wziąłem pod uwagę tego, że obsługa stosu będzie bardziej problematyczna.
Niezbyt przemyślany był także wybór układu STM32F107, który ma
stosunkowo mało RAM-u i nie ma nawet parametrów pozwalających na
uruchomienie na nim MBEDTLS-a. Mam nadzieję, że w serii STM32F4 znajdę
coś pinowo kompatybilnego, mającego wszystkie peryferia w tych samych
miejscach, co pozwoliłoby mi wykonać łatwą podmianę. ;)

Tak czy inaczej, na szczęście ciągle jeszcze całkiem sporo stacji
internetowych nadaje po czystym HTTP. W tym właściwie wszystkie te, na
których mi najbardziej zależało.


> Niemniej doceniam i rozumiem myśl. Też mnie denerwuje, że po włączeniu
> "radia" muszę czekać niemal minutę na dźwięk.

Ten projekt tak naprawdę i tak jest trochę przesadnie skomplikowany, w
celach edukacyjnych. Widziałem już w internecie znacznie prościej
robione radia internetowe na ESP32. :)

do góry

On Wed, 28 Sep 2022 09:30:56 +0200, Atlantis wrote:
> On 27.09.2022 15:35, J.F wrote:
>> A tak swoja drogą - te radia działają na TCP ?
>
> Działają na TCP, a konkretnie na zwyczajnym protokole HTTP. Otwierasz
> połączenie z serwerem i wysyłasz GET-a, prosząc o udostępnienie
> konkretnego streamu. W odpowiedzi dostajesz odpowiedź i nagłówki. Jeśli
> jest to 200 OK, możesz zacząć odbierać i dekodować przychodzące dane
> audio. Oczywiście trzeba też obsłużyć inne sytuacje, jak np.
> przekierowanie pod inny adres.
>
>> Bo chyba powinny na UDP ...
>
> Po co? Strumień audio nie potrzebuje niskiej latencji - wszystko i tak

Nie o latencje chodzi, tylko o zaciecia na straconych pakietach.

> jest buforowane po stronie serwera. Można się o tym dość łatwo przekonać
> włączając jednocześnie dowolne radio FM i jego sieciowy odpowiednik,
> albo jeszcze lepiej - Jedynkę na falach długich i tę samą stację
> nadawaną on-line.

Owszem, jest opoznienie spore ... ale to serwer czy po stronie klienta
buforowanie jest ?

Serwer do kompresji cos musi buforowac, ale dla radia to chyba
niewiele - gorzej z video mpeg. No ale telewizja cyfrowa tez
kompresuje ..

>> Kolejna sprawa - jak te radia działają?
>> Dawniej podawali jakies parametry do bezposredniej transmisji,
>> dzis wszystko pochowane. Wyswietl nasza strone www.
>
> Niektóre stacje nadal podają bezpośrednie URL-e do swoich streamów. Jest
> też trochę różnych zestawień w Internecie. W przypadku stacji
> narzucających własną aplikację na stronie i tak bardzo często pod spodem
> mamy zwyczajne połączenie HTTP - wtedy wystarczy wyłuskać adres
> analizując ruch, np. za pomocą narzędzi deweloperskich Chrome'a.
>
>> A radia (te niby "sprzetowe") jakos działają ... maja jakies serwery
>> z listami parametrów ?
>
> Tak. I to jest właśnie głównym powodem dla którego zabrałem się za ten
> projekt. Wkurzał mnie fakt, że większość dostępnych komercyjnie
> rozwiązań będzie działała tak długo, jak długo producent raczy
> utrzymywać infrastrukturę. Tutaj sam wpisuję URL-e stacji, które chcę
> słuchać.

No tak, to jest argument.

Wyszukac wlasciwy adres na stronie np rmf.fm
nie tak latwo, ale lepiej miec mozliwosc wyszukania i wpisania,
niz miec martwe radio.

>> Na moj gust, gdzies musisz sobie założyc bufor odpowiedniej dlugosci,
>> wpychac tam dane które przyszly, i potwierdzac otrzymanie, lub
>> poczekac jak sie bufor konczy ... aby zatrzymac transmisje.
>
> No właśnie tutaj jak na razie rozbijam się o szczegóły. W przypadku
> stosu MLA z PIC32 po prostu pobierałem sobie z bufora odbiorczego tyle
> danych, ile w danym momencie potrzebowałem. Stos robił pod spodem całą
> resztę - jeśli w buforze było miejsce, prosił serwer o więcej danych.
> Efekt był taki, że dekoder MP3 z automatu narzucał prędkość transmisji i
> nawet przy stosunkowo niewielkich buforach wszystko działało płynnie.

Z drugiej strony - to i serwer powinien narzucac predkosc,
bo co ma przyslac, jesli za szybko potwierdzisz ?

> Tutaj sprawa jest trochę bardziej skomplikowana. Dane nie są buforowane
> w taki sposób i nie mogę po prostu pobrać dowolnej ilości w dowolnym
> momencie. Jeśli zostanie wywołany callback odbiorczy, mam obowiązek
> odebrać całą paczkę, zwolnić pamięć i wywołać tcp_recved. Jednak z tego
> co rozumiem ta ostatnia funkcja jedynie zwiększa rozmiar okna
> odbiorczego, więc nawet pomimo braku jej wywołania nie mam gwarancji, że
> jeszcze przez chwilę nie przyjdą kolejne callbacki - być może uda mi się
> uzyskać taki efekt odpowiednio manipulując ustawieniami stosu.
>
> Przerobiłem wczoraj nieco swoją aplikację, implementując bufor cykliczny
> do którego trafiają dane ze strumienia. Serwer jednak wysyła je nieco
> szybciej niż wynikałoby to z bitrate'u strumienia audio - ma to sens, bo
> nadmiarowe dane w normalnych warunkach mogą zostać użyte do uzupełniania
> bufora.

No tak sobie ma to sens - bo skad ma wziac tresc do wyslania, jak sie
uzbiera tych nadmiarowych danych minuta czy kwadrans?

Co prawda teraz sporo radiostacji z dysku nadaje, ale i tak nie ma za
duzego bufora, bo chocby aktualnosci powinny byc aktualne :-)

> Tak więc jeśli po prostu odbieram dane, wrzucam je do bufora i
> potwierdzam otrzymanie, to dość szybko dochodzi do przepełnienia bufora
> - dźwięk jest, ale postrzępiony.

Sprobuj wiekszy bufor. Gdzies musi byc granica.

No ale to bardziej z ciekawosci, bo jak najbardziej trzeba potwierdac
w miare ubywania danych.

> Próbowałem wywoływać tcp_recved() w
> innym miejscu dopiero wtedy, gdy w buforze była dostatecznie dużo
> wolnego miejsca, jednak jak na razie nie udało mi się uzyskać poprawnego
> działania. Będę jeszcze eksperymentował.
>
> Eksperymenty z zewnętrzną pamięcią SPI RAM 128 kB jak na razie też nie
> przyniosły idealnych rezultatów. Nawet przy maksymalnej
> dostępnej prędkości (18 MHz) wydaje się ona zwyczajnie zbyt wolna.
> Trochę mnie to zaskoczyło, bo karta SD przy dwa razy wolniejszej
> transmisji spokojnie wyrabiała z dostarczaniem danych z pliku MP3. Z

Karta SD mogla mies jakis szybszy tryb pracy niz SPI,
ale wydaje sie, ze te 18MHz powinno wystarczyc z naddatkiem.
W koncu strumien ma rzedu 256kbit/s.

> drugiej strony jednak tutaj mam operacje odczytu i zapisu, występujące
> naprzemiennie w krótkich odstępach czasu.
>
> Zaczynam zastanawiać się czy faktycznie dobrym pomysłem nie będzie
> zastosowanie FreeRTOS-a i socketów. Nie wiem tylko czy problemem nie
> będzie niewielka ilość RAM-u mikrokontrolerze (64kB).

Ok, to ciekawosc by trzeba sprawdzic na innym modelu, z wieksza
pamiecią.
Ale pomijac wymagania RTOS na pamiec - jesli on potrafi zbuforowac
dane, to i Ty powinienes potrafic dostępnymi srodkami ...

J.

do góry

On 28.09.2022 18:39, J.F wrote:

> Owszem, jest opoznienie spore ... ale to serwer czy po stronie klienta
> buforowanie jest ?

Co prawda trochę tutaj spekuluję, jednak wydaje mi się, że w przypadku
normalnego serwera HTTP i tak nie bardzo w grę wchodzi zapewnienie
prędkości idealnie dopasowanej do bitrate'u. Serwer dysponuje pewna pulą
na bieżąco uzupełnianych danych, a klient o nie prosi. Może się zdarzyć,
że do klienta dane będą docierały przez pewien czas z prędkością poniżej
bitrate'u (bo np. pojawi się konieczność kilkukrotnej retransmisji
któregoś pakietu) więc czemu nie miałaby mieć miejsca odwrotna sytuacja
- kiedy klient prosi o udostępnienie danych z pewnym wyprzedzeniem?


> Serwer do kompresji cos musi buforowac, ale dla radia to chyba
> niewiele - gorzej z video mpeg. No ale telewizja cyfrowa tez
> kompresuje ..

Kiedyś podstawiłem obok siebie moje radio internetowe odbierające
radiową Jedynkę oraz stare radio AM, nastawione na 225 kHz. Różnica
mogła wynosić dobre 10 sekund. Oczywiście nie znaczy to, że całe
opóźnienie pochodzi od bufora w serwerze, bo jeszcze częściowo może być
wprowadzane na różnych łączach pomiędzy studiem a serwerem. Pomiędzy
Jedynką na FM i AM też jest widoczne opóźnienie, chociaż może nie tak
znaczne.


> Z drugiej strony - to i serwer powinien narzucac predkosc,
> bo co ma przyslac, jesli za szybko potwierdzisz ?

Ale to chyba właśnie tak działa w TCP. Po odebraniu pakietu klient
informuje serwer, że teraz dysponuje większym oknem odbiorczym i może
przyjmować dane. Serwer decyduje ile wyśle - równie dobrze może wysłać
mniej niż jest miejsca w oknie.


> No tak sobie ma to sens - bo skad ma wziac tresc do wyslania, jak sie
> uzbiera tych nadmiarowych danych minuta czy kwadrans?

Wiadomo, że serwer nie wyśle więcej, niż w danej chwili ma.


> No ale to bardziej z ciekawosci, bo jak najbardziej trzeba potwierdac
> w miare ubywania danych.

Ok, trochę pozmieniałem w kodzie i mam kilka nowych obserwacji. Możliwe
też, że niektóre z moich wcześniejszych wniosków mogły być błedne...
Po pierwsze dodałem odpowiednie zabezpieczenia, chroniące przed
nadpisywaniem bufora cyklicznego. Teraz przed każdym zapisem sprawdzana
jest ilość wolnego miejsca. Jeśli miejsca jest na tyle, zapis do bufora
odbywa się w callbacku odbiorczym. Jeśli miejsca jest za mało, to
jedynie zapisywany jest wskaźnik do otrzymywanych danych i pętli program
sprawdza czy dane się zwolniło - jeśli tak, dane trafiają do bufora i
wywoływana jest funkcja tcp_recved(), zgłaszająca gotowość przyjęcia
kolejnych danych.
Dodałem także zabezpieczenie przed opóźnieniem bufora - jeśli danych
zaczyna być za mało przestają one być pobierane do bufora audio (a więc
przestaje on grać) i zamiast tego jedynie przyjmujemy dane z serwera.
Odtwarzanie jest wznawiane dopiero po zapełnieniu bufora do pewnej wartości.

Teraz jednak zauważyłem, że dane do bufora przychodzą bardzo wolno.
Ilość danych odpowiadająca ułamkowi sekundy odtwarzania nieraz ładuje
się przez ładnych kilka sekund, a więc odtwarzanie jest poszatkowane, z
wyraźnymi przerwami. Jednak nie zawsze tak jest - parę razy udało mi się
trafić na idealny moment, kiedy odtwarzanie było płynne, a ilość danych
w buforze oscylowała wokół jednej wartości.


> Karta SD mogla mies jakis szybszy tryb pracy niz SPI,

Karta jest właśnie podłączona do standardowego SPI - STM32F107 nie ma
nawet SDIO. ;) Początkowo myślałem, że może to być wina niekoniecznie
optymalnych funkcji transmisyjnych z biblioteki HAL, ale potem
przypomniałem sobie, że dokładnie tak samo była zrealizowana obsługa
komunikacji z kartą SD. ;)

do góry

On 29/09/2022 00:26, Atlantis wrote:
> On 28.09.2022 18:39, J.F wrote:
>
>> Owszem, jest opoznienie spore ... ale to serwer czy po stronie klienta
>> buforowanie jest ?
>
> Co prawda trochę tutaj spekuluję, jednak wydaje mi się, że w przypadku
> normalnego serwera HTTP i tak nie bardzo w grę wchodzi zapewnienie
> prędkości idealnie dopasowanej do bitrate'u. Serwer dysponuje pewna pulą
> na bieżąco uzupełnianych danych, a klient o nie prosi. Może się zdarzyć,
> że do klienta dane będą docierały przez pewien czas z prędkością poniżej
> bitrate'u (bo np. pojawi się konieczność kilkukrotnej retransmisji
> któregoś pakietu) więc czemu nie miałaby mieć miejsca odwrotna sytuacja
> - kiedy klient prosi o udostępnienie danych z pewnym wyprzedzeniem?
>
Takie coś nie występuje w przyrodzie bez jakiejs wymyślnej implementacji
(a na pewno nie w HTTP)
Klient może tylko spowolnić odbiór (w przypadku TCP)
W UDP nawet tego nie może.




>> Serwer do kompresji cos musi buforowac, ale dla radia to chyba
>> niewiele - gorzej z video mpeg. No ale telewizja cyfrowa tez
>> kompresuje .. >
> Kiedyś podstawiłem obok siebie moje radio internetowe odbierające
> radiową Jedynkę oraz stare radio AM, nastawione na 225 kHz. Różnica
> mogła wynosić dobre 10 sekund. Oczywiście nie znaczy to, że całe
> opóźnienie pochodzi od bufora w serwerze, bo jeszcze częściowo może być
> wprowadzane na różnych łączach pomiędzy studiem a serwerem. Pomiędzy
> Jedynką na FM i AM też jest widoczne opóźnienie, chociaż może nie tak
> znaczne.

Nie wiem jak dochodzi feed do nadajnika AM ale FM to są głównie satelity

Kompresja w telewizji (czy też DAB) to inna bajka. Jest tam sporo danych
nadmiarowych do FEC. Tam gdzie używa się UDP (RTP) do transmisji głosu i
obrazu też jest używane FEC
Przy obrazie to widać że w przypadku utraty pakietów, część obrazu staje
się bardziej "zamazana" (H264, H265) a w przypadku głosu, dzwiek ma
mniejsze pasmo (Opus)
Samo uzycie FEC juz wprowadza dodatkowe (choc niewielkie) opóźnienie.


Często słucham radia internetowego i w zasadzie zauważyłem że jeśli są
problemy w transmisji i następują przerwy to po przerwie radio gra
dokładnie od momentu kiedy przerwało co by znaczyło że bufor po stronie
nadawcy zostaje zwiększony ale prędkość odgrywania radia się nie
zwiększa. Ten bufor jest resetowany co jakiś czas, co skutkuje że
transmisja nagle przeskakuje o kilka minut do przodu. Głównie zauważalne
w samochodzie podczas jazdy. Moim zdaniem UDP np z Opusem o wiele lepiej
by zdało egzamin...

c.

do góry

On 29.09.2022 10:58, Cezar wrote:

> Takie coś nie występuje w przyrodzie bez jakiejs wymyślnej implementacji
> (a na pewno nie w HTTP)
> Klient może tylko spowolnić odbiór (w przypadku TCP)
> W UDP nawet tego nie może.

A co powstrzymuje serwer przed podjęciem próby wypchnięcia klientowi
swojego całego dostępnego bufora? ;)

do góry