PCM1794A + Raspberry Pi - wygodnie i nowocześnie :-)

[tomek_j]

Samodzielne konstruowanie przetwornika DAC wydaje się dzisiaj trochę pomysłem staroświeckim. Bracia Azjaci oferują za stosunkowo małe pieniądze wszystko co potrzeba, gotowe moduły  a jak ktoś chce to mają  kompletne urządzenia  łącznie z obudową i zasilaniem.  Ja jednak chciałem to zrobić sam i wymyśliłem sobie, że zrobię DAC połączony magistralą I2C z Raspberry Pi. Żeby było nowocześnie i wygodnie. Nie jest to zbyt oryginalne zadanie, bo przecież wszystko (prawie) tu już wymyślono, zaprojektowano i można kupić. No ale każdy kto samodzielnie zaprojektuje, wykona i uruchomi swoje urządzenie ma jakąś tam satysfakcję to po pierwsze, a po drugie można sobie to zrobić tak jak się potrzebuje. Ja potrzebowałem DAC jak już wiemy  połączony z Raspberry PI  przez I2S. Z założenia miał to być "trochę lepszy" przetwornik cokolwiek maiłoby to znaczyć. Po niezbyt długim namyśle wybór padł na PCM1794A, co raczej nie powinno nikogo dziwić. I tu się pojawił pierwszy dość fundamentalny problem. Nie za bardzo Raspberry PI jest przygotowany tego żeby "gadać" z tym przetwornikiem po I2S. Nie żeby było coś nie tak z I2S, bo jest wszystko (prawie) w porządku. Problem leży trochę po stronie PCM1794A, bo potrzebuje on  jednego dodatkowego sygnału zegarowego, którego nie ma w specyfikacji magistrali. Mowa jest tu o zegarze MCLK, czyli zegarze taktującym wewnętrzne układy: konwertera cyfrowo analogowego i układy filtrów cyfrowych. Częstotliwość MCLK musi być wielokrotnością częstotliwości próbkowania Fs i być zgodna fazowo (chyba)  w pozostałymi sygnałami I2S. Ta wielokrotność wynosi  minimum 128. Sygnał BCK w I2S ma częstotliwość 64xFs - za mało, ale są tacy, którzy uważają, że wystarczy i łączą równolegle MCLK i BCK. Ja tak nie uważam, bo mam tak, że wierzę  inżynierom projektującym układ i jak piszą, że MCLK  to minimum 128xFs to tak musi być. Można to jakoś obejść? Najprościej  zastosować Amanero, lub coś tak samo działającego i będzie dobrze, bo takie moduły generują też zegar MCLK. Ale to nie jest przez I2S tylko USB jeżeli popatrzymy na to z punktu widzenia Raspbery  Pi. Można to obejść też przez moduły odbiornika SPDIF z wyjściem I2S. To znowu nie przez I2S, tylko przez SPDIF. Da się przez I2S bezpośrednio z poprawnym sygnałem MCLK? Da się, i tak to zostało  tu zrobione. 
 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Oprócz magistrali I2C założyłem sobie, że mogę zastosować  separator galwaniczny sygnałów I2S, ale ostatecznie z niego zrezygnowałem. Płytka w teorii na to pozwala. Kolejnym założeniem było umieszczenie na płytce zworek łączących układ zewnętrznych konwerterów I/U  z wyjściami prądowymi przetwornika, tak by można było bez cięcia ścieżek odłączyć istniejący układ analogowy  podłączyć jakiś inny (tranzystory, lampy czy co kto tam chce).  Na płytce jest umieszczony  kompletny tor analogowy z konwerterami I/U i filtrami dolnoprzepustowymi realizowanymi na opampach. Opampy są w obudowach SMD i układ raczej się nie nadaje do "tuningu".  Mnie  układ analogowy na płytce odpowiada i na razie tak gra.  Zastosowałem tez trochę nietypowy (jak dla mnie) układ zasilania części analogowej PCM1794A oparty o układy TL431 i układ zasilania opampów oparty o elementy dyskretne.  W sumie nic odkrywczego, ale efekty tych działań są bardzo obiecujące.  C.D.N 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[Daniel_68412]

