Ogłoszenie

Collapse
No announcement yet.

USB Audio - forumowe "Amanero"

Collapse
Ten temat jest przyklejony.
X
X
 
  • Filtr
  • Czas
  • Pokaż
Clear All
new posts

  • .3lite
    replied
    No to może trochę ciekawych faktów - oficjalnie układ CM6631A oraz CM6632A chodzi z maksymalną prędkością 192 kHz, ale nieoficjalnie podkręcany jest do 384 kHz pryz zwiększeniu zegara wejściowego, tj. master clock'a (z 24.576 MHz / 22.5792 MHz na 49.152 MHz / 45.1584 MHz) przy oszukaniu wewnętrznego układu, tj. układ tak naprawdę myśli, że ma na wejściu zegary 24.576 MHz / 22.5792 MHz, więc układ pracuje bez dzielnika i z dwa razy większą prędkością. Nie robi mu to żadnej różnicy, ponieważ ewidentnie został tak zaprojektowany, ale został ograniczony z powodu faktu, że 24.576 MHz oraz 22.5792 MHz są znacząco tańsze od 49.152 MHz oraz 45.1584 MHz (przynajmniej tak twierdzi pracownik C-Media z diyaudio.com). W takim wypadku można by pomyśleć, że jak zwiększymy zegar wejściowy do 98.304 MHz oraz 90.3168 MHz to powinien chodzić nawet przy 768k. Niestety, testowałem to zaraz na początku i wewnętrzna logika siadła już przy zegarze 60 MHz, więc pomysł upadł. Po kilka tygodniach wpadł mi pomysł ze slave mode, tj. w tym trybie CM6631A wymaga tylko taktowania BCLK oraz LRCK, więc teoretycznie ten problem nie występuje. No to zobaczmy co się dzieje na wyjściu BCLK oraz DATA przy podaniu BCLK na poziomie 49.152 MHz i LRCK na poziomie 705,6 kHz:



    Żółty - BCLK.
    Niebieski - DATA.

    Coś tam się dzieje i układ odpowiada, ale nieprawidłowo (za duże opóźnienie reakcji DATA względem opadającego zbocza BCLK). Zobaczmy jak to wygląda przy BCLK na poziomie 24.576 MHz oraz LRCK na poziomie 384 kHz:



    Tutaj reakcja jest prawidłowa.

    No ale skoro układ odpowiada przy 768 kHz to i można zrobić pewien trik, tj. stworzyć dwa sygnały BCLK oraz LRCK, jedne taktują CM6631A w slave-mode a drugie są opóźnione w fazie o 90 stopni BCLK i służą do odbioru danych z DATA:



    Musiałem na szybko dopisać obsługę formatu right-justified w FPGA i puścić go na PCM58 od kolegi olog z forum AS, ponieważ żaden z dostępnych u mnie przetworników nie przyjmie takiego formatu na klatę a PCM58 już tak:





    Niebieski - zegar dla formatu right justified.
    Żółty - LRCK.

    No i koniec końców pliczek z diyinhk do testowania ich najnowszego XMOS'a:



    Generator w ARTA był ustawiony na 1 kHz a pliczek na jednym kanale odtwarza 2 kHz, więc dla programu THD to 100% :) Co nie zmienia faktu, że wszystko widać.

    Mamy układ, który potrafi odtworzyć plik 768 kHz bez większego problemu :)
    Last edited by .3lite; 05.06.2018, 14:04.

    Zostaw komentarz:


  • .3lite
    replied
    Mała aktualizacja firmware (2018-06-01):

    6631A-4549-custom-ALL.hex - zegary 49.152 MHz oraz 45.1584 MHz (PID własny, sterownik systemowy).
    6631A-4549-cmedia-ALL.hex - zegary 49.152 MHz oraz 45.1584 MHz (PID od C-Media, sterownik tak samo).

    W tej rewizji naprawiłem piny P1, P2 oraz P3 - negowały swój stan względem wartości z Amanero (tj. jak Amanero miał 1, to tutaj miały 0 i odwrotnie). Teraz jest dokładnie tak samo jak w Amanero.
    Załączone pliki

    Zostaw komentarz:


  • MICHNIOR
    replied
    Nie na temat...
    Zamieszczone przez .3lite Zobacz posta
    ..... może tym razem uda się wyciągnąć 768 kHz
    wariat :)

    Zostaw komentarz:


  • .3lite
    replied






    Taki addon :) Jego głównym zadaniem jest tworzenie różnicowych sygnałów w każdym formacie. Zanim ta rewizja płytki dotarła to już zdążyłem dodać zewnętrzne wejście I2S (przełączalne, USB Audio lub zewnętrzne) oraz osobny zegar dla formatu right-justified (teraz dane taktowane są względem głównego BCLK a można jeszcze go podzielić przez dwa).

    SPDIF generowany jest z wejściowego I2S. Płytka ta nie używa wyjścia SPDIF z USB Audio. W praktyce ma działać z USB Audio w trybie slave, tj. sam będzie taktował DMA w CM6331A i być może tym razem uda się wyciągnąć 768 kHz, ponieważ logika siadała przy 60 MHz na wejściowym zegarze a tutaj nie będzie tego problemu, więc zobaczymy.

    Zostaw komentarz:


  • .3lite
    replied
    Mała aktualizacja firmware (2018-05-27):

    6631A-4549-custom-ALL.hex - zegary 49.152 MHz oraz 45.1584 MHz (PID własny, sterownik systemowy).
    6631A-4549-cmedia-ALL.hex - zegary 49.152 MHz oraz 45.1584 MHz (PID od C-Media, sterownik tak samo).

    W tej rewizji poprawiłem SPDIF. Mam nadzieję, że będzie już działał poprawnie.
    Załączone pliki

    Zostaw komentarz:


  • .3lite
    replied
    Zamieszczone przez raven1985 Zobacz posta
    Trzeba by inną skalę przyjąć tych wykresów żeby coś na nich zobaczyć :)
    J-test to sygnał sinus o częstotliwości 1/4 fs na który został nałożony prostokąt o częstotliwości fs/192 z amplitudą 1 LSB .
    Przy obecności jitteru w widmie w około tonu podstawowego którego f dla próbkowania 44.1k to 11.025kHz pojawią się prążki na f. +- 229.68Hz i harmonicznych tych częstotliwości i je należy porównywać .
    Więc skale częstotliwości trzeba powiększyć do góra kliku kHz w okołu 11.025k a skale amplitudy przyjąć max -70dB bo amplituda tych prążków nie będzie za duża :)
    Obecność jitteru będzie też widać ( jeśli będzie na tyle duży ) na noise floor i w "grubości" tonu podstawowego (nisko częstotliwościowy jitter ).
    Dlatego warto zrobić pomiar samego noise floor z dużym uśrednianiem .
    No to J-Test 48 kHz zgodnie z wytycznymi (65k punktów i liniowe uśrednianie):

    Amanero:



    USB Audio z generatorami Crystek CCHD-575 (około 50 PLN sztuka):



    USB Audio z generatorami z Mouser (około 6 PLN sztuka):



    Najlepiej to nałożyć na siebie, ale to nie jest takie proste bo krzywe są bardzo blisko siebie:

    Amanero (zielony) vs USB Audio z generatorami z Mouser (niebieski):



    USB Audio z Crystek CCHD-575 (zielony) vs USB Audio z generatorami z Mouser (niebieski):



    Forumowa kompresja obrazków daje w kość, ale coś widać. Amanero generuje dodatkowe prążki przy bazowej częstotliwości.

    Zostaw komentarz:


  • .3lite
    replied


    Cały dokument:

    http://www.nanophon.com/audio/diagnose.pdf

    Zostaw komentarz:


  • irek
    replied
    Programowe analizatory dzialajace z kartami muzycznymi maja zwykle max 65535 probek a to nie do konca jest wystarczajace, do tego jeszcze wybor okna.

    Mnie najbardziej ciekawia prazki od tetnien zasilania. I od PLL cyfrowej i analogowej. A slyszalem tez, ze czasami kombinuje sie zwyklymi procesorami skladac czestotliwosc probkowania z kilku roznych dostepnych czesotltiwosci. Bo jesli wygenerujemy 900hz przez pol sekundy a pozniej przez kolejne pol sekundy 1100hz to otrzymamy czestotliwosc 1000hz ale gdzie wyskocza prazki jittera?

    - - - - - aktualizacja - - - - -

    Zamieszczone przez raven1985 Zobacz posta
    J-test to sygnał sinus o częstotliwości 1/4 fs na który został nałożony prostokąt o częstotliwości fs/192 z amplitudą 1 LSB .
    A nie da sie tego zrobic tak jak z analiza samego generatora? Czyli sam prostokat fs/4 i analiza widmowa w waskim pasmie?

    Zostaw komentarz:


  • .3lite
    replied
    Zgadzam sie z tym Trzeba też wspomnieć, że FFT w pomiarach było ustawione na 65536 punktów, więc też nie tak mało. Jak będzie chwila to zrobię pomiar z przybliżeniem, ale jest też jest pewna granica w ocenie "grubości" prążka na dużym przybliżeniu, ponieważ jest limit w którym niskoczęstotliwościowy jitter nie będzie już nazywany jitterem

    Zostaw komentarz:


  • raven1985
    replied
    Trzeba by inną skalę przyjąć tych wykresów żeby coś na nich zobaczyć :)
    J-test to sygnał sinus o częstotliwości 1/4 fs na który został nałożony prostokąt o częstotliwości fs/192 z amplitudą 1 LSB .
    Przy obecności jitteru w widmie w około tonu podstawowego którego f dla próbkowania 44.1k to 11.025kHz pojawią się prążki na f. +- 229.68Hz i harmonicznych tych częstotliwości i je należy porównywać .
    Więc skale częstotliwości trzeba powiększyć do góra kliku kHz w okołu 11.025k a skale amplitudy przyjąć max -70dB bo amplituda tych prążków nie będzie za duża :)
    Obecność jitteru będzie też widać ( jeśli będzie na tyle duży ) na noise floor i w "grubości" tonu podstawowego (nisko częstotliwościowy jitter ).
    Dlatego warto zrobić pomiar samego noise floor z dużym uśrednianiem .

    Zostaw komentarz:


  • .3lite
    replied
    Nie użyłem ASRC właśnie po to aby wynik był w miarę poprawny. D/A to był PCM58 kolegi olog z AS i jego filtrem, który używa MCLK do wyplucia zewnetrznych danych do przetwornika. Akurat to miałem na testach, więc stwierdziłem, że będzie dobrym D/A do pomiaru :)

    Zostaw komentarz:


  • sylvester
    replied
    Zamieszczone przez .3lite Zobacz posta
    Myślę, że wnioski można samemu wysnuć i nie muszę nic pisać
    Pytanie miałbym jeszcze, dla pełności obrazu, DAC wykorzystywał MCLK generowany przez konwerter, czy ze swojego lokalnego generatora, z ASRC na wejściu?

    Zostaw komentarz:


  • .3lite
    replied
    Nie wiem, ale pobór na pewno zależy od próbkowania Jak będziesz miał swoją wersję to możesz sprawdzić - wystarczy pominąć U1 podczas lutowania (oraz jeśli ktoś chce to i C2/C3/C4) i zasilić go z zewnętrznego zasilania.

    - - - - - aktualizacja - - - - -

    Z selektorem na CPLD może sprawdzę jak będzie chwila

    - - - - - aktualizacja - - - - -

    Zamieszczone przez irek Zobacz posta
    Prawde mowiac to nie wiem jak interpretowac wyniki. Moze glowny jitter to jitter karty muzycznej ktora mierzyles? Co to za karta?
    EMU 0202.

    Zamieszczone przez irek Zobacz posta
    Bo ja tu zadnego pana jittera nie widze!
    No właśnie Szkoda czasu i pieniędzy na wybitne zegary, nic to nie da. Samo Amanero ma prążki wyżej niż ten konwerter, więc jest to dosyć ciekawe

    Zostaw komentarz:


  • Holgin
    replied
    Z innych pytań - jaki jest pobór prądu?

    Zostaw komentarz:


  • irek
    replied
    Sprawa wymaga wypicia dwoch browcow i dopiero mozna podjac rozmowe fachowcow :)

    Prawde mowiac to nie wiem jak interpretowac wyniki. Moze glowny jitter to jitter karty muzycznej ktora mierzyles? Co to za karta?

    A moze ten crystek jest najgorszy :)

    Moznaby jeszcze sam generator podzielic tyle razy aby dostac 11,025khz i wrzucic to jako referencje na karte muzyczna.

    W kazdym razie rzezbienie! :) Bo ja tu zadnego pana jittera nie widze! Za to slysze!

    Zostaw komentarz:


  • Holgin
    replied
    Byłbyś chętny zmierzyć to samo na wyjściu CPLD? :)

    Zostaw komentarz:


  • .3lite
    replied
    No to w takim wypadku Jitter Test na wyjściu DAC z różnymi zegarami oraz Amanero dla porównania:

    Amanero:



    Mój konwerter oraz Crystek CCHD-575 (ponad 50 PLN za sztukę):



    Mój konwerter oraz zegary po 6 PLN z Mouser:



    Myślę, że wnioski można samemu wysnuć i nie muszę nic pisać :)

    Zostaw komentarz:


  • Holgin
    replied
    Moje PCB pod WM8804 ma zarówno transformator jak i odbiornik optyczny, więc byłaby to chyba dobra baza do testów. W razie czego mogę oddać płytkę do badań :)

    Zostaw komentarz:


  • irek
    replied
    Zgadza sie, dobrze byloby porownac polaczenie coaxial z toslink.

    Pewnym klopotem bedzie wygenerewanie sygnalu spdif. Bo jego zrodlo ma duzy wplyw, dobrze byloby zbadac odbiorniki spdif na dobrym zrodle i tu chyba opisywany uklad mozna nazwac dobrym srodlem sygnalu spdif (zdaje sie ma takie wyjscie). A dla porownania mozna wziac jakis tani odtwarzacz DVD ktory na pewno bedzie kiepski :) Moze uda sie wykazac jak WM8804 zmniejsz jitter a CS w porywach bardziej go nie psuje :)

    Ale to juz zabawa dla zabawy i wszystko po stronie checi .3lite :)

    Jak pisze raven czasem warto skierowac energie w inna strone :)

    Zostaw komentarz:


  • Holgin
    replied
    Mam odbiornik zarówno na CS8416 jak i WM8804, CS na trawionym PCB, drugi ma płytkę z zakładu. Chętnie pomogę w takich pomiarach :)
    Tylko że jeżeli mówimy o SPDIF to zaraz transformator czy odbiornik optyczny też trzeba będzie miał wpływ... :)

    Zostaw komentarz:

Czaruję...
X