On 05.10.2022 18:37, a...@m...uni.wroc.pl wrote:

> To by wskazywalo na zbyt male bufory/okno danych. Sprzet wyraznie
> moze pracowac szybciej, ale kontrola przeplywu TCP mu nie pozwala.

Które opcja w konfiguracji lwIP za to odpowiada? W stosie TCP/IP od
Microchipa po prostu ustawiało się parametr określający wielkość bufora
odbiorczego i nadawczego przy konfiguracji konkretnego socketu. W lwIP
nie widzę czegoś takiego niestety.


> Ja bym sprawdzil co sie dzieje jak wywalisz caly kod odpowiedzialny
> za dzwiek i zostawisz tylko odbior strumienia, ale potwierdzajac
> w takim tempie (w przyblizeniu) jak kodek by je odbieral.

Najbliższą rzeczą do tego jaką zrobiłem było wywalenie zapisywania
nadchodzących danych do bufora cyklicznego. I wygląda na to, że wtedy
leciały z maksymalną dostępną prędkością, odpowiadającą bitrate'owi
streama. Nie bardzo wiem natomiast jak w przypadku lwIP narzucić tempo
odpowiadające tempu zapotrzebowania na dane przez VS10xx. W przypadku
stosu od Microchipa było to proste - przychodzące dane trafiały do
bufora FIFO socketa, z którego mogłem je pobierać porcjami o dowolnej
wielkości. Jeśli dobrze rozumiem w przypadku lwIP i RAW API jest inaczej
- mam obowiązek przyjąć całą porcję danych zgłoszoną przez callback
odbiorczy, zwolnić pamięć i wywołać tcp_recved. Stąd potrzeba stosowania
bufora cyklicznego.


> Jeszcze moze glupie pytanie: w jakim tempie piszesz/czytasz ten
> RAM SPI? DMA powinno przerzucac dane z maksymalna predkoscia
> SPI, ale RAM moze miec porabany protokol a jak go obsluzysz
> przez software to moga byc straty predkosci.

Na chwilę obecną nie używam DMA - dane są po prostu przepisywane z
jednego miejsca w drugie w pętli. Myślałem, że SPI może powodować
opóźnienia, jednak tę hipotezę można już odrzucić ponieważ:
- Urządzenie zachowuje się identycznie w przypadku bufora cyklicznego w
ulokowanego pamięci SPI, jak również (mniejszego) w zwykłym RAM-ie.
- Żadne problemy nie występują w przypadku odtwarzania z karty SD.


> Pytanie kiedy potwierdzasz odbior: przed czy po zapisie do SPI
> RAM. Jesli po to potwierdzenie jest opoznione i efektywnie
> zmniejsza dostepne okno.

To tak można? ;) Myślałem, że tcp_recved() wolno mi wywołać dopiero po
przetworzeniu odebranych danych i zwolnieniu pamięci za pomocą pbuf_free().


> Pisales ze jest 6kB na bufory LWIP. To 4 pakiety maksymalnej
> wielkosci. Jesli 1 to wlasnie odbierany pakiet (nie wiem

6kB to chyba było odnośnie wcześniejszej wersji urządzenia,
zrealizowanej na PIC-u. Tam dość łatwo było ustawić konkretną wielkość
bufora odbiorczego.


> Piszesz o jakims "buforze audio". Nie wiem co to ma byc,
> ale datasheet VS1003 mowi o przesylaniu bloku 32 bajtow,
> czyli w zasadzie jesli jest portrzebny jakis bufor to
> na poziomie max setek bajtow. Czyli pownny byc dziesiatki
> kilobajtow wolnej pamieci: STM32F107 ma 64KB RAM.

Dodatkowy bufor na dane audio, pośredniczący w komunikacji pomiędzy
źródłem danych (Ethernet, lokalny nośnik pamięci) a VS10xx. Praktyka
pokazała, że jego zastosowanie dość mocno zwiększa stabilność, zwłaszcza
w przypadku Ethernetu. Implementowałem go do tej pory na jeden z dwóch
sposobów:
- klasyczny bufor cykliczny
- Dwuczęściowy bufor. Gdy jedna część karmi dekoder MP3, druga jest
ładowana danymi z zewnątrz. Potem następuje zamiana.
To właśnie tę funkcję w projekcie pełni pamięć SPI RAM.