22 minuty temu, tomek_j napisał:

Nie żeby było coś nie tak z I2S

Akurat i2s z rpi jest słabe. Jak uda mi się poszukać link do bardzo dobrej analizy tematu to podeślę. Jeśli ma to jako tako grać to ok ale ma mocne ograniczenia by design.

[raven1985]

1 godzinę temu, tomek_j napisał:

F. Da się przez I2S bezpośrednio z poprawnym sygnałem MCLK? Da się, i tak to zostało  tu zrobione. 

rpi w slave mode na i2s  , master dla PCM z lokalnym generatorem MCLK.

[tomek_j]

Godzinę temu, Daniel_68412 napisał:

Akurat i2s z rpi jest słabe. Jak uda mi się poszukać link do bardzo dobrej analizy tematu to podeślę. Jeśli ma to jako tako grać to ok ale ma mocne ograniczenia by design.

Moduł I2S    jest modułem sprzętowym procesora BCM2711Raspberry Pi 4 . Dane wysyłane są buforowane w 64 bitowych buforach FIFO, a wszystkie sygnały interfejsu I2S są generowane w bloku taktowanym jednym zegarem PCM_MCLK. Nie wiem jak tak generowane sygnały interfejsu I2S miałoby być "słabsze" niż te odtwarzane z sygnału SPDIF przez układy odbiorników takich jak na przykład DIR9001 czy podobnych. 

25 minut temu, raven1985 napisał:

rpi w slave mode na i2s  , master dla PCM z lokalnym generatorem MCLK.

A co w takim przypadku z różnymi częstotliwościami próbkowania? 

[raven1985]

16 minut temu, tomek_j napisał:

A co w takim przypadku z różnymi częstotliwościami próbkowania? 

2 generatory i trzeba się przełączać.

Ktoś to ogarną już. Od strony sprzętu proste , od strony rpi już gorzej jak ktoś nie ogarnia linuxa (jak ja ? )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

 

alternatywa pll i generowanie mclk z bclk .

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[tomek_j]

1 minutę temu, raven1985 napisał:

alternatywa pll i generowanie mclk z bclk .

I tą drogą właśnie pójdziemy, ale to jutro  

[jar1]

24 minuty temu, raven1985 napisał:

Ktoś to ogarną już. Od strony sprzętu proste , od strony rpi już gorzej jak ktoś nie ogarnia linuxa (jak ja ? )

Można wsadzić WM8804 jako źródło zegarów i wykorzystać podłączenia i driver jak dla np. hifiberry digi + pro. 

Planuję coś takiego sobie zrobić. Jakoś nie mogę się zebrać?

Edytowane 17 Października 2020 przez jar1

[sybic]

ja uważam, że konfiguracja komputer -> DAC jest najwygodniejsza, wiec nie bardzo rozumiem te kombinacje  

[tomek_j]

1 godzinę temu, sybic napisał:

ja uważam, że konfiguracja komputer -> DAC jest najwygodniejsza, wiec nie bardzo rozumiem te kombinacje  

Ok - w takim razie ten DAC i watek nie jest dla Ciebie ?

Kontynuujemy: co z tym MCLK? Przy poszukiwaniach przetwornika połączonego z Raspberry Pi  przez I2S najczęściej wyskakiwał mi układ TI rodziny PCM510x.  Moduły z tymi przetwornikami nie potrzebowały sygnału MCLK, mimo że sam układ PCM miał wejście MCLK. Jak się okazało, ten DAC ma wbudowany wewnętrzny  układ PLL powielający zegar BCK. Zegar z wyjścia układu PLL może być wewnętrznym  sygnałem MCLK w przypadku kiedy interfejs I2S nie jest uzupełniany o taki sygnał zewnętrzny.  W przypadku PCM510x problem braku MCLK z wyjść I/O Raspbeery PI jest rozwiązany i pewnie dlatego tak chętnie jest wykorzystywany do budowy modułów DAC łączonych  z Raspberry Pi przez I2S. Ta idea mi się spodobała bo ma zalety: prostota wykonania i niezależność od częstotliwości próbkowania. Potrzebny będzie "tylko" układ PLL.  Powielenie częstotliwości i wygenerowanie sygnału MCLK powierzyłem układowi ICS570B produkowanemu przez firmę Renesas.  Wybór został podyktowany jego unikalnymi właściwościami:

 
- Zastosowaniem rozwiązania Zero Delay Buffer (ZDB). Powielony sygnał wyjściowy nie jest opóźniony w fazie z sygnałem wejściowym. Inaczej mówiąc nie ma opóźnienia pomiędzy zboczami sygnału wejściowego i wyjściowego.  

