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. ;)