Jplay

[michelangelo]

... A ekwipotencjalizacja ładunków na szczelnym metalowym i jednorodnym ekranie, wcale nie powoduje, że staje się on nieprzeźroczysty dla fal ekektromagnetycznych, o długości większej niż "otwory" w ekranie, czyli większej niż odległości między atomami metalu? No jeśli tak, to sorry, faktycznie nie wiem jak potrafi zachowywać się klatka Faradaya, o bardzo małych "oczkach". Nie jestem w stanie z tym polemizować, tak samo jak z twierdzeniem, że Ziemia jest płaska. Może jednak wsadź radio na UKF do kuchenki mikrofalowej i spróbuj odebrać RMF na 96MHz? Zobaczymy czy Ci się uda, a w ekranie kuchenki otwory są "ciut" większe, niż odległości pomiędzy atomami w obudowie rezonatora kwarcowego. Albo wsadź tam telefon i na niego zadzwoń. A właśnie, na jakieś częstotliwości pracuje telefon GSM? Ciut więcej, niż te kilkadziesiąt MHz, a dalej fale nie przechodzą przez te "ogromne" otwory w ekranie kuchenki.

No i widzisz... akurat im większa częstotliwość fali, tym mniejsza głębokość wnikania. Dlatego gigaherce można sobie zaekranować cieniutko, ale obudowa kwarcu to tak powiedzmy 1% tego, co by spowodowało całkowite odbicie fali do wewnątrz, jak to masz w mikrofalówce. Oczywiście, wysokie harmoniczne powstrzyma, ale te pierwsze kilka, kilkanaście, nie za bardzo. Zresztą weź klocek ferrytowy i przystaw słuchając, najlepiej przez słuchawki, bo nie będziesz musiał robić żadnych przemieszczeń. Gdyby to pole nie wychodziło, to by taki ferryt nic nie robił, bo niczego by nie przewodził magnetycznie. Tymczasem poprzez spadek reluktancji przy "nadajniku" ściągasz prawie całe pole rozpraszające się po urządzeniu i wywołujące interferencję z innymi układami, indukując się w ścieżkach.

 

Oczywiście to powyższe to autosugestia, zbiorowa halucynacja, teleportacja percepcji słuchowej, omamy, itp. Dlatego można stwierdzić czy kwarc sieje dużo prościej i zgodnie z propagowanymi przez kolegów metrologów metodami. Robimy sobie cewkę powietrzną z drutu, kilka zwojów średnicy 5mm powinno styknąć. Zapinamy ją na sondę oscyloskopu, ustawiamy odpowiednią czułość i podstawę czasową na nim, zbliżamy cewkę do kwarcu i patrzymy. Kręcimy cewką tak, żeby ustalić jednoznacznie skąd pole wychodzi - z kwarcu, ścieżek PCB, a może układu wzbudzającego? Jak ktoś nie lubi uszami, to może oscyloskopem.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[marekzawa]

Może jednak wsadź radio na UKF do kuchenki mikrofalowej i spróbuj odebrać RMF na 96MHz? Zobaczymy czy Ci się uda, a w ekranie kuchenki otwory są "ciut" większe, niż odległości pomiędzy atomami w obudowie rezonatora kwarcowego.

 

Jak włączy kuchenkę to zagra :)

 

 

Michelangelo proponuje obejrzeć filmik dla rozjaśnienia wiedzy.

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ą )

[Gość SlawekR]

No i widzisz... akurat im większa częstotliwość fali, tym mniejsza głębokość wnikania. Dlatego gigaherce można sobie zaekranować cieniutko,

 

Oo, to nowość. Jednak nie znam zasady działania klatki Faradaya. Co prawda zawsze było dokładnie na odwrót jak piszesz, no ale może coś się zmieniło.....

 

Zawsze było tak, że im większa częstotliwość, tym większa głębokość wnikania, gdyż do nieprzeźroczystości elektromagnetycznej, klatka musiała być bardziej szczelna i mieć mniejsze otwory.

Co jest logiczne zważywszy, że im większa częstotliwość - mniejsza długość fali, tym mniejsze muszą być otwory w klatce aby falę zatrzymać. A im mniejsze częstotliwości, tym klatka może być rzadsza. Co zresztą znajduje odzwierciedlenie w praktyce, gdzie w samochodzie, bez anteny zewnętrznej, na falach długich radia nie posłuchasz, pomimo ogromnych otworów w postaci okien, za to przez telefon komórkowy spokojnie porozmawiasz, bo pracuje na większej częstotliwości, no ale skoro piszesz, że jest inaczej, to pewnie musi to być nowa fizyka.

 

Naprawdę, dobrze radzę, zakończmy dyskusję na ten temat, bo zaczyna robić się coraz dziwniej, przez grzeczność nie chcę pisać że zabawniej :).

 

 

ale obudowa kwarcu to tak powiedzmy 1% tego, co by spowodowało całkowite odbicie fali do wewnątrz, jak to masz w mikrofalówce. Oczywiście, wysokie harmoniczne powstrzyma, ale te pierwsze kilka, kilkanaście, nie za bardzo. Zresztą weź klocek ferrytowy i przystaw słuchając, najlepiej przez słuchawki, bo nie będziesz musiał robić żadnych przemieszczeń. Gdyby to pole nie wychodziło, to by taki ferryt nic nie robił, bo niczego by nie przewodził magnetycznie. Tymczasem poprzez spadek reluktancji przy "nadajniku" ściągasz prawie całe pole rozpraszające się po urządzeniu i wywołujące interferencję z innymi układami, indukując się w ścieżkach.

 

Naprawdę, proszę Cię wróćmy do mieritum wątku. Raz, że Kolega Stasiop chce chronić rezonator przed wpływem zewnętrznym, a nie na odwrót. A dwa, to patrz pierwszy akapit na temat częstotliwości. Cóż mogę więcej napisać.

 

Oczywiście to powyższe to autosugestia, zbiorowa halucynacja, teleportacja percepcji słuchowej, omamy...

 

Nie chcę się wdawać w polemiki co kto słyszy, jak i dlaczego i na podstawie jakich teorii, prawdziwych, czy też błędnych. Znam osoby, które demagnetyzują nośniki CD i znacznie lepiej im grają, znam takich co słuchają CD postawionego na szklankach i lepiej gra, są też cacy którym "grają" routery i kable LAN w odtwarzaczach strumieniowych, anawet WiFI. Więc czemu nie ma grać ferryt przyłożony do obudowy rezonatora, szczególnie jeśli po przyłożeniu, wpłynie na zmniejszenie drgań rezonatora, z czym się akurat zgadzam :)

 

To tyle w tym temacie. Jeszcze raz gorąco namawiam, wróćmy do meritum i sposobu przenoszenia jittera z danych nieprzezegarowanych z komputera, do konwertera asynchronicznego i jak się ma do tego jittera Jplay. A, o co zapytałem na końcu poprzedniego postu, gdyż bardzo jestem ciekaw dróg przenoszenia tegoż jittera.

 

Jak włączy kuchenkę to zagra :)

...

 

O. I to jest merytoryczne podejście. Kolega rzeczowo wykazał lukę w moim rozumowaniu. Chwała Mu za to :-).

 

NA swoją obronę mam tylko to, że i owszem zagra, ale tylko raz i tylko przez chwilę. No i muzyka jaka z tego popłynie będzie zdecydowanie nieprzyjemna, a poziom jitteru poza wszelkimi granicami ;-))).

[michelangelo]

Włożyłem telefon komórkowy do mikrofalówki, drzwiczki zamknąłem dokładnie. Słuchawka Bluetooth przestaje widzieć telefon. Wysłałem SMSa z netu. Odebrany bez błędów i opóźnień wewnątrz mikrofali. Czyli nowa fizyka już działa. Teraz jeszcze artykuł o rozpływie indukowanych prądów, jakby się ktoś upierał, że głębokość wnikania rośnie z częstotliwością.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Oczywiście zaraz ktoś tu na mnie naskoczy, że to jest o prądach i skąd one, ale ja odpowiem od razu - wirowe, od pola. A ponieważ prąd wirowy zmienny generuje zmienne pole magnetyczne, a to znowu zmienne pole elektryczne, to mamy efekt odbicia fali od przewodnika. Przecież tak właśnie działa mikrofalówka, bo jakby pochłaniała pole zamieniając je na prądy wyrównawcze w klatce Faradaya (taka jest jej zasada działania w wolno zmiennym polu), to by się zamiast jedzenia ugotowała sama mikrofalówka. :) Zresztą, co ja się tu będę produkował.

Zasada działania

 