- Niskim itterem sygnału wyjściowego. Według danych katalogowych można osiągnąć  jitter sygnału wyjściowego na poziomie 50psek 

Współczynnik powielania ustawiany jest sprzętowo przez wymuszanie stanów na wejściach konfiguracyjnych S0 i S1. Możliwe jest ustawianie stanu niskiego, wysokiego i wejścia nie podłączonego (float).  W moim układzie na wejście ICLK jest podawany sygnał BCK o częstotliwości 64Fs. Wejścia S0 i S1 są nie podłączone i częstotliwość wejściowa jest mnożona przez 6. Sygnał wyjściowy CLK podawany na wejście SCK przetwornika ma częstotliwość 6x64fs = 384Fs.  Zegar systemowy PCM1794A akceptuje mnożniki 128fs, 192fs, 256fs 384fs, 512fs i 768fs. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

uprzedzając pytania 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )  

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[daris666]

2 godziny temu, sybic napisał:

ja uważam, że konfiguracja komputer -> DAC jest najwygodniejsza, wiec nie bardzo rozumiem te kombinacje  

Myślałem, że taka właśnie konfiguracja jest w tym wątku. 

[Muzg]

Kiedyś zastanawiałem się, dlaczego dźwięk z I2S komputera NanoPi NEO2 jest tak "dziwny". Podłączone to było do DACa ES9038PRO pracującego w trybie asynchronicznym, czyli bez udziału MCLK. Wsłuchiwałem się w ten dźwięk dość długo aż stwierdziłem, że coś za wolno to gra. Szybkie podłączenie częstościomierza do sygnału LRCK pokazało 44,050kHz. Dodatkowo częstotliwość cały czas pływała. Niestety nie da rady bez zegarów. Moduł Amanero rozwiązuje problem dość skutecznie, ale kusi tryb slave z dobrymi zegarami (co najmniej Crystek).

[jar1]

12 minut temu, Muzg napisał:

Szybkie podłączenie częstościomierza do sygnału LRCK pokazało 44,050kHz.

44,1 a 44,05 to niewielka różnica i wątpię, aby miało to wpływ na "szybkość". Natomiast mam przećwiczone puszczanie 44,1 na 48 i tu było już słychać "szybsze" granie. Efekt był całkiem ciekawy, tak, jakby dynamiczniej się wszystko działo. ?

Bez dwóch zegarów dla audio się nie obejdzie ?

Edytowane 18 Października 2020 przez jar1

[tjbox]

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[tomek_j]

40 minut temu, tjbox napisał:

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

no i...?  To co sobie zaprojektowałem nie jest czymś bardzo odkrywczym. Dotyczy to całego układu od interfejsu I2S poprzez przetwornik, układ zasilania po układ konwertera I/U i filtrów analogowych. Ktoś zrobił tak samo jak ja, albo ja zrobiłem tak jak ktoś dowodzi tylko tego że to rozwiązanie jest ok. Tak na marginesie rozważałem na początku inny układ powielacza:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Nawet kupiłem jeden z tej rodziny i napisałem fragment softu gadającego z tym układem, ale znalazłem  ICS570B dużo prostszy w implementacji, bo nie wymaga stosowania mikrokontrolera tylko po to by ustawić współczynniki powielania/podziału układu PLL.  Niezależnie co się tam da idea jest jedna: powielamy BCK by dostać MCLK.  

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 18 Października 2020 przez tomek_j

[Muzg]

18 minut temu, tomek_j napisał:

