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

do góry

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.

do góry

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

c.

do góry

On 28.09.2022 09:30, Atlantis wrote:
[...]
> 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.

do góry

On Fri, 30 Sep 2022 10:04:41 +0100, Cezar wrote:
> 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.

do góry

On Thu, 29 Sep 2022 17:05:58 +0200, Atlantis wrote:
> 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.

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

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

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

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

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

J.

do góry

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

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.

do góry

On Tue, 27 Sep 2022 15:35:51 +0200, "J.F"
<j...@p...onet.pl> wrote:
> 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

do góry

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?

do góry

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

do góry