Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Advanced Search
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

ESP32: pager RTP i odbiornik wirtualnej karty dźwiękowej

ostrytomasz 23 Apr 2020 21:05 25407 5
Reply Cool? Ranking DIY | New topic
Notify about new articles
  • Chciałbym przedstawić dwie proste aplikacje audio bazujące na module ESP32.

    ESP32 posiada wbudowany DAC, ale jakość dźwięku generowanego przez niego jest bardzo niska.

    ESP32: pager RTP i odbiornik wirtualnej karty dźwiękowej

    Po krótkim teście z użyciem wewnętrznego DAC podłączyłem zewnętrzny kodek PCM5102. ESP32 pozwala dowolnie mapować piny I2S - możliwe jest połączenie dwóch modułów bokami 1:1 przy użyciu 5 zworek albo jak na zdjęciu przy użyciu 1 dużej 8-krotnej zworki:
    ESP32: pager RTP i odbiornik wirtualnej karty dźwiękowej

    * D4 - BCK
    * D2 - DIN
    * D15 - LCK (LRCK / WS)
    * GND - GND
    * 3V3 - VIN

    Ponieważ zegar master nie jest użyty, zworka na wierzchniej stronie modułu PCM5102 koło pinu SCK powinna być zwarta.

    Pager RTP odbiera strumienie audio G.711.a/u oraz G.722. Nasłuchuje na porcie 4000, dołączając się też do grupy multicast 234.2.1.1.
    Nadajnikiem RTP może być większość średniej klasy telefonów VoIP (funkcja opisana najczęściej jako "multicast paging", ale w telefonach które widziałem adresy unicastowe jako adresy docelowe są również akceptowane) lub softfon - tSIP.

    Projekt Scream to wirtualna karta dźwiękowa emitująca nieskompresowane próbki PCM. Jakość dźwięku byłaby niezła gdyby nie widoczna - przynajmniej u mnie - utrata pakietów (w przypadku pagera RTP mniej odczuwalna, być może ze względu na dziesięciokrotnie mniejsze pasmo). Strumień audio domyślnie wysyłany jest na adres multicast 239.255.77.77:4010 (skonfigurowany też w firmware).

    ESP32: pager RTP i odbiornik wirtualnej karty dźwiękowej

    Programy przygotowane zostały z użyciem ESP-IDF w wersji 3.3. W archiwach są też projekty Code::Blocks, ale używane były tylko do edycji kodu i można je zupełnie zignorować.

    Wszystkie wersje oprogramowania używają mechanizmu SmartConfig do ustalenia SSID i hasła sieci WiFi (konfiguracja wstępna przez aplikację androida kodującą te ustawienia jako długość pakietów). Ustawienia zapisywane są w pamięci FLASH (SPIFFS) jako plik JSON. Zwarcie podczas startu pinu GPIO27 do masy powoduje wyzerowanie ustawień i ponowne włączenie SmartConfig.

    Orientacyjne koszty:
    - moduł ESP32: ~$4
    - moduł PCM5102: ~$3

    Załączniki:
    - firmware pagera RTP używające wbudowanego DAC esp32_rtp_...er_dac.zip Download (547.24 kB)
    - firmware pagera RTP z PCM5102 w dwóch wersjach z różnymi długościami bufora esp32_rtp_...er_i2s.zip Download (475.96 kB) esp32_rtp_...buffer.zip Download (547.94 kB)
    - firmware odbiornika wirtualnej karty dźwiękowej esp32_sc..m.zip Download (462.86 kB)

    Dodatkowy opis: http://tomeko.net/projects/esp32_rtp_pager/

    Cool? Ranking DIY
    About Author
    ostrytomasz
    Level 23  
    Offline 
    ostrytomasz wrote 418 posts with rating 74, helped 66 times. Been with us since 2004 year.
  • #2
    Stanley_opo
    Level 10  
    Projekt ciekawy i coś dla mnie bo szukałem jakiegoś sposobu przesyłania dźwięku, obecnie rozwiązałem przez bluetooth transmiter.

    Te straty RTP mogą być z powodu zaszumionego środowiska WiFi (RSSI poniżej -65dBm bym zalecał).
    Po drugie 2,4 GHz wypada gorzej na rzecz 5GHz w przypadku przesyłania sygnału audio.
    Jeśli poczytasz na temat VoIP'a wszyscy zalecają używanie 5GHz ale przy ESP to tylko 2,4GHz w grę wchodzi.

    Pewnie jitter ci rozwala to audio, delay z tego co pamiętam nie wpływał na MOS(ale zalecenia dla delay są poniżej 150ms w jedną stronę).
    RTCP by dał by dużo informacji o audio gdzie leży przyczyna, braku jakości.

    A do wyłączenie podpisu sterowników dla Windows 10, aby łykał wszystko bez problemu najlepsza metoda moim zdaniem
    https://spece.it/windows-10-i-instalowanie-sterownikow-bez-podpisu-cyfrowego/

    Spróbuję za jakiś czas u Siebie to odpalić, samemu zobaczyć bo wygląda to całkiem nieźle!
  • #3
    ostrytomasz
    Level 23  
    Stanley_opo wrote:

    Te straty RTP mogą być z powodu zaszumionego środowiska WiFi (RSSI poniżej -65dBm bym zalecał).


    Tutaj niestety zbyt dużego wyboru nie mam - siła sygnału powinna być w porządku, ale zagęszczenie sieci jest też duże. Winy nie mógłbym na pewno zwalać tylko na ESP32, bo grając online wiem że komunikacja potrafi się na 2-3 sekundy zamrozić co jakiś czas jeżeli nie podepnę kabla.

    Stanley_opo wrote:

    Pewnie jitter ci rozwala to audio, delay z tego co pamiętam nie wpływał na MOS(ale zalecenia dla delay są poniżej 150ms w jedną stronę).


    Jitter nie byłby dużym problemem sam w sobie (chyba że tak naprawdę trzeba liczyć się 2-3 sekundami?), komunikacja jednokierunkowa nie jest zbyt wrażliwa na opóźnienia zakładając że nie słyszę z głośników tego co mówię do mikrofonu (niektórzy mocno się wtedy jąkają). Oglądając jakieś fragmenty filmów też nie przeszkadzało mi opóźnienie, ale nie testowałem tutaj od jakiej wartości zaczyna być ono zauważalne. Jeżeli chodzi o aplikacje VoIP, to w przypadku PC opóźnienia rzędu 150-200 ms end-to-end są raczej dobrze tolerowane i trudno o mniejsze (bufor/kolejka buforów urządzenia audio, pakietyzacja 10 lub 20 ms, opóźnienie transportowe, 2-3 pakiety UDP po 20 ms w buforze jittera, bufor urządzenia audio).

    Nie szukałem na razie zbyt długo źródła utraty pakietów. W przypadku transmisji multicast może być to po części natura samego WiFi (https://tools.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-01.html), ale przy unicastowej transmisji RTP też widziałem straty ("kartę" Scream też da się przestawić w tryb unicast, ale nie przetestowałem tego).
  • #4
    Stanley_opo
    Level 10  
    Jeszcze co mi przychodzi do głowy to może być też kwestia samego routera i QoS lub jego braku.
    Jeśli router wspiera 802.11e(WMM) to znakowanie pakietów(DSCP) przy obciążonym WiFi mogło by też coś dać :)
    OpenWRT na pewno wspiera, z tego co pamiętam był widoczny efekt jak to testowałem.
  • #5
    ostrytomasz
    Level 23  
    Stanley_opo wrote:
    Jeszcze co mi przychodzi do głowy to może być też kwestia samego routera i QoS lub jego braku.
    Jeśli router wspiera 802.11e(WMM) to znakowanie pakietów(DSCP) przy obciążonym WiFi mogło by też coś dać :)


    Router raczej nie jest obciążony, chociaż to "klasa średnio-niska", technicolor od operatora z zablokowaną w większości konfiguracją.
    Odkurzyłem dla porównania "antyczny" Pentagram Cerberus P6391 i zrobiłem kilka testów z nim:
    - Scream przestawiony w tryb unicast
    - kanał radiowy przestawiony na 13
    - trochę bliżej ESP32
    Jest lepiej, być może to już kres możliwości WiFi i dalej można to już tylko kompensować przez PLC - jedno "zacięcie" audio / niedopełnienie bufora na kilka minut co oznacza około 0.25% utraty pakietów. Określiłbym to jako akceptowalne - dało się słuchać muzyki przez dłuższy czas. W przypadku RTP w ciągu kilku kilkuminutowych transmisji niedopełnienia nie zaobserwowałem (przy przerwie między transmisjami bufor się zapełnia od nowa).
  • #6
    ostrytomasz
    Level 23  
    Wersja "przewodowa" odbiornika Scream - nucleo STM32F429ZI:
    - użyte wbudowane przetworniki DAC (12-bit, ale jakość jest całkiem w porządku)
    - 48 kHz stereo
    - opóźnienie maksymalne 42 ms, typowo 30 ms
    - domyślnie aktywne DHCP
    - dołączenie do grupy multicast 239.255.77.77 - powinno to działać bez potrzeby konfiguracji (nie licząc przestawienia we właściwościach urządzenia Windows próbkowania z 44,1 kHz na 48 kHz)
    ESP32: pager RTP i odbiornik wirtualnej karty dźwiękowej
    Attachments:
Reply Cool? Ranking DIY | New topic
Notify about new articles
Popular Topics