no i...?  To co sobie zaprojektowałem nie jest czymś bardzo odkrywczym. Dotyczy to całego układu od interfejsu I2S poprzez przetwornik, układ zasilania po układ konwertera I/U i filtrów analogowych. Ktoś zrobił tak samo jak ja, albo ja zrobiłem tak jak ktoś dowodzi tylko tego że to rozwiązanie jest ok. Tak na marginesie rozważałem na początku inny układ powielacza:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Nawet kupiłem jeden z tej rodziny i napisałem fragment softu gadającego z tym układem, ale znalazłem  ICS570B dużo prostszy w implementacji, bo nie wymaga stosowania mikrokontrolera tylko po to by ustawić współczynniki powielania/podziału układu PLL.  Niezależnie co się tam da idea jest jedna: powielamy BCK by dostać MCLK.  

Jeżeli komputer będzie odtwarzał ze złym tempem to uzyskasz MCLK z takim samym błędem.

1 godzinę temu, jar1 napisał:

44,1 a 44,05 to niewielka różnica i wątpię, aby miało to wpływ na "szybkość". Natomiast mam przećwiczone puszczanie 44,1 na 48 i tu było już słychać "szybsze" granie. Efekt był całkiem ciekawy, tak, jakby dynamiczniej się wszystko działo. ?

Bez dwóch zegarów dla audio się nie obejdzie ?

Taka różnica zmienia wszystkie częstotliwości dźwięków.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[tomek_j]

2 minuty temu, Muzg napisał:

Jeżeli komputer będzie odtwarzał ze złym tempem to uzyskasz MCLK z takim samym błędem.

 Jeżeli "złe tempo" rozumiemy przesyłanie materiału audio z częstotliwością inną niż został spróbkowanyw procesie zapisu, to będzie on nie poprawnie odtwarzany niezależnie od tego czy MCLK będzie wielokrotnością "prawidłowego" czy "błędnego" Fs. Sygnały zegarowe magistrali  I2S musza być wielokrotnością częstotliwości próbkowania, ale tej częstotliwości, którą określa zegar LRCK. Nie wiem co by było , gdyby na przykład LRCK = 45kHz, a MCLK był wielokrotnością 44.1KHz. Wolałbym żeby MCLK był wtedy wielokrotnością 45kHz, bo BCK będzie równe 64x 45kHz i w połączeniu z LRCK to te dwa zegary "mówią" DAC jak ma konwertować dane cyfrowe. 

Zresztą  to są wydumane problemy. Źródło sygnału ma poprawnie przesyłać dane i jeżeli tego nie potrafi, to nic się nie poradzi. W przypadku Raspberry Pi moje zgrubne pomiary częstotliwości LRCK za pomocą oscyloskopu zawsze wskazywały poprawne wartości 

[jar1]

30 minut temu, Muzg napisał:

Taka różnica zmienia wszystkie częstotliwości dźwięków.

Raczej długość grania danych dźwięków. Ciekawe doświadczenie to np odtworzyć sobie plik 192/24 na 96/24. Jest wszystko dużo wolniej, ale nie ma takiego efektu, jak np. wolniejszych obrotów płyty w gramofonie.

 

 

[Barbapapa]

Ten schemat z Elektora dawno mi chodził po głowie... Gdzie dostałeś ICS570B ? 

[tomek_j]

2 godziny temu, Barbapapa napisał:

Ten schemat z Elektora dawno mi chodził po głowie... Gdzie dostałeś ICS570B ? 

Mój przetwornik poza zastosowaniem ICS570B i PCM1794A nie ma wiele wspólnego ze schematem zamieszczonym wyżej. Ja ICS570B kupiłem na A...gro, ktoś sprzedawał za niewielkie pieniądze. Link do mousera podawałem w pierwszym poście. 

Parę słów o zasilaniu   

