Elektroda.pl
Elektroda.pl
X
CControls
Proszę, dodaj wyjątek 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 21 Maj 2006 19:30 18235 99
  • #61 21 Maj 2006 19:30
    upanie
    Poziom 21  

    Mówiąc o kontrolerze SDRAM miałem właśnie na myśli realizację w FPGA.
    Chodzi mi o to, że to musi być duuuży FPGA skoro tyle chcesz w nim upchać.
    W mojej firmie koledzy używali MicroBlaze ale to raczej nie jest demon szybkości dlatego raczej kiepsko będzie dekodować mp3. Jak już szaleć to możnaby trzasnąć najbardziej mocożerne procedury dekodowania właśnie w FPGA. Kontroler lcd można zrobić na małym fpga a nawet cpld np. CoolRunner za niewielkie pieniądze. Co do ceny to ja się rozglądałem kiedyś za xc3s200 w polsce i kosztują ok. 80 zł najtaniej. Ale do tego co Ty zamierzasz to ten scalak sie nie nadaje. Trzeba sporo większego. Ja kiedyś sprowadziłem kilka xc3s200 z Singapuru i wyszło mi z przesyłką ok 45 zeta za sztukę. Popieprzony jest nasz kraj :(
    Tak jako ciekawostkę mogę powiedzieć, że moja firma kupowała niedawno Virtex4 za jedyne 1100 dolców za sztukę!!! Ale te scalaki to mogą robić więcej niż się fizjonomom śniło ;)

    A co do Tremor to sobie zciągnąłem kod i może kiedyś popatrzę ale dalej w głowie mam zakodowane, że trzeba więcej mocy niż dla mp3.

    A ja w tej chwili mam inny problem. Nie mogą na swoim armie odpalić malloca. Problem z newlibem i nie wiem co zrobić. Coprawda do dekodera z helixa malloc nie jest konieczny ale jak "chłop żywemu nie przepuści..." :)

    upanie

  • CControls
  • #62 21 Maj 2006 22:22
    UDMA
    Poziom 16  

    upanie napisał:

    A ja w tej chwili mam inny problem. Nie mogą na swoim armie odpalić malloca. Problem z newlibem i nie wiem co zrobić. Coprawda do dekodera z helixa malloc nie jest konieczny ale jak "chłop żywemu nie przepuści..." :)


    Ponoć trzeba redefiniować funkcję _sbrk_r(), u mnie coś tam drgnęło, malloc zwraca wskaźnik o adresie dokładnie na końcu mapy RAM (za bss i stack).
    http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/lpc_2129_adc_stdio_20050514c.zip

  • #63 21 Maj 2006 23:04
    upanie
    Poziom 21  

    Dzięki ale problem już rozwiązałem. Trzeba podmienić cały plik syscalls.c
    Podmiana polega na tym, że do projektu dołączasz swój plik syscalls.c a linker sam oleje ten plik z newlib-a i wybierze Twój :) W tym pliku trzeba zaimplementować funkcję _sbrk. Działa cudnie. Jak ktoś będzie miał problem to w miarę możliwości służę pomocą.

    upanie

  • #64 26 Maj 2006 20:03
    upanie
    Poziom 21  

    Skompilowałem i odpaliłem. Na oko wygląda, że dekoduje się mniej więcej tylo samo czasu, co trwa mp3. Ale na oko to chłop w szpitalu umarł ;)
    Zegar mi pyka na 48 MHz czyli nie na maxa - trzeba podkręcić. Muszę dodać jakiś pomiar czasu i sprawa się wyjaśni. No i oczywiście nie robiłem żadnych przenosin z flash-a do ram-u, kod odpaliłem na żywca. A ram-u to jest sporo wolnego. Zajmuje ok 28 KB (może mniej). W każdym razie odpaliłem dekoder 2 razy bez zwalniania pamięci i działał.

    upanie

  • #65 26 Maj 2006 20:52
    UDMA
    Poziom 16  

    upanie napisał:
    Skompilowałem i odpaliłem. Na oko wygląda, że dekoduje się mniej więcej tylo samo czasu, co trwa mp3. Ale na oko to chłop w szpitalu umarł ;)


    Zrób test na próbce MP3 320kbps bo w tamtym kodzie jest tylko 128kbps.

  • #66 26 Maj 2006 21:02
    upanie
    Poziom 21  

    Się zrobi ale jutro, szefunciu, jutro ;) Nie znam się, nie wiem, zarobiony jestem ;)
    A poważnie mówiąc to muszę sobie zrobić jakiś sensowny sposób przesyłania komunikatów przez USB bo nie chce mi się kabla RS-owego robić ;)

    Ale ten łikend będzie należał do owocnych.
    Zawsze tak sobie obiecuję :?

    upanie

    Dodano po 3 [minuty]:

    A i jeszcze jedna sprawa. Czy masz, a może ktokolwiek inny, namiary na opis formatu pliku mp3. Ale opis całego pliku a nie ramek danych bo to można znaleźć wszędzie a opisu całego pliku jakoś mi się nie dudało.

    upanie

  • #67 26 Maj 2006 21:10
    UDMA
    Poziom 16  

    upanie napisał:
    Się zrobi ale jutro, szefunciu, jutro ;) Nie znam się, nie wiem, zarobiony jestem ;)


    Spoko, spoko mnie szczególnie interesuje jak sobie poradzi z dekoderem MP3 AT91SAM7 od Atmela. Ponoć nie jest za szybki ale ma I2S. Z kolei taki LPC2106 pojedzie i na 84MHz ale nie ma sensownego sposobu na podłączenie DAC.
    Gdyby Atmel dał radę to zmieniam platformę:)

  • #68 26 Maj 2006 21:20
    upanie
    Poziom 21  

    Mam lpc ale robię to na sam7s256. Temat mnie podrajcował i nie odpuszczę aż nie wycisnę wszystkiego co się da ;)

    upanie

  • CControls
  • #69 26 Maj 2006 21:51
    UDMA
    Poziom 16  

    upanie napisał:


    Dodano po 3 [minuty]:

    A i jeszcze jedna sprawa. Czy masz, a może ktokolwiek inny, namiary na opis formatu pliku mp3. Ale opis całego pliku a nie ramek danych bo to można znaleźć wszędzie a opisu całego pliku jakoś mi się nie dudało.


    Nie posiadam takowej dokumentacji. Z informacji z sieci wynika że najważniejsze są ramki i znaczniki synchronizacji, metadane (ID3) to dodatek.

  • #70 26 Maj 2006 22:48
    shg
    Specjalista techniki cyfrowej

    Ano cały plik mp3 to w zasadzie tylko ramki i doklejony na końcu (w starszych wersjach), lub na początku (w nowszych) ID3.
    Więc jedyne co Cię powinno interesować to właśnie ramki.
    Ramki powinny być umieszczone jedna za drugą, jeżeli po skończeniu dekodowania aktualnej ramki dekoder nie znajdzie nowej (synchro na początku ramki i nie tylko), to powinien te dane zignorować i szukać dalej, no chyba że to koniec pliku.

  • #71 26 Maj 2006 22:49
    upanie
    Poziom 21  

    No to ładnie :)

    Znalazłem funkcję co się zowie MP3CLearBadFrame. Zerknij sobie na to UDMA. Funkcja robi za memset a jest napisana "recznie" for-em i to jeszcze z jaki warunkiem stopu?! W każdej iteracji wykonuje się poważne mnożenie 3 liczb. Funkcja ta raczej nie jest często wołana ale jak tak jest napisana reszta kodu to trzeba go przewertować.

    upanie

  • #72 27 Maj 2006 02:03
    UDMA
    Poziom 16  

    upanie napisał:
    No to ładnie :)
    Znalazłem funkcję co się zowie MP3CLearBadFrame. Zerknij sobie na to UDMA. Funkcja robi za memset a jest napisana "recznie" for-em i to jeszcze z jaki warunkiem stopu?! W każdej iteracji wykonuje się poważne mnożenie 3 liczb. Funkcja ta raczej nie jest często wołana ale jak tak jest napisana reszta kodu to trzeba go przewertować.


    He he lepiej ustaw optymalizację z -s (size) na -O2. W tym drugim przypadku kompilator wywali warunek poza pętlę.

  • #73 27 Maj 2006 09:05
    upanie
    Poziom 21  

    Jak już mówiłem, w tym przypadku to nie ma znaczenia, gdyż funkcja jest wołana tylko w przypadku wystąpienia blędów w trakcie dekodowania.
    A co do optymalizacji to nie wiem dlaczego nie O3. W swoim życiu programisty spotkałem się tylko raz z przypadkiem, gdy kompilator zrobił mi pętlę liczącą w dół podczas gdy moja liczyła w górę. Rozumiem, że prostszy był warunek stopu, ale tak się nieszczęśliwie składało, że kolejność u mnie miała znaczenie. To było dla O3, jak dałem O2 było ok ale później zmieniłem komiplator na 3.4.3 i było dobrze dla każdej optymalizacji. Wcześniej kompilowałem 3.4.1. Robiłem różne inne proste programiki, aby powtórzyć ten efekt ale nic z tego. Tak optymalizował tylko tamten projekt.
    Co do jakości optymalizacji O3 to nie wiem, mogę tylko powiedzieć, że rozmiar kodu jest brdzo podobny do Os.

    upanie

  • #74 28 Maj 2006 21:31
    upanie
    Poziom 21  

    Uff. Nie mogę sobie poradzić z driverem USB pod windę dla 7s256, ale olałem to i coś tam pomierzyłem oscyloskopem.
    I oto moje pierwsze wnioski (narazie tylko dla 128 kbs - próbki ze źródeł).
    W programie GoldWave można się dowiedzieć, że dźwięk trwa 627 ms.
    Dekodowanie trwa:
    Os - 568 ms (80KB)
    O2 - 576 ms (82KB)
    O3 - 548 ms (99KB)
    O3 - rules, w nawiasach jest rozmiar binarki zawierający również sam plik mp3 (10KB). Acha procek chodzi na 47,92 MHz.
    Dla O3 mamy zatem 548/627*47,92 = 41,9 MHz potrzebne na zdekodowanie mp3 128 kbps.
    Wiem, że to są zbyt trywialne obliczenia i nie można tak poprostu stwierdzić, że mamy 6MHz na inne zadania ale jest to jakiś początek.

    upanie

    Dodano po 24 [minuty]:

    Małe sprostowanie.
    Podane rozmiary kodu dotyczą mojej aplikacji. Jak wywalić obsługę USB, printfy, plik mp3 i inne cudaki to napewno zejdzie się poniżej 50 KB dla Os.

    upanie

    Dodano po 1 [godziny] 11 [minuty]:

    Wrzuciłem tę sąmą emeptrójkę ale przerobioną na 320kbps.
    Dla O3 dekodowanie trwa 600 ms, czyi potrzeba ok. 46 MHz.
    Przypominam, że dla 128kbps to 548 ms i 42 MHz.
    Czyli wzrost mocy potrzebnej do zdekodowania mp3 jest mniej więcej zgodny z przewidywaniami na stroni helix-a.
    Jak się nic nie da wycisnąć więcej z procka to ciężko będzie zrealizować coś więcej poza dekodowaniem mp3 320kbps. Ale bądźmy dobrej myśli :)

    upanie

    Dodano po 2 [godziny] 13 [minuty]:

    To fascynujące :D Procka można puścić nawet na 105 MHz !!! :D
    I o dziwo dalej działa. Potrzebuje 276 ms do zdekodowania 627 ms mp3 przy bitrate 320 kbps. Dekoduje prawie 4 razy szybciej niż w czasie rzeczywistym.
    Ani razu nie zgłasza błędu (podpiąłem sobie błąd dekodowania pod diodę i nie mruga anie nic nie można zaobserwować na oscyloskopie).
    Mimo wszystko jednak jestem podejżliwy bo czas dekodowania zmalał ok. tyle samo razy co wzrosła prędkość zegara. To nie powinno mieć miejsca bo FLASH chodzi maksymalnie na 40MHz co oznacza, że dla każdego rozkazu powinien czekać min. 2 cykle na dane/instrukcje z FLASH-a. Jednym słowem albo ja jestem głupi albo ktoś, a rczej coś, mnie robi w konia.
    Nie ważne, przez chwilę pożyję sobię w świadomości, że życie jest piękne.
    Na 110 MHz procek już nie chce brykać - wiesza się. No ale puszczenie go 2 azy szybciej niż podaje producent to już ładny wynik.

    Acha. Poza tym, że w drugim pliu jest 320 kbps to jeszcze jest jedna różnica. A mianowicie w pierwszym pliku były tylko dane (ramki) a w drugim jest cały plik. Co to oznacza? Ano to, że wyszukanie pierwszej ramki trwa dłużej niż w pierwszym przypadku i oczywiście po ostatniej ramce występuje szukanie ramki, której nie ma bo jest tam tylko ID3.
    Różnica dla całego pliku to pewnie nic nie znaczące mikrosekundy albo jakaś 1 ms ale mimo wszystko musiałem o tym wspomnieć.

    Jak trochę odsapnę to zrobię taki myk, coby wysyłać całą emptrójkę (w kawałkach oczywiście) do procka poprzez usb i odbierać zdekodowane dane. Jak się odtworz wav prawidłowo to znaczy, że wszystko piękni działa.

    upanie

  • #75 29 Maj 2006 05:59
    UDMA
    Poziom 16  

    upanie napisał:

    To fascynujące :D Procka można puścić nawet na 105 MHz !!! :D


    LOL super:) Czas przesiąść się na Atmela.
    Fajny benchmark, zrobię podobny dla LPC, może pojawią się jakieś ogólne wnioski.

    Dodano po 3 [godziny] 32 [minuty]:

    Zmierzyłem czasy dekodowania dla LPC2106 i całych MP3 (www.efsl.be i życie stało się prostsze;). W tle chodził timer na IRQ 1kHz. Sumowałem czas dekodowania ramek (MP3Decode) dla pliku MP3 z rozdzielczością 1ms.
    Wychodzi na to że dla 320kbps trzeba 38 MHz taktowania na sam dekoder. Czyli albo LPC jest trochę wydajniejszy od AT91 (zaleta MAM ??) albo gdzieś jest błąd.
    Ustawienia:
    GCC 4.1.0 -O2
    MAM = full
    MAMclk = 3

    Code:

    fclk   Bitrate   T_mp3         T_dec   Utilization
    ---------------------------------------------------
    48MHz   128      2:35 (155s)      105s   68%
    48MHz   249      6:04 (364s)      258s   71%
    48MHz   320      3:04 (184s)      142s   77%

    72MHz   128      2:35 (155s)      70s      45%
    72MHz   249      6:04 (364s)      172s   47%
    72MHz   320      3:04 (184s)      95s      52%

  • #76 29 Maj 2006 17:22
    szymtro
    Poziom 30  

    Panowie jesteście wielcy.

    Ja narazie jeszcze nie zabradzo czaję C ale postaram sie w miare szybko uaktualnic do C - przynajmniej zeby przeczytać program ze zrozumieniem.

    Miałbym takie pytanie czy jest szansa nieco uprościć zapis (zmniejszyc ilość plików - poprzenosić wszystko do jednego) w tym projekcie i zrobić może tylko 5 plików textowych w których bedzie cały program (domyślam sie że jeden plik z całym programem to za dużo roboty).

    Moje pytanie dotyczy właśnie tego hxplay na którym bazujecie.

  • #77 29 Maj 2006 17:41
    piotr_go
    Poziom 27  

    @szymtro
    hehe, obawiam sie że jak wrzucisz wszystko do jednego pliku to będzie jeszcze większy problem ze zrozumieniem o co w tym chodzi :)

    @upanie, UDMA
    dobra robota, a może teraz ogg odpalicie?
    albo kodowanie do mp3

    jak znajde troche czasu to może też sie tym zajme(mam lpc2106 i lpc2148)

    pozdro

  • #78 29 Maj 2006 19:41
    upanie
    Poziom 21  

    Cytat:
    dobra robota, a może teraz ogg odpalicie?

    Chętnie spróbuję Tremora.

    Cytat:
    albo kodowanie do mp3

    Jakoś qrcze wydaje mi się, że to się chyba nie uda :?

    Cytat:
    Czyli albo LPC jest trochę wydajniejszy od AT91 (zaleta MAM ??) albo gdzieś jest błąd.


    Hmm. Ja też używam gcc 4.1.0. Różnica jest jednak spora. U mnie O2 daje najgorsze wyniki spośród O2, O3 i Os albo coś mi się posrało przy notowaniu wyników. Ale nawet O3 nie jest w stanie zbliżyć się do Twojego wyniku. No cóż w LPC jest prefetch-buffer 128 bitów co daje odczyt 4 słów 32-u bitowych. Dla sekwencyjnego wykonywania programu daje to jednocyklowy dostęp do pamięci nawet do 80MHz. W AT91SAM7S nie ma takiego bajeru.
    Co do pomiaru czasu to ja nie mierzyłem czasu wykonania funkcji MP3Decode. Otóż ja musiałem przerobić nieco funkcję main i włożyć ją do swojego programu. U mnie funkcja nazywa się decodeSample i jest właściwie odpowiednikiem funkcji main z oryginalnych źródeł helix-a bez kodu specyficznego dla LPC. No i jeszcze dołożyłem zwalnianie pamięci zajmowanej przez dekoder MP3FreeDecoder().
    Jednym słowem mierzę więcej kodu, ale mimo wszystko różnica jest duża. A mierzę w taki sposób, że zapalam diodę przed wywołaniem decodeSample i gaszę ja po zakończeniu. Na oscyloskopie obserwuję czas trwania impulsu i notuję.

    Spróbuj O3, może się jeszcze poprawi ;)

    upanie

    Dodano po 3 [minuty]:

    A tak swoją drogą to maż zacięcie UDMA: 5:59 :)
    O tej porze to ja jeszcze się cieszyłem, że mam jeszcze 15 min. do wstania :)

    upanie

    Dodano po 11 [minuty]:

    Tym to możnaby się pobawić ;) STR912FW44X
    http://mcu.st.com/mcu/inchtml.php?fdir=pages&fnam=str9

    upanie

  • #79 29 Maj 2006 21:10
    bajk
    Poziom 12  

    Gratuluję, dobra robota
    płytkę prototypową już robię, jeszcze tylko w C się dokształcę i też piszę dekoder :D

    Natknąłem się na mały problem (w AT91SAM7S265), w SSC sygnał zegarowy to MCK (zamiast peripheral clock), czyli niby ten sam, który taktuje CPU. Skoro taktuje CPU to będzie pochodził z PLLa, bo zewnętrzny kwarc tylko do 20MHz może chodzić (o ile się nie pomyliłem). Jeżeli chodzi na sygnale z PLLa, a według schematu ze str 27 pełnej noty zegar jest zawsze ten sam dla CPU i peryferiów między innymi też dla SSC to w takim przypadku nie da się uzyskać 44,1kHz (idealnego).

    Wobec tego po co jest środkowy blok (Programmable Clock Controller str27)? I nie możnaby zrobić takiego myku żeby CPU było taktowane z PLLa, a SSC albo chociaż jakiś timer z zewnętrznego kwarcu tak, żeby na wyjściu preskalera było idealnie 44,1kHz?(tak jak da się zrobić przy 12,288MHz i 48kHz)

    W takim razie pytanie, czy fabryczne playery też mają takie różnice w częstotliwości odtwarzania jak to opisano w „Connecting the Atmel ARM-based Serial Synchronous Controller (SSC) to an I2S-compatible Serial Bus”(Application Notes - Application Example and Algorithms)?

  • #80 04 Cze 2006 14:17
    upanie
    Poziom 21  

    Witam ponownie po małej przerwie.
    Mam coś do wyjaśnienia. Mianowicie wyniki, które wcześniej zamieściłem są prawidłowe ale nie zamieściłem informacji, że dotyczą one konfiguracji procka z WS (wait state) równym 1 (czyli dwa cykle procka na odczyt z flash-a). Dlatego też procek chodzi na 105 MHz. Jak mu ustawić WS na 0 to sytuacja się zmienia, trochę na gorsze a trochę na lepsze. Na gorsze to to, że maksymalny speed to 55 MHz (więcej się nie da bo flash więcej nie wydoli - brak prefetch buffer-a). Z tego wynika, że flash chodzi szybciej niż podaje ATMEL (maks. 40 MHz). Natomiast zmienia sią trochę na lepiej bo znacznie mniej potrzebuje magaherców do dekodowania. A oto wyniki:

    Code:
    FCPU                  48 MHz              55 MHz
    
    Total dec. time       400 ms              358 ms
    Frame dec. time       11,2 - 17,6 ms      9,4 - 16,4 ms
    CPU usage             30,6 MHz            31,4 MHz


    Niestety musimy wybrać wersję 48 MHz jak chcemy mieć działające USB.
    Ew. można wybrać wersję z WS=1 i FCPU=96 MHz (też działa USB)

    Code:
    FCPU                  96 MHz
    
    Total dec. time       298 ms
    Frame dec. time       8,0 - 13,4 ms
    CPU usage             45,6 MHz

    Relatywnie gorsze wyniki ale bezwzględnie znacznie lepsze.

    bajk
    Za dni kilka (może nawet jutro) zabieram się za podłączenie DAC-a do procka. Dlatego też wyczaję SSC i mam nadzieję, że wszystko będzie OK. Dam znać co się udało zrobić.

    upanie

  • #81 08 Cze 2006 06:16
    artek3xp
    Poziom 9  

    Hey witam.
    Od jakiegos czasu zajmuje sie ARM AT91SAM7S64.Zrobilem cos takiego- odczytuje plik WAV z karty MMC i przesylam interfejsem I2S do DAC TDA1543.Wykorzystuje wbudowany SSC ktury mozna przystosowac do I2S.
    WAV'y sa 16 bitowe 44.1kHz.Musze powiedziec ze dosc slabo to wyszlo.Nie wiem czy ten DAC jest marnej jakosci czy problem w ustawieniu odpowiedniej predkosci transferu bitow do DAC'a.Np. przy zmianie rejestru dzielnika czestotliwosci(SSC) tylko o jeden muzuka jest albo lekko za szybka albo bardzo wolna.
    Jeszcze jedno jesli chodzi o przetaktowanie tego ARM'a to podajcie ustawienia odpowiednich rejestrow.W dokumentacji napisane jest ze wyjscie PLL musi oscylowac przynajmniej od 80 do 150 MHz pozniej dopiero mozna je dzielic,wiec jesli po wyliczeniach wychodzi ze czestotliwosc rdzenia rowna jest 100Mhz a na wyjsciu PLL ponizej 80MHz to tak naprawde rdzen taktowany jest xMhz(niewiadomo ile) :)
    dzieki

  • #82 08 Cze 2006 18:25
    shg
    Specjalista techniki cyfrowej

    artek3xp napisał:
    Nie wiem czy ten DAC jest marnej jakosci czy problem w ustawieniu odpowiedniej predkosci transferu bitow do DAC'a.Np. przy zmianie rejestru dzielnika czestotliwosci(SSC) tylko o jeden muzuka jest albo lekko za szybka albo bardzo wolna.


    Jeżeli chodzi o DAC to wszystko w porządku.
    Problem leży właśnie w tym, że dane do DAC trzeba podawać z odpowiednią szybkością.
    Nie wiem, jak ten TDA, ale UDA1330, którego zamierzam użyć nie ma żadnego bufora, ba żeby sprawę jeszcze bardziej skomplikować, to sygnał zegoarowy dla DACa musi być DOKŁADNIE x (trzy możliwe ustawienia) razy większy od sygnału zegarowego na magistrali IIS. Jedyne sensowne rozwiązanie jakie znalazłem to kwarc 18.432MHz (dostępny bez problemu) i wybów dzielnika w DACu 384, co da częstotliwość próbkowania dokładnie 48kHz. teraz kolejny problem - mp3 inne niż 48kHz trzeba będzie potraktować resamplerem, a resampling 44.1kHz -> 48kHz jest 'nieco' uciążliwy.

    Oczywiście brak bufora oznacza (jedyne co jest to pewnie rejestr SIPO), że strumień danych na wejściu musi być ciągły. Dopuszczalny jest jitter (o ile takiwe coś można jeszcze jitterem nazwac...) zegara pomiędzy kolejnymi próbkami (można przyspieszyć nawet do 64fS), ale same próbki muszą pojawiać się w określonych odstępach.

    Chyba jedyne sensowne rozwiązanie tego problemu to wykorzystanie wbudowanego kontrolera DMA

    A co do dzielnika w SSC to faktycznie nie masz zbyt dużego wyboru. Musisz dobrać kwarc, ewentualnie kombinować tak z PLLem, żeby zegar proca ładnie się dzielił do częstotliwości wymaganej przez IIS.

  • #83 09 Cze 2006 09:52
    upanie
    Poziom 21  

    No cóż, ja poleciałem po całości i wstawiam do swojego projektu DDS!
    Generuje taką częstotliwość jaką chcę do 12,5 MHz i już.
    Ten DDS to AD9833 a DAC to UDA1330. SSC można napędzać zewnętrznym zegarem i tak zamierzam zrobić bo wystarczy podzielić wyjście DDSa.
    Jedyny mankament SAM7S to niestety maksymalnie 16-to bitowe próbki do DACa przez SSC.

    upanie

  • #84 09 Cze 2006 14:41
    bajk
    Poziom 12  

    Moim zdaniem, jeśli już to w urządzeniu przenośnym (jeżeli takie to ma być) lepiej użyć PLLa z 60 MHz-ami niż dodawać jakieś zewnętrzne układy, które zwiększają rozmiar płytki, komplikują ją oraz zwiększają cenę i pobór prądu. Kwarc 12.288 albo 18.432MHz też nie załatwia sprawy do końca, a przy 60MHz można dać dzielnik 42 i wtedy f wyjściowa próbkowania będzie 44,643 kHz co w efekcie spowoduje, że utwór ok. 4minutowy będzie krótszy o ok. 3 sekundy, a więc nie jest to chyba jeszcze tak źle, tym bardziej, że atmel sam podaje takie wyniki w swoim "Connecting the Atmel ARM-based Serial Synchronous Controller (SSC) to an I2S-compatible Serial Bus" i w dodatku jest to rozwiązanie (chyba) najprostsze.

    Jak ktoś ma fabryczny odtwarzać to może sprawdzić czy 4 minutowy utwór trwa rzeczywiście 4 minuty, czy krócej, większą różnicę będzie widać przy dłuższym pliku no i trzeba to jeszcze dokładnie zmierzyć :/
    W profesjonalnych playerach też zapewne mieli takie problemy i chyba jakoś to załawili, choć sam AT91SAM7S256 jest przeznaczony m.in. do takich aplikacji (i jego SSC też) więc jak chcieli troche zaoszczędzić to być może zrobili nie do końca idealnie, bo przecież nie każdy zauważy.

  • #85 09 Cze 2006 21:14
    upanie
    Poziom 21  

    Po co robić samemu przenośny odtwarzacz mp3?
    Ani to opłacalne cenowo, ani atrakcyjne wizualnie ani nie ma szans zbliżyć się chociażby do produktów komercyjnych pod względem zapotrzebowania na energię. Ja robię "odtwarzacz" tylko po to aby sprawdzić czy dam radę i przy okazji nauczyć się tego i owego, a jeżeli będę chciał tego użyć to napewno stacjonarnie.
    W przypadku UDA1330 trzeba jeszcze podać zegar "napędzający" ten układ. A częstotliwość tego zegara to 256*fs, 384*fs lub 512*fs. Jak to zrobić za pomocą tylko SAM7S to ja nie bardzo wiem. Poza tym dlaczego ograniczać się do 44,1 KHz? Są przecież inne częstotliwości próbkowania, np. 48 KHz, 8KHz, 11,025 KHz itd. Co wtedy?
    A te firmy, które robią przenośne odtwarzacze to korzystają ze specjalizowanych układów i takie problemy ich nie dotyczą.
    Jak zapodasz częstotliwość 60 MHz to nie będziesz miała działającego USB :(
    ATMEL nie miał w swoich zamierzeniach uczynienia SSC interfejsem robiącym z I2S czego dowodem może być fakt iż w takim trybie nie da się nadawać więcej niż 16 bitów na kanał.

    upanie

  • #86 16 Cze 2006 21:03
    bajk
    Poziom 12  

    Robienie własnego odtwarzacza nie jest aż tak nieopłacalne. Zakładając, że program zmieści się w at91sam7s64 i dokładając rs-mmc 512MB, dac wraz ze wzmacniaczem można dostać jako próbki można osiągnąć niezłą cenę.
    mmc 512MB + at91sam7s64 <=> 46zł+24zł=70zł
    Nie liczę akumulatorków gdyż w fabrycznych przy zakupie też zazwyczaj ich nie dołączają.
    Płytka prawie nic, tylko trochę pracy.
    Pozostałe elementy to nie więcej jak parę złotych.
    Wyświetlacz nawet od n3310 to ewentualnie dyszka więcej.
    Tak więc na pewno można zmieścić się poniżej 100zł.

    Fabryczny z pamięcią 512MB to wydatek co najmniej stokilkanaście zł.
    Radia nie biorę pod uwagę.

    Oczywiście te stokilkanaście dotyczy chińskich playerów, natomiast te z lepszymi DACami dużo więcej np. taki creative albo philips, a zamawiając dac jako próbki mamy trochę lepszy -lepsza jakość –(tak mi się wydaje) przez co można go porównywać do różnych philipsów itp., a nie popatrzeć że na allegro są chińskie i to takie co się psują często, choć muszę przyznać, że być może niedługo taki projekt będzie całkowicie nieopłacalny.(szczególnie ze względu na tanie produkty z dalekiego kraju)

    A co do obudów to są takie od irdy i nie tylko na nikomp.pl i według mnie idealnie nadają się do takich urządzeń przenośnych. Chodzi mi o te z tej strony http://www.nikomp.com.pl/cgibin/shop?show=OBC00&sort=id&sid=7e328de7 .

  • #87 16 Cze 2006 23:13
    upanie
    Poziom 21  

    No nie wiem. Ale jak zrobisz takie cóś to zapodaj jakieś fotki, może faktycznie jakoś to będzie wyglądać.
    A co do DDS to płytki strasznie nie powiększy. Ma on 10 wyprowadzeń w rastrze 0.5mm co daje jakieś 3-4 mm długości scalaka. Nie potrzebuje żadnych elementów zewnętrznych, a prądu pobiera 5.5 mA przy 25MHz przy włączonym DACu wyjściowym. Jako, że ja potrzebuję prostokąta na wyjściu, to mogę wyłączyć DACa i zmniejszyć pobór prądu (mam nadzieję ;) ). Mam go w domu ale nie mogę przylutować bez płytki. Jutro spróbuję porozginać mu nogi (góra-dół i przylutować do jakiegoś uniwersalniaka). Większy (fizycznie) będzie dzielnik zegara wyjściwego z DDS przez 8. Jest to konieczne dla nadawania danych po I2S. A krok ustawianej częstotliwości wyjściowej w zakresie 0 do 12,5 MHz to 0,1 Hz.

  • #88 07 Lut 2007 22:27
    adamusx
    Poziom 27  

    Witam.
    Jak posunela sie sprawa z odtwarzaczem bo temat trochę ucichł.
    Jakie postępy upanie?

  • #90 11 Mar 2007 22:42
    szymtro
    Poziom 30  

    Kolego zauważ że to co wkleiłeś to amatorka w porównaniu z tym co tu koledzy wyprawiają. A o ile dobrze pamiętam to linki do gotowych urządzeń były na 1 i drugiej stronie i dodatkowo w wątku o snd.

    Jak dla mnie to co koledzy wyprawiają jest za trudne - mam za mało czasu aby nad tym tyle posiedzieć.
    Za to znalazłem fajną stronkę z fajnym ide (proste) jak na początek z lpc(at91 w drodze).
    http://www.hbbrbasic.com/ <- może komuś się przyda aby w ogóle zacząć arm (jak mi)
    cena 39 usd też nie jest wcale wysoka (bo dolar osłabł).