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

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

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

>> 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ą.

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

> 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% ...

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

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

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.