Mikrofale wprawiają cząsteczki wody znajdujące się w nagrzewanym ciele w drgania rotacyjne. Energia drgających cząsteczek wody' date=' w wyniku silnego tłumienia drgań rozprasza się i jest przekazywana cząsteczkom podgrzewanego ciała – tym samym rośnie jego energia termiczna (zob. ciepło), a zatem i temperatura. Zjawisko to odkrył przypadkowo amerykański inżynier Percy Spencer podczas badań nad wytwarzaniem fal elektromagnetycznych stosowanych w urządzeniach radarowych (częstość 1 – 40 GHz)[1']. Dzięki temu odkryciu w 1947 r. wprowadzono na rynek pierwsze kuchenki. Pierwsza kuchenka mikrofalowa nazywała się Radar Range i była dużych rozmiarów – 1,8 m wysokości, oraz miała dużą masę – 340 kg.

 

Metalowa komora mikrofalówki wraz z siatką wbudowaną w szybę drzwiczek stanowią istotne elementy konstrukcyjne zaprojektowane tak, by odbijać mikrofale do wewnątrz kuchenki i nie dopuszczać do ich emisji na zewnątrz. Oczka siatki muszą być małe, znacznie mniejsze od długości fali (ok. 12,2 cm)[1]. W mechanizmie zamka drzwiczek znajduje się wyłącznik mający za zadanie odciąć zasilanie magnetronu w przypadku ich otwarcia, zanim mogłoby dojść do przypadkowych oparzeń wywołanych nieszczelnością ekranowania podczas otwierania i zamykania drzwiczek.

Dobór częstotliwości mikrofal

 

Płynna woda, z powodu bardzo silnego tłumienia drgań nie posiada wyraźnego maksimum rezonansowego, lecz pochłania silnie fale elektromagnetyczne w dość szerokim zakresie częstotliwości mikrofalowych. Częstotliwość mikrofal kuchenki musi mieścić się tym zakresie i jest wynikiem kompromisu pomiędzy dostępnymi częstotliwościami w paśmie ISM (Industrial, Scientific, and Medical band) a głębokością wnikania fal (która jest odwrotnie proporcjonalna do stopnia ich pochłaniania). Przy częstotliwości 2,45 GHz cząstki wody drgają na tyle szybko, by zapewnić dobre pochłanianie a tym samym i szybkie ogrzewanie potrawy, lecz mikrofale wnikają w głąb tylko na około 2,5 cm (w zależności od zawartości wody w ogrzewanym produkcie). Przy niższych częstotliwościach fale wnikałyby głębiej, lecz przenikałyby przez cienkie struktury – tym samym ogrzanie potrawy mogłoby trwać dłużej.

 

Rodzaj nagrzewanych substancji

 

Transfer energii z fal elektromagnetycznych do materiału podgrzewanego jest efektywny wówczas, gdy materiał ogrzewany zawiera wodę, także w postaci związanej, lub gdy inne jego cząsteczki chemiczne mają częstość drgań leżącą w zakresie emitowanych mikrofal. Własność tę mają praktycznie wszystkie potrawy, które wymagają podgrzania w kuchni. Metale odbijają mikrofale i nie nagrzewają się istotnie, jednak gdy w kuchence nie ma ciał pochłaniających energię mikrofal, w wyniku wielokrotnych odbić natężenie prądów wirowych w metalowej obudowie kuchenki jest tak duże, że nagrzewa nawet metalową obudowę. Większość ceramik, szkło i plastiki są przezroczyste dla mikrofal dlatego słabo nagrzewają się w kuchenkach mikrofalowych.

 

Niebezpieczeństwa

 

Przedmioty metalowe

 

Do kuchenek nie mogą być wkładane przedmioty metalowe (z wyjątkiem jednolitych talerzy i tacek) – mikrofale nie przenikają przez metal, ale wywołują w nim prądy wirowe, przez co dochodzi do silnego nagrzewania, a nawet iskrzenia w miejscu gdzie metal jest cienki (np. złocenia ceramiki) oraz w miejscach słabego styku dwóch kawałków metalu a także na ostrych krawędziach i szpicach. Silne nagrzewanie się elementów metalowych i iskrzenie może wywołać zapłon podgrzewanych produktów[1]. Potrawy w naczyniach metalowych (a także zawinięte w folie aluminiowe), poprzez właściwości ekranujące, nie są nagrzewane bezpośrednio przez mikrofale.

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ą )

[Lumperator]

Aż telefon musiał znaleźć się w mikrofalówce, żeby można było dalej toczyć temat o odtwarzaczu muzycznym :P

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Stasiop]

Z plasteliną to akurat nie jest dobry ani potrzebny pomysł. Można spokojnie przykleić ferryt do kwarcu, bo zwiększając jego masę spada jego zdolność mikrofonowania (nie widzę zresztą problemu) poprzez wzrost bezwładności, a jak się jeszcze ten sam ferryt jednocześnie chwyci do podłoża kroplą kleju, to już w ogóle oscylator jest zablokowany na sztywno.

No nie wiem nie kleilem nigdy ferrytu do kwarcu ale plastelina ma sens bo tu moze chodzic o niskie czestotliwosci. W kazdym badz razie slychac to i wcale nie malo:)

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Gość SlawekR]

Aż telefon musiał znaleźć się w mikrofalówce, żeby można było dalej toczyć temat o odtwarzaczu muzycznym :P

 

Jak widać dokładnie tak :-). Dlatego nie zamierzam ciągnąć wątku ekranowania, a wróćmy do kwestii Jplaya i ostatnio podnoszonej opcji, czyli do rozważań na temat jittera i przypuszczeń, że poprzez jego redukcję, wpływa on (Jplay) na dźwięk. Ta kwestia podnoszona jest przez Kolegę Stasiop.

 

Ja to widzę tak, przynajmniej na stan mojej wiedzy. Jitter może być transportowany pod postacią zakłóceń wysokoczęstotliwościowych po liniach sygnałowych, po których przesyłany jest użyteczny sygnał cyfrowy. A jak wiadomo sygnał cyfrowy, to tak naprawdę przebieg analogowy, zazwyczaj prostokątny, który dopiero staje się nośnikiem informacji zero-jedynkowej , a to dzięki przyjęciu umownych wartości napięć, odpowiadających logicznego zeru i jedynce. W takim analogowym przebiegu, oczywistym jest, że może znajdować się składowa zakłócająca, która ten przebieg zniekształca, powoduje nieprawidłowości w detekcji przełączeń pomiędzy stanami zero jeden i z powrotem. Czasem też, zakłócenia mają tak wysoką częstotliwość, że sam przebieg nie jest zbytnio zniekształcony, za to same zakłócenia wpływają na działanie układów cyfrowych logiki, które też przecież są tak naprawdę analogowe, a tylko starają się zbliżyć do ideału cyfrowego układu przełączającego.

Tą drogą, to znaczy po liniach sygnałowych, a już nie daj Boże zasilających, jeśli kolejny układ jest zasilany z tego samego źródła, mogą przenosić się zakłócenia generujące jitter. To jest dla mnie oczywista oczywistość.

Nazwę tę drogę A, to dla uproszczenia dalszej dyskusji.

 

Kolejną drogą dla transportu jittera, może być przebieg zegarowy, przy synchronicznym przesyłaniu strumienia danych, taktowanych tym właśnie zegarem. Źródłem jittera w tym przypadku jest niestabilność zegara, niedoskonałość jego zboczy na przykład i tym samym możliwość pojawienia się zniekształceń fazowych. To też jest dla mnie jasne i oczywiste. Oznaczę tę drogę transportu jittera literką B.

 

Innych metod na przedostanie się jittera do układu jak na razie nie znam, ale jeśli ktoś zna to bardzo proszę o dopisanie, jeszcze trochę alfabetu nam zostało :-).

 

Zastanówmy się więc, nad naszym systemem. Jitter przenoszony wraz z zegarem, czyli B można wyelimonować, usuwając synchroniczny przebieg zegarowy z transmisji danych. Do tego właśnie przydaje się asynchroniczny konwerter USB, który przyjmuje dane nieprzezegarowane zegarem końcowym. A tworzy go dopiero sam, na podstawie własnego zegara referencyjnego i informacji o częstotliwości, jaką przebieg wyjściowy ma być przetaktowany. Oczywistym jest, że jitter typu B, który musi się pojawić w sygnale wyjściowym jest ściśle i silnie zależny, wyłącznie od jakości samego konwerter asynchronicznego, jakości jego zegara referencyjnego, jakości układów zasilających zegar i sam konwerter, filtrów, układów odsprzęgających itp. itd. Im lepszy konwerter, tym mniejszy będzie jitter na jego wyjściu. I w tę część systemu warto inwestować zawsze i wszędzie. jasnym też jest że na jitter typu B nie będzie mieć wpływu to co się dzieje przed konwerterem, albo wpływ ten będzie marginalny, jeśli tylko konwerter jest wystarczająco dobrej jakości.

 

Zastanówmy się teraz nad jitterem przenoszonym drogą A. Tu już nie jest tak miło. Aby od tego jitteru odciąć się możliwie najlepiej, należy spełnić kilka istotnych warunków. Z zakłóceniami o bardzo wysokiej częstotliwości, znacznie wyższej niż częstotliwość sygnału użytecznego, można powalczyć dość łatwo. Wystarczy zastosować układ separujący, o odpowiednio dobranym paśmie prznoszenia, dopasowanym do sygnału użytecznego, a naturalnie nie przepuszczającym zakłóceń wcz.

