RTV forum PL | NewsGroups PL

lwIP - odbieranie danych przez TCP

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - lwIP - odbieranie danych przez TCP

Goto page Previous  1, 2, 3  Next

Atlantis
Guest

Wed Sep 28, 2022 11:06 am   



On 28.09.2022 10:52, Mateusz Viste wrote:

Quote:
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.


Quote:
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).


Quote:
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.


Quote:
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.


Quote:
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. Smile

J.F
Guest

Wed Sep 28, 2022 4:39 pm   



On Wed, 28 Sep 2022 09:30:56 +0200, Atlantis wrote:
Quote:
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.

Quote:
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 ..

Quote:
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.

Quote:
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 ?

Quote:
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 :-)

Quote:
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.

Quote:
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.

Quote:
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.

Atlantis
Guest

Wed Sep 28, 2022 11:26 pm   



On 28.09.2022 18:39, J.F wrote:

Quote:
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?


Quote:
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.


Quote:
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.


Quote:
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.


Quote:
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.


Quote:
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. Wink 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. Wink

Cezar
Guest

Thu Sep 29, 2022 8:58 am   



On 29/09/2022 00:26, Atlantis wrote:
Quote:
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.




Quote:
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.

Atlantis
Guest

Thu Sep 29, 2022 2:48 pm   



On 29.09.2022 10:58, Cezar wrote:

Quote:
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? Wink

Atlantis
Guest

Thu Sep 29, 2022 3:05 pm   



Ok, przysiadłem jeszcze do tego projektu i udało mi się ustalić kilka
kolejnych faktów:

1. Byłem w błedzie co do pamięci SPI RAM. Z cała pewnością NIE JEST za
wolna, żeby pełnić funkcję bufora. Przepisałem kod odpowiedzialny za
odtwarzanie plików tak, żeby kierował dane z karty SD przez bufor
cykliczny w tym zewnętrznym RAM-ie. Odtwarzanie jest całkowicie płynne.
Oczywiście w teorii taki duży bufor w tym przypadku nie jest mi do
niczego potrzebny, bo zarówno karta SD jak i pendrive są zupełnie
stabilnymi źródłami danych, ale zostawię to jak jest - dla uproszczenia
projektu.
2. Przeniesienie bufora w całości do pamięci SPI pozwoliło mi odzyskać
trochę wbudowanego RAM-u, którego część przeznaczyłem na powiększenie
buforów lwIP. Robiłem to na wyczucie, wiec nadal nie wiem czy
konfiguracja jest optymalna. Wygląda jednak na to, że sytuacja się
poprawiła. Teraz jestem w stanie w czasie prawie rzeczywistym odtwarzać
stream Radia Kraków w 32 kbps. "Prawie" bo raz na jakiś czas słychać zgrzyt.
3. Natomiast stacje nadające w normalnej jakości (stereo i bitrate
powyżej 100 kbps) są już potwornie poszatkowane.

Ponieważ odtwarzanie z karty SD przez bufor SPI RAM działa normalnie to
wszystko wskazuje na to, że wina leży po stronie wolnej transmisji
danych z Internetu. Nie chce mi się wierzyć, że wbudowany w STM32
FastEthernet MAC z PHY podłączonym przez RMII nie jest w stanie
wyciągnąć tych trochę ponad 100 kbps (i z trudem wyciąga 32kbps).
Zwłaszcza, że właściwie identyczny układ bez żadnych problemów działa na
wcześniejszej konstrukcji z PIC32.
Stawiałbym raczej na konfigurację stosu lwIP. Gdzie się będzie dało
spróbuję jeszcze odzyskać w tym projekcie trochę RAM-u. Tymczasem ktoś
mógłby mi może podpowiedzieć które opcje konfiguracyjne są najbardziej
kluczowe z punktu widzenia odbierania streama audio? Co mogę wyłączyć,
które wartości powinienem poddnieść, a które mogę zmniejszyć?

Jeśli projekt doczeka się kiedyś kolejnej iteracji to chyba już na
jakimś STM32F4xx, o ile kiedyś znów będą dostępne w normalnych cenach. Smile

J.F
Guest

Fri Sep 30, 2022 7:49 am   



On Thu, 29 Sep 2022 01:26:34 +0200, Atlantis wrote:
Quote:
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.

