Elektroda.pl
Elektroda.pl
X
Computer ControlsComputer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

bajk 05 Kwi 2006 16:06 18577 99
  • Computer ControlsComputer Controls
  • #32
    bajk
    Poziom 12  
    Ale niestety radioda to jest `51, a nie AVR, więc ja sam nie umiałbym z nim nic zrobic. Gdyby takie coś bylo z rdzeniem AVR to co innego, a poza tym to chyba nie jest on tak łatwo dostepny w polsce, jak już to jest jeszcze AT89C51SND1C ale to też 51.
  • #33
    szymtro
    Poziom 30  
    OK troche poczytałem

    Wygląda na to że oprócz nagłówka i stopki w utworzonym pliku są same wartosci nas interesujace.
    Poczytałem to:
    http://resource.intel.com/telecom/support/appnotes/adpcm.pdf

    Tam jest napisane ze 4 bity sa tak naprawdę 3 bitowe plus znak po lewej stronie.
    Tylko nie bardzo moge zrozumieć co tam piszą do mnie. Czy to jest dwa zera (plus i minus zero) czy skala po prostu jest w jedna wieksza a w druga mniejsza. Przygotowąłem sobie fragment jakiegoś utworu w formacie 16 i 8 bitowym i mam też 4 bitowy adpcm. Jakoś wymyśle gdzie się zaczynają próbki audio w pliku.

    Powiedzcie tylko co to jest ten step size i po cho... jest ta tablica do ustalania wartosci step size.

    Dodano po 17 [minuty]:

    UPDATE, UPDATE.

    d(n) = (ss(n)*B2)+(ss(n)/2*B1)+(ss(n)/4*BO)+(ss(n)/8)
    if (B3 = 1) then
    d(n) = d(n) * (-1)
    X(n) = X(n-1) + d(n)

    to chyba mozna przetłumaczyć na cos takiego:

    if B3=1 then
    X(n)=X(n-1) -d(n)
    else
    X(n)=X(n-1)-d(n)
    end if

    B0..B3 to są wejsciowe próbki zapisanego sygnału.
    B3 jak widac to bit znaku i jak jest 1 to minus.
    SS(n) to jest ten step size co pytałem wcześniej

    X(n) to już gotowa wartość wyjściowa.

    Mam wrażenie ze ten ss(n) to jest poprostu współczynnik "wagi" poszczególnego bitu - to by tłumaczyło adaptive?
  • Computer ControlsComputer Controls
  • #34
    bajk
    Poziom 12  
    Próbki audio zaczynają się jak normalnym pliku wav (nagłówek i potem dane) tyle że zamiast 0x01 w "data format code, 1 = PCM" jest wpisana wartość 0x11.
    Wszystko jest jak w pdfie, proponuję przejżeć otwarty plik i porównać z www.tdt.com/T2Support/technical_notes/tn0132.pdf <- wszystko co trzeba odnośnie nagłówka w środku.
  • #35
    szymtro
    Poziom 30  
    OK ustaliłem cos wiecej.
    Otóż nie jest to takie proste jak tylko dodawanie i odejmowanie. Ten step size (troche zła nazwa ale o tym dalej) to jest tak naprawdę rozpiętość dla następnej próbki. Tu mamy 4 bity z tym ze jeden to znak tak więc trzy bity. Trzy bity to max 7 tak wiec mało i konstruktorzy o tym wiedzieli. Dlatego wprowadzony jest tzw step size który określa maksymalną rozpietosć dla następnego kroku. Rozpietość jest liczona na podstawie poprzednich wartości próbek)
    W ten sposób jezeli do tej pory dźwiek zmienił sie mało to step size też bedzi wyliczony mały a co za tym idzie maksymalny przyrost też bedzi emalutki - a więc powolnie zmieniający sie dźwięk będzie odtwarzany stosunkowo dokładnie. Ale zamieszałem.

    Przedstawione powyżej równanie (na d(n)) jest niczym innym jak skalowanie. W pdf'ie podaja że wartość step size mozna ustalać w tablicy dwuwymiarowej (albo pewnie dwóch tablicach jednowymiarowych - coi było by prostsze w asm)

    Jakaś sobie tam wyliczona wartość ss(n) jest podzielona na 4 części:
    ss(n)
    ss(n)/2
    ss(n)/4
    ss(n)/8
    narazie prosto bo to przesuwanie o jeden bit w prawo
    i teraz jezeli np B2 (bit 3 w próbce) jest = 1 to doliczamy wartość ss(n)
    następnie jeżeli B1=1 to doliczamy jeszcze ss(n)/2
    jezeli B0 = 1 to dodajemy jeszcze ss(n)/4
    i na końcu dodajemy zawsze wartość ss(n)/8

    W ten sposób uzyskaliśmy jakąs wartość która bedzie odpowiadała kolejnemu przyrostowi/spadkowi sygnału na wyjściu
    B3 (bit znaku) określa natomiast czy dodajemy wyliczone d(n) do porzedniej zdekodowanej wartości czy odejmujemy.

    Narazie proste do obliczeń ale niestety strasznie "dociąży" uC.

    Do tego dochodzi jeszcze obliczanie samego ss(n)
    W nocie jest jakiś tam wzór ss(n+1)=ss(n)*1.1M(L(n))
    Tego za bardzo nie rozumiem ale jezeli tam jest mnożenie wartości z przecinkiem to lipa. I nie chodzi tu wcale o samo dzielenie tylko o zapis samego zera w systemie ułamkowym komputerów (ćwiczenia z matlab vs mathematica vs mathcad - ci co mieli wiedzą o co chodzi)

    Jak widać codec niby prosty ale tak naprawdę dosć skomplikowany.

    Czy ktoś mógłby jeszcze przedstawić to co napisali w tej nocie a propos odczytu ss(n) z tablicy - czytałem to juz 4 razy (pomimo że znam techniczny angielski) ale jakoś ni emogę tego zrozumieć.
  • #36
    shg
    Specjalista techniki cyfrowej
    bajk napisał:
    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.

    Vorbis wymaga tylko niewiele mniej mocy obliczeniowej niż mp3, a czasem i więcej (też niewiele), zależy od architektury i stopnia optymalizacji kodu. Ogólnie są to formaty dosć podobne, różnią się kilkoma szczegółami, które jak się okazuje mają dość istotny wpływ na jakość sygnału.

    bajk napisał:
    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?

    Zauważ, że wymagania ARMa dla strumienia 320kbit/s i 128kbit/s różnią się nieznacznie: http://www.spiritdsp.com/mp3_arm.html
    A to dlatego, że jedyna różnica jest w początkowym etapie dekodowania na który skłądają się: obsługa ramek, dekompresjia kodowania Huffmana no i w zasadzie tyle. Dalej strumienie o różnym natężeniu wejściowym nie róznią się kompletnie niczym z punktu widzenia CPU (de facto po tych etapach natężenie strumienia jest zależne tylko od częstotliwości próbkowania). Niestety dopiero kolejne etapy wymagają znacznej części mocy obliczeniowej 'zużywanej' w procesie dekodowania. Z najbardziej 'procesorożernych': Rekwantyzacja - 16.9% mocy obliczeniowej, IMDCT - 17.9%, subband synthesis (synteza podpasmowa?) 58.2%.
    Istnieje rozwiązanie tego problemu, ale niestety tylko połowiczne. Polega ono na odrzuceniu informacji odpowiadających wyższym cząstotliwościom, co niestety wiąże się z pogorszeniem jakości. Wiele dekoderów ma taką opcję (1/2 i 1/4 szerokości pasma), ale zysk nie jest aż tak duży.

    Pojedynczy AVR nie da rady chociązby też z tego względu, że jest ośmiobitowy, a mp3 jest formatem 'z natury' szesnastobitowym i większość operacji wymaga przetwarzania liczb szesnastobitowych. Trzeba by go było bardzo podkręcić, myślę, ze nawet powyżej 50MHz (przy obniżonej jakości), co jest raczej niewykonalne.

    Do ADPCM AVR z pewnością będzie wystarczający, chociaż nie wiem, jak będzie to wyglądało przy wyższej częstotliwości próbkowania. Mam w planach kodek ADPCM na AVR, ale 8 bit 8kHz, a właściwie to teraz się zastanawiam, bo ma być on połączony z modemem i nie wiem, czy obu urządzeń nie zrobić na jednym procu (ARM), ale to raczej odległa przyszłość. Narazie 'trawię' mp3.
  • #37
    bajk
    Poziom 12  
    No, za dekodowanie mp3 na AVR bym się nawet nie brał.
    Kiedy będę mieć troche więcej wolnego czasu, zajmę się dokładniej adpcm.
    Sprawdziłem też jakość po konwersji z oryginalnej płyty CD i jest ona oczywiście dużo lepsza, natomiast po przerobieniu mp3jki jakość spada jeszcze bardziej i to samo stanie się po konwersji z mp3 do ogg vorbis chociaż w mniejszym stopniu, więc lepszym rozwiązanim byłoby samo mp3.
  • #38
    szymtro
    Poziom 30  
    Odświerzamy gdyż temat jest naprawdę interesujacy aby go "pogrzebać"

    Czy komuś już coś zadziałało?
  • #39
    bajk
    Poziom 12  
    Po przejżeniu i przeczytaniu części dokumentacji vorbisa, troche się przestraszyłem.
    Mi samemu nie uda się zrobić dekodera na uC, za mało rozumiem te ich wszystkie pomysły z pdfa, chociaż jest tam napisane że dekompresja jest prostsza od mp3, ale potrzebuje więcej `working memory`.

    A może by tak stworzyc własny codec audio, specjalnie dla uC, aby każdy mógł na swoim avrku czy picu dekodować w miare dobrej jakości muzykę. Nie ma przecież żadnego takiego wypełniającego głęboką lukę pomiędzy jakością/rozmiarem rzędu ogg vorbis czy mp3, a zwykłym adpcm) Algorytm miałby być bardzo prosty, ale jednocześnie nie tracący na jakości. Głównym sposobem na jej zachowanie było by wykorzystanie kilku metod prostej dekompresji (tak aby w danym momencie wykorzystać zalety xyz* algorytmu) np.: w jednej ramce danych byłby zastosowany algorytm xyz1 bo taki pozwalał by na najwierniejsze odwzorowanie oryginalnego przebiegu, w kolejnej ramce byłby użyty algorytm xyz2, bo taki własnie pozzwolił by na uzyskanie najbliższego oryginałowi rezultatu, w porównaniu z pozostałymi. Długość ramki zmienna do ok. 512B lub ew. do 1024B żeby nie tracić za dużo pamięci na synchro.
    Głównym ułatwieniem było by zrzucenie najtrudniejszego elementu na enkoder. Od niego zależało by, który algorytm użyć, tak aby był on najbardziej optymalny dla danej ramki.
    Mówiąc o tych prostych algorytmach mam na myśli wykorzystywanie na przemian np.: adpcm, lub jakichś podobnych, które możnaby opracować, tak aby były proste, a jednocześnie aby pozwalały na zenkodowanie w sposób jak najlepszy pewnego rodzaju sygnału.
    Główne założenia:
    -rozmiar pliku nie większy niż 2*rozmiar_adekwatnego_mp3,
    -wykorzystanie zalet kilku algorytmów w zależności od przebiegu próbek w danej chwili, aby dojść najbliżej oryginału, (czyli aby najlepiej brzmiało)
    -rozmiar ramki danych zmienny, w każdej odpowiedni bajt lub dwa informował by, ile jeszcze zostało do początku następnej ramki (czyli jak długo xyz* będzie najlepszym, tak długo będzie wykorzystywany), natomiast nr. użytego algorytmu to kwestia 2,3 dodatkowych bitów
    -jakość, która nie dochodzi do poziomu ogg vorbis (chociaż może się uda :>), ale jest bardzo opłacalna jak na ok. 9MB/plik przy tym stopniu skomplikowania
    Na koniec, sam bitstream można by jeszcze potraktować jakąś kompresją bezstratną jak np. huffmana, ale nie chcę przesadzać.
    Co o tym sądzicie ?
  • #40
    szymtro
    Poziom 30  
    Pomysł jest niezły ma tylko ale. Sprawdzałeś w praktyce jak atmega z maksymalnym kwarcem rzadzi sobie z jaka kolwiek obróbką danych? U mnie na kwarcy 14,7456 wychodzi to dosć kiepsko i jak patrzę na te potrzebne prędkosci 44100 (lub 48000) to niestetu obciażenie będzie dosć duże juz samym wysyłaniem próbek do przetwornika (I2S). Zostaje bardzo malutko na jakiekolwiek inne operacje.

    Czy ktoś ume już powiedzieć jak zastowosować ten odczyt tablicowy wartości SS(n). Żadne inne operacje (typu mnożenie przez 11 i dzielenie przez 10) nie wchodzą w grę - to są wartosci 16 bitowe i naprawdę nie ma tyle czasu, a co dopiero jak to ma być stereo.

    Mozna by sie pokusić o napisanie własnego kodowania ale to chyba nie jest aż takie proste wymyślić coś co dobrze kompresuje, bezstranie i nie wymaga nie wiadomo jakiego procesora? (szybki, bezstratny, mało miejsca) czcesz mieć trzy urządzenia?

    Dodano po 1 [godziny] 14 [minuty]:

    W załaczniku dwa pliki wave 8000 próbek na sekundę, 8 bitów, unsigned(tzn bez znaku ale...). Trzeba tylko skasowac .rar na końcu gdyż na elektrodzie nie mozna umieszczać plików wav. Jeden (pusty) zawiera wygenerowany plik który jest pusty i próbki danych to same 80h. Drugi to zrzut z mikrofonu (szum a raczej buczenie) i tam widać co siezgrało. Oba mozna odtworzyć. Ilosć próbek to 8000 (1F40h) czyli 1 sekunda długości. Pliki dobre do zobrazowania co gdzie jest w pliku. Dane zaczynaja siew komórkach 2Ch i kończą siew komórkach 1F6Bh. Reszta to opis wygenerowany przez program.
    To jest jako zwykły PCM ale jak kazdy sobie przerobi to do 4 bitowego ADPCM to już będzie widac rżnice. Dla pierwszego pliku będą same zera a dla drugiego - no właśnie ....
  • #41
    bajk
    Poziom 12  
    Rzeczywiście nawet przy 20MHz dla 44100Hz na każdą próbkę pozostają ok. 453 instrukcje/cykle. O samym pogodzeniu dekompresji z resztą myślałem w ten sposób: jakieś tam operacje mniej ważne będą sobie wykonywane w nieskończonej pętli czyli np. i2s i obsługa mmc, natomiast sama dekompresja wywoływana cyklicznie przez timer i póki nie zostanie skończona dekompresja reszta będzie miała spokój. Wszystko było by pogodzone, ale to i tak raczej za mało.

    Wymyślanie własnego codeca to fajna sprawa, przede wszystkim wiadomo by było dokładnie o co chodzi, czyli odpada ślęczenie nad pdfami (przynajmniej dla twórców, którzy wiedzą o co chodzi najlepiej). Sam algorytm miałby być prostszy, więc teoretycznie urządzenia przenośne działały by dłużej (mniejsza wykorzystana moc obliczeniowa).
    Nie chodziło mi o dokładnie „bezstratny”, ale dobrej jakości natomiast zenkodowany bitstream byłby jeszcze dodatkowo skompresowany, ale to można sobie odpuścić.
    Najwięcej miejsca można zaoszczędzić na takich rzeczach jak m.in. początkowa i końcowa cisza czyli zazwyczaj wiele zer zastąpione liczbą tych zer lub nawet nie zera ale inne takie same wartości. Czasem pod koniec lub na początku zdarzają się naprzemian 0xFFFF i np. 0x0100 – a więc wystarczyło by tylko zapamiętać „sposób, a nie całą formułkę”; nawet ciąg siedmiu 0xFF zastąpiony 3 bajtami (długość ramki, rodzaj zastosowanego algorytmu i kawałek jakiejś zawsze stałej wartości) – nr algorytmu mówi o tej wartości, a długość ramki o długości ciągu i dalej następna ramka, czyli z 16bitów*stereo*długość_ciągu skrócona tylko do 3,4 bajtów. Poza za tym różne poudziwniane algorytmy typu „differential” dopasowane do danej sytuacji tak, aby różnica była jedynie kwestią odstępstwa o jeden lub dwa od oryginału, dzięki wybraniu najkorzystniejszej drogi.
    Najtrudniejszą częścią zadania było by zenkodowanie danych. Dekoder byłby śmiesznie prosty. Myślę, że metoda sprawdzania strat po każdym sposobie kompresji -> (enkoder porównywał by oryginał z przerobioną wartością i każdą różnicę zapamiętywałby, a potem wybierał najkorzystniejszą przeliczoną średnią wartość odstępstwa na próbke) była by chyba najlepsza, chociaż nie wiem czy da to podobne efekty jak testy odsłuchowe.s

    Główne założenie to zastąpienie jednego sposobu kompresji z wieloma algorytmami, wieloma sposobami z jednym algorytmem co najważniejsze dającym najlepsze rezultaty.

    Kompresja taka wymagająca mniej mocy obliczeniowej, a dająca dobre rezultaty co do jakości, nawet zrobiona na ARMie była by już sukcesem. Oczywiście wszystko dostępne dla wszystkich za darmo czyli jak vorbis, tylko prostsze. Czekam więc na sugestie/pomysły i ewentualnie jeżeli jest ktoś na tak to pozostaje mi zadać pytanie „Czy ktoś się dołącza do projektu?”
  • #42
    UDMA
    Poziom 16  
    bajk napisał:
    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).


    Zainteresuj się HelixPlayer (hxplay). Po pewnej wiwisekcji da się ten kod bez problemu uruchomić na LPC2106 ;)
  • #43
    bajk
    Poziom 12  
    Właściwie to zrezygnuje ze standartowego mp3, na rzecz opracowania nowego darmowego kodeka specjalnie dla uC.
    W sumie to bardzo interesujący pomysł, nie sądzicie? Pierwszy codec stworzony tak, aby prawie cały trud przy kodowaniu dźwięku przenieść na encoder, natomiast decoder odtwarzał by tylko przebieg z informacji typu prostych poleceń kilku bitowych zawartych w bitstreamie lub z dodatkowych danych które były by dodawane zależnie od przypadku, tak aby najwyższa jakość dźwięku przy niewielkich nakładach była uzyskana.
    Całość oczywiście bez zbędnych bitów, a najczęściej powtarzające się struktury zminimalizowane do postaci kilku bitów, tak jak w huffmanie, ramki danych jeżeli występują to powinny być zmienne tak, aby w określonej części danych typ ramki był najodpowiedniejsze - najefektowniejszy, jeżeli chodzi o rezultaty(jakość).

    Ogólnie chodzi o to, żeby codec był inteligentny, a nie jak to bywa w przypadku m.in. ADPCM gdzie masowo są zapisywane same zera na początku, a całość ‘wewnętrzna’ jest enkodowana jak leci, jednym nie zawsze korzystnym algorytmem. Z resztą w mp3 jest podobnie, wiele bajtów/bitów jest tam marnotrawionych głównie w headierze gdzie znajdują się informacje praktycznie zbędne (a dla każdej ramki potrzebne oddzielnie razy ilość ramek (około 8tyś)). Z algorytmem jest podobnie, encoder leci wszystko tak samo, jak mu napisano, ale jakoś nikt nie zauważył, że łatwiej jest zawsze użyć kilku algorytmów zoptymalizowanych dla każdej sytuacji niż męczyć jeden komplikując go, co nie daje i tak najlepszych efektów. Użycie kilku algorytmów jest kwestią dodania tylko kilku bitów do każdej ramki, zamiast podawania takich informacji jak częstotliwość itp. ma to swoje zalety, ale w normalnym pliku z muzyką jest niepotrzebne.
    A właśnie taki codec chciałbym stworzyć – tylko niezbędna ilość bitów (także zmienna w zależności od okoliczności) w headierach, wiele algorytmów dopasowanych do prawie każdego przebiegu, przy zmiennej długości ramek.

    Otwieram więc oficjalnie projekt kryptonim ‘codec for uC”. Czy jest ktoś chętny do współpracy ? Byłby to wielki krok dla hobbystycznych aplikacji multimedialnych. Dobrze opracowany i rozpowszechniony, nabrał by znaczenia wypełniając lukę między wav, adpcm, a mp3 i vorbisem. Każdego chętnego do współpracy zapraszam, wspólnie uda się lepiej opracować naprawdę porządny codec. W końcu pierwszy taki na świecie.

    Mateusz
  • #44
    LordBlick
    VIP Zasłużony dla elektroda
    1. Już zacząłeś, czy to pomysł z serii "weźmy się szczepmy i zróbcie cud" ?
    2. Opis działu "Mikrokontrolery" :
    Cytat:
    Popularne mikrokontrolery serii PIC, AVR, '51 oraz ich sposoby programowania. Programowanie układów PLD, SPLD, GAL, CPLD, FPGA także ASIC
    Czyli zagadnienia praktyczne dotyczące programowania i budowy w/w układów. Tymczasem dyskusja dotyczy bardziej algorytmu, przenoszę do "Programowanie Ogólnie".
  • #45
    bajk
    Poziom 12  
    To pomysł z serii "weźmy się zczepmy i zróbmy coś fajnego" nie chcę się nikim wyręczać. Jak nikt się tym nie zainteresuję to sobie po prostu siąde cicho w domu i zaczne coś pisać, a jak skończe to może opublikuję. Jeżeli chodzi o współpracę to wiem, że sam wszystkiego najlepiej nie zrobię (co najwyżej tak po swojemu), a projekt będzie doskonalszy kiedy znajdzie się ktoś kto doda swój pomysł, podzieli się doświadczeniem i wykorzysta trochę swojej wiedzy. Każdy taki wkład dużo pomaga, bo przecież nie ma duzo osób, które są specjalistami od wszystkiego, poza tym większość już obmyślałem.
    Jak nikt chętny się nie znajdzie do współpracy, to zacznę swoje pomysły skromnie realizować sam.
  • #46
    upanie
    Poziom 22  
    Witam.
    Poczytałem sobie posty w tym wątku i mam takie uwagi.
    MP3 na AVR nie ma szans. Obniżenie BR nic nie da. ARM ma inną architekturę i specjalne instrukcje, które wspomagają algorytmy dekompresji np. mnożenie i mnożenie MAC. Są ARM-y z FPU i DSP ale to ARM9.
    Zaprojektowanie algorytmu, o którym mówicie może się okazać bezcelowe (czyt. dalej). Raczej nikt chyba na poważnie się tym nie zajmuje.
    Z tego co zrozumiałem chcecie zrobić jakiś prosty i tani plejerek empetrójek.
    Tworzenie nowego algorytmu to nie prosta sprawa i napewno nie tania z punktu widzenia czasu na to poświęconego.
    Jak użyjecie ARM7 60 MHZ (np. LPC2xxx, AT91SAM7xxx lub STR7xxx) to macie gotowe źródła, które popylają zaledwie na 20 do 30 MHZ i kilkanaście kilo RAM-u. Pozostaje masa megaherców RAM-u i FLASH-a do użycia. Efekt jest taki, że koszt takiego rozwiązania jest niezwykle niski. YAMPP się może schować bo poza VS1001 musi tam być dodatkowy procek, a tu mamy jeden procek, w którym dekodujem MP3 i robimy wszystkie pozostałe czynności i dalej jest masa możliwości. Teraz UWAGA! VS1001 + AVR to ponad 100 zł a ARM (AT91SAM7S256 -64 KB RAM i 256 KB FLASH) to 37 zł (z VATem) a dostępność tych procków cudowna. Acha no i takie rzeczy jak transmisja danych do DAC-a czy z zewnętrznego flasha to czynności, które można zrealizować za pomocą bogatyc peryferiów. Są takie ARM-y, które mają wbudowany interfejs I2S bądź uniwersalne interfejsy szeregowe. Poprostu jest w czym wybierać. No i najważniejsze, że te procki są tanie i coraz tańsze.
    A co do programowania no to łątwiej się nie da. Jeśli chcecie programować w ASM to macie do dyspozycji tylko ok. 35 instrukcji!!!
    I wszystko się da zrobić (jest między innymi mnożenie ;) ). Są proste tryby adresowania i przejrzysta architektura. Jeśli chodzi o C to nie ma o czym mówić. Stado darmowych narzędzi i lektury. Wystarczy znać język (no tego się nie da przeskoczyć) ale jak się zna ASM to droga jest prosta.
    EP teraz robi kurs C, warto się zapoznać.
    Padło też hasło: LINUX. Linux tak ale na procku, który ma interfejs do zewnętrznej pamięci. A to już nie ta klasa projektowania sprzętu bo potrzebna jest szybka pamięć zewnętrzna (i dużo jej trzeba) a to powoduje, że wymagania na płytkę rosną w zastraszjącym tempie. Bardzo szybko się okazuje, że aby cały układ był rozsądnie mały to trzeba zrobić płytkę 4-ro warstwową. No a tego już nie można nazwać rozwiązaniem prostym ani tym bardziej tanim.
    Ja pierdziu to sobie popisałem. W każdym razie powodzenia panowie.
    Jak zdecydujecie się na ARM-a to mogę pomóc w tym i owym. Mam z tymi prockami jakieś doświadczenie (bawiłem się nimi prywatnie i w domu).
    Dobra kończę bo się qrczę rozpisałem na maxa.

    Upanie.[/url]

    Dodano po 13 [minuty]:

    > Prywatnie i w domu
    To żem wykombinował :) Chodziło mi oczywiście, że w firmie i w domu. Firma, w której pracuję wykorzystuje różne procki np. PPC, AVR, ARM. Z doświadczenia wiem, że należy unikać rozwiązań skomplikowanych z punktu widzenia programistycznego. Jak się coś da zrobić łatwo w sprzęcie to tak TRZEBA to zrobić.

    PS. Może się komuś narażę ale PHILIPS to robi dobre depilatory a nie procesory. Używaliśmy serii LPC2xxx i takich problemów jak z nimi nie mieliśmy z żadnymi innymi prockami żadnej innej firmy. Masa różnych drobnych problemów, które skutecznie hamują i zniechęcają. Poza tym łżą w dokumentacji co powoduje przeróbki w sprzęcie. Dla porównania: wszystkie (kilkanaście) prototypowe płytki z AVR-ami wdrożone zostały do produkcji bez ŻADNYCH zmian, w przypadku LPC dwie płytki prototypowe (LPC2106 i LPC2136) musiały być modyfikowane ze względu na nieścisłości i kłamstwa w dokumentacji.

    upanie
  • #47
    bajk
    Poziom 12  
    Wobec tego mam pytanie, dlaczego do dekompresji ARMy Philipsa i Atmela potrzebują dużo większego taktowania (rzędu ponad 70MHz) skoro biblioteki helixa potrzebują około 20-30MHz? Przecież ten nadmiar mocy obliczeniowej nie jest tak niezbędny do obsługi pamięci, systemu plików itp. A wraz z tym idzie w parze zużycie energi.

    A swoją drogą to czemu nie własny algorytm, wystarczy tylko MDCT ze wzoru, uproszczenie tego co człowiek nie usłyszy i potem jakaś kompresja bezstratna np. jak w ATRACu, tylko żeby brzmiało chciaż dobrze.
  • #48
    shg
    Specjalista techniki cyfrowej
    bajk napisał:
    Wobec tego mam pytanie, dlaczego do dekompresji ARMy Philipsa i Atmela potrzebują dużo większego taktowania (rzędu ponad 70MHz) skoro biblioteki helixa potrzebują około 20-30MHz?

    Pewnie chodzi o kod na podstawie biblioteki mad. Jest on pisany bardziej pod kątem jakości niż wydajności. Dla ARMów tylko IMDCT jest napisana w asemblerze, reszta jest w C.
    Parę optymalizacji tu i tam, odrobinę niższa jakość (mad liczy na 32 bitach i "wypluwa" 24 bitowe próbki) i 30MHz będzie wystarczające. Czasem wystarczy po prostu kod w C przepisać "żywcem" na asembler żeby uzyskać procedurę działającą dwa razy szybciej.
  • #49
    upanie
    Poziom 22  
    Helix na swojej stronie podaje, że te 30 MHz to dla armualtora z zero-wait-state memory. Jak kod w atmelu czy philipsie chodzi z flasha to niestety tak nie będzie. Philps: flash chodzi na 20MHz ale jednocześnie są czytane 4 słowa 32-bitowe. No to pół biedy, ale jak kod zacznie skakać (if-y) to mamy problem. W najgorszej sytuacji 3 razy wolniej. Zdrugiej strony ARM-y wykonują instrukcje warunkowe czyli nie czyszczą pipeline-a i czytają w sposób ciągły z pamięci, ale nie w przypadku "dużych" if-ów. Jednym słowem wszytsko jest pomiszane i może dać 60 MHz. Nie ma się czym przejmować tylko zerknąć na kod i zobaczyć czy jest on zoptymalizowany pod ARM-y. Jak się korzysta z instrukcji typu MAC w ARM-ach to nawet kolejność wywołania tych instrukcji ma wpływ na wydajność. Helix co prawda pisze, że zoptymalizował to na ARM, ale spojrzeć nie zawdzi;) A tak swoją szosą to trzeba to poprostu sprawdzić doświadczalnie i już. Ja to zrobię u siebie na AT91SAM7S256 i zamieszczę swoje wyniki. A tak swoją szosą na forum yahoo napotkałem na maila gościa, który odpalił kod na lpc2138 i 27 MHz ale to raczej ściema bo lpc2138 ma tylko 32KB RAM-u.

    upanie
  • #50
    shg
    Specjalista techniki cyfrowej
    upanie napisał:
    A tak swoją szosą na forum yahoo napotkałem na maila gościa, który odpalił kod na lpc2138 i 27 MHz ale to raczej ściema bo lpc2138 ma tylko 32KB RAM-u.


    Eeeee, czemu? spokojnie wystarczy. Tylko kwestia optymalizacji, dekodery 'komputerowe' potrzebują więcej, ale to raczej tylko dlatego, że programiści chcieli sobie dość znacząco uprościć sprawę, jakby zrobić wszystko maksymalnie 'in-place' to myślę, że nawet poniżej 16kB da się zejść.

    Co do wait-states to też fakt, potrafią zepsuć całą zabawę, ale wpadłem na taki pomysł. O ile się nie mylę, to ARM potrafi wykonywać program z RAMu, w Atmelach dostęp do ramu nie potrzebuje żadnych wait-states niezależnie od częstotliwości zegara, więc gdyby tak umieścić kilka bardziej krytycznych fragmentów w RAMie... Dużo tego nie będzie, myślę że kilka kB, bo w sumie dość znaczna część 'objętości' dekodera to wszystkie procedury sklejające do kupy "klocki" i ogólnie obsługa ramek itd.

    Jeszcze takie pytanko, czy komuś udało się w ogóle ściągnąć kod helixa? probowałem go z CVS pobrać (jestem zarejestrowany), ale za każdym razem jakieś błędy wywalało, o ile dobrze pamiętam, to Permission denied między innymi. Postępowałem według jakiejś zamieszczonej tam instrukcji, ba a nawet dwóch i próbowałem też kombinować sam, ale bez rezultatów :/

    A no i znalazłem jeszcze jedno źródło źródeł :]
    IPP - Intel Performance Primitives (chyba.. :P) ze strony intela mozna za free zassać, jest tam między innymi dekoder na stałym przecinku.

    Zresztą widzę dość spore kłopoty z mp3 i zaczynam bardzo poważnie rozważać uruchomienie w pierwszej kolejności Tremora (dekoder Vorbis).
  • #51
    upanie
    Poziom 22  
    Niedopowiedziałem chyba, że ten gościu odpalił kod helix-a, a oni twierdzą, że dekoder potrzenuke 37KB RAM-u a lpc2138 ma 32 KB. Dlatego powiedziałem, że to ściema ;)

    Co do wkładania kawałków dekodera do ramu to pomysł jest ok. Sam też na to wpadłem, ale przystopował mnie rozmiar RAM-u. Bo 37KB + dane wejściwe + dane wyjściowe to da jakiś niezły rozmiar, a do tego dekoder... No ale można spróbować, najwyżej nie zostanie nic miejsca na żadną inną funkcjonalność. Ale mimo wszystko nawet gdyby ten procek miał tylko dekodować mp3 i nic więcej to i tak jest dobra cena (37zł) za scalaka dekodujacego mp3.
    Na początek można spróbować przewalić te stada tablic, które są umieszczone we FLASH do RAM-u co by przyspieszyć odczyt ich wartości, ale ich niestety jest sporo. Taka operacja daje dwie korzyści: 1) szybszy odczyt wartości tablic 2) nie rozwala prefetch-buffer'a bo odczytywany jest w miarę sekwencyjnie tylko kod.

    Ja ściągnąłem helix-a z http://www.mikrocontroller.net/attachment.php/195202/mp3dec-test.tar.gz

    Tremor ? mógłbyś kilka słów trzasnąć na ten temat?

    Tak przy okazji. Kilka wiadaomości wcześniej ktoś wpadł na pomysł dekodowania Ogg-ów (Vorbis). Otóż nie mam pewności ale z tego co wiem to trzeba nieziemsko (przesadzam) mocy do dekodowania tego formatu :(
    Z drugiej jednak strony, kiedyś widziałem w necie firmę, która robi przenośne odtwarzacze. Podają dosyć dokładną specyfikację techniczną swoich cudaków i okazuje się, że na arm7 dekodują bez roblemów mp3 i różne takie, a nawet jakiś czas temu odpalili Ogg-i :D ale mają zewnętrzny RAM.

    upanie

    Dodano po 1 [godziny] 34 [minuty]:

    Nie chcę Cię zniechęcać ale popatrz na te linki
    http://linux.gda.pl/pub/finearch.com/OggVorbisProductSummaryE.pdf
    http://linux.gda.pl/pub/finearch.com/PressRelease20030715E-2.pdf

    Takiej mocy chyba nie wyciśniesz z ARM7 raczej trzeba dziewiątki i więcej MHz.

    upanie
  • #52
    UDMA
    Poziom 16  
    upanie napisał:


    Komuś udało się to skompilować?
    Mam błędy:
    mp3dec.c:5:25: error: lpc/lpc210x.h: No such file or directory
    mp3dec.c:6:27: error: lpc/dev_cntrl.h: No such file or directory
    mp3dec.c:7:27: error: lpc/lpc_ioctl.h: No such file or directory
    mp3dec.c:14: error: 'com1' undeclared here (not in a function)

    Dodano po 19 [minuty]:

    shg napisał:

    Jeszcze takie pytanko, czy komuś udało się w ogóle ściągnąć kod helixa? probowałem go z CVS pobrać (jestem zarejestrowany), ale za każdym razem jakieś błędy wywalało, o ile dobrze pamiętam, to Permission denied między innymi. Postępowałem według jakiejś zamieszczonej tam instrukcji, ba a nawet dwóch i próbowałem też kombinować sam, ale bez rezultatów :/


    Można nie korzystać z CVS tylko ręcznie ściągnąć pliki z przeglądarki:
    https://helixcommunity.org/viewcvs/cgi/viewcvs.cgi/datatype/mp3/codec/fixpt/
  • #53
    upanie
    Poziom 22  
    Skompilowałem to po wyeliminowaniu błędów. Pochodzą tylko i wyłącznie z funkcji specyficznych dla lpc210x.

    Z tego co mi się udało zaobserwować z kompilacji to RAM-u potrzeba 28 KB w tym: bufor na dane wyjściowe i cała pamięć alokowana przez dekoder. Nie wiem ile będzie zajmował stos.
    Teraz muszę to dostosować do AT91SAM7S256 i zobaczę co będzie.

    upanie[/url]
  • #54
    piotr_go
    Konstruktor DIY elektronika
    witam

    przyglądam sie temu tematowi od dłuższego czasu

    ja natomiast mam inny pomysł na player

    procek w FPGA (MicroBlaze albo coś w tym stylu) do tego pamięć sdram/ddr, dysk/cd-rom, lcd.......
    +spore możliwości
    +odpada problem z projektowaniem pcb :)
    myśle że jego moc wystarczy do dekodowania mp3, ogg i paru innych..... może nawet jakiś linux?

    co o tym myślicie?

    pozdro piotrek
  • #55
    UDMA
    Poziom 16  
    piotr_go napisał:

    ja natomiast mam inny pomysł na player
    procesor w FPGA (MicroBlaze albo coś w tym stylu) do tego pamięć sdram/ddr, dysk/cd-rom, lcd.......
    +spore możliwości
    +odpada problem z projektowaniem pcb :)
    myśle że jego moc wystarczy do dekodowania mp3, ogg i paru innych..... może nawet jakiś linux?


    Raczej science fiction. Widziałeś gdzieś darmowy dekoder MP3/Ogg w VHDL/Verilog? Jaka jest cena takiego układu FPGA? W tym topiku rozważa się jak najtańsze rozwiązania playera.
    Po za tym jaki sens ma użycie maszyny sekwencyjnej (procesora) w FPGA jeśli można w układzie programowalnym zrealizować dekoder jako wiele _równolegle_ działających bloków.
  • #56
    upanie
    Poziom 22  
    FPGA hmm...
    Są plusy dodatnie i ujemne takiego rozwiązania.
    Wadą jest napewno koszt. MicroBlaze potrzebuje dużo zasobów. W spartanie 3 xc3s200 można go zrealizować ale nic poza nim. Wyższe modele to już niezła kasa. Aby zrealizować dekoder trzeba znać bardzo dobrze vhdl-a i znać doskonale kodeki. Jak chcesz podłączyć SDRAM to do tego jeszcze kontroler. Ten FPGA musi naprawdę niezły.
    Plus dodatni to kawał niezłej zabawo/nauki ;)
    A płytkę to zawsze trzeba zrobić, natomiast Twój pomysł nie wróży prostej konstrukcji pcb :)

    Ale pomysł jest OK.

    upanie[/url]
  • #57
    UDMA
    Poziom 16  
    upanie napisał:
    Skompilowałem to po wyeliminowaniu błędów. Pochodzą tylko i wyłącznie z funkcji specyficznych dla lpc210x.

    Z tego co mi się udało zaobserwować z kompilacji to RAM-u potrzeba 28 KB w tym: bufor na dane wyjściowe i cała pamięć alokowana przez dekoder. Nie wiem ile będzie zajmował stos.
    [/url]


    Jak określiłeś zajętość RAM, przez analizę kodu czy są jakieś inne metody? Dekoder używa malloc() w buffers.c więc na etapie kompilacji nic nie wiadomo ile kod zajmie RAM. Ja wywaliłem dynamiczną allokację z buffers.c i zrobiłem wszystkie bufory i struktury jako static i w statystykach kompilacji wyszło 28 KB .bss dla całego kodu (bez obsługi sprzętu).
  • #58
    upanie
    Poziom 22  
    No i właśnie o to chodzi.
    Alokowanie za pomocą malloca jest tylko w jednym pliku.
    Podmieniłeś na statyczne bufory i wyszło ok. Ja jeszcze wywaliłem bufor na dane wyjściowe na zmienną globalną i wynik gotowy. Jedyny znak zapytania to stos. Tu można się tylko przyjrzeć kodowi ale w tym przypadku praktycznie nie do obczajenia.

    To ile zajmuje kod ramu i flasha pokazuje program arm-elf-size ale w makefile-u, o którym mówimy jest wszystko zrobione i na końcu kompilacji wszystko się wyświetla. Ram to .data i .bss pozostałe sekcje to flash. W pliku mp3dec.map można zobaczyć co ile dokładnie zjmuje.

    upanie
  • #59
    piotr_go
    Konstruktor DIY elektronika
    Cytat:
    Raczej science fiction. Widziałeś gdzieś darmowy dekoder MP3/Ogg w VHDL/Verilog? Jaka jest cena takiego układu FPGA? W tym topiku rozważa się jak najtańsze rozwiązania playera.

    W vhdlu to dekodowania nie zamierzałem robić, myślałem raczej o softwarowym na microblaze. Co do ceny to i tak będzie niższa niż CPU + dekoder + sterownik lcd + .......

    Cytat:
    Jak chcesz podłączyć SDRAM to do tego jeszcze kontroler.

    Tak sie składa że nie, wszystko ma być zaprogramowane w fpga.

    Z procesorami na fpga nie miałem zbyt wiele do czynienia, narazie tylko sterowniki lcd i inne mniej skomplikowane układy. Ale od czegoś trzeba zacząć :)

    Cytat:
    A płytkę to zawsze trzeba zrobić, natomiast Twój pomysł nie wróży prostej konstrukcji pcb

    Ale wyprowadzenia FPGA moge sobie wybrać a to znacznie upraszcza projektowanie.
  • #60
    shg
    Specjalista techniki cyfrowej
    O Tremorze wiele nie ma, w sumie sie zdziwilem trochę, w każdym razie źródła są tu: http://xiph.org/vorbis/

    Tu jest co nieco o Tremorze:
    http://www.mp3-tech.org/programmer/docs/embedded_vorbis_thesis.pdf

    Z przeprowadzonych eksperymentów na procesorach Pentium I i Pentium II wynika, że Vorbis wymaga mniej więcej tyle samo mocy obliczeniowej co mp3. Ale w sumie togo nie można ot tak porównać. Nie wiem, jakie było zapotrzebowanie na pamięć obu dekoderów, podobnież nie wiem, czy któryś z nich był optymalizowany dla jakiejś architektury, czy wszystko kompilowane pod i386.

    Wracając do uruchamiania kodu z RAMu. Nawet jeżeli co druga instrukcja będzie pobierała dane z Flasha, to lepsze to niż wykonywanie z Flasha każdej instrukcji. Zresztą z tabel korzystają głównie dekoder Huffmana i rekwantyzacja. IMDCT wymaga dość małej tabeli, którą można by w ramie upchnąć, a filtry polifazowe chyba nie wymagają tabel wcale, te dwa ostatnie 'klocki' zużywają najwięcej CPU, czyli z nimi do RAMu, a reszta niech się wykonuje z Flasha.

    -------

    O i tak właśnie sobie doczytałem, że Helix jest oparty na wspomnianech przeze mnie procedurach IPP :]