Taki układ separujący, transformator lub optoizolator, przy okazji powoduje galwaniczną izolację naszego konwertera od źródła czyli komputera. Oczywiście nadal przez linię transmisyjną mogą przenikać zakłócenia, o częstotliwości zbliżonej do użytecznej naszego sygnału. Ale z tym też można powalczyć, na przykład poprzez zastosowanie odpowiednich interfejsów i protokołów transmisyjnych z nimi powiązanych, które z natury rzeczy nastawione są, na nie przenoszenie i na walkę z zakłóceniami. Mowa choćby o sieci LAN, WiFi. Są nawet dość ciekawe układy USB over LAN. A jeśli już podłączamy się bezpośrednio interfejsem USB, to na pewno warto zadbać o osobne zasilanie konwertera asynchronicznego. Zasilanie go, z USB z komputera, to moim zdaniem, największe możliwe źródło przenikania zakłóceń, gdyż stabilizatory napięcia, do zasilania portów USB, mieszczą się głęboko w strukturze płyty głównej, często blisko sekcji zasilającej procesor, który pracuje z ogromnymi częstotliwościami. Warto na pewno postarać się też, o wspomniany już, układ separacji galwanicznej, który przy okazji ma użyteczne pasmo, możliwie dopasowane do naszego sygnału użytecznego. Stosowanie szybszych, o szerszym paśmie, układów, w tym kontekście, wydaje się nie być dobrym pomysłem.

 

Niebawem postaram się odnieść, jak i co, w tym kontekście może zrobić Jplay, w odniesieniu do jego ceny i możliwości i patrząc na zwykłą logikę.I tak już elaborat wyszedł zdecydowanie za długi, jak na jeden post. Więc podzielę go na kilka. W każdym razie, mam nadzieję, że jak na razie jest wystarczająco merytorycznie i bez voodoo.

[Stasiop]

Zabawa z ekranowaniem magnetycznym i elektrostatycznym powinna współgrać z odpowiednią dyscypliną zasilania globalnego i lokalnego układów cyfrowych, poczynając od takich banałów jak pętle masy i łączenie jej sekcji cyfrowej z "analogową", czyli tą odpowiedzialną za PLL na przykład.

Hihi rozbawilo mnie tu slowo banałów jesli chodzi o masy. Przeciez to chyba najbardziej skomplikowana czesc pracy inzynierskiej w przypadku audio ;)

 

Fajnie, że ktoś próbuje wyjaśnić, iż "asynchroniczność" to jest wada, a nie zaleta, co wbijają do głowy na studiach kierunkowych podczas kursu techniki cyfrowej,

Asynchronicznosc to jednak zaleta jest tylko ze obarczona istotna wada ktora ciezko ludziom zrozumiec, tak bym to bardziej ujal. Ale dlugie FIFO i asynchronicznosc powinne te wszystkie rozwazania zalatwic jednym cieciem, tak uwazam.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Gość SlawekR]

........

Asynchronicznosc to jednak zaleta jest tylko ze obarczona istotna wada ktora ciezko ludziom zrozumiec, tak bym to bardziej ujal. Ale dlugie FIFO i asynchronicznosc powinne te wszystkie rozwazania zalatwic jednym cieciem, tak uwazam.

 

Przybliż jeśli możesz, "Wadliwość" rozwiązania konwersji asynchornicznej w interesujących nas zastosowaniach. Kolega wcześniej napisał dośc ogólnikowo, całkowicie "niepoważając" taką metodę transmisji, z gruntu uznając ją za złą. Co akurat dość trudno mi zaakceptować w tym konkretnym zastosowaniu. Dla mnie zalety są zdecydowanie przeważające.

 

Ale Ty jednak widzisz jej zalety, tak samo jak ja. Co już jest podstawą do dalszej dyskusji :). Oczywiście chętny jestem do rozważań na temat wad. Bo dzięki temu, będzie można, przynajmniej postarać się, te wady zminimalizować.

[Stasiop]

To tak jakby twierdzić, że przesłanie piosenki mailem da inny poziom jittera na wyjściu konwertera asynchronicznego, niż przeniesienie tej piosenki na pendrive, albo przewiezienie na dysku ssd. Do tego się to sprowadza. A w zasadzie do twierdzenia, że dane komputerowe nie podlegające taktowaniu, są źródłem i nośnikiem jittera, w zależności jak je potraktujemy, patrz mail, pendrive.

 

Ja rozumiem zapędy Kolegi StasioP do powiązania elektrycznego połączenia układu 1 i 2, jako nośnika zakłóceń, tyle że jest taki mały detal, te układy mogą nie być połączone elektrycznie, patrz wspomniany Rdac z WiFi, na TASie zresztą. Jedyne połączenie obu urządzeń to czysta informacja i to nieprzezegarowana, więc niestabilność zegara, którego po prostu nie ma, nie może być źródłem jittera. Idealnym przykładem mogą być urządzenie pracujące na protokole airplay Apple, wiele urządzeń audio może się tak komunikować i nie będą połączone elektyrcznie. Jak prześlę bezprzewodowo z Macbooka strumień Audio z Itunes, do urządzenia na tym protokole, to gdzie szansa żebym przesłał sygnał z jitterem pierwotnym? Nie ma na to szans.

 

Jak nie ma zegara??? oczywiscie ze jest oba urzadzenia chodza na odrebnych zegarach ale ten pierwszy zegar zmodulowany jest zakloceniami zrodla czyli w tym wypadku komputera. Drugi zegar zmodulowany jest tym pierwszym bo tryb asynchroniczny to nie jest cos idealnego on musi podazac za tym pierwszym zegarem a wszystko odbywa sie na zawrotnych predkosciach i tych modulacji jest tysiace moze miliony.

Jak przeslesz piosenke mailem to sie nic nie dzieje, bo chodzi o odtwarzanie w czasie rzeczywistym. Ale jesli zrobisz taki eksperyment i nagrasz ta sama piosenke na dwoch roznych pendrivach nawet dokladnie tych samych co do nalepek na nich(wewnetrznie beda sie zawsze roznic, taka jest technologoa pendrivow). To zauwazysz roznice w brzmienich. Robiono takie eksperymenty. Bo chodzi o to ze to sie wtedy podczas odtwarzania bedzie modulowac w zaleznosci od wewnetrznej struktury pena jego bledow wewn metod obliczania sum kontrolnych i wyliczania poprawnych wartosci matematycznie.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Gość SlawekR]

Jak nie ma zegara??? oczywiscie ze jest oba urzadzenia chodza na odrebnych zegarach ale ten pierwszy zegar zmodulowany jest zakloceniami zrodla czyli w tym wypadku komputera. Drugi zegar zmodulowany jest tym pierwszym bo tryb asynchroniczny to nie jest cos idealnego on musi podazac za tym pierwszym zegarem a wszystko odbywa sie na zawrotnych predkosciach i tych modulacji jest tysiace moze miliony.

Jak przeslesz piosenke mailem to sie nic nie dzieje, bo chodzi o odtwarzanie w czasie rzeczywistym. Ale jesli zrobisz taki eksperyment i nagrasz ta sama piosenke na dwoch roznych pendrivach nawet dokladnie tych samych co do nalepek na nich(wewnetrznie beda sie zawsze roznic, taka jest technologoa pendrivow). To zauwazysz roznice w brzmienich. Robiono takie eksperymenty. Bo chodzi o to ze to sie wtedy podczas odtwarzania bedzie modulowac w zaleznosci od wewnetrznej struktury pena jego bledow wewn metod obliczania sum kontrolnych i wyliczania poprawnych wartosci matematycznie.

 

Ja nie twierdzę, że transmisja asynchroniczna, nie ma zegara, bo oczywistym jest, że tak być nie może. Takie twierdzenie byłoby pozbawione sensu. Ale zegar bufora ramki asynchronicznej, w dobrze zrealizowanym układzie, nijak nie jest powiązany z zegarem transmisji synchronicznej na wyjściu.

 

Zegar transmisji asynchronicznej nie bierze udziału w generowaniu zegara wyjściowego. W naszym przypadku ma on charakter wyłącznie pomocniczy, wyznacza sloty służące do asynchronicznego przesyłania porcji danych komputerowych. Podkreślam, danych komputerowych. Tak samo jak zdjęć, dokumentów Worda itd. Różnica jest tylko taka, że dane komputerowe potencjalnie zawierające informację audio, posiadają też informację o zegarze jakim te dane powinny zostać przetaktowane na wyjściu. Informację, a nie takt zegarowy, który mógłby być źródłem jittera. Tak samo jak zdjęcia zawierają informację, o metodzie zastosowanej kompresji, na przykład jpeg. Ewentualny jitter od taktu bufora ramki, nie będzie mieć wpływu na jitter zegara wynikowego, gdyż ten drugi nie jest tworzony z udziałem i na podstawie tego pierwszego. A powstaje całkowicie od nowa i zostaje "wpleciony" w nowy synchroniczny sygnał wyjściowy. Oczywiście to wszystko przy założeniu odpowiednio dobrej aplikacji konwertera asynchronicznego. Co innego z konwerterze Isosynchronicznym, ale nie tutaj.

 