IMO - samo sie dopasuje.

Quote:
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?

No to serwer poczeka, az mu sie uzupelni pula..
Czy raczej - jak sie uzbiera kolejna porcja danych audio, to
program na serwerze ja wysle, a TCP albo wysle od razu, albo poczeka
chwile - na potwierdzenie od odbiorcy.
Tak czy inaczej - buforowanie po stronie serwera wydaje sie nie miec
sensu. odbiorca niech sobie zbuforuje, zeby nie miec przerw w
transmisji.

Tak swoja droga - dla masowych nadawcow typu radio czy TV krajowa ...
jakos inaczej powinno byc to zorganizowane, przynajmniej tak mi sie
wydaje. IP Multicast przeciez jakis byl przewidziany.

Quote:
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.

Na RMF roznica jest wieksza ... ale - to to twoje radio, gdzie program
piszesz? wstepne wypelnienie bufora robisz, czy pchasz od razu w
glosnik?

Quote:
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.

I to swietnie dziala z FTP czy inna transmisja plikow, gdzie dane do
wyslania czekają. Radio, TV, czy chocby terminal - nie ma wiecej
danych do wyslania. Chwilowo nie ma - za moment bedą.

Quote:
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.

nie znam tej biblioteki, ale brzmi, jakbys potrzebowal bufora kolowego
na ... te wskazniki :-)

Quote:
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.

IMO niepotrzebne. Skoro i tak masz przerwe, to odegraj dane do konca.
Po czym zatrzymaj odgrywanie, az sie bufor zapelni odpowiednio - 50%
czy 90% ...

Quote:
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.

A jakie radio?

Bo wiekszosc na innych programach raczej nie ma problemow.
Internet i serwery mamy dosc szybkie.

Quote:
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. Wink 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. Wink

Czyli co - ten SPI RAM jakis wolny? Jaka to dokladnie kosc?

A moze ... na odczyty starczalo, na zapisy i odczyty juz nie starcza
przepustowosci.
Bo skoro RAM, to spodziewam sie, ze zapis jest szybki ...

J.

Cezar
Guest

Fri Sep 30, 2022 9:04 am   



On 30/09/2022 08:49, J.F wrote:

Quote:
Tak swoja droga - dla masowych nadawcow typu radio czy TV krajowa ...
jakos inaczej powinno byc to zorganizowane, przynajmniej tak mi sie
wydaje. IP Multicast przeciez jakis byl przewidziany.
Multicast nie przejdzie prze inteneret (oczywiście oprócz VPNnów,

tunelów i innych MPLSów)
Duzi nadawcy mogą użyć multicast to swoich PoP a tam unicastem do
odbiorców.
Taka Polska to taki jeden region w sumie - nie wiem czy jest sens
kombinować.

c.

JDX
Guest

Fri Sep 30, 2022 10:12 am   



On 28.09.2022 09:30, Atlantis wrote:
[...]
Quote:
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.
Nie zawsze to działa. Np. brytyjskie Absolute Radio nakłada ograniczenia

geograficzne na większość z ich stacji i jeśli wykryje IP z poza UK, to
pyta się o kod pocztowy. Wystarczy podać jakiś fejkowy kod z UK i
działa. To oczywiście jeśli korzystasz z ich playera. Jeśli wydłubiesz
konkretnego URL-a i zapodasz go do VLC, to już nie będzie działać. Na
pewno da się to obejść, ale trzeba podłubać. Ja nie miałem czasu.

J.F
Guest

Fri Sep 30, 2022 10:13 am   



On Fri, 30 Sep 2022 10:04:41 +0100, Cezar wrote:
Quote:
On 30/09/2022 08:49, J.F wrote:
Tak swoja droga - dla masowych nadawcow typu radio czy TV krajowa ...
jakos inaczej powinno byc to zorganizowane, przynajmniej tak mi sie
wydaje. IP Multicast przeciez jakis byl przewidziany.
Multicast nie przejdzie prze inteneret (oczywiście oprócz VPNnów,
tunelów i innych MPLSów)
Duzi nadawcy mogą użyć multicast to swoich PoP a tam unicastem do
odbiorców.
Taka Polska to taki jeden region w sumie - nie wiem czy jest sens
kombinować.

