-
Data: 2022-09-28 09:30:56
Temat: Re: lwIP - odbieranie danych przez TCP
Od: Atlantis <m...@w...pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]On 27.09.2022 15:35, J.F wrote:
> A tak swoja drogą - te radia działają na TCP ?
Działają na TCP, a konkretnie na zwyczajnym protokole HTTP. Otwierasz
połączenie z serwerem i wysyłasz GET-a, prosząc o udostępnienie
konkretnego streamu. W odpowiedzi dostajesz odpowiedź i nagłówki. Jeśli
jest to 200 OK, możesz zacząć odbierać i dekodować przychodzące dane
audio. Oczywiście trzeba też obsłużyć inne sytuacje, jak np.
przekierowanie pod inny adres.
> Bo chyba powinny na UDP ...
Po co? Strumień audio nie potrzebuje niskiej latencji - wszystko i tak
jest buforowane po stronie serwera. Można się o tym dość łatwo przekonać
włączając jednocześnie dowolne radio FM i jego sieciowy odpowiednik,
albo jeszcze lepiej - Jedynkę na falach długich i tę samą stację
nadawaną on-line.
> Kolejna sprawa - jak te radia działają?
> Dawniej podawali jakies parametry do bezposredniej transmisji,
> dzis wszystko pochowane. Wyswietl nasza strone www.
Niektóre stacje nadal podają bezpośrednie URL-e do swoich streamów. Jest
też trochę różnych zestawień w Internecie. 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.
> A radia (te niby "sprzetowe") jakos działają ... maja jakies serwery
> z listami parametrów ?
Tak. I to jest właśnie głównym powodem dla którego zabrałem się za ten
projekt. Wkurzał mnie fakt, że większość dostępnych komercyjnie
rozwiązań będzie działała tak długo, jak długo producent raczy
utrzymywać infrastrukturę. Tutaj sam wpisuję URL-e stacji, które chcę
słuchać.
> Na moj gust, gdzies musisz sobie założyc bufor odpowiedniej dlugosci,
> wpychac tam dane które przyszly, i potwierdzac otrzymanie, lub
> poczekac jak sie bufor konczy ... aby zatrzymac transmisje.
No właśnie tutaj jak na razie rozbijam się o szczegóły. W przypadku
stosu MLA z PIC32 po prostu pobierałem sobie z bufora odbiorczego tyle
danych, ile w danym momencie potrzebowałem. Stos robił pod spodem całą
resztę - jeśli w buforze było miejsce, prosił serwer o więcej danych.
Efekt był taki, że dekoder MP3 z automatu narzucał prędkość transmisji i
nawet przy stosunkowo niewielkich buforach wszystko działało płynnie.
Tutaj sprawa jest trochę bardziej skomplikowana. Dane nie są buforowane
w taki sposób i nie mogę po prostu pobrać dowolnej ilości w dowolnym
momencie. Jeśli zostanie wywołany callback odbiorczy, mam obowiązek
odebrać całą paczkę, zwolnić pamięć i wywołać tcp_recved. Jednak z tego
co rozumiem ta ostatnia funkcja jedynie zwiększa rozmiar okna
odbiorczego, więc nawet pomimo braku jej wywołania nie mam gwarancji, że
jeszcze przez chwilę nie przyjdą kolejne callbacki - być może uda mi się
uzyskać taki efekt odpowiednio manipulując ustawieniami stosu.
Przerobiłem wczoraj nieco swoją aplikację, implementując bufor cykliczny
do którego trafiają dane ze strumienia. Serwer jednak wysyła je nieco
szybciej niż wynikałoby to z bitrate'u strumienia audio - ma to sens, bo
nadmiarowe dane w normalnych warunkach mogą zostać użyte do uzupełniania
bufora. Tak więc jeśli po prostu odbieram dane, wrzucam je do bufora i
potwierdzam otrzymanie, to dość szybko dochodzi do przepełnienia bufora
- dźwięk jest, ale postrzępiony. Próbowałem wywoływać tcp_recved() w
innym miejscu dopiero wtedy, gdy w buforze była dostatecznie dużo
wolnego miejsca, jednak jak na razie nie udało mi się uzyskać poprawnego
działania. Będę jeszcze eksperymentował.
Eksperymenty z zewnętrzną pamięcią SPI RAM 128 kB jak na razie też nie
przyniosły idealnych rezultatów. Nawet przy maksymalnej
dostępnej prędkości (18 MHz) wydaje się ona zwyczajnie zbyt wolna.
Trochę mnie to zaskoczyło, bo karta SD przy dwa razy wolniejszej
transmisji spokojnie wyrabiała z dostarczaniem danych z pliku MP3. Z
drugiej strony jednak tutaj mam operacje odczytu i zapisu, występujące
naprzemiennie w krótkich odstępach czasu.
Zaczynam zastanawiać się czy faktycznie dobrym pomysłem nie będzie
zastosowanie FreeRTOS-a i socketów. Nie wiem tylko czy problemem nie
będzie niewielka ilość RAM-u mikrokontrolerze (64kB).
Następne wpisy z tego wątku
- 28.09.22 09:35 Atlantis
- 28.09.22 10:52 Mateusz Viste
- 28.09.22 13:06 Atlantis
- 28.09.22 18:39 J.F
- 29.09.22 01:26 Atlantis
- 29.09.22 10:58 Cezar
- 29.09.22 16:48 Atlantis
- 29.09.22 17:05 Atlantis
- 30.09.22 09:49 J.F
- 30.09.22 11:04 Cezar
- 30.09.22 12:12 JDX
- 30.09.22 12:13 J.F
- 30.09.22 12:21 J.F
- 30.09.22 12:23 J.F
- 02.10.22 07:48 Marek
Najnowsze wątki z tej grupy
- jak szybko plynie prad
- Płytki Milkv-Duo
- Światłowód między budynkami
- POtrzebny bufor 3.3<>5V, jedonkieruowy, trójstanowy, wąski
- retro
- Bezprzewodowe polączenie Windows z projektorem
- rozklejanie obudowy
- Prośba o identyfikację komponentu
- Smart gniazdko straciło na zasięgu wifi?
- Smart gniazdko straciło zasięg wifi?
- nurtuje mnie
- dziwna sprawa...
- Laptop MSI się nie uruchamia.
- Dobra listwa LED (CRI 90-95, bez migotania)
- masowe programowanie AVR
Najnowsze wątki
- 2024-11-04 GNSS Motorola G85 vs Redmi Note 9 pro
- 2024-11-04 Katowice => SAP BTP Consultant (mid/senior) <=
- 2024-11-04 Katowice => Spedytor międzynarodowy <=
- 2024-11-04 Warszawa => Specjalista/tka ds. Zamówień publicznych <=
- 2024-11-04 Poznań => QA Engineer <=
- 2024-11-04 Poznań => QA Inżynier <=
- 2024-11-04 Polskie sądy są bardzo wyrozumiałe...
- 2024-11-04 Wrocław => SAP Project System/EPPM Consultant <=
- 2024-11-04 Gliwice => Team Lead / Tribe Lead FrontEnd <=
- 2024-11-04 Kraków => Programista Full Stack (.Net Core) <=
- 2024-11-04 Kraków => Software .Net Developer <=
- 2024-11-04 Kraków => Programista Full Stack .Net <=
- 2024-11-04 Warszawa => Key Account Manager <=
- 2024-11-04 Warszawa => Spedytor Międzynarodowy <=
- 2024-11-04 Warszawa => E-COMMERCE specialist <=