Taką tezę potwierdza zwykła praktyka.

Zauważ, że transfer danych asynchronicznych, może się odbyć na wiele sposobów, na przykład poprzez LAN, czy tez WiFi, a wtedy mamy kolejny zegar bufora ramki. W sieci 100Mbit inny,w gigabitowej inny i to jest kolejny zegar po drodze, który jeszcze bardziej rozdziela zegar z komputera, będącego źródłem audio, od zegara na wyjściu konwertera. I jakoś odbywa się to bez jakiejkolwiek dalszej szkody na sygnale.

 

Gdyby było inaczej, to nie byłbym w stanie prawidłowo napisać tego posta. Aż trudno sobie wyobrazić, przez ile zegarów taktujących bufory ramek, przechodzi informacja, którą napisałem na swoim komputerze, zanim dotrze na serwer Audiostereo, przez 10, 20, 50? Gdyby kolejne zegary były modulowane zegarami wcześniejszymi i przenosiły się za ich pomocą zakłócenia, to informacja na końcu byłaby totalną sieczką. Zawaliłby się cały internet i jego podstawy :-).

 

A odtwarzanie muzyki z pendrive, niczym nie różni się od przesłania mailem. I jedno i drugie odbywa się w środowisku i systemie, który nie jest systemem czasu rzeczywistego, dla naszego sygnału audio. I tu jest problem, wiele osób próbuje koniecznie szukać zależności, jakby był on systemem czasu rzeczywistego, a takim staje się dopiero od wyjścia z konwertera asynchronicznego. I dopiero od tego momentu zaczynają obowiązywać wszelkie zależności, o których piszesz. Modulacje zegarów w kolejnych łańcuchach toru itd. Dlatego oczywiście sam konwerter i jego jakość, są tak ultra ważne. Temu akurat nie przeczę.

 

Dlatego też z Jplayem widzę jeden problem. Autor opisuje mechanizmy jakie zastosował i ich zbawienny wpływ, opierając się na zależnościach dość logicznych, ale obowiązujących w systemie czasu rzeczywistego. Robi "fiku miku" jakby system był systemem czasu rzeczywistego, na takim który takowym nie jest. A jak już w końcu przyznaje, że nie jest on systemem czasu rzeczywistego, to ma mieć to jakoby wpływ na kolejne ogniwo, które już będzie systemem czasu rzeczywistego, bo będzie się mniej "męczyć" jego wejście. Troszki się to nie trzyma kupy.

[Stasiop]

Oj SkawekR Ja Cie rozumiem ale ty ciagle myslisz cyfrowo a nie anologowo! Tu sa konkretne pomiary gdzie goscie mierza super czyste generatory w roznych srodowiskach w zakloconym smogiem w.cz i pod przykryciem. Caly uklad generujacy wraz z zasilaczami jest przykryte prawdopodobnie mata pochlaniajaca RF wyniki pomiarow sa oczywiste.

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

 

 

A wnioski koncowe sa cyt: Testing phase noise of ULPN OCXOs requires using the

cross-correlation technique. Special care must be taken for

reduction of RF interference, especially while testing 100

MHz ULPN OCXO in the vicinity of strong FM broadcasting

stations.

 

 

A muzyka z roznych pen-drivow bedzie rozna nawet z tej samej linii jesli bedzie odtwarzana w czasie rzeczywistym, ale jesli nagrasz to i przeslesz mailem to juz nie.

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ą )

[marekzawa]

A muzyka z roznych pen-drivow bedzie rozna nawet z tej samej linii jesli bedzie odtwarzana w czasie rzeczywistym, ale jesli nagrasz to i przeslesz mailem to juz nie.

 

????????

Coś tu logiki brak. W jednym i drugim przypadku zapisujesz do pamięci.

Czym się różni zapisanie maila na HDD od zapisania tej samej treści na inny przenośny rodzaj pamięci ?

Czy zapisana informacja ulega zmianie ??? Co ma do tego czas ?

 

Może narysuj o co chodzi bo to zdanie jest dla mnie tak zakręcone jak 100 metrów sznurka w kieszeni.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Stasiop]

Jesli chodzi o zapis to mozesz to nawet zapisywac na dyskietkach 1.44 ( nie wiem czy jeszcze ktos pamieta ze takie cos bylo ;)) nie ma to zadnego znaczenia mozesz to przesylac kopiowac setki razy to nic nie zmieni sie. Ale jesli zaczniesz to odtwarzac w czasie rzeczywistym z roznych zrodel o to tutaj roznice beda i to znaczne. Np w pendrivach tam jest sporo namieszane dane nie sa odtwarzane z jednej przestrzeni logiki cyfrowej tylko sa porozrzucane komputer zarzadzajacy musi to przemielic i tu nastepuja zaklocenia czyli jitter.Ale powiem wiecej mozna nawet takie dwa pendrivy sformatowac i nagrac tylko jeden utwor i roznice tez beda mniejsz ale beda . Taka to cholera jest z tego jitteru :D I oczywiscie to tez sie da wytlumaczyc logicznie ;)

 

Pozdrawiam StasioP

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[marekzawa]

Mail również zapisze się na HDD w poszatkowanej postaci. Dodatkowo przeleci przez kilka serwerów, a każdy z nich to inna czaso-przestrzeń logiczna :)

Dalej brak ciągłości logicznej :(

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Gość SlawekR]

Oj SkawekR Ja Cie rozumiem ale ty ciagle myslisz cyfrowo a nie anologowo!

 

Parafrazując mojego Szanownego Kolegę, Ja Cię rozumiem, ale Ty ciągle myślisz analogowo, tam gdzie powinieneś myśleć cyfrowo. Wyjaśnię to dalej.

 

Tu sa konkretne pomiary gdzie goscie mierza super czyste generatory w roznych srodowiskach w zakloconym smogiem w.cz i pod przykryciem. Caly uklad generujacy wraz z zasilaczami jest przykryte prawdopodobnie mata pochlaniajaca RF wyniki pomiarow sa oczywiste.

 

 

http://www.nelfc.com/pdf/PID2382573_E.pdf

 

 

A wnioski koncowe sa cyt: Testing phase noise of ULPN OCXOs requires using the

cross-correlation technique. Special care must be taken for

reduction of RF interference, especially while testing 100

MHz ULPN OCXO in the vicinity of strong FM broadcasting

stations.

 

No wszystko ok, ja nigdy nie twierdziłem, że takie generatory zegarowe nie sieją i to na różne sposoby, po linach danych, czy też za pomocą RF. Ale jaki to ma związek z naszym konkretnym przypadkiem? O czym za moment.

 

 

A muzyka z roznych pen-drivow bedzie rozna nawet z tej samej linii jesli bedzie odtwarzana w czasie rzeczywistym, ale jesli nagrasz to i przeslesz mailem to juz nie.

 

Ale jak niby chciałbyś zrealizować odtwarzanie muzyki w czasie rzeczywistym z pendrive? Ot choćby w takim systemie jak Twój? I to jest to miejsce, w którym się nie zgadzamy i myślimy inaczej.

 

Muzyka z komputera jako źródła, odtwarzana za pomocą, odpowiedniego konwertera asynchronicznego, nie jest i nie będzie odtwarzana w czasie rzeczywistym, niezależnie czy będzie się to odbywać z pendrive, z RAM, z HDD, NASa, SSD.... Taki jest mój punkt widzenia. Ty twierdzisz że będzie, tak wynika przynajmniej z Twojego toku rozumowania, ja twierdzę że nie będzie. I w tym różnimy się fundamentalnie. Napisz proszę więc, dlaczego uważasz, że jest ona odtwarzana w czasie rzeczywistym ze źródła. Jak opiszę dlaczego uważam, że tak nie jest.

 

Jestem w stanie sobie wyobrazić konwerter asynchroniczny, z odpowiednio dużym buforem i mocą obliczeniową, który będzie pobierać dane, zakładam że będą to dane muzyczne, odpowiadające 16bit/44,1kHz, będzie on pobierać te dane raz na 120 sekund i to w zasadzie w dowolnym momencie tego okresu czasu. W pozostałych sekundach tego sloty czasowego, źródło czyli komputer może być całkowicie wyłączone w 100% i budzone raz na 120 sekund na żądanie konwertera. Oczywiście nieco przejaskrawiłem, ale to na potrzeby unaocznienia kwestii. W każdym razie nadmiarowość transmisyjna interfejsu USB 2.0 pozwala na przerwy nawet do 140 sekund, więc 100 sekund to luzik.

 

Jestem sobie w stanie wyobrazić konwerter asynchroniczny, który dzięki odpowiedniemu oprogramowaniu w firmware, potrafi pobrać dane audio wprost z serwera pocztowego, logując się na nim raz na 120 sekund, a i tak muzyka będzie grać ciągle na jego wyjściu, ale nie jest ona pobierana ze źródła w czasie rzeczywistym. Twoim zdaniem, taki przypadek to jest odtwarzanie w czasie rzeczywistym, czy może jest to przesyłanie mailem, które takim odtwarzaniem już nie jest? Ciekawy przypadek, nieprawdaż? :-) Według mnie i jedno i drugie niczym się nie różni i nie jest odtwarzaniem ze źródła w czasie rzeczywistym. Strumień czasu rzeczywistego pojawia się dopiero na wyjściu konwertera asynchronicznego, na jego wejściu nie ma absolutnie o tym mowy.

 