Przetwornik PCM1794A ma rozdzielone wyprowadzenie zasilania części cyfrowej i analogowej. Dotyczy to zarówno masy jak i wejść plusów zasilania. Układy cyfrowe są zasilane napięciem +3,3V ze scalonego stabilizatora  LT1763 3,3. To niskoszumny stabilizator LDO o wydajności prądowej 500mA . Napięcie +3,3V zasilające układy cyfrowe  DAC jest blokowane parą kondensatorów: elektrolitycznym 10uF/16V o niskim ESR  i ceramicznym 100nF.  Kondensatory są umieszczone na płytce drukowanej jak najbliżej wejść zasilających VDD i DGND. Tym samym napięciem +3,3V zablokowanym ceramicznym kondensatorem  o pojemności 100nF jest również zasilany układ  ICS570B.  Na temat blokowania zasilania kondensatorami napięć zasilających układy cyfrowe są różne zdania, każdy może sobie tam wlutować co zechce jak mu się zmieści na płytce.  
 

W części analogowej zastosowałem trochę nietypowe ( jak dla mnie)  zasilanie.  PCM1794A ma wyprowadzone osobne zasilanie części analogowej kanału lewego VCCL i kanału prawego VCCR, oraz wspólnej części analogowej VCC1 (+5V). Postanowiłem zasilić każde z tych wyprowadzeń z osobnego układu stabilizatora. Do stabilizacji został użyty stabilizator parametryczny z rezystorem szeregowym i układem TL431 (shunt regulator). Widziałem kiedyś podobny układ zasilania i postanowiłem go tutaj zastosować. Ponieważ w czasie projektowania nie byłem pewien jak to się sprawdzi to na płytce jest alternatywny układ zasilania układów analogowych DAC ze stabilizatora LT1763 5.0. Ostatecznie nigdy nie został wykorzystany, bo układy z TL431 sprawdziły się bardzo dobrze.   

 

Edytowane 18 Października 2020 przez tomek_j

[Muzg]

4 godziny temu, tomek_j napisał:

Jeżeli "złe tempo" rozumiemy przesyłanie materiału audio z częstotliwością inną niż został spróbkowanyw procesie zapisu, to będzie on nie poprawnie odtwarzany niezależnie od tego czy MCLK będzie wielokrotnością "prawidłowego" czy "błędnego" Fs. Sygnały zegarowe magistrali  I2S musza być wielokrotnością częstotliwości próbkowania, ale tej częstotliwości, którą określa zegar LRCK. Nie wiem co by było , gdyby na przykład LRCK = 45kHz, a MCLK był wielokrotnością 44.1KHz. Wolałbym żeby MCLK był wtedy wielokrotnością 45kHz, bo BCK będzie równe 64x 45kHz i w połączeniu z LRCK to te dwa zegary "mówią" DAC jak ma konwertować dane cyfrowe. 

Jeżeli LRCK, BCK i MCLK nie będą synchroniczne, to będą najnormalniej występować trzaski, szumy, szmery. Ale jak ich nie ma to nie oznacza, że wszystko gra. W momencie gdy I2S pracuje w trybie master, to PLL komputera generuje MCLK i to ona taktuje także odtwarzacz. BCK uzyskiwane jest właśnie z tego MCLK i jest obarczony tym samym błędem. Podobnie z LRCK. Tryb slave lub asynchroniczny konwerter sygnału USB pozwala na wprowadzenie do układu precyzyjnego MCLK które taktuje zarówno transmisje jak i decyduje o prędkości odtwarzania.

 

4 godziny temu, tomek_j napisał:

Zresztą  to są wydumane problemy. Źródło sygnału ma poprawnie przesyłać dane i jeżeli tego nie potrafi, to nic się nie poradzi. W przypadku Raspberry Pi moje zgrubne pomiary częstotliwości LRCK za pomocą oscyloskopu zawsze wskazywały poprawne wartości 

Przez te wydumane problemy współczesne komputery grają gorzej od odtwarzaczy CD wymyślonych w latach 70-tych - oczywiście nie wszystkie. Oscyloskop służy do obserwacji, nie pomiaru. Podczas pomiaru cytowanego wcześniej użyłem częstościomierza z wzorcem OCXO. 

4 godziny temu, jar1 napisał:

