logo elektroda
logo elektroda
X
logo elektroda
Szukanie Zaawansowane
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

ADPCM (zamiast MP3) player (teraz to właściwie mp3 na ARMie)

bajk 23 Mar 2006 15:27 20545 99
Najlepsze odpowiedzi

Czy da się zbudować tani odtwarzacz muzyczny na AVR z ADPCM zamiast MP3, czy lepiej użyć VS1001 albo ARM?

Jeśli zależy Ci na bardzo tanim i prostym odtwarzaczu, ADPCM na AVR jest wykonalne, ale do muzyki lepszy będzie ARM albo gotowy dekoder typu VS1001, bo ADPCM jest prostsze tylko pozornie i szybko pokazuje swoje ograniczenia [#2459549][#2622246] Przy 44 kHz stereo i 4 bitach autorowi i kilku osobom jakość wydawała się całkiem dobra, ale inni w ślepym teście słyszeli lekkie „spłaszczenie” i trzeszczenie, zwłaszcza na wokalach, a przy niższych częstotliwościach ADPCM wypada wyraźnie gorzej [#2448437][#2457655] Trzeba też pamiętać, że w AVR-ach wewnętrzny przetwornik A/C nie wyciąga 44 kHz, więc do audio i tak potrzebny jest zewnętrzny DAC [#2456424] Dekodowanie ADPCM to nie tylko dodawanie różnicy do poprzedniej próbki — dochodzi adaptacja kroku kwantyzacji, więc obciążenie procesora jest większe niż w prostym DPCM [#2501327][#2459549] Jeśli celem jest odtwarzacz „jak MP3”, to bardziej opłaca się iść w ARM7 z gotowymi bibliotekami dekodera niż upychać wszystko w AVR, bo na ARM-ach można już znaleźć działające źródła i rozwiązania jednoukładowe [#2622246][#2640319]
Wygenerowane przez model językowy.
Zgłoś naruszenie prawa
Odpowiedz | Nowy temat
  • #1 2448053
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Witam,
    ostatnio wpadłem na pomysł budowy odtwarzacza adpcm, zamiast mp3, na zasadzie ATmega+MMC+DAC. Przetwornik, wzmacniacz słuchawkowy i ewentualnie przetwornica ze stabilizatorem - jak w AT89c51snd1c. Próbki byłyby dekodowane przez atmegę i dalej programowo na dac i sł. Ewentualnie jeszcze LCD od Nokii 6610.
    Konwersję można przeprowadzić oczywiście w Winampie. 4MB-towa mp3-ójka po przerobieniu (44kHz; stereo; 16bit na 4bit) waży około 8MB, przy czym jakość pozostaje prawie taka sama (w większości przypadków nie do odróżnienia poza małą różnica głośności), ale za to algorytm dekompresji wyjątkowo prosty i nie trzeba kupować vs1001.
    Nie udało mi sie znaleźć żadnego projektu bazującego na podobnej idei. Chodzi gównie o to, że przy mniejszych nakładach finansowych można zbudować odtwarzacz muzyki o jakości podobnej do mp3.
    Co o tym sądzicie ? Czy bardziej opłaca się już kupić vs1001 ?
    Arrow MultiSolution Day Warsaw 2026 – bezpłatna konferencja elektroniki i automatyki już 16 czerwca [sponsorowany]
  • #2 2448232
    MirekCz
    Poziom 35  
    Posty: 2220
    Pomógł: 330
    Ocena: 62
    Jak dla mnie adpcm ma kiepską jakość dźwieku, przynajmniej przy niższych częstotliwościach. Ja próbowałem 16khz,16bit,mono i niektóre dźwięki wychodziły fatalnie.

    Sama idea jak najbardziej ok i powinno ślicznie działać.
  • #3 2448437
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    16khz nadaje się jak już, to do głosu, nie do muzyki, a po przekonwertowaniu na mono(zmiksowaniu dwóch kanałów) masz racje - niższe częstotliwości wychodzą beznadziejnie i to nie tylko w adpcm, nawet w nieskompresowanym wavie są z tym problemy, ale konwersja z oryginału na stereo rozwiązuje problem.
    Mi chodzi konkretnie o 44khz stereo i próbki 4bitowe, wtedy bardzo trudno jest zauważyć różnice, zachęcam do sprawdzenia tego, różnica jak dla mnie niezauważalna
  • #4 2450972
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Dodam, że jak by ktoś chciał sprawdzić jakość po konwersji, to można to zrobić w Winampie. Options >preferences...>output>nullsoft disk writer plug-in>configure>w polu "conversion" zaznaczamy "convert to format" i wybieramy format wyjściowy(ADPCM najlepsza jakość). Plik zapisuje się na c:\ , ale można to zmienić w polu "output file location". Po ustawieniu wszystkiego odpowiednio i wciśnięciu play cała playlista zostanie skonwertowana i zapisana gdzie ustawiliśmy.
    Jak pisałem jakość tylko w niektórych przypadkach jest zauważalna, jednak normalny człowiek(w większości przypadków), co mogę stwierdzić po testach na moim bracie, nie jest praktycznie w stanie zauważyć różnicy. Trzeba sie bardzo wsłuchać aby ją dostrzec, ale to zależy też od utworu.
  • #5 2451585
    wladi.klimek
    Poziom 18  
    Posty: 370
    Pomógł: 20
    Ocena: 46
    Bardzo interesujacy pomysl, moglbys przyblizyc nam sam algorytm dekompresji ADPCM?
  • #6 2451793
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Polega to na tym, że zamiast wartości zdekompresowanych próbek PCM zapisywana jest jedynie różnica pomiędzy kolejnymi ich wartościami, co pozwala zmniejszyć bitrate nawet czterokrotnie.
  • #7 2456261
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Czy naprawde nikt nie słyszał o kodowaniu ADPCM ? Jakość jest bardzo dobra, jeżeli nie lepsza(przy maksymalnym bitracie), a projekt wyszedłby bardzo ekonomicznie.
    Czy nie warto wogóle zaczynać i kupić po prostu vs1001 ? Nie chcę marnować na to czasu, jeżeli stosunek jakości do oszczędności po użyciu zwykłego DACa zamiast dekodera jest nieopłacalny. Może jakieś sugestie albo pomysły?
  • #8 2456424
    Prymulka
    Poziom 18  
    Posty: 378
    Pomógł: 9
    Ocena: 8
    Problem w tym, że przetwornikiem wewnętrznym w ATMEGA nie wyciągniesz 44kHz. Mi w atmega8535 lub atmega8 udało się maksymalnie wyciagnac 22100Hz. W dokumentacji masz napisane
    conversion time: 60 - 200us
    A o tej konwersji nie słyszałem i powiem szczerze bardzo mnie zainteresowała. Gdzie mozna o niej poczytac?
  • #9 2456431
    wladi.klimek
    Poziom 18  
    Posty: 370
    Pomógł: 20
    Ocena: 46
    Moja sugestia jest taka zebys sie zabral za ten projekt, powalczyl i pozniej pochwalil co z tego wyszlo. Calosc wydaje sie (przynajmniej na tym etapie) sensowna a podjecie budowy uzasadnione. Sugerowalbym ewentualnie przeanalizowanie innych algorytmow kompresji i wybranie najoptymalniejszego no i rozwazenie zastosowania procesora DSP. Wydaje mi sie iz niski pobor pradu bedzie kluczem do funkcjonalnosci, wszelkie wodotryski (rozbudowany interfejs uzytkownika,itd.) mozna sobie darowac, a skoncentrowac na zapewnieniu minimu mocy obliczeniowej niezbednej do dekompresji.

    Pozdrawiam i powodzenia.
    Bartek

    A Prymulce sie chyba przetworniki pomylily

    Jesli chodzi o pradozernosc to Atmel szykuje nam niespodzianke PicoPower Technology.
  • #10 2456446
    Prymulka
    Poziom 18  
    Posty: 378
    Pomógł: 9
    Ocena: 8
    No właśnie czy interesuja Cie inne procki niz AVR? Ja jakis czas temu dostalem probki dsPICow i powiem szczerze ze nadaja sie idealnie do tego tematu.
  • #11 2456708
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Innych niż AVRy nie, ale myślałem też o ARMach Philipsa lub Atmela.

    A wogóle to jeszcze jakaś firma przysyła próbki do polski ? Ja po doświadczeniach z TI na jakiś czas sobie wybiłem z głowy próbki.

    A tak poza tym z tego co widzę, to dsPICi fajne są, ale nauka nowej rodziny... nie mam za dużo czasu, jak już napisałem najprędzej ARMy, cóż taka moda, chociaż chciałem kiedyś zająć się `51, ze względu na peryferia (USB), ale przedewszystkim MP3.

    Na razie podszkole się troche na AVRach. Do tej aplikacji zwykły ATmega168 chyba wystarczy.

    PS. 1,8V chodziło mi po głowie, albo żeby to jakoś z jednej AAA zasilić bez przetwornicy, żeby długo działało, ale znaleźć reszte do niego to bym się musiał naszukać, raczej takie układy nie są jeszcze zbyt rozpowszechnione.
  • #12 2456755
    Prymulka
    Poziom 18  
    Posty: 378
    Pomógł: 9
    Ocena: 8
    A uważasz że dużo szybciej opanujesz ARM niz dsPICi? Zreszta to Twoja sprawa jaki procek wykorzystasz. JAk tak wogóle to prróbki dsPICów dostalem w niecałe dwa tygodnie a przyleciały chyba z Tajwanu. Tak wiec nie zaszkodzi Ci chociaz je wypróbować. Jeśli programujesz w C to naprawde nie jest to takie trudne a nie warto trzymac sie sztywno jednej rodziny procków.

    PS Widze ze przetwornik w ATMEGA168 jest troszke szybszy
    conversion time 13 - 260us.
  • #13 2456790
    wladi.klimek
    Poziom 18  
    Posty: 370
    Pomógł: 20
    Ocena: 46
    Jesli chodzi o peryferia na 1,8V to nie jest tak zle, zobacz chociazby MAX9850 (DAC + wzm. sluchawkowy). A z pewnoscia wybor jest znacznie szerszy.

    Prymulka:
    Czy do dsPICow sa jakies biblioteki mogace przydac sie w tego typu urzadzeniu? (pytam z ciekawosci).
    A jesli chodzi o przetwornik to mialem na mysli to ze Atmega ma na pokladzie A/C a tu przydalby sie C/A ... , ale mozna oczywiscie zastosowac zewnetrzny.
  • #14 2456859
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Chodziło mi o zewnętrzny przetwornik cyfrowo-analogowy I2S i dalej mały wzmacniacz słuchawkowy jak w aplikacji AT89C51SND1C, tylko że na AVRze.

    Niestety pisze w asemblerze, w C się dopiero ucze, ale jak już miałbym się przesiadać, to na ARMy, w EP jest kurs, nadają się do większych projektów, a dsPICi chociaż nie znam ich bliżej, to wydaje mi się że sa podobne do AVRów tylko troche szybsze no i 16bit z tego co widzę, peryferia mają takie zwykłe, żadnych sensacji, tylko te 16bit i 40Mhz... może kiedyś, szczególnie, te próbki, póki jeszcze wysyłają.

    Z tak prostym dekodowaniem powinien poradzić sobie atmega, ew. dodam jakieś wstawki assemblerowe.

    Na razie pozostanę przy tym, co mam, bo jeszcze się tak dobrze ich nie nauczyłem, żebym się łapał za następne.

    Dodano po 5 [minuty]:

    MAX9850 widziałem, aż mi się oczy zaświeciły jak go zobaczyłem, niestety potem od razu zgasły bo w żadnym sklepie go nie widziałem jak dotąd. Może wiecie gdzie go można dostać?
  • #15 2456893
    Prymulka
    Poziom 18  
    Posty: 378
    Pomógł: 9
    Ocena: 8
    1) Jeśli chodzi o przetwornik CA to ja proponuje to zrobic na PWMie. Oczywiscie AVRki z zegarem nawet 16MHz nie zapewnia wystarczajacej predkosci PWM (4xpasmo sygnalu audio).

    2) Z tego co widziałem w dokumentacji dsPICow to z petla PLL moga miec 120MHz. Druga sprawa to predkosc wykonywania skomplikowanych operacji matematycznym. Np mnozenie liczb 16-bit trwa 1 cykl a dzielenie 18-cykli. Jesli chodzi o wybor tego procka nie mialem na mysli ze ma on wiele peryferiow ale duze mozliwosci cyfrowej obrobki.

    A tak wogole to sie uparlem na tego proca bo myslalem ostatnio o swoim MP3 ale rzeczywicie w tym projekcie spokojnie wystarczy cos innego. Chcialem Ci tylko uzmyslowic ze wg. mnie przetworniki AC w AVRkach nie nadaja sie do dzwieku (chyba ze tak jak juz ktos napisal tylko do mowy).

    Biblioteki do dsPICow sa na stronie microchipa. Niestety platne. Ale pewnie sa w obiegu na necie :). Z tego co pamietam sa biblioteki z filtrami FIR, cyfrowa eliminacja szumu, DFT lub FFT.
  • #16 2456937
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Co do PWMa to nie za bardzo, jakość ADPCM nie jest aż taka żałosna żeby ja zniżać do poziomu audio z pwma. Kiedy piorwszy raz sprawdziłem na komputerze jak to brzmi to aż się zdziwiłem że jest tak dobrze(na najwyższym bitracie - powtarzam). Naprawde brzmi prawie jak mp3 - prawie - ale w niektórych utworach to bardzo ciężko odróżnić który to który. Czemu nikt nie spróbuje ? (stereo przedewszystkim żeby nie psuć ścieżek, 44kHz, 4bit) może ktoś się wypowie, to nie bede musiał bazować wyłącznie na swoich wrażeniach dot. tej jakości.

    Jakość na zwykłym 16bitowy przetworniku audio powinna być odpowiednia. tylko szkoda, że ten max nie jest dostępny w polsce, ale za to można ściągnąć z aplikacji AT89C51SND1C i akurat by było, a jego części są łatwo dostępne, nie chce nikogo reklamować ale w seguro jest wszystko więc tylko zlutować pozostaje...

    Jak by ktokolwiek wiedział z kąd wziąść tego MAXa9850 to prosze nie czekać, tylko pisać! :)

    Ja od początku nie myślałem że przetworniki w AVRach są odpowiednie, dlatego chciałem użyć audio-dac`a do tego jak w normalnych odtwarzaczach.
  • #17 2457655
    wladi.klimek
    Poziom 18  
    Posty: 370
    Pomógł: 20
    Ocena: 46
    To mnie zaskoczyles z tym zrodlem zaopatrzenia w MAXy ..... czyzbym czegos nie wiedzial i Maxim juz probek do Polski nie wysylal?

    Zrobilem test odsluchowy tego formatu. Przerobilem 5 dobrze znanych utworow i wlaczylem ja przemieszane z 'oryginalami'. W slepym tescie da sie je odroznic (w szczegolnosci wokale). Nie potrafie okreslic na czym polega roznia, ale w utworach ADPCM jest wlasnie taki maly, ale irytujacy brak jakosc (cos jakby splaczony, minimalnie jakby trzeszczacy dzwiek). Nie mam kosmicznej karty dziwekowej, lecz w plejku tez nie bedzie super przetwornika.
    Tak wyglada sprawa w moich uszach. Test powtorze jutro rano, moze na swierzo bede w stanie cos wiecej powiedziec.

    Jesliby sie Maxim nie spodobal to TI tez ma cos ciekawego: PCM1770 .. PCM1773 (dac) i TPA6100 ... TPA6103 (wzm. sluchawkowy).
  • #18 2458640
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Jeżeli chodzi o próbki, to po daremnych próbach u TI spasowałem, ale jak Maxim? tego nie wiem, nie próbowałen już potem w żadnej innej firmie. U TI codziennie wysyłałem prośby o nie przez tydzień, a potem wysłałem maila i mnie olali. Dlatego już nie wierzę, że cokolwiek do mnie dojdzie, chociaż chyba jeszcze spróbuje u Maxima, może się uda.

    Co do jakości to mnie udało się zauważyć tylko w jednym przypadku mały spadek głośności najwyższych częstotliwości i coś tak jakby chwilowe trzeszczenie głosu w pewnym momencie, ale takie samo było w oryginale tylko cichsze, trafiło mi się tylko w jednym przypadku, pozostałe wypadły bardzo dobrze. No cóż nie jestem raczej audiofilem. Z resztą to zależy od przebiegu próbek, a więc ogólenie od utworu.

    A ustawiłeś na stereo i najwyższą możliwą częstotliwość ? Bo po miksowaniu z 2 do 1 kanału też jest taki efekt, który od razu zniechęca.
  • #19 2459549
    wladi.klimek
    Poziom 18  
    Posty: 370
    Pomógł: 20
    Ocena: 46
    Maxim probki wysylal, nie wiem jak jest obecnie. Pliki skonwertowalem zgodnie z Twoim opisem.
    Przyjzalem sie dzis troche temu zagadnieniu i mam taka konkluzje. Sa dwie drogi do zrobienia Twojego urzadzenia:
    1-pozostac przy ADPCM i 8bitowym uC, majac swiadomosc ze jest to jednak kodek zaprojektowany dla przenoszenia glosu i bedzie pracowal na maksimum swoich mozliwosci oferujac jakosc jaka oferuje. Tu jeszcze dodam, iz nie jestem tak do konca pewien czy dekompresja bedzie polegala jedynie na okreslaniu wartosci na podstawie roznicy w stosunku do poprzedniej probki - to jest kompresja DPCM, ADPCM zmienia jeszcze krok kwantyzacji i moze to znaczaco obciazyc procesor. Tak przynajmniej wyczytalem w znalezionych materialach.
    2-zastosowac ktorys z nowoczesnych kodekow (mp3,aac,tta,vorbis,...) i konstrukcje oprzec o ktorys z DSP. TI i inni oferuja (takze darmowe) bibloteki zawierajace gotowe rozwiazania, zarowno dekompresji jak i obslugi FAT.

    Co bys nie wybral mozesz liczyc na pomoc.
    Pozdrawiam.
    Bartek
  • #20 2459733
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Jeżeli bym wybrał opcję z DSP to raczej bym daleko nie zaszadł, nie jestem aż taki dobry zeby zrobić na DSP programowo dekodowanie mp3, nawet z dużą pomocą, za którą bardzo dziękuję. Jak już to jakiś sprzętowy dekoder, ale to oznaczałoby wykorzystanie vs...

    Moim głównym założeniem było zbudowaine naprawde "low-cost" urządzenia nie tracącego przy tym zbytnio na jakości odtwarzanego dźwięku, oczywiście na popularnym AVRze (to już pod yamppa podchodzi troche).
    Jeżeli bym użył jakiegoś mocniejszego uC to może wspomnianego ARMa? Mam też zapisane na dysku biblioteki w C dekodowania programowo mp3, tylko nie wiem na co, ale raczej ich nie spożytkuję, przynajm, nie tak szybko.

    Głównie interesował mnie ten adpcm (to prawda, to co innego niż samo dpcm, ale atmel zrobił juz adpcm decoder więc to była by tylko kwestia przerobienia go troche).
    Jak widzę jednak chyba jakość jest trochę "za mała" chociaż dla mnie taka jakość nie jest najgorsza.

    A czy te biblioteki, o których wspomniałeś daiłają na zasadzie:
    1)zapisz blok danych mp3 gdzieć w pamięci sram
    2)skocz do funkcji X
    (i gotowe)
    3)wyślij blok zdekodowanych próbek pcm z sram do DAC ?
  • #21 2462073
    wladi.klimek
    Poziom 18  
    Posty: 370
    Pomógł: 20
    Ocena: 46
    Mysle ze taki jest ogolny algorytm dzialania takiego dekodera: MMC->SRAM->dekodowanie->DAC (inaczej sobie tego nie wyobrazam, ale nie sprawdzalem wiec nie moge powiedziec z cala pewnoscia). Przelotem tez gdzies widzialem gotowe biblioteki do ARM7/9 (zarowno mp3 jak i tta).
    Hmm no i nie wiem co teraz doradzic bo znowu wyszlo ze jednak yampp to optymalne rozwiazanie - moze pociagnij za jezyk 'shg' https://www.elektroda.pl/rtvforum/topic480740.html.
  • #22 2468721
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Pozostaje mi więc tylko zadać pytanie "czy opłaca się wogóle zaczynać projekt, gdzie schodząc do jakości adpcm, zyskuje się dużą oszczędność na dekoderze sprzętowym i uproszczenie całego urządzenia?" Czy może lepiej jest nauczyć sie ARMów i pomęczyć troche w C?

    Nie chce żeby się ze mnie audiofile po cichu naśmiewali w dziale akustyka.
  • #23 2468820
    wladi.klimek
    Poziom 18  
    Posty: 370
    Pomógł: 20
    Ocena: 46
    Mysle ze kazda okazje do nauczenia sie czegos nowego nalezy wykozystac. Niemniej rozsadek nade wszystko, ja na Twoim miejscu, zrobilbym liste korzysci plynacych z jednego jak i drugiego rozwiazania uwzgledniajac jak najwiecej aspektow - takze takie, ze mozesz posiedziec nad czyms nowym. No i wybrac to najbardziej 'oplacalne'. Przegladalem dzis projekt MAD z sourceforge i jest on calkiem zachecajacy, przynajmniej jako podstawa do rozwoju, albo jako sciaga.

    Pozdrawiam.
    Bartek

    Dzis dostrzeglem w MADzie pewna niedogodnasc: otwiera plik mp3, alokuje ram wielkosci pliku i przenosi zakodowane probki do zaalokowanego obszaru. O ile takie rozumowanie w przypadku PC jest sluszne, o tyle w systemie wbudowanym juz nie do konca. Przy odrobinie czasu chetie rzuce okiem Twoje linki.
  • #24 2469122
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Chyba jednak przerzuce się na ARMy i pomęcze się w C. Ja na mp3-tech znalazłem takie "Mp3playlib" i z tego trochę patrzyłem(proso choćbez komentarzy). Znalazłem kiedyś jeszcze taki dekoder na FPGA www.mp3-tech.org/programmer/docs/fpga_report.pdf. Szczegółowo opisane, więc z jakiejś biblioteki można by wyciąć fragmenty algorytmów, (6 bloków opisane w pdfie) i wykorzystaćna ARMie.

    Natomiast MAD i niektóre inne biblioteki otwierają mi się w poprzek, a nie wzdłuż (używam notatnika do otwierania) więc jak na razie jeszcze nie przejżałem dokładnie wszystkich źródeł.

    Pozdrawiam
    Mateusz
  • #25 2472341
    wladi.klimek
    Poziom 18  
    Posty: 370
    Pomógł: 20
    Ocena: 46
    Hmm, no niby wszystko w miare jasne, lecz to wszystko zmierza do skonstruowania systemu na ktorym mozna by odpalic 'lekkiego' linuxa tylko po to zeby zdekodowac mp3. Nie moge pozbyc sie wrazenia ze to troche przerost formy nad trescia i vs1001 pobedzie jeszcze troche z nami z racji swojej prostoty. Powodzenia w walce i pochwal sie jak juz cos zwojojesz.

    Bartek
  • #26 2491573
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Czemu nie linux? Jeszcze tylko lcd od S65 i już jest PDA:). Po implementacji linuxa nie trzeba by było przechodzić przez cały algorym dekompresji.
    Największym problemem stała by się sama implementacja no i obsługa konkretnego wyświetlacza i klawiatury (chyba to wymagałoby dopisania paru linijek), a z tym niestety sobie raczej nie poradzę, nie znam się na OS dla uC.
  • #27 2493796
    szymtro
    Poziom 30  
    Posty: 1421
    Pomógł: 101
    Ocena: 59
    Jeżeli tak kombinujesz to barzo dobre rozwiązanie zaproponował ktoś wcześniej - kup router sprzęt5owy w którym jest jakiś klon arm'a i dodatkowo pamieci już podlączone.

    Mnie bardziej interesuje odpalenie czegoś takiego na uC 8 bitowym rodzina nie ma znaczenia (avr, 51, pic).

    Mam tylko takie pytanie. To jest format delta (przyrost) 4 bitowy. Tylko jak określić jaką maksymalną wartość moze osiągnać zmienna? Na komputerze to to może nie ma aż takiego znaczenia ale w uC ma zasadnicze.
    Jak sobie z tym poradzić?

    Pomyślałem ze na poczatek mozna zrobić to używając komputera i po koleji wrzucać próbki. Nie programuje aż tak biegle na PC (używam VB6) i szybciej bym coś takiego zrobił na uC.

    To jak zaczniemy?
  • #28 2494563
    wladi.klimek
    Poziom 18  
    Posty: 370
    Pomógł: 20
    Ocena: 46
    Witam.
    Otoz to szymtro, tez jestem zwolennikiem rozwiazania 8-bitowego (no moze 16-bitowego biorac pod uwage rozmiar probek). Jesli chodzi o maksymalan wartosc probki, to nie bedzie ona wiekszy od slowa16 bitowego bez znaku.

    Moze jednak uda sie zbudowac prostego i taniego mp3plejka wspolnymi silami na elektrodzie.

    Pozdrawiam.
    Bartek
  • #29 2495200
    Januszcz22
    Poziom 15  
    Posty: 119
    Pomógł: 9
    Ocena: 22
    A może jednak o Ogg Vorbis? Wymaga mniej mocy obliczeniowej niż mp3 ma lepszą jakość a dodatkowo nie jest opatentowany i jest bezpłatny do celów prywatnych i komercyjnych.
  • #30 2495873
    bajk
    Poziom 13  
    Posty: 88
    Pomógł: 3
    Ocena: 1
    Co do ogg vorbis, to mają lepszą jakość miż mp3 przy mniejszym rozmiarze pliku, ale dekompresja, jak to gdzieś czytałem "jest równie zawiła jak w przypadku mp3" więc byłby to mały problem dla AVRka.
    Rozejrze się jeszcze po innych formatach i poczytam dokładniej o ogg vorbis.

    Rozwiązania dekompresji mp3 na ARMach wymagają dwudziestukilku MHz przy 32bitowym uC w przypadku 320kbps, 48kHz, stereo.
    Nowsze AVRy mogą być taktowane kwarcem do 20MHz, ewentualnie by się troszke podkręciło, czy nie wystarczyłoby to do dekodowania 128 albo 64kbps, 44kHz nawet mono? Czy jednak lepszym wyjściem byłby jakiś inny format?