Teraz kwestia przytoczonych przez Ciebie pomiarów, no ok, zegary sieją.

 

Rozważmy więc taką sytuację, wcale nie hipotetyczną. W jednym pomieszczeniu mamy komputer połączony z siecią za pomocą LAN, a następnie z Routerem z AP bezprzewodowym, dwa pokoje dalej mamy DACa z interfejsem asynchronicznym, z transmisją danych na wejściu za pomocą WiFi. Patrz choćby odpowiednia wersja Rdaca.

Jakim sposobem, zakłócenia z komputera, dwa pomieszczenia dalej i nie połączonego w żaden sposób elektrycznie z konwerterem, a transmitującego dane za pomocą protokołu TCP bezprzewodowo z przepływnością 54 Mbit, jakim sposobem zegar komputera będzie zakłócać pracę DACa i interfejsu? Będzie się sprzęgać i modulować nośną sygnału WIFi? Która ma się do częstotliwości generatora zegarowego w komputerze i do tego w DACu/interfejsie jak pięść do nosa, czyli nijak.

 

Reasumując, różnice w naszym rozumowaniu:

 

Ty twierdzisz, że w takim systemie (komputer sterowany systemem operacyjnym, który nie jest systemem czasu rzeczywistego plus do tego konwerter asynchroniczny) muzyka odtwarzana jest w czasie rzeczywistym ze źródła.

 

Ja twierdzę, że w takiej konfiguracji nie ma mowy o odtwarzaniu muzyki w czasie rzeczywistym ze źródła danych.

[Lumperator]

Wszystkie operacje na komputerze są gdzieś chwilowo przetrzymywane, dawkowane w porcjach, muszą czekać na przerwanie innego urządzenia, przeskok głowicy w dysku. W tych trudnych czasach tylko patefon może nas uratować :)

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[migrena]

Co to jest "przestrzeń logiki cyfrowej"?

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Stasiop]

będzie on pobierać te dane raz na 120 sekund

Jesli bedzie on pobieral dane raz na 120 sekund to moim zdaniem odetniemy sie od zrodla bledow prawie zupelnie

 

Która ma się do częstotliwości generatora zegarowego w komputerze i do tego w DACu/interfejsie jak pięść do nosa, czyli nijak.

A w tym wypadku petla i tak bedzie ganiac i sie ciagle dostrajac to ze jest to bezprzewodowe nic nie zmienia

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Gość SlawekR]

Jesli chodzi o zapis to mozesz to nawet zapisywac na dyskietkach 1.44 ( nie wiem czy jeszcze ktos pamieta ze takie cos bylo ;)) nie ma to zadnego znaczenia mozesz to przesylac kopiowac setki razy to nic nie zmieni sie. Ale jesli zaczniesz to odtwarzac w czasie rzeczywistym z roznych zrodel o to tutaj roznice beda i to znaczne. Np w pendrivach tam jest sporo namieszane dane nie sa odtwarzane z jednej przestrzeni logiki cyfrowej tylko sa porozrzucane komputer zarzadzajacy musi to przemielic i tu nastepuja zaklocenia czyli jitter.Ale powiem wiecej mozna nawet takie dwa pendrivy sformatowac i nagrac tylko jeden utwor i roznice tez beda mniejsz ale beda . Taka to cholera jest z tego jitteru :D I oczywiscie to tez sie da wytlumaczyc logicznie ;)

 

Pozdrawiam StasioP

 

 

Kolega Migrena zwrócił moja uwagę na ciekawy post, który wcześniej pominąłem, a tu faktycznie mamy śliczne kwiatki. Kłania się znajomość działania pamięci flash wszelkiego typu. Przede wszystkim, zapisem i odczytem z poszczególnych komórek nie zajmuje się żaden komputer zarządzający, a kontroler pamięci flash w samym pendrive, komputer dostaje dane transmitowane szeregowo i kompletnie nie wie z jakiego obszaru pamięci flash one pochodzą, ba nie ma szans aby sterował miejscem gdzie ten zapis się odbywa. Formatowanie też tego nie zmieni. Kontroler zapisuje wedle swoich algorytmów, które mają oszczędzać komórki poprzez zapisywanie ich możliwie najrzadziej. Oznacza to, że jeśli pendrive był zapełniony w połowie, to jego sformatowanie nie spowoduje zapisu od początku, a od połowy, dalej wedle ustalonego algorytmu. Zapis do komórek które były zapisane przed formatowaniem, nastąpi dopiero po wyczerpaniu miejsca pustego. Dzięki temu ogranicza się ilość zapisów do pamięci nieulotnej, która ma tą ilość ograniczoną.

 

Komputer zarządzający "jago go ładnie określiłeś" nie ma tu nic do gadania. Dlatego też kompletnie pozbawionym sensu, a wręcz szkodliwym jest próbowanie defragmentacji na takiej pamięci flash, gdyż i tak nigdy nie uzyskamy ciągłości pliku, algorytmy kontrolera na to nie pozwolą. Tak czy inaczej, dane docierają z pendrive do komputera szeregowo po USB, już poukładane i komputerowi powiewa, jak to nazwałeś, zaraz znajdę..... przestrzeń logiki cyfrowej, zresztą kompletnie nie ma na nią wpływu. Tym samym żaden magiczny program, pokroju, Jplaya również nie ma szans na jakikolwiek wpływ na zapis, czy też odczyt z tego typu pamięci flash. Z punktu widzenia komputera, każdy pendrive stanowi pamięć masową, widoczną dla niego jako pamięć o szeregowym zapisie ciągłym, pakiet po pakiecie. To samo tyczy się odczytu. Jitter na takim nośniku w związku z tym również nie jest możliwy, gdyż operacje wykonywane są raz, pakietowo, dwa, w losowych slotach czasowych i nie synchronicznie, trzy, wyłącznie w miejsca wyznaczone przez kontroler, a nie komputer zarządzający. Stąd też logikę którą zastosowałeś do pendrive, niestety zmuszony jestem uznać za kompletnie bezzasadną i niemożliwą w praktyce do realizacji.

 

Próby uczynienia tych operacji odczytu i zapisu synchronicznymi i przezegarowqanymi na modłę i logikę analogowa, raz że nie mają sensu w systemie, który nie jest systemem czasu rzeczywistego, dwa nie ma na to szans, z tego samego powodu zresztą. Przykro mi bardzo, że nie jestem żadnym sposobem przekonać Cię do odrzucenia logiki analogowej, którą stosujesz tylko dlatego, że na nośniku składowane są dane zawierające informację o muzyce. Jitter w tym przypadku to nie żadna "cholera" z tego prostego powodu, że nie dotyczy on tego systemu.

 

Jesli bedzie on pobieral dane raz na 120 sekund to moim zdaniem odetniemy sie od zrodla bledow prawie zupelnie

 

A i owszem, ale to dotyczy tak naprawdę dowolnego bufora, niekoniecznie na 120 sekund, może być znacznie, znacznie, krótszy. Byle tylko był wystarczający na spełnienie swojej roli gromadzenia danych przy asynchronicznym ich pobieraniu. Jeśli bufora braknie, to wtedy owszem, nastąpi błąd, ale będzie on miał charakter błędu grubego, który usłyszysz w postaci przerwy w dźwięku, a nie w zmianie jego charakteru pochądzącej od jittera, gdyż od niego właśnie jesteś odcięty, dzięki tym mechanizmom. I to jest istota kwestii.

 

Zauważ, że właśnie przyznałeś, że odetniemy się od źródła błędu przy buforze 120s. Ok, przy buforze 50s, też się odetniemy? Oczywiście, a przy buforze 2s? Również. Przy 0,5s? A i owszem, jeśli skala błędów pojawiających się i korygowanych nie jest tak duża, żeby bufor się opróżnił. Itd. itp. No i tak to właśnie działa w konwerterze asynchronicznym, a i w samym przetworniku Sabre, który posiadasz, również po raz drugi, to do kompletu, żeby było zabawniej.

 

A w tym wypadku petla i tak bedzie ganiac i sie ciagle dostrajac to ze jest to bezprzewodowe nic nie zmienia

 

A gdzie masz tam pętlę w ogóle, że zapytam? Pętla od czego, od zegara referencyjnego na wejściu, na podstawie którego niby tworzony jest z kolei, właśnie za pomocą pętli, zegar referencyjny wyjściowy? Oczywiście, że nie. Z tej prostej przyczyny, że zegar wyjściowy nie jest tworzony w ten sposób. Tworzony jest tak, że z danych wejściowych asynchronicznych pobierana jest informacja o wartości częstotliwości zegara wyjściowego, a sam zegar tworzony jest z zegara master samego konwertera. Z typową pętlą mamy do czynienia co najwyżej, jeśli zegar referencyjny konwertera wymaga utworzenia zegara wyjściowego o nietypowej, niepodzielnej wartości. Ale to jest pętla dotycząca zegara konwertera i zegara wynikowego. A nie zegara na wejściu i zegara wynikowego.

 