Raczej długość grania danych dźwięków. Ciekawe doświadczenie to np odtworzyć sobie plik 192/24 na 96/24. Jest wszystko dużo wolniej, ale nie ma takiego efektu, jak np. wolniejszych obrotów płyty w gramofonie.

Zachodzi wówczas zjawisko zwane transpozycją:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[tomek_j]

33 minuty temu, Muzg napisał:

Jeżeli LRCK, BCK i MCLK nie będą synchroniczne, to będą najnormalniej występować trzaski, szumy, szmery. Ale jak ich nie ma to nie oznacza, że wszystko gra. W momencie gdy I2S pracuje w trybie master, to PLL komputera generuje MCLK i to ona taktuje także odtwarzacz. BCK uzyskiwane jest właśnie z tego MCLK i jest obarczony tym samym błędem. Podobnie z LRCK. Tryb slave lub asynchroniczny konwerter sygnału USB pozwala na wprowadzenie do układu precyzyjnego MCLK które taktuje zarówno transmisje jak i decyduje o prędkości odtwarzania.

Trochę odbiegamy od tematu, bo interfejs I2S w Raspberry Pi nie pracuje w trybie Slave. Precyzyjnie rzecz ujmując może pracować w tym trybie przynajmniej tak podaje dokumentacja, ale na porty GPIO nie ma wyprowadzonego wejścia ( i jak wiemy wyjścia) sygnału MCLK.  Jesteśmy zdani na mniej lub bardziej precyzyjny wewnętrzny zegar taktujący komputerka i układ generowania sygnałów zegarowych dla układów peryferyjnych. Nie chcę przekonywać wszystkich, że połączenie przez I2S jest lepsze niż inne rozwiązania. Jest jakie jest i można go użyć, albo nie .  Konstrukcja jest wynikiem przyjęcia i zrealizowania pewnych założeń. Ma na pewno tę "wadę" że nie można gonić króliczka i wsadzić tego lub innego generatora i usłyszeć że jest lepiej lub gorzej. 

Co do pomiaru oscyloskopem to wyraźnie napisałem,  o "zgrubnym" pomiarze. Trochę wiem do czego on służy, ale nie będziemy tu się o to tu spierać.  

[krzysieks_2007]

Jeżeli plik audio w wyniku konwersji formatu ma transpozycję dobrze jest go odtworzyć programem VLC ,ma on funkcję rozciągania czasu dźwięku i to działa. 

Edytowane 18 Października 2020 przez krzysieks_2007

[Daniel_68412]

W dniu 17.10.2020 o 21:35, tomek_j napisał:

Nie wiem jak tak generowane sygnały interfejsu I2S miałoby być "słabsze"

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

O ten wpis mi chodziło. To była malina 1 więc może się zmieniło. Nie znam się na elektronice natomiast trochę się znam na linuxie. Pamiętam z zajęć że traktowanie systemu z wywłaszczaniem jako źródła taktowania nie jest dobrym pomysłem. Nawet jeśli jakaś część kodu chodzi niezależnie i asynchronicznie na dedykowanym procesorze względem  CPU to i tak alsa musi się do tego dostosować a ta już może być wywłaszczona przez kernel.

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[tomek_j]

2 godziny temu, Daniel_68412 napisał:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

O ten wpis mi chodziło. To była malina 1 więc może się zmieniło. Nie znam się na elektronice natomiast trochę się znam na linuxie. Pamiętam z zajęć że traktowanie systemu z wywłaszczaniem jako źródła taktowania nie jest dobrym pomysłem. Nawet jeśli jakaś część kodu chodzi niezależnie i asynchronicznie na dedykowanym procesorze względem  CPU to i tak alsa musi się do tego dostosować a ta już może być wywłaszczona przez kernel.

 

Mam z tym wpisem pewien problem. Autor przedstawia dość poważne zarzuty  nie poprawnego generowania sygnałów zegarowych. Problemem podstawowym nie jest brak możliwości wygenerowania dokładnej częstotliwości Fs, ale bardzo duże fluktuacje fazy zegarów . Nawet w tak starym komputerku to nie powinno mieć miejsca. Moduł I2S a właściwie PCM/I2S jest modułem sprzętowym z buforami FIFO, obsługą przerwań i może pracować pod kontrolą DMA. 