Ale wlasnie o to chodzi - czy to nie powinno byc tak, ze nadawca
emituje tylko kilka pakietow na kluczowe kierunki,
a routery po drodze je rozmnazają?

Oczywiscie wymagalo by to raczej UDP.

J.

J.F
Guest

Fri Sep 30, 2022 10:21 am   



On Thu, 29 Sep 2022 17:05:58 +0200, Atlantis wrote:
Quote:
Ok, przysiadłem jeszcze do tego projektu i udało mi się ustalić kilka
kolejnych faktów:

1. Byłem w błedzie co do pamięci SPI RAM. Z cała pewnością NIE JEST za
wolna, żeby pełnić funkcję bufora. Przepisałem kod odpowiedzialny za
odtwarzanie plików tak, żeby kierował dane z karty SD przez bufor
cykliczny w tym zewnętrznym RAM-ie. Odtwarzanie jest całkowicie płynne.
Oczywiście w teorii taki duży bufor w tym przypadku nie jest mi do
niczego potrzebny, bo zarówno karta SD jak i pendrive są zupełnie
stabilnymi źródłami danych, ale zostawię to jak jest - dla uproszczenia
projektu.

Karta SD/pendrive niekoniecznie sa stabilnymi zrodlami danych,
jak bedziesz na nie zapisywal.

Quote:
2. Przeniesienie bufora w całości do pamięci SPI pozwoliło mi odzyskać
trochę wbudowanego RAM-u, którego część przeznaczyłem na powiększenie
buforów lwIP. Robiłem to na wyczucie, wiec nadal nie wiem czy
konfiguracja jest optymalna.

Hm ... uzyj lepszy procek, Luke :-)

Quote:
Wygląda jednak na to, że sytuacja się
poprawiła. Teraz jestem w stanie w czasie prawie rzeczywistym odtwarzać
stream Radia Kraków w 32 kbps. "Prawie" bo raz na jakiś czas słychać zgrzyt.
3. Natomiast stacje nadające w normalnej jakości (stereo i bitrate
powyżej 100 kbps) są już potwornie poszatkowane.

Dodaj pare diodek sygnalizujacych pusty bufor.
Czy zapisuj jakies statystyki.
A inne radia czy programy jak rozumiem sobie radzą?
Bo bufor w programach bywa duzy, np 20s.

Quote:
Ponieważ odtwarzanie z karty SD przez bufor SPI RAM działa normalnie to
wszystko wskazuje na to, że wina leży po stronie wolnej transmisji
danych z Internetu. Nie chce mi się wierzyć, że wbudowany w STM32
FastEthernet MAC z PHY podłączonym przez RMII nie jest w stanie
wyciągnąć tych trochę ponad 100 kbps (i z trudem wyciąga 32kbps).
Zwłaszcza, że właściwie identyczny układ bez żadnych problemów działa na
wcześniejszej konstrukcji z PIC32.

A jak z pamiecią? Bo
wersja a) PIC mial wiekszy bufor, i na zacięcia starczało,
wersja b) masz jakies straty pakietow, co w TCP owocuje przestojami ..

Quote:
Stawiałbym raczej na konfigurację stosu lwIP. Gdzie się będzie dało
spróbuję jeszcze odzyskać w tym projekcie trochę RAM-u. Tymczasem ktoś
mógłby mi może podpowiedzieć które opcje konfiguracyjne są najbardziej
kluczowe z punktu widzenia odbierania streama audio? Co mogę wyłączyć,
które wartości powinienem poddnieść, a które mogę zmniejszyć?

Jeśli projekt doczeka się kiedyś kolejnej iteracji to chyba już na
jakimś STM32F4xx, o ile kiedyś znów będą dostępne w normalnych cenach. Smile

Albo po prostu zapomnij - grac moze komputer, laptop, telefon :-)

J.

J.F
Guest

Fri Sep 30, 2022 10:23 am   



On Thu, 29 Sep 2022 16:48:44 +0200, Atlantis wrote:
Quote:
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? Wink

TCP window wlasnie.

Przy czym jak pisalem ... akurat w przypadku radia wydaje sie, ze
serwer powinien miec bufor malutki, moze nawet zaden.
Chyba, ze dla nowych klientow - zeby im szybko zapelnic bufor,
i zeby im gralo od początku ..