Oczywiście to wszystko przy założeniu, że sam konwerter jest w odpowiedniej i dobrze zrobionej aplikacji. Ale to sprawa oczywista. A może pisząc asynchroniczny, masz na myśli isochroniczny? Bo tam pętla taka jest i owszem. W asynchronicznym konwerterze, taka pętla "nadążająca", czy jak ją tam zwał, jest zbędna, gdyż konwerter kontroluje strumień napływających do niego danych i potrafi nim sterować poprzez kanał zwrotny. Dlatego jest to zresztą najlepsza forma przesyłania danych audio. Syf może się pojawić dopiero po opuszczeniu konwertera, gdzie mamy już transmisję tradycyjną.

[Stasiop]

Zauważ, że właśnie przyznałeś, że odetniemy się od źródła błędu przy buforze 120s. Ok, przy buforze 50s, też się odetniemy? Oczywiście, a przy buforze 2s? Również. Przy 0,5s?

Tak ale wraz z krotszym buforem problem jitteru bedzie narastal, mysle ze jest to moment ze mozesz teraz wlasnie zalapac o co mi caly czas chodzi. Bo tu problem jest w tym ze ja sie bawilem petlami PLL i dokladnie wiem jak to dziala. Jesli bufor bedzie krotszy konwerter asynchroniczny bedzie wydawal czesciej rozkazy przeslij mniej albo wiecej probek bo konczy lyb pusty mam bufor. Zauwaz ze to bedzie sie dzialo tak czesto jakie beda roznice w czasie miedzy generatorami oraz glownie od dlugosci bufora. Jesli bedzie to wystepowac czesto petla bo tak to musimy nazwac (owszem jest cyfrowa) pobierajac wolniej lub szybciej na jednostke czasu bedzie powodowala blad szumowy przestrajania.Oczywiscie bedzie to blad cyfrowy bo petle cyfrowe tez szumia. A nawet wolne bardzo wolne przestrajanie nawet z czestotliwoscia 0.1Hz bedzie powodowalo szum o podstawowej harmonicznej i prazkach bocznych do kilo a moze nawet mega hercow. Oczywiscie nim wolniej (tzn dluzszy bufor tym lepiej, bo nizsze harmoniczne) Ale jedyna opcja ze odetniemy sie od zrodla jitteru jest sytuacja ze bufor jest na tyle dlugi ze nie ma co regulowac bo sa wyrownywane w FIFO roznice czestotliwosci generatoroiw a synchronizacja zachodzi co 1h. Jest taki projekt na forum diyaudio robiony przez Iana, a uwierz mi Ian to ekspert jesli chodzi o jitter. Warto poczytac ten okroponie dlugi watek mozna sie wiele nauczyc.

 

potrafi nim sterować poprzez kanał zwrotny.

Kanal zwrotny to juz jest petla ;)

 

Tak czy inaczej, dane docierają z pendrive do komputera szeregowo po USB, już poukładane i komputerowi powiewa, jak to nazwałeś, zaraz znajdę..... przestrzeń logiki cyfrowej, zresztą kompletnie nie ma na nią wpływu. Tym samym żaden magiczny program, pokroju, Jplaya również nie ma szans na jakikolwiek wpływ na zapis, czy też odczyt z tego typu pamięci flash.

Owszem ma ;) bo moze skopiowac to do jednego obszaru pamieci RAM i pobierac je z komputera

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Lumperator]

Foobar też pobiera cały plik do ramu. Tyle, że dysk dalej wiruje, procesor wykonuje jakieś drobne zadania w tle. Czy na serio odbiór całości z ramu daje słyszalnie lepszy efekt niż pobieranie danych partiami z dysku twardego, nierzadko zewnętrznego przez USB? Ja czegoś takiego nie zaobserwowałem. To jak odtwarzanie muzyki strumieniowo z netu. Paczki dochodzą z serwera, zapisują się w pliku tymczasowym, są wysyłane do ramu. Bit do bitu się zgadza. Istotne co dzieje się między ramem na DACem w trakcie odtwarzania (o czym już wspomniał stasiop kilka postów wyżej). I jeszcze pytanie - skoro sprawcą problemów są zakłócenia wynikające z pracy podzespołów, to czy podpięcie drugiego zasilacza ATX (np. pod dyski twarde, wentylatory...) mogłoby w jakiś sposób zniwelować problem czy to nie ma żadnego znaczenia?

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Gość SlawekR]

Tak ale wraz z krotszym buforem problem jitteru bedzie narastal, mysle ze jest to moment ze mozesz teraz wlasnie zalapac o co mi caly czas chodzi.

 

Ale ja wiem, o co Ci cały czasz chodzi. Dokładnie wiem. Tyle, że popełniasz niestety błąd myślowy, z racji na naleciałości analogowe w myśleniu.

 

"Wic" polega na tym właśnie, że z krótszym buforem problem nie będzie w żadnym razie narastał. To jest właśnie takie myślenie analogowe, jak w analogowej telewizji, gdzie słabszy sygnał oznacza gorszą jakość.

 

A tu należy myśleć cyfrowo, tak jak w telewizji cyfrowej, dobry sygnał - dobra jakość, słabszy sygnał - brak zmiany w jakości, jeszcze słabszy sygnał, nadal brak zmiany, bardzo słaby - brak obrazu. Mamy do czynienia ze stanem jest lub nie ma, nie ma stanu pośredniego gorzej-lepiej. Tak samo jest w naszym przypadku. Czy bufor ma 120 sekund, czy 2 sekundy, czy 0,5, nie ma znaczenia. Większy bufor to tylko większy margines bezpieczeństwa. Tak samo jak w telewizji cyfrowej, lepszy sygnał - większy margines na niepogodę, ale w żadnym wypadku nie zmiana jakości obrazu.

 

Bo tu problem jest w tym ze ja sie bawilem petlami PLL i dokladnie wiem jak to dziala.

 

 

Nie przeczę, że wiesz jak działa pętla. Tyle, że taki drobny szczegół tutaj nie mamy do czynienia z tego typu pętlą PLL, służącą generowaniu zegara wyjściowego, w oparciu o zegar wejściowy.

 

Jesli bufor bedzie krotszy konwerter asynchroniczny bedzie wydawal czesciej rozkazy przeslij mniej albo wiecej probek bo konczy lyb pusty mam bufor. Zauwaz ze to bedzie sie dzialo tak czesto jakie beda roznice w czasie miedzy generatorami oraz glownie od dlugosci bufora.

 

No właśnie nie jest tak. Rozważmy to na przykładzie.

 

Załóżmy że interfejst wejściowy udostępnia 10 slotów, czyli 10 możliwych porcji na przesłanie porcji danych. Takimi możliwościami nadawczymi (moc obliczeniowa) dysponuje i takimi też dysponuje odbiornik. To tak dla przykładu wartości. Na razie jest ok, wszystko jasne?

 

 

Jedziemy dalej, Interfejs ma przepustowość 100000 bajtów na sekundę. Czyli taką ma nośną zegarową. Dalej jasne? Oznacza to, że w jednym takcie slocie można przesłać 10000 bajtów.

 

Zegar wynikowy, determinuje potrzebę pobrania określonej ilości danych w ciągu sekundy, powiedzmy że potrzebuje ich 100 bajtów.

 

Oznacza to, że bufor wyśle żądanie, raz w ciągu sekundy, w jednym slocie zostanie mu dostarczone potrzebne 100 bajtów. Dalej wszystko jasne i się zgadza?

 

Oznacza to, że przez pozostałą część sekundy, źródło może się przespać, nie odbywa się i nie jest konieczna transmisja.

 

Rozważmy kolejny przypadek, zmieniliśmy interfejs na taki o przepustowości, nie 100000 (sto tysięcy), a 10000 (dziesięć tysięcy).

 

Zegar wynikowy się nie zmienił. Zegar wejściowy, od którego zależy przepływność, zmalał dziesięciokrotnie. Dalej mamy moc obliczeniową na poziomie 10 porcji danych.

 

Sprawdźmy zatem co się stanie w naszej konfiguracji. Konwerter nadal potrzebuje otrzymać 100 bajtów w ciągu sekundy, tu się nic nie zmieniło, co więc robi, wyśle jeden raz zapytanie o te dane i otrzyma je w jednym slocie. Przez resztę czasu system może spać.

 

Otrzymaliśmy więc sytuację:

 

W drugim przypadku, zmienił się stosunek zegara wejśćiowego do wyjściowego? Zmienił się. Zmieniła się ilość zapytań kanałem zwrotnym? Nie zmieniła się. Gdzie tu więć zależność pomiędzy zegarami poprzez pętlę? Nie ma takiej zależności, bo nie ma pętli tworzącego zegar wyjściowy, na podstawie zegara wejściowego.

 

