On 6.10.2022 17:18, J.F wrote:

> Ciekawe co na to serwer - nie moze ci wyslac danych odpowiednio
> szybko, buforowac tez nie moze w nieskonczonosc - powinien gdzies u
> siebie przeskakiwac na aktualne dane.

I wszystko wskazuje na to, że tak to właśnie działa. Przynajmniej
odnoszę wrażenie, że dźwięki które słyszę z przerwami nie są kolejnymi
fragmentami tego samego strumienia audio, ale raczej "okienkami" które
aktualnie udaje się odebrać.


> W przypadku radia moze byc inaczej, jesli nie ma u siebie bufora
> danych. No ale nawet wtedy te ~20kB/s szybko uzbiera, a Ty nie
> nadążasz odebrac.

Tak. Pytanie tylko dlaczego nie nadążam tego odebrać. Można było
teoretyzować o niskiej przepustowości pamięci SPI RAM (co i tak było
wątpliwe, bo 18 MHz to naprawdę szybka transmisja) ale ta teoria padła w
momencie, gdy identyczny problem udało się stwierdzić także w przypadku
zastosowania bufora cyklicznego w RAM-ie.


> Z grubsza mozliwe, ale patrz nizej.
> A moze przerwania sa blokowane ?

Jakie przerwania? W moim kodzie w ogóle nie używam przerwań związanych z
Ethernetem. Używam gotowych sterowników dostarczanych przez producenta
mikrokontrolera oraz gotowego stosu (lwIP). W rozsądnym projekcie
użytkownik nie powinien w ogóle przejmować się przerwaniami - powinny
one w tle ładować dane do jakiegoś FIFO. Zresztą nigdzie w dokumentacji
nie znalazłem ani jednej wzmianki o przerwaniach.
O ile informacje na jakie udało mi się trafić w Internecie są poprawne,
to procedura odbioru jest następująca:
- Stos wywołuje zarejestrowana wcześniej funkcję obsługi callbacku
odbiorczego.
- Do tej funkcji przekazywany jest wskaźnik na struct pbuf. Struktura
zawiera dynamicznie alokowany bufor na payload. Może też zawierać
wskaźniki do kolejnych struktur tego samego typu.
- Z jednej lub kilku struktur trzeba pobrać dane i gdzieś je zapisać.
- Jeśli już skończyliśmy tę operację, wywołujemy pbuf_free() aby zwolnić
pamięć oraz tcp_recved() aby zwiększyć rozmiar okna (poinformować
serwer, że może przesłać więcej).

U mnie może się zdarzyć sytuacja, że otrzymanych danych będzie więcej
niż miejsca w buforze. Wtedy nie mogę ich odebrać od razu - muszę się z
tym wstrzymać do czasu, aż dekoder MP3 wyjmie z bufora odpowiednią ilość
danych. Wtedy odbiór tej konkretnej paczki jest opóźniony i odbywa się w
pętli głównej.

W żadnym miejscu nie mam do czynienia z przerwaniami.


> Troche wątpie. Przy zgubieniu pakietu timeout sie wlacza, i to mogą
> byc grube sekundy. Chyba bys nie uzyskal 5-11 kB/s.

Kiedy transmisja zaczyna mulić to nie jest 5-11 kB/s, a 0-2kB/s.


> Raczej bym sie spodziewal problemu w jakims opoznieniu w wyslaniu
> potwierdzenia. Ale zeby az tak to SPI zwalniało? 18MHz wydaje sie
> sporo ... a ogladales oscyloskopem? Albo czy mierzyles
> przepustowosc/czas zapisu pakietu?

Nie, bo wydawało mi się to nie mieć sensu. Udało mi się ustalić, że wina
nie leży po stronie pamięci SPI. Przemawiają za tym dwa argumenty:
- Pamięć SPI doskonale sprawdza się przy buforowaniu streama z karty SD.
- Ten sam problem występuje, jeśli dane przychodzące przez TCP próbuję
zapisywać do bufora cyklicznego ulokowanego w zwykłym RAM-ie.


> A w ogole ... masz tam jakies zabezpieczenie kolejnosci w tej
> bibliotece? Bo powiedzmy przychodzą pakiety nr 1, 2, 3, a nr 4 nie
> przychodzi. Ale przychodzi nr 5, 6, 7 ... i co wtedy - nie dostaniesz
> callbacka z nr 5, a bufory 5, 6, 7 zostaną skasowane ?

Wydaje mi się, że przecież chyba TCP ogarnia kwestię pakietów
przychodzących w złej kolejności i użytkownik nie musi się przejmować tą
kwestią podczas pisania aplikacji. Ten problem pojawia się dopiero w
przypadku zastosowania UDP.
Tak czy inaczej lwIP ma opcję związana właśnie z tą kwestią. Jeśli
dobrze rozumiem to można wybrać jak ma się zachować stos. W przypadku
zgubienia któregoś z pakietów w sekwencji można albo trzymać nadmiarowe
do momentu otrzymania brakującego, albo poprosić jeszcze raz o wysłanie
całej sekwencji licząc, że tym razem przyjdą wszystkie i po kolei.
Próbowałem obydwu ustawień.

Swoją drogą, czy ktoś może mi wyjaśnić w jaki sposób skonfigurować lwIP,
żeby mieć dostatecznie duży bufor odbiorczy? W stosie od Microchipa po
prostu ustawiało się wielkość bufora nadawczego i odbiorczego dla
konkretnego gniazda. Tutaj cała masa opcji, które nic mi wprost nie mówią...

https://github.com/marekw1986/InternetRadioSTM32/blo
b/main/code/LWIP/Target/lwipopts.h