Odpowiedz | Nowy temat
Zgłoś naruszenie prawa

Podsumowanie tematu

✨ Dyskusja dotyczy pomysłu budowy odtwarzacza audio wykorzystującego dekodowanie ADPCM na mikrokontrolerze ATmega z kartą MMC i zewnętrznym DAC, jako tańszej alternatywy dla odtwarzaczy MP3 z dedykowanymi układami VS1001. Poruszono kwestie jakości dźwięku ADPCM, która przy 44 kHz, stereo i 4-bitowej próbkach jest według autora trudna do odróżnienia od MP3, choć inni uczestnicy wskazują na zauważalne pogorszenie jakości, zwłaszcza przy niższych częstotliwościach i mono. Omówiono algorytm ADPCM, polegający na zapisie różnicy między kolejnymi próbkami oraz adaptacyjnym kroku kwantyzacji (step size), co pozwala na kompresję danych.

Wielu uczestników zwraca uwagę na ograniczenia mikrokontrolerów AVR w zakresie prędkości próbkowania DAC (maksymalnie około 22 kHz) oraz wydajności obliczeniowej przy próbie dekodowania MP3 programowo. Proponowane są alternatywy: użycie procesorów ARM (np. LPC2106, AT91SAM7S256) lub dsPIC, które dzięki wyższym taktowaniom i specjalnym instrukcjom DSP lepiej radzą sobie z dekodowaniem MP3 i innych formatów audio. Dyskutowano o optymalizacji kodu dekodera MP3 (np. Helix MP3) pod kątem ARM, problemach z pamięcią RAM (około 28-37 kB potrzebne do dekodera), konieczności przenoszenia krytycznych fragmentów kodu do RAMu dla zwiększenia wydajności oraz o ograniczeniach związanych z pamięcią flash i wait states.