Ilość żądań wysyłanych przez konwerter zależy wyłącznie od przepływności wymaganej na jego wyjściu i ewentualnie od stopy błędów na wejściu, a nie zależy od stosunku zegarów. To nie jest Oczywiście musi być spełniony warunek wystarczającej przepływności interfejsu wejściowego, znaczy zegar musi być wystarczający, żeby interfejs w ogóle zdążył wysłać dane.

 

Uprzedzając od razu pytanie i wątpliwość. Kiedyś to liczyłem, nadmiarowość interfejsu wejściowego USB2.0, w stosunku do przepływności koniecznej do przesłania danych audio 16bit/44.1kHz wynosi "drobne" 140 razy, słownie sto czterdzieści. I to z uwzględnieniem rezerwacji pasma na ciągłą komunikację dwukierunkową.

 

Jeśli to co wyżej napisałem do Ciebie nie przemówi, to ja się poddaję.

 

 

Jesli bedzie to wystepowac czesto petla bo tak to musimy nazwac (owszem jest cyfrowa) pobierajac wolniej lub szybciej na jednostke czasu bedzie powodowala blad szumowy przestrajania.

 

Nie, nie, nie. To nie jest pętla w rozumieniu zależności zegara wyjściowego od wejściowego i konieczności "nadążania" pętli. Nic z tych rzeczy. A dlaczego, to opisałem to wyżej.

 

 

Oczywiscie bedzie to blad cyfrowy bo petle cyfrowe tez szumia. A nawet wolne bardzo wolne przestrajanie nawet z czestotliwoscia 0.1Hz bedzie powodowalo szum o podstawowej harmonicznej i prazkach bocznych do kilo a moze nawet mega hercow. Oczywiscie nim wolniej (tzn dluzszy bufor tym lepiej, bo nizsze harmoniczne) Ale jedyna opcja ze odetniemy sie od zrodla jitteru jest sytuacja ze bufor jest na tyle dlugi ze nie ma co regulowac bo sa wyrownywane w FIFO roznice czestotliwosci generatoroiw a synchronizacja zachodzi co 1h. Jest taki projekt na forum diyaudio robiony przez Iana, a uwierz mi Ian to ekspert jesli chodzi o jitter. Warto poczytac ten okroponie dlugi watek mozna sie wiele nauczyc.

 

Wszystko pięknie, tyle że tu nie ma mowy o takiej pętli.

 

 

Kanal zwrotny to juz jest petla ;)

 

Nie jest to pętla w rozumieniu zegarów, co pokazałem Ci na przykładzie wyżej. Stosunek zegarów wejście-wyjście, nie ma znaczenia. Czy zastosujesz USB, LAN, czy WiFi nadal nie będzie mieć to znaczenia, a każde z tych mediów transmisyjnych będzie mieć inny zegar, a co za tym idzie inną przepustowość. Kanał zwrotny jest w tym przypadku kanałem komunikacyjnym technicznym, a jego zachowanie w praktyce zależy wyłącznie od zegara wyjściowego i stopy błędów, błędów grubych, dodajmy, czyli absolutnych przekłamań w transmisji, a nie zakłóceń wcz.

 

Owszem ma ;) bo moze skopiowac to do jednego obszaru pamieci RAM i pobierac je z komputera

 

Co dalej nie ma znaczenia w naszym przypadku, bo jest to bez wpływu na sygnał dostarczany do interfejsu wyjściowego pracującego asynchronicznie.

 

Foobar też pobiera cały plik do ramu. Tyle, że dysk dalej wiruje, procesor wykonuje jakieś drobne zadania w tle. Czy na serio odbiór całości z ramu daje słyszalnie lepszy efekt niż pobieranie danych partiami z dysku twardego, nierzadko zewnętrznego przez USB? Ja czegoś takiego nie zaobserwowałem. To jak odtwarzanie muzyki strumieniowo z netu. Paczki dochodzą z serwera, zapisują się w pliku tymczasowym, są wysyłane do ramu.

 

Przy założeniu, że korzystamy z dobrego interfejsu asynchronicznego, nie będzie to mieć znaczenia, skąd i jak pobieramy dane. Byle dotarły one w odpowiedniej ilości i w potrzebnym na to czasie, aby bufor się nie opróżnił. W przeciwnym razie pojawi się przerwa w dźwięku, ale nie pogorszenie jakości. Patrz przykład z telewizją cyfrową.

 

 

... I jeszcze pytanie - skoro sprawcą problemów są zakłócenia wynikające z pracy podzespołów, to czy podpięcie drugiego zasilacza ATX (np. pod dyski twarde, wentylatory...) mogłoby w jakiś sposób zniwelować problem czy to nie ma żadnego znaczenia?

 

Im bardziej przysadzimy się do zasilania konwertera i jego odcięcia elektrycznego i magnetycznego, od komputera, tym mniejsze będzie mieć znaczenie co w samym komputerze siedzi. Chociaż, na zdrowy rozum, z oczywistych względów, im lepiej jest zrobione zasilanie w samym komputerze, tym potencjalnie jego wpływ może być mniejszy, a że jego wpływ zależny będzie od jakości konwertera i jego budowy, to przy marnym konwerterze i komputer będzie w stanie coś pomóc. Ot zwykła logika, aczkolwiek nie wszyscy chcą przyjmować do wiadomości logiczne rozumowanie.....

[Stasiop]

konwerter raz dostaje 100 bitow raz 120, w nastepnym 12000, pozniej czeka 500 probek, nastepnie pobiera 20000 i co nie ma tu modulacji ????????? hihi Cyfrowka to w idei to samo co analogowka te same mechanizmy zachodza co na drodze cyfrowej myslelismy ze swiat da sie zapisac w dwoch stanach super wiernie i owszem i da, ale problemy przyszly niespodziewanie gdzie indziej.Modulacje pozostaly. To Ty Slawku nie rozumiesz toTy.

 

Przy założeniu, że korzystamy z dobrego interfejsu asynchronicznego, nie będzie to mieć znaczenia, skąd i jak pobieramy dane. Byle dotarły one w odpowiedniej ilości i w potrzebnym na to czasie, aby bufor się nie opróżnił. W przeciwnym razie pojawi się przerwa w dźwięku, ale nie pogorszenie jakości. Patrz przykład z telewizją cyfrową.

Chyba przy zalozeniu ze puszczamy utwor przez konwerter asynchroniczny z FIFO o dlugosci 1h wtedy roznic wlasciwie byc nie powinno w kazdym innym wypadku bedzie to slyszalne mniej lub wiecej. Owszem z konwerterem asynchronicznym USB malo ;) ale jednak roznice beda i wcale nie takie subtelne jak pokazuja moje doswiadczenia odsluchowe.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[zibra]

Mam konwerter XMOS z diyaudio i zastanawialem sie wlasnie jaki wplyw mialoby dodatkowe wpiecie tego bufora od Iana. Ciagle nie wiem czy to rzeczywiscie rozwiaze sprawe. Jakis tam forumowicz ciagle sceptycznie do tego podchodzil, ale nie moge znbalezc tej wypowiedzi.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Stasiop]

Mam konwerter XMOS z diyaudio i zastanawialem sie wlasnie jaki wplyw mialoby dodatkowe wpiecie tego bufora od Iana. Ciagle nie wiem czy to rzeczywiscie rozwiaze sprawe. Jakis tam forumowicz ciagle sceptycznie do tego podchodzil, ale nie moge znbalezc tej wypowiedzi.

Moim zdaniem to jest JEDYNE rozwiazanie ktore oleje wszystkie problemy z napedami pen-drivami dyskami Jplayer-ami itp. bedziesz mogl sluchac z czego bedziesz chcial a roznice beda bliskie zeru nie zerowe ale zblizysz sie do tego zera najblizej jak w obecnej chwili mozna. Ja tez namierzam sie na ten konwerter. Bedzie to lepsze anizeli najlepszy naped HIGH_END nic nie ma obecnie lepszego. Zreszta to co zaprezentowal Ian w swoim konwerterze zasluguje na najwieksze uznanie. Zastosowal najlepsza technologie polaczona z najlepszym programowaniem.

 

Pozdrawiam StasioP

 

Jakis tam forumowicz ciagle sceptycznie do tego podchodzil, ale nie moge znbalezc tej wypowiedzi.

Zawsze sie znajdzie ktos kto powie ze biale jest czarne, jedyny slaby punkt tego jest ze na muzyke troszke trzeba poczekac ;)

 

Przy założeniu, że korzystamy z dobrego interfejsu asynchronicznego, nie będzie to mieć znaczenia, skąd i jak pobieramy dane. Byle dotarły one w odpowiedniej ilości i w potrzebnym na to czasie, aby bufor się nie opróżnił.

 

Sam sobie zaprzeczasz zreszta

 

Chociaż, na zdrowy rozum, z oczywistych względów, im lepiej jest zrobione zasilanie w samym komputerze, tym potencjalnie jego wpływ może być mniejszy, a że jego wpływ zależny będzie od jakości konwertera i jego budowy, to przy marnym konwerterze i komputer będzie w stanie coś pomóc.

 