J.

Marek
Guest

Sun Oct 02, 2022 5:48 am   



On Tue, 27 Sep 2022 15:35:51 +0200, "J.F"
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
A tak swoja drogą - te radia działają na TCP ?
Bo chyba powinny na UDP ...

No cóż. Wiele wynalazków sieciowych zostało porzuconych. Czy np.
jakiś op nadaje w swojej sieci multimedia multikastem? Ja się nie
spotkałem.

--
Marek

Atlantis
Guest

Sun Oct 02, 2022 7:39 am   



Ok, dopisałem kilkanaście linijek kodu odpowiedzialnego za mierzenie
ilości danych obieranych w serwera w ciągu sekundy. Po prostu sumuję
każdą kolejną wartość p->tot_ten ze zmienną tymczasową, która co sekundę
jest przepisywana do zmiennej trzymającej aktualną wartość pomiaru a
potem zerowana.

Przeprowadziłem dwa pomiary podczas odbierania streamu radiowej Jedynki.
Pierwszy był przy zakomentowanych operacjach zapisy do pamięci SPI RAM.
Wychodził transfer na poziomie 21-25 kB/s (czyli 168-200 kbps). Wartość
zgodna z bitratem typowego strumienia audio.
Natomiast po odkomentowaniu tych operacji wartość spada do 5-11 kB/s
(40-88 kbps) co tłumaczy przerywany dźwięk.
Nie wiem na ile to ma znaczenie, ale dodatkowo widać, że w obydwu
przypadkach na początku transmisja jest nieco szybsza i po kilku
sekundach stabilizuje się wokół niższej wartości.
Generalnie można już wyciągnąć kilka wniosków:
1. Można całkowicie odrzucić tezę, że winę za spowolnienia ponosi
projekt płytki i gubienie pakietów z powodu błędów na warstwie
sprzętowej (interfejs RMII). Gdyby tak było, to efekt byłby widoczny
cały czas.
2. Operacja zapisu do pamięci SPI RAM ma wpływ na szybkość transferu
danych. Jednak nie jest to raczej prosta zależność na zasadzie pamięci
mającej niewystarczającą szybkość. Jak już mówiłem - ten bufor
całkowicie normalnie działa z lokalnymi nośnikami, poza tym przy
prędkości taktowania 18 MHz powinno być możliwe przesyłanie danych ze
znacznie większą prędkością niż tych kilka kB/s. Poza tym problemy
występowały też w przypadku stosowania (dużo mniejszego) bufora w
normalnej pamięci.

Na chwilę obecną stawiałbym raczej na moją oryginalną tezę: w czasie gdy
program jest zajęty zapisywaniem oryginalnego pakietu, Ethernet nie jest
w stanie odebrać następnej porcji danych (bo kończy mu się jakiś
bufor/okno odbiorcze) i dochodzi do retransmisji, która spowalnia realną
prędkość przesyłu danych.

I teraz mam kilka pytań co do tego, jak właściwie działa Ethernet w STM32:
Samo pobieranie danych z sieci do bufora odbiorczego jest realizowane w
tle przez sprzęt, czy też pętla główna programu musi regularnie
wywoływać jakiś sterownik? To znaczy jeśli bufor odbiorczy jest
dostatecznie duży, to dane będą nadal dochodziły nawet wtedy, jeśli
pętla główna będzie zajęta czymś innym?

Marek
Guest

Sun Oct 02, 2022 1:05 pm   



On Wed, 28 Sep 2022 09:30:56 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
przyniosły idealnych rezultatów. Nawet przy maksymalnej
dostępnej prędkości (18 MHz) wydaje się ona zwyczajnie zbyt wolna.

Teraz mi się przypomniało, że miałem podobne problemy z tym
projektem, z socket buf na spiram nawet 128kB (używany wewnętrznie
przez stos MLA) powodował po pewnej chwili buffer underrun a o wiele
mniejszy bufor aplikacyjny na dane (ale nie socket buffer) w ram mcu
dawał spokojnie radę.

--
Marek

Goto page Previous  1, 2, 3  Next

elektroda NewsGroups Forum Index - Elektronika Polska - lwIP - odbieranie danych przez TCP

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map