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.