Bo jesli mowisz ze jesli mamy konwerter asynchroniczny a masz na uwadze konwerter USB bez FIFO bo o takim dyskutujemy i ze jesli cos przez niego przepuscimy to piszesz nie bedzie to mialo znaczenia skad i jak pobieramy dane to zaprzeczasz tym samym ze zmiana z komputerze wplynie na zmiane dzwieku. Wiec za ktora opcja juz jestes? ;)

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Gość SlawekR]

konwerter raz dostaje 100 bitow raz 120, w nastepnym 12000, pozniej czeka 500 probek, nastepnie pobiera 20000 i co nie ma tu modulacji ?????????

 

Podałeś przykład, jakby sygnał przechodził przez pas asteroid, a nie wysoce nadmiarowy (140x) interfejs. Konwerter dosta tyle bitów ile zażąda, zważywszy że on jest urządzeniem master. Od tego jest oprogramowanie sterujące (firmware), żeby takie dziwności jak opisujesz nie zachodziły. Niby z jakiego powodu konwerter miałby dostawać losowe, co do ilości i zawartości, porcje danych? Konwerter z założenie zawsze, żąda 100 bajtów, dostaje 100 bajtów. później czeka 500 próbek, znowu dostaje 100 bajtów, i tak w kółko. Raz na kilka-kilkadziesiąt tysięcy takich identycznych operacji, zdarzy mu się zażądać powtórzenia transmisji tych 100 bajtów, jeśli wystąpi w niej błąd przekłamujący dane. A na takie powtórzenie ma mnóstwo czasu, z racji na ogromną nadmiarowość. Ma pod tym względem pełen komfort.

 

Nie wiem skąd Ci się wzięły takie fluktuacje, oprogramowanie konwertera, zaraz po starcie transmisji dąży do osiągnięcia stanu równowagi, to nawet słychać, jeśli soft nie wycisza wtedy sygnału an wyjściu. Słychać to w postaci charakterystycznego "blurpa". Po osiągnięciu stanu równowagi, transmisja odbywa się praktycznie bez najmniejszych zmian. Ewentualnie raz na kilka tysięcy operacji, może zdarzyć się żądanie powtórzenia jednego pakietu i tyle.

 

 

hihi Cyfrowka to w idei to samo co analogowka te same mechanizmy zachodza co na drodze cyfrowej myslelismy ze swiat da sie zapisac w dwoch stanach super wiernie i owszem i da, ale problemy przyszly niespodziewanie gdzie indziej.Modulacje pozostaly. To Ty Slawku nie rozumiesz toTy.

 

Tak uważasz? A przeczytałeś mój przykład z telewizją analogową i cyfrową? Napisałem tam prawdę, czy nie? Uważasz, że wraz z pogorszeniem jakości sygnału, pogarsza się jakość obrazu, przy transmisji cyfrowej sat, czy się nie pogarsza?. No chyba, że faktycznie uważasz, że się pogarsza, to nie mamy o czym rozmawiać, bo rozmawiamy innymi językami. Widać mamy zwoje mózgowe skręcone w różne strony. Ja Ci podaję konkretne rzeczy, konkretne przykłady, a Ty mi w odpowiedzi w kółko utarte slogany, jak zacięty gramofon. Slogany poparte co najwyżej, tu cytat "hihi". Sorry, ale to jest mocno jednostronna dyskusja, jeśli chodzi o argumentację.

 

 

Chyba przy zalozeniu ze puszczamy utwor przez konwerter asynchroniczny z FIFO o dlugosci 1h wtedy roznic wlasciwie byc nie powinno w kazdym innym wypadku bedzie to slyszalne mniej lub wiecej. Owszem z konwerterem asynchronicznym USB malo ;) ale jednak roznice beda i wcale nie takie subtelne jak pokazuja moje doswiadczenia odsluchowe.

 

A to ciekawe, a przy Fifo pół godzinnym, już będzie pogorszenie? A przy 15 minutowym? A przy minutowym? A przy 1,5 godzinnym będzie jeszcze lepiej, niż przy godzinnym?

 

Ile wynosi magiczna granica, przy której nagle sygnał cyfrowy przestajesz uważać za podlegający regułom analogowym? Skąd się ta granica bierze, na podstawie jakich wyliczeń, czy też może doświadczeń. Czyżby odsłuchowych?

 

To jest niestety nielogiczne co napisałeś. Po prostu nielogiczne. Wybacz, ale takie jest moje zdanie. Nie ma w tym logiki, zwykłej logiki.

 

Ja uważam, że bufor Fifo musi być tylko taki, aby był wystarczający na reakcję, na losowe błędy grube w transmisji asynchronicznej,, aby nie nastąpiła przy nich przerwa w transmisji, spowodowana opróżnieniem bufora. Dla mnie to już jest wystarczająca granica, na odcięcie się od problemu. A nie jakaś magiczna wartość, choćby jednej godziny.

 

....

Bo jesli mowisz ze jesli mamy konwerter asynchroniczny a masz na uwadze konwerter USB bez FIFO bo o takim dyskutujemy i ze jesli cos przez niego przepuscimy to piszesz nie bedzie to mialo znaczenia skad i jak pobieramy dane to zaprzeczasz tym samym ze zmiana z komputerze wplynie na zmiane dzwieku. Wiec za ktora opcja juz jestes? ;)

 

OOO, wreszcie jakieś konkrety się klarują.Wreszcie poznałem przyczynę, dla której analogizujesz tak konwersję asynchroniczną.

 

Nie mam na uwadze konwertera asynchronicznego bez Fifo, bo sama idea konwertera asynchronicznego na to nie pozwala. Nie istnieje konwerter asynchroniczny bez FiFo. Do możliwego działania idei konwersji asynchronicznej i możliwości powtórzenia transmisji przekłamanej paczki, niezbędny jest bufor FiFo składujący dane, choćby przez czas potrzebny na powtórzenie transmisji i na żądanie kanału zwrotnego.

 

O może w tym masz problem. W załapaniu w czym rzecz. Już sam nie wiem. Nawet Twój konwerter, na podstawie projektu Kolegi Jarka ma bufor FiFo, malusieńki, to fakt, bo TAS to nie jest potężny układ z dużą pamięcią, ale ma, bo nie ma innej opcji, przy konwersji asynchronicznej. Część rejestrów jest tam wykorzystana na potrzeby bufora. Konwerter "asynchroniczny" który nie miałby choćby najmniejszego bufora, przestaje być asynchronicznym, a staje się Isochronicznym, w lekkim uproszczeniu można tak napisać. A w takim konwerterze zachodzą oczywiście zjawiska o których piszesz. Ale nie w prawdziwym, asynchronicznym. Może tu jest "pies pogrzebany" gdzie nie bardzo czujesz temat. Pomyliłeś może taki konwerter z konstrukcją, choćby na Tenorze 7022L.

 

 

Pendrive, które różnie grają i konwertery asynchroniczne bez żadnego bufora, nie dogadamy się, oj nie dogadamy.

[marekzawa]

StasioP, czy przypadkiem nie jesteś zegarmistrzem i stąd to umiłowanie do zegarów :)

 

zibra

podaj linka do konvertera diyaudio na XMOS

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[zibra]

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ą )

[Gość SlawekR]

StasioP, czy przypadkiem nie jesteś zegarmistrzem i stąd to umiłowanie do zegarów :)

.....

 

Apropos braku bufora Fifo w konwerterze asynchornicznym... ba, w konwerterze, który osobiście używa Kolega Stasiop...

 

To link do dyskusji o tymże konwerterze. W podlinkowanym poście wypowiada się autor i wykonawca projektu konwertera, Kolega JarekC. Czyli informacja z pierwszej ręki.

http://www.audiostereo.pl/konwerter-usb-i2s-spdif-na-tas1020b-tryb-asynchroniczny-24bit96khz_75045.html/page__view__findpost__p__2341296

 

Normalnie przecieram oczy ze zdumienia, dochodząc do połowy lektury postu. Czary jakieś. Pozwolę sobie przytoczyć to jedno zadziwiające zdanie:

 

.....

Układ pracuje bardzo ładnie, udało mi się doprowadzić do stanu takiego że bufor odbiorczy FIFO jest przez cały czas transmisji wypełniony w połowie +- 1 próbka.

.....

 

UPS!!!!! No i mamy po temacie. Cóż więcej pisać. Można użyć cytatu ze Shreka "Boski Wiatr, nie ma przebacz" :-))). A tak poważnie, to Koledze Stsiop proponuję jeszcze raz zapoznać się z ideą i sposobem działania konwertera asynchronicznego. Może wreszcie uda mu się zatrybić, o co tak się spieramy. I skieruje Swoje wysiłki tam, gdzie realnie mogą one przynieść poprawę w dźwięku.

 

A najgorsze w tym wszystkim jest to, że Sabre, którego Kolega również używa, też posiada bufor Fifo i to całkiem spory, większy jak ten w konwerterze asynchronicznym. Bo bez niego nie mógłby się nijak obejść, przy tworzeniu wynikowego strumienia danych, na podstawie swojego zegara. Czyli mamy kolejne miejsce na odcięcie się od wpływu źródła i to w całkiem sporym stopniu.