Wywłaszczanie jako źródło taktowania? W modułach sprzętowych źródłem taktowania są oscylatory, albo główny taktujący rdzeń, albo dodatkowe taktujące układy peryferyjne.  Źródło taktowania jest podawane na programowany układ generatora zegarów i tak bardzo elastycznie można zaprogramować potrzebną częstotliwość przez jej mnożenie i dzielenie. Zaprogramowany układ taktowania pracuje sprzętowo i w żadnym przypadku nie obciąża procesora, ale jego jakość zależy od głównego oscylatora. Albo ten pan zrobił sobie programowe PCM, albo coś tam było uszkodzone, albo Pan nie potrafił tego dobrze zmierzyć, Po wpisem jest znaczący komentarz:

"Czas trwania impulsów wydaje się wahać się między 11,33μS a 11,38μS.
Z „analizatorem logicznym” Saleae 24Msps nie można oczekiwać lepszych wyników - ponieważ błąd próbkowania takiego „instrumentu” wynosi 0,042μs."

 

To są moje przypuszczenia bo ja takich pomiarów nie robiłem. Używam Raspberry Pi 4 . Pomiędzy Rpi1 i RPI4 jest technologiczna przepaść i tamte wnioski raczej nie są aktualne. Przed rozpoczęciem prac na przetwornikiem trochę szukałem jak to jest ( tego materiału nie znalazłem) i niczego niepokojącego nie znalazłem. Jest mało DAC dla RPi przez I2S z lepszymi przetwornikami ale to może być wynikiem braku MCLK na magistrali. Za to jest sporo nakładek zasilanych tym samym napięciem +5V co komputerek robionych na bazie PCM510x. 

Jeżeli ktoś poważnymi pomiarami potwierdzi, że zegary I2S bezpośrednio z RPi 3, lub RPi4  mają tak słabe parametry przy sygnale z na przykład playera Volumio (soft ma znaczenie)   to oczywiście jest słabo. Jednak na moje ucho jest dobrze, na pewno nie gorzej niż przy sygnale z odbiorników SPDIF DIR9001, lub WM8804.  Zawsze można do wejść I2S tego DAC podłączyć konwerter USB  i wszystko będzie działało. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 19 Października 2020 przez tomek_j

[Daniel_68412]

5 minut temu, tomek_j napisał:

Wywłaszczanie jako źródło taktowania?

Przepraszam, użyłem skrótu myślowego. Miałem na myśli, że malina ma system operacyjny, z którym trzeba się liczyć. Wiem, że gdzieś tam jest układ sprzętowy z 1 kodem na pętli jak np w arduino gdzie kontrolujesz każdy takt. Jednak źródło audio jest w linuxie a i2s nie jest projektowany że czasem będzie musiał poczekać - w sensie na pewno mniej niż protokół usb. To takie spojrzenie totalnego laika, nie chce kolegi zniechęcać czy coś.

[tomek_j]

Raspberry Pi nawet  wersji 1 ma zasoby pozwalające na bezproblemowe przesyłanie strumienia danych audio przez port I2S. To nie jest jakieś bardzo wymagające zadanie. Ja używam Raspberry Pi 4 i dla tego komputerka "granie" nie jest żadnym obciążeniem.  Temu zadaniu podoła nawet prosty 16, czy nawet 8 bitowy mikrokontroler pod warunkiem posiadania sprzętowego modułu I2S i sprzętowego modułu czytającego dane audio np  USB , czy Ethernet.  Wydaje mi się, że JarekC popełnił tu konwerter USB/I2S z TAS1020 (lub podobnym). Tam mikrokontroler sterujący to 8 bitowy 8051 i wszystko działa jak powinno bo cała robotę robią układy peryferyjne, a mikrokontroler je tylko inicjuje i być może robi coś jeszcze mało wymagającego