Poruszono także temat alternatywnych formatów audio, takich jak Ogg Vorbis, AAC, a także pomysł stworzenia własnego, prostego kodeka audio dedykowanego dla mikrokontrolerów o ograniczonych zasobach, który łączyłby prostotę dekodowania z dobrą jakością dźwięku i niskim zużyciem mocy. Wspomniano o problemach z dostępnością i wsparciem dla próbek DAC (np. MAX9850) oraz o implementacji interfejsu I2S na mikrokontrolerach ARM do współpracy z zewnętrznymi przetwornikami DAC.

W dyskusji pojawiły się także propozycje wykorzystania FPGA z softprocesorem MicroBlaze do dekodowania MP3, jednak ze względu na koszty i złożoność projektowania PCB uznano to za mniej praktyczne. Wątek poruszał również kwestie taktowania mikrokontrolerów ARM, generowania zegarów dla DAC, problemów z synchronizacją próbkowania i implementacją interfejsów SSC/I2S.

Podsumowując, projekt odtwarzacza ADPCM na AVR jest możliwy, ale ograniczony jakością dźwięku i wydajnością. Lepszym rozwiązaniem jest wykorzystanie procesorów ARM z gotowymi bibliotekami dekodującymi MP3, choć wymaga to większej wiedzy programistycznej i optymalizacji. Pomysł własnego kodeka audio dla mikrokontrolerów pozostaje otwarty i interesujący dla społeczności. Wiele osób dzieli się doświadczeniami z kompilacją i optymalizacją kodu Helix MP3 na platformach ARM oraz problemami sprzętowymi związanymi z DAC i interfejsami audio.
Wygenerowane przez model językowy.
REKLAMA