Odtwarzanie danych audio może wyglądać tak (w RPi ale też w konwerterze USB/I2S typu Amanero):  z otwartego pliku audio umieszczonego gdzieś w pamięci masowej ( HDD)  przez interfejs komunikacyjny  USB przesyłane są dane do bufora w pamięci RAM komputerka o wielkości na przykład 4kB. Z tego bufora RAM soft palyera pobiera dane   o długości 64 próbek 32 bitowych  do bufora FIFO modułu PCM/I2S. Dane z bufora są wysyłane kolejno przez port I2S do DAC. Jeżeli bufor FIFO się opróżni na przykład do połowy, to jest generowane przerwanie i komputer jak ma czas to ładuje znowu bufor FIFO do pełna z bufora pamięci RAM . Jeżeli używany do tego DMA to sprawa się sprowadza do zainicjowania kanału i dalej wszystko się dzieje bez udziału procesora.  Bufor w pamięci RAM może się zapełniać analogicznie. Soft sprawdza czy zostało na przykład wyczytanych 50% danych i inicjuje transfer danych przez USB z pliku do bufora RAM.  Przy prawidłowo napisanym sofcie nie ma możliwości gubienia danych, a zegary są generowane sprzętowo. Jedyny "problem" to jakość zegara MCLK generowanego przez procesor Raspberry Pi.  Być może jest to bardzo przyzwoity zegar i dopóki go ktoś nie zmierzy dokładnie: wartość częstotliwości, jej stabilność krótko i długookresowa, jitter itp to możemy tylko dywagować.      

 

[tomek_j]

Wróćmy do zasilania części analogowej przetwornika. Jak już wspominałem zasilanie każdego z kanałów i zasilanie części wspólnej ma swój układ stabilizatora oparty na układzie "programowanej diody Zenera" czyli TL431. Napięcie wyjściowe jest programowane dwoma rezystorami 1kohm, i wynosi dwukrotność napięcia referencyjnego czyli ok +4,9V. Ważne żeby różnica napięć pomiędzy VCC1, VCC2R i VCC2L nie była większa niż 0,1V.  Napięcie wejściowe VADAC jest dostarczane z zewnętrznego zasilacza i ma wartość ok +8V. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[Waldi_06]

>tomek_j
prosty i fajny pomysł,
kiedyś chciałem zastosować ICS502 w jakimś układzie, mam ich kilka.
kibicuję.
z chęcią zakupię.

[RatsRex]

W dniu 19.10.2020 o 11:36, tomek_j napisał:

  Zawsze można do wejść I2S tego DAC podłączyć konwerter USB  i wszystko będzie działało. 

A ja to problem potrzeby i braku pełnego zestawu sygnałów I2S z RPi do PCM1794 rozwiązałem przez nakładkę AK4137.  (Pomijając konwersje rozdzielczości i częstotliwości sygnału PCM działa jako reclocker, oczywiście z przymknięcie oka na to jakiej jakości generatory są tam zastosowane - ale raczej wychodzi to znacznie lepiej niż z samego RPi)

Tak na marginesie to zastanawiam się na ile jest prawdopodobne ze ta wCiry płytka ma oryginalne wzmacniacze operacyjne TI NE5534 i NE5532. 
Generalnie jednak udowadnia tezę (słusznie zresztą postawiona przez Waldi_06) że dwie kości DAC-a zamiast jednej cudów poza 3dB nie uczynią) , stopień wyjściowy to cała tajemnica wiary ?

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 1 Listopada 2020 przez RatsRex
rozszerzenie

[jar1]

1 godzinę temu, RatsRex napisał:

A ja to problem potrzeby i braku pełnego zestawu sygnałów I2S z RPi do PCM1794 rozwiązałem przez nakładkę AK4137.  (Pomijając konwersje rozdzielczości i częstotliwości sygnału PCM działa jako reclocker, oczywiście z przymknięcie oka na to jakiej jakości generatory są tam zastosowane - ale raczej wychodzi to znacznie lepiej niż z samego RPi)

Jak mi sią wydaje, ta nakładka działa w trybie slave dla I2S maliny.

Czy są oprócz,  np hifiberry digi plus pro (WM8804),  na AKMach nakładki działające w trybie master dla I2S?  Żeby było z dsd?