Jplay

[zibra]

Stasiop, wgraj Linuxa i powiedz jakie sa zmiany w stosunku do Win7:)

[Gość SlawekR]

Do SlawekR

 

Odpowiem na te pytania ale jeden skrot myslowy zrobmy tak na szybko bo nie mam teraz czasu pisac a moze to cos wytlumaczy

Mamy bufory przez ktore przepuszczamy sygnal audio i2C sa trzy szyny danych (zeby bylo cos wzietego z zycia) i tymi buforami jest licznik typu D 7474 i zasilone to jest z odrebnego zasilacza. Teraz na te bufory przychodzi sygnal cyfrowy audio a na wejscie zegarowe podawany jest super stabilny sygnal zegara. I teraz jak mamy foobara to on generuje spora ilosc zaklocen to wszystko przenoszone jest fala elektromagnetyczna na obwody w tym buforze, zasilanie jest szarpane bardzo stromymi impulsami bo taki maja charakter sygnaly cyfrowe. takie zasilanie zaklocone bedzie powodowac to ze bufor nie przelaczy sie idealnie w czasie ale czas jego przelaczania bedzie przesuniety o to zaklocenie, powstanie jitter koniec kropka! A wielkosc tego zaklocenia bedzie zalezne od ilosci szumow cyfrowych, czyli np Jplayer bedzie ich mial mniej bo wiemy ze robi rozne zabiegi przenosi do pamieci minimalizuje watki zamraza procesy itp...i to wplywa na ilosc zaklocen. W przypadku transmisji asynchronicznej problem jest bardziej skomplikowany bo tu wystepuje petla czasowa ktora sama zakloca w tym wypadku bufory i teraz im bardziej ona bedzie pracowac ( a odbywaja sie tam szalone procesy)tym wieksze szarpanie bufora kolejna kropka.

 

A zabawa cala rozgrywa sie od okolo 200ps do obecnie 0.1ps to sa naprawde super male przesuniecia czasu w ukladach cyfrowych, a jest to udowodnione odsluchowo jak i matematycznie ze jest to slyszalne!

 

 

1ps = 0.000000000001 s

pozdrawiam Stasiop

 

Uczyniłeś rzeczywiście baaardzo duży skrót myślowy bo pominąłeś całą istotę, dlaczego omawiany przez nas system, własnie nie będzie podlegać tym zjawiskom.

 

1. Pierwszy skrót myślowy, to założenie, ze Foobar czy jakikolwiek inny program, operuje na synchronicznych, przezegarowanych danych czasu rzeczywistego, A strumień I2S w istocie takowym jest. Tyle, że nic takiego nie ma miejsca. Na takie uproszczenie, wpychające kuchennymi drzwiami ideę pracy synchronicznej, do systemu który nie jest systemem czasu rzeczywistego, na takie uproszczenie się nie zgadzam, gdyż taka sytuacja nie jest możliwa, nawet hipotetycznie. Więc odpada jedno źródło nośności zakłóceń i jittera.

 

2. Drugi skrót myślowy, niejako połączony z pierwszym, to wyrzucenie z toru, konwertera danych komputerowych, na synchroniczny sygnał I2S. A jeśli nie wyrzucenie, to przynajmniej zintegrowanie tegoż konwertera z pierwotnym systemem i źródłem danych. To próba stworzenia kolejnej drogi przedostawania się zakłóceń, a której to drogi w praktyce można uniknąć. Sygnał I2S jeśli już się pojawia w naszym systemie, to wyłącznie na wyjściu konwertera i nijak nie jest zależny od tego się przed konwerterem znajduje. Dla DACa który jest podpięty dalej, tak naprawdę jedynym widocznym źródłem, jest nasz konwerter, a nie komputer przed nim.

Spokojnie można zasilić konwerter z osobnego źródła, spokojnie można go całkowicie galwanicznie uniezależnić od komputera jako źródła. Ba, można go całkowicie uniezależnić w jakikolwiek sposób, także elektromagnetyczny. To tylko kwestia odpowiedniego interfejsu i umieszczenia konwertera w odpowiednim miejscu, patrz LAN, WiFi, AirPlay itd.

 

Rozpatrywana przez Ciebie sytuacja dotyczy sygnału I2S i zakłóceń przy okazji przenoszonych tą drogą. Przy czym, w naszej sytuacji, jedynym możliwym źródłem tych zakłóceń może być nasz konwerter, jakość jego zegara i zasilania. Ale nie komputer przed nim, gdyż nie ma on nic wspólnego ani z samym sygnałem I2S, który powstał w samym konwerterze, ani z jego zegarem.

 

Naprawdę nie musisz mi tłumaczyć jak działają bramki, zbocza sygnałów, przerzuty i piki w sygnale prostokątnym, możliwe opóźnienia od błędnej, detekcji zera i jedynki. Ja to wszystko wiem i zdaję sobie z tego sprawę. Tyle, że są to zjawiska dotyczące typowego toru audio, ze źródłem czasu rzeczywistego. W naszym przypadki nie ma na szans.

 

EDIT

Nadal czekam na odpowiedź na pytania wcześniejsze i to konkretną, a nie w formie cytatu, linka, czy też rozważań, które nie mają zastosowania do naszego systemu, gdyż działa on na innej zasadzie.

 

Skoro nadal masz problem z odpowiedzią na moje pytania, to mała podpowiedź, pytanie pomocnicze:

Czy jedną z istotnych i mocno podkreślanych, przez autora, zalet Jplaya, jest umieszczenie danych w dużym buforze pamięciowym, wcześniej na tę operację zarezerwanym w pamięci głównej? Jest tak w istocie, czy nie?

[prezi]

Stasiop, wgraj Linuxa i powiedz jakie sa zmiany w stosunku do Win7:)

Mam lepszy pomysł: niech skonfrontuje debiana z ubuntu :)

[migrena]

A co do badań to ja Ci mogę powiedzieć że takie badanie nie uprawnia Cię do stwierdzenia, że coś ma na coś wpływ. Może i o układach wiesz więcej (chyba na pewno :P) ale korelacja nie jest narzędziem, które pozwala na formułowanie związków przyczynowo skutkowych. Jest wiele korelacji np korelacja pozorna gdzie obie zmienne ze sobą korelują w sposób dodatni czy ujemny ale nie ma między nimi związku na poziomie jakichkolwiek interakcji. Wniosek który uprawniał by Cię do stwierdzenia, że napęd miał by wpływ na brzmienie musiał by mieć charakter eksperymentalny. Wyniki płynące z tego rodzaju badań pozwalają na formułowanie wniosków przyczynowo skutkowych.

 

Może być to dla Ciebie wniosek dość pokrętny ale wielu naukowców wykłada się na tym "dość prostym" ograniczeniu wynikających z zastosowania narzędzi badawczych (chodzi o statystykę i metodologię). Więc nie dziwi mnie ten fakt a raczej jest to coś normalnego ale prosił bym byś miał tego świadomość. Może być tak że jedna zmienna wpływa na drugą a przy kolejnych badaniach okaże się, że jest zmienna która łączy obie zmienne i to ona jest podatna na zmiany tej pierwszej. Zaś ona sama wpływa bezpośrednio na zmienną drugą.

 

No ale nie o tym wątek :P

Zwroc uwage jaka metode badan proponuja czytelnikom autorzy cytatu - nagrac sobie kopie plytki i posluchac roznic. Juz pomijajac absurdalnosc implikacji jakie niesie ze soba sugestia, ze pojawia sie roznice, sami takich testow nie zrobili. A przeciez sami twierdza, ze to taki banalny tescik... ;)

 

Pozwole sobie zamiescic link do prezentacji o testach na sluch (i nie tylko). Z AES, zeby nie bylo, ze to jacys niekompetentni ludzie.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Polecam obejrzec, zrobic sobie proponowane testy i zastanowic sie jak duze zmiany musza byc dokonywane w sygnale aby byl on slyszalny. Dla porownania dobrze jest przeczytac test jplay na computeraudiophile, ktory wrzucilem wczesniej.

 

Jakaś zależność pomiędzy wielkością pitów i landów a wynikowym strumieniem, pojawia się wyłącznie w przypadku słabych napędów, pracujących w czasie rzeczywistym. Przy czym im lepszy napęd, o lepszej zdolności odczytującej, że tak to ujmę, to i ta zależność jest coraz mniejsza, aż do jej całkowitego zaniku, w przypadku napędu asynchronicznego o zwielokrotnionej prędkości odczytu do bufora, czy też zwykłego napędu, w którym zastosowano EAC do odczytu danych, w trybie "do skutku".

Ja mam nadzieje, ze nie sugerujesz, ze wielokrotne przegrywanie plytki na nagrywarce stacjonarnej ze zrodla z odczytem x1 bedzie powodowac kumulacje jittera? :)

Natomiast zebysmy byli scisli to odczyt plyty cd w stacjonarym odtwarzaczu nie odbywa sie w czasie rzeczywistym - jak juz wspomnialem, sposob zakodowania danych na plycie wymaga operacji matematycznych przed ich podaniem na przetwornik, ktore wymagaja zastoswoania bufora. A za buforem to wiadomo ile zostaje z jittera.

 

PS

W dalszym ciagu mamy doczynienia ze spekulacjami i czysto akademickimi rozwazaniami, podczas gdy znacznie prosciej byloby gdyby autor programu poparl swoja teorie lezaca u podstaw programu czyms namacalnym - wynikami pomiaru lub chociazby testu odsluchowego wykluczajacymi efekty psychoakustyczne. Ale cos mi sie widzi, ze takowych nie zobaczymy...

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Gość SlawekR]

Ja mam nadzieje, ze nie sugerujesz, ze wielokrotne przegrywanie plytki na nagrywarce stacjonarnej ze zrodla z odczytem x1 bedzie powodowac kumulacje jittera? :)

 

A skąd takie przypuszczenie? Czy coś takiego zasugerowałem, w którejkolwiek części mojej wypowiedzi?

Jedyne co sugeruję, to to, że są napędy CD mogą być lepszej jakości, jak i takie o jakości gorszej.

 

Natomiast zebysmy byli scisli to odczyt plyty cd w stacjonarym odtwarzaczu nie odbywa sie w czasie rzeczywistym - jak juz wspomnialem, sposob zakodowania danych na plycie wymaga operacji matematycznych przed ich podaniem na przetwornik, ktore wymagaja zastoswoania bufora. A za buforem to wiadomo ile zostaje z jittera.

 

Wiem jak się odbywa odczyt danych z płyty CD. Traktuję go jako odczyt w czasie rzeczywistym, gdyż mimo wszystko, odbywa się on z przepływnością x1, czyli 150KB/s, bez kanału zwrotnego i bez możliwości powtórzenia operacji odczytu tego samego pola. Gdy pojawi się błąd gruby odczytu, który wygeneruje trzask, to się pojawi. Musztarda po obiedzie i żaden mechanizm ani algorytm nic na to nie poradzi.

 

A to z całą pewnością różni go w sposób zasadniczy, od działania napędów, o prędkości większej niż x1 i algorytmów umożliwiających wielokrotny odczyt płyty, pokroju EAC, który potrafi "spróbować" do 100 razy odczytać feralny fragment. Do tego jest jeszcze mechanizm ostatecznej weryfikacji Accuraterip.

 

Uprościłem to do takiego schematu, dla przejrzystości dyskusji, inaczej byłoby juz totalne masło maślane. Co oczywiście nie znaczy, że w optymalnych warunkach (99% przypadków), tryb pierwszy nie będzie wystarczającym. Ale mimo wszystko różnica między oboma trybami pracy, jest tak duża, że jednoznacznie unaocznia absurdalność niektórych założeń i twierdzeń dotyczących, choćby potencjalnego, występowania określonych zjawisk.

[migrena]

Chcialem sie upewnic, gdyz sugestia jakoby istniala zaleznosc miedzy jakoscia zapisu na plycie a odczytanym sygnalem (przy poprawnym odczycie, a wiec braku bledow c2) jest moim zdaniem dziwna. A tak wlasnie zrozumialem to co napisales - ze istnieje zaleznosc miedzy dokladnoscia zapisu danych na plytce a jitterem w "ostatecznym" strumieniu danych (powiedzmy spdif). Czy wg ciebie istnieje taka zaleznosc i czym mialaby byc spowodowana?

 

Tak, nie ma mozliwosci ponowienia odczytu ale czy jest to proces czasu rzeczywistego czy nie zalezy od tego jaka definicje takiego procesu przyjmiemy. Na plycie dane nie przeciez zapisane w sposob identyczny z tym w jaki zostana podane na przetwornik badz wyjscie cyfrowe. Musza zostac odprzeplecione, musi zostac zmieniony sposob kodowania, musi nastapic ich weryfikacja i korekcja itd. Wszystkie te procesy nie operuja na pojedynczych bitach w strumieniu ale na porcjach danych i to niekoniecznie w tej samej kolejnosci w jakiej one sa odczytane z plyty. Stad dla mnie nie jest to proces czasu rzeczywistego. Ale to roznica wynikla zdaje sie tylko z rozbieznosci definicji, z ktorych korzystamy.

[marekzawa]

A zabawa cala rozgrywa sie od okolo 200ps do obecnie 0.1ps to sa naprawde super male przesuniecia czasu w ukladach cyfrowych, a jest to udowodnione odsluchowo jak i matematycznie ze jest to slyszalne!

 

 

Proszę o wyliczenia matematyczne.

 

1ps = 0.000000000001 s

 

1 ps to bardzo mały interwał czasowy. Światło w tym czasie przebędzie drogę nieco poniżej 0.3mm a sygnał elektryczny w przewodniku jeszcze mniej.

 

Z jaką dokładnością wykonałeś połączenia I2S konwertera JarkaC do DACa ?

Aby zachować zbieżność czasową sygnałów I2S na poziomie 0.1ps wszystkie ścieżki muszą mieć dokładnie tę samą długość z dokładnością rzędu 0.01mm !!!

 

Tak patrze na zdjęcie jakie zamieściłeś w wątku poświęconym konwerterowi JarkaC, na którym pokazałeś połączenie konwertera do DACa po I2S.

Druciki jakimi połączyłeś konwerter na idealnie równe nie wyglądają. Dokładność raczej przypadkowa - jak się ucięło i oko widziało. Większej dokładności jak 2-3mm tam chyba nie ma. Czyli rozjazd czasowy rzędu 10ps !!! Uuuuuu nieźle zabagniłeś.

Teoria rozjechała się z praktyką, czy zapomniałeś o wielkościach jakie tu głosisz ?

Dla osoby, która głośi że słyszy jiter rzędu 1ps, słuchanie zdekodowanych danych, które trafiły do DACa z rozjazdem czasowym 10ps musi być traumatyczne. Tego się nie daje słuchać !!!

Ale na traumę StasioP znalazł lek o nazwie..... - kto zgadnie jaki ?

[Gość SlawekR]

Chcialem sie upewnic, gdyz sugestia jakoby istniala zaleznosc miedzy jakoscia zapisu na plycie a odczytanym sygnalem (przy poprawnym odczycie, a wiec braku bledow c2) jest moim zdaniem dziwna. A tak wlasnie zrozumialem to co napisales - ze istnieje zaleznosc miedzy dokladnoscia zapisu danych na plytce a jitterem w "ostatecznym" strumieniu danych (powiedzmy spdif). Czy wg ciebie istnieje taka zaleznosc i czym mialaby byc spowodowana?

 

Hmm, zmuszasz mnie, abym cytował sam siebie. To już zaczyna być ponad moje siły, wystarczy że muszę cytować innych :-P. Ale dobrze, zacytuję sam siebie, specjalnie dla Ciebie, z postu nr 385:

 

tu cytat:

 

Twierdzenie więc, że istnieje korelacja pomiędzy pitami i landami, a sygnałem wynikowym, jest absolutnie nieuprawnione.

 

Czu to rozwiewa Twoje wątpliwości, co do intencji moich wypowiedzi?

 

 

Tak, nie ma mozliwosci ponowienia odczytu ale czy jest to proces czasu rzeczywistego czy nie zalezy od tego jaka definicje takiego procesu przyjmiemy.

 

Dokładnie tak, masz 100% racji. Stąd też, tak jak już wcześniej wspomniałem, dla przejrzystości dyskusji przyjąłem spore uproszczenie definicji, na potrzeby bieżących rozważań. Jest to o tyle uprawnione, że tak naprawdę pierwotnie dyskutujemy o asynchronicznej transmisji z kanałem zwrotnym i systemie Windows, a nie o odtwarzaczach CD.

No litości, wyobrażasz sobie, co by było, gdyby zaczął dzielić, aż tak włosa na czworo? Jest wystarczająco trudno trafić do niektórych, pomimo aż takich uproszczeń, w stylu "kawa na ławę". A to i tak do nich nie trafia.

 

Na plycie dane nie przeciez zapisane w sposob identyczny z tym w jaki zostana podane na przetwornik badz wyjscie cyfrowe. Musza zostac odprzeplecione, musi zostac zmieniony sposob kodowania, musi nastapic ich weryfikacja i korekcja itd. Wszystkie te procesy nie operuja na pojedynczych bitach w strumieniu ale na porcjach danych i to niekoniecznie w tej samej kolejnosci w jakiej one sa odczytane z plyty. Stad dla mnie nie jest to proces czasu rzeczywistego. Ale to roznica wynikla zdaje sie tylko z rozbieznosci definicji, z ktorych korzystamy.

 

No ja to wszystko wiem, wiem, o przeplocie. kodach korekcyjnych i całej reszcie, że to są tylko dane, które na samej płycie nie są przecież przezegarowane na sztywno. Gdyby było inaczej, nie byłoby możliwości odczytu płyty szybciej, ze zmienną prędkością. A to przecież powszechna praktyka w komputerach. Rzeczywisty proces taktowania powstaje dopiero w procesorze stacjonarnego odtwarzacza CD i na podstawie jego zegara. I tak naprawdę to jest element o znaczeniu zasadniczym i strategicznym dla wynikowego strumienia danych audio, a nie sam moment techniczny odczytu płyty. Ale naprawdę pozwól mi przyjąć uproszczenie, jak wyżej napisałem, to nie psuje całej koncepcji nijak, a przynajmniej nie rozwodni dyskusji.

[Stasiop]

Dla osoby, która głośi że słyszy jiter rzędu 1ps, słuchanie zdekodowanych danych, które trafiły do DACa z rozjazdem czasowym 10ps musi być traumatyczne. Tego się nie daje słuchać !!!

Ale na traumę StasioP znalazł lek o nazwie..... - kto zgadnie jaki ?

Tylko ta 1ps jest w ukladzie gdzie nastepuje modulacja czyli problem jest mnozony wiele, wiele razy. Ale to prawda slychac dlugosci sciezek jak i ekranowie i rodzaj przesylu danych . A to oczym Ty piszesz to dziecinne uproszczenie problemu

 

 

Dla osoby, która głośi że słyszy jiter rzędu 1ps, słuchanie zdekodowanych danych, które trafiły do DACa z rozjazdem czasowym 10ps musi być traumatyczne. Tego się nie daje słuchać !!!

I jeszcze raz to wszystko sie zwielokratnia w modulacjach.

 

Aby zachować zbieżność czasową sygnałów I2S na poziomie 0.1ps wszystkie ścieżki muszą mieć dokładnie tę samą długość z dokładnością rzędu 0.01mm !!!

Nie musza bo to trafia na bufor i tam jest przezegarowywane. Ale masz racje lepiej aby byly dokladnie takie same tu sie zgodze :) Ale ciekawa i trafna z innej strony uwaga.

[marekzawa]

A to oczym Ty piszesz to dziecinne uproszczenie problemu

 

Pewnie że uproszczenie, ale obrazuje zależności czasowe na poziomie 1ps i mniej.

Nie musza bo to trafia na bufor i tam jest przezegarowywane.

 

To bufor jednak działa ? Będzie się trzęsło czy nie ?

Jest światełko w tunelu czy dalej ciemno :)

[migrena]

(ciach)

Ok, ok. Tak sie tylko upewniam, ze rozumiemy temat w ten sam sposob. Na tym forum mozna nabawic sie paranoi, ze mimo uzywania tych samych terminow dyskutuje sie o czyms zupelnie roznym, lub tez niektorzy pisza z komputerow w innej rzeczywistosci...

[Stasiop]

Pewnie że uproszczenie, ale obrazuje zależności czasowe na poziomie 1ps i mniej.

No wartosc jest abstrakcyjnie mala, jak 14 lat temu bawilem sie generatorami to wartosc 200ps to bylo juz bardzo malo, a teraz sam slyszalem roznice pomiedzy 1ps a 5 ps tylko ze te 1ps to jest wartosc RMS czyli skuteczna, wartosc prawdziwa szczyt-szczyt jest znacznie wieksza okolo 5-20ps w zaleznosci od generatora, no i dodatktowo roznie generatory maja to porozkladane pod wzgledem czestotliwosci, zazwyczaj maja bardzo duze szumy fazowe w zakresie od1Hz do okolo 500Hz gdzie jak wiemy mamy fale akustyczna slyszalna. Ale przyznam ze wartosci rzedu ps sa abstrakcyjnie male - a jednak to slychac! Chociaz sa juz technologie cyfrowe ktore zapewniaja jitter na poziomie 40fs czyli jeszcze mamy 3 zera do tylu. Nie wiem jak to mierza??? Ale sa technologie :)

 

To bufor jednak działa ? Będzie się trzęsło czy nie ?

Jest światełko w tunelu czy dalej ciemno :)

Bedzie sie trzeslo oczywiscie ale bufor swoje tez zrobi, gdyby nie robil nie byloby sensu go stosowac.

A swiatelka w tunelu nie ma i prawdopodobnie nigdy nie bedzie bo problem jitteru chyba nie jest do zlikwidowania do zera nigdy.

[Stasiop]

4. Kolejna kwestia sporna. Na moje konkretne pytanie, stwierdziłeś że Jplay wykonuje operacje audio czasu rzeczywistego i uważasz, że dane są przezegarowane zegarem komputera. Ja stwierdziłem, że jest dokładnie odwrotnie. Jplay nie odczytuje muzyki w czasie rzeczywistym, co tym samym nie daje możliwości, aby strumień danych, rozumiany jako strumień audio, skoro mowa o jitterze to musi to być strumień audio, aby ten strumień był przezegarowany w ten sposób.

 

5. Na moje kolejne pytanie, dlaczego uważasz, że Jplay działa w czasie rzeczywistym, skąd ta jedna, jedyna aplikacja w systemie nie będącym systemem czasu rzeczywistego, nagle ten jeden program potrafi działać w takim systemie w czasie rzeczywistym. Na to nie otrzymałem odpowiedzi również.

Prawde mowiac dokladnie to nie mam zielonego pojecia jak dziala JPlayer i powiem wiecej nie wiem co wewnatrz robi komputert bo to zalezy od oprogramowania z synlame cyfrowym audio. i to faky nie wiem czy to jest czas rzeczywisty czy tez nie ale nie tu lezy problem. Jesli chodzi o konwertert asynchroniczny jitter przedostaje sie kilkoma drogami ale moim zdaniem i z tego co bawilem sie petlami generatorami roznymi odbiornikami to glowna droga przedostawania sie jitteru jest wplyw zaklocen czy tez mozna nazwac drzenia czasowego ktore jest generowane w zrodle czyli w tym wypadku w komputerze, pozniej mamy izolacje galwaniczna pozniej TAS-a ktory zwalnia lub przyspiesza odbior w zaleznosci jakie sa roznice w czasie generatorow i ich wspolnycn rozedrgan czasowych czyli jitteru. I teraz mechanizm ktory ja uwazam za podstawowy to jest to ze procent zajitterowanego sygnalu z komputera ma wplywa na to ile raz i w jakim czasie ten TAS przyspieszy odbior lub zwolni. To zwalnianie i przyspieszanie w takt zaklocen z komputera bedzie wplywalo na generacje jittera w TAS-ie bo nastepuje modulacja i problem jest wiele wiele razy zwielokratniany, bo to co robi TAS to nie sa wolne rekacje tylko szybkie, bo bufor jest krotki (trzeba sobie to wyobrazic ze to nastepuje bardzo szybko i jest to skorelowane z jitterem zrodla czyli komputera JPlayera. A to ze TAS pracuje raz z taka czestotliwoscia a raz z inna bedzie mialo wplyw na zasilania i przesuniecia czasu w buforach wyjsciowych ktory on posiada.

To nie sa moje jakies domorosle metody wyjasniania tego ale tu trzeba by sie wgryzc w teorie dzialania roznorakich petli PLL DPLL czy tez trybu asynchronicznego ktory jest tez swoista petla. Na te petle zawsze oddzialywuje zaklocenia i nigdy NIGDY nie sa one idealne. Tu trzeba sie obczytac w matemaytyce dzialania petli analogowych i cyfrowych innej rady nie ma.

Dla tego dzialanie takich programow jak JPLAYer bedzie slyszalne i jest slyszalne!!!

 

KONIEC KROPKA

 

oczywiscie mojej strony

 

Pozdrawiam StasioP

[Stasiop]

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) i jeszcze z tym warto sie zapoznac na wstepie ;) a pozniej to juz tylko matematyka na temat petli

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Gość SlawekR]

Prawde mowiac dokladnie to nie mam zielonego pojecia jak dziala JPlayer i powiem wiecej nie wiem co wewnatrz robi komputert bo to zalezy od oprogramowania z synlame cyfrowym audio. i to faky nie wiem czy to jest czas rzeczywisty czy tez nie ale nie tu lezy problem.

 

I na tym właśnie bazuje szeroko pojęte voodoo audio. Na niewiedzy i w związku z tym na braku refleksji, co w danym systemie w ogóle jest możliwe, a co nie. I tu leży problem zasadniczy, a Ty go niestety bagatelizujesz. To czy jest to system czasu rzeczywistego, czy też nie, determinować będzie możliwość występowania pętli w ogóle. A przecież na występowaniu pętli opierasz całe swoje rozważania.

 

Jesli chodzi o konwertert asynchroniczny jitter przedostaje sie kilkoma drogami ale moim zdaniem i z tego co bawilem sie petlami generatorami roznymi odbiornikami to glowna droga przedostawania sie jitteru jest wplyw zaklocen czy tez mozna nazwac drzenia czasowego ktore jest generowane w zrodle czyli w tym wypadku w komputerze, pozniej mamy izolacje galwaniczna pozniej TAS-a ktory zwalnia lub przyspiesza odbior w zaleznosci jakie sa roznice w czasie generatorow i ich wspolnycn rozedrgan czasowych czyli jitteru.

 

No i tu jest właśnie problem w Twoim rozumowaniu. Skąd przyszło Ci do głowy że TAS zwalnie i przyśpiesza, czyli że jego zegar nadąża za zegarem ramki źródła. Nic takiego nie ma miejsca. Jedymym istotnym i stałym zegarem w tym systemie, z punktu widzenia audio, jest zegar urządzenia Master. A urządzeniem master jest konwerter asynchorniczny na TASie. I to nie on musi nadążać za drżeniem ramki, a to on zmusza źródło, do dostarczenia mu danych, wyłącznie na jego życzenie. Źródło jest w tym wypadku urządzeniem Slave i to ono musi się dostosowywać. Ba, przy odpowiednio szybkim interfejsie, konwerter może wysłać żądanie wyłączenia się źródła, na określony czas. Tak działa właśnie system nie będący systemem czasu rzeczywistego. Źródło zostanie wyłączone i będzie budzone wyłącznie jak konwerter zażąda od niego kolejnej porcji danych. Czas nieaktywności źródła, w stosunku do jego zegara, będzie wręcz wiecznością. W tym czasie, konwerter cały czas pracuje i tworzy wynikowy strumień danych. Taka jest domena systemu nie będącego systemem czasu rzeczywistego, i nie ma, za przeproszeniem, pieprzonej możliwości, na występowanie nadążającej pętli PLL. Jesli źródło jest zbędne przez większość czasu i może zostać wręcz odłączone przez konwerter, to jakim cudem miałaby zachodzić możliwość pętli? Przez zapach łąki, fluidy, czy pszczoły zapylające kwiaty?

 

I teraz mechanizm ktory ja uwazam za podstawowy to jest to ze procent zajitterowanego sygnalu z komputera ma wplywa na to ile raz i w jakim czasie ten TAS przyspieszy odbior lub zwolni.

 

No właśnie, o tym pisałem. TAS nie zwolni, ani nie przyśpieszy, TAS pracuje stabilnie wedle własnego zegara, a co najwyżej on steruje zwalnianiem lub przyśpieszaniem porcji danych, których zresztą sam żąda ze źródła, czyli komputera.

Tak samo jak program pocztowy żąda od serwera dostarczenia poczty. Program pocztowy też wysyłą żądania w porcjach, a na ich częstotliwość wpływ ma wyłącznie sam program pocztowy, a nie zegar serwera i jego oprogramowanie. A częstotliwość nośna łącza ADSL, jeśli na ten przykład ktoś korzysta z neostrady, to też ma zerowy wpływ na częstotliwość zapytań programu pocztowego.

 

To zwalnianie i przyspieszanie w takt zaklocen z komputera

 

Które nie ma miejsca, po prostu nie istnieje.

 

bedzie wplywalo na generacje jittera w TAS-ie bo nastepuje modulacja

 

Nie będzie wpływać na nic, bo nie ma modulacji jednego zegara drugim, gdyż chartakter pracy źródła i konwertera, umożliwia w skrajnym przypadku nawet czasowe całkowite wyłączenie źródła.

 

i problem jest wiele wiele razy zwielokratniany, bo to co robi TAS to nie sa wolne rekacje tylko szybkie, bo bufor jest krotki (trzeba sobie to wyobrazic ze to nastepuje bardzo szybko i jest to skorelowane z jitterem zrodla czyli komputera JPlayera. A to ze TAS pracuje raz z taka czestotliwoscia a raz z inna bedzie mialo wplyw na zasilania i przesuniecia czasu w buforach wyjsciowych ktory on posiada.

 

Problem, którego nie ma jest zwieolratniany głównie przez Cibie. A i tak 0 x 100, nadal da wynik 0. :-)

 

A TAS pracuje ze stałą częstotliwością, czy to Ci się podoba, czy nie i niezależnie od Twoich o nim wyobrażeń.

 

To nie sa moje jakies domorosle metody wyjasniania tego

wyjsciowych ktory on posiada.

 

Wybacz szczerość, ale dokładnie takie są, to są Twoje metody wyjasniania zjawisk, których mechanizmów nie do końca czaisz. Dlatego starasz się na nie przenieść mechanizmy z innych, tu nie przeczę, znanych Ci zjawisk. Ale jednak zjawisk, które przełożenia na naszą sytuację mieć nie będą.

 

ale tu trzeba by sie wgryzc w teorie dzialania roznorakich petli PLL DPLL

 

Nie trzeba się w nie wgryzać, gdyż nie mają zastosowania do naszego przypadku.

 

czy tez trybu asynchronicznego ktory jest tez swoista petla.

 

A którego "swoistość" polega na tym, że nie jest pętlą :-). Gdyż w tym trybie, sygnał wejściowy może zostać całkowicie odłączony na określony czas, a i tak konwerter nadal może działać. Więc o pętli można zapomnieć.

 

Na te petle zawsze oddzialywuje zaklocenia i nigdy NIGDY nie sa one idealne. Tu trzeba sie obczytac w matemaytyce dzialania petli analogowych i cyfrowych innej rady nie ma.

Dla tego dzialanie takich programow jak JPLAYer bedzie slyszalne i jest slyszalne!!!

czy tez trybu asynchronicznego ktory jest tez swoista petla.

 

Jak wyżej. O "swoistości" tej pętli już napisałem. Dlatego też uważam Twoje rozważania za całkowicie błędne.

[Stasiop]

Gdyż w tym trybie, sygnał wejściowy może zostać całkowicie odłączony na określony czas, a i tak konwerter nadal może działać

 

Hihi i tu jest Twoj blad myslowy ten czas jest krotki bardzo krotki bo bufor w TAS to tylko dwie ramki ;) nie prawdaz, Slawku? Mozna to policzyc jakis czas temu, JarekC gdzies to podawal jaki to czas :)

 

Jak wyżej. O "swoistości" tej pętli już napisałem. Dlatego też uważam Twoje rozważania za całkowicie błędne.

To jest teoria dzialania petli ktorej ucza na studiach i aby sie z nia niezgodzic trzeba podac konkretne kontrargumenty juz matematyczne. Zadna petla nie jest idealna a to ze nie jest ona analogowa i ma przerwy w dzialaniu nie oznacza ze mozesz spac spokojnie. Mozesz spac spokojnie ale to beda czasy rzedu msekund a w tym czasie nastapi modulacja gdzie prazki widmowe nie sa tylko na mikrosekundach ale i na usekundach az do nanosekund i picosekund. To zjawisko zachodzi wiec obczytaj sie w tym. Mozesz mowic ze tego nie slychac tu juz bardziej mozemy polemizowac ale ze zjawisko zachodzi to no coz dziwne ze tego nie rozumiesz i dalej uparcie jest zamkniety na arumenty.

 

Ale tu masz racje ze jesli ten bufor bedzie dluzszy to problem bedzie sie zmniejszal bo jakgdyby filtracja cyfrowa jest znacznie nizej tzn stala czasowa jest mniejsza to lepsze filtrowanie na wyzszych czestotliwosciach. Rozumiesz teraz? I dlatego ja caly czas mowie ze problem moze rozwiazac tylko dlugie FIFO ale bardzo dlugie tak aby si odsunac ze stala czasowoa rzedu minut, wtedy dopiero prazki wysokoczestotliwosciowe beda male!!!

[Gość SlawekR]

Hihi i tu jest Twoj blad myslowy ten czas jest krotki bardzo krotki bo bufor w TAS to tylko dwie ramki ;) nie prawdaz, Slawku, mozna to policzyc jaki czas temu, JarekC gdzies to podawal jaki to czas :)

 

Pisałem to w kontekście idei konwersji asynchronicznej w ogóle. Oczywiście odłączenie źródła to dość przejaskrawiony przypadek, ale specjalnie o nim wspomniałem, bo jest bardzo obrazowy. A i na pewno możliwy do zrealizowania, czyż nie?

 

A skoro piszesz o "wadzie" konwersji asynchronicznej, w postaci pętli, to pokazałem Ci błąd logiczny jaki popełniasz, do czego wystarczy wskazanie choćby jednego przypadku konwersji asynchronicznej, kiedy jaskrawo widać, że nie ma szans na pętlę. I taki przypadek też wskazałem. I jest ob bezpośrednią konsekwencją pracy w trybie nie czasu rzeczywistego. W TASie, pomimo, że bufor jest mniejszy, to nadal sygnał wejściowy do niego dociera w identyczny sposób. Jak ci nie pasuje TAS, kup sobie coś na CM6631, który ma dedykowaną zewnętrzną pamięć. Weź bufor na Xilixie, Atmelu, lub jakikolwiek inny.... A nie pisz o zbawiennym wpływie Jplaya, tylko zainwestuj tam gdzie to ma sens, czyli w porządny konwerter.

 

http://home.zonnet.nl/ultimate_audio/PDF-files/jitter.pdf i jeszcze z tym warto sie zapoznac na wstepie ;) a pozniej to juz tylko matematyka na temat petli

 

 

Jak już powołujesz się na matematykę, to ja proponuję do kompletu logikę, bo tej niestety brak w Twoich rozważaniach, a bez której matematyka zda się w tym przypadku psu na budę :).

 

To jest teoria dzialania petli ktorej ucza na studiach i aby sie z nia niezgodzic trzeba podac konkretne kontrargumenty juz matematyczne.

 

Wiem jaka jest teoria działania pętli. A konkretnym argumentem z mojej strony jest wskazanie, choćby teoretycznej, możliwości braku tej pętli, w przypadku konwersi asynchronicznej. I taką wykazałem. Teoretyczny czas 1s przerwy w transmisji, wymaga bufora na poziomie 150KB. Nie jest to oszałamiająca, wydumana, ani niemożliwa do zrealizowania, wartość.

 

EDIT

Typowy bufor stosowany przy asynchronicznej transmisji protokołem Airplay, wynosi od 4 do 7MB. To daje możliwość uśpienia źródła na 46 sekund.

[Stasiop]

A nie pisz o zbawiennym wpływie Jplaya, tylko zainwestuj tam gdzie to ma sens, czyli w porządny konwerter.

 

No ale kazda klasyczna teoria matematyczna zaklada dzialanie petli kazdej analogowej we wzmacniaczu czy tez cyfrowej w DPLL czy tez cyfrowej w trybie asynchronicznym ze poprawiany jest blad BLAD tyke razy ile wzmocnienie petli. Ale petla wprowadza tez swoj blad, glownie czasowy ale na skroty - jesli blad wejsciowy jest maly to i mnieszy bedzie na wyjsciu. No ja juz nie wiem jak Ci to tlumaczyc!!!

 

Czyli jesli jest mniejszy blad zrodla to i mniejszy wyjsciowy!!!!!!!!!!!!!!

 

Czyli Jplayera moze byc slychac to wynika z teorii

 

A to ze slychac jest tylko dowodem potwierdzajacym teorie!

 

Koniec wiecej sie nieodzywam!

 

Pozdrawiam StasioP

[dio]

Coraz bardziej przypomina to dyskusję XIX wiecznego chłopa z współczesnym studentem astronomii.

Ziemia jest okrągła. Ale gdzie tam, panocku pier...lisz, przeca widzę że jest płaska!

 

Ale Stasiop trzymaj się, Kiedyś czytałem "Szpilki", dzisiaj czytam Twoje wpisy w tym temacie ;)

[Gość SlawekR]

No ale kazda klasyczna teoria matematyczna zaklada dzialanie petli kazdej analogowej we wzmacniaczu czy tez cyfrowej w DPLL czy tez cyfrowej w trybie asynchronicznym ze poprawiany jest blad BLAD tyke razy ile wzmocnienie petli. Ale petla wprowadza tez swoj blad, glownie czasowy ale na skroty - jesli blad wejsciowy jest maly to i mnieszy bedzie na wyjsciu. No ja juz nie wiem jak Ci to tlumaczyc!!!

 

Tyle, że usiłujesz stworzyć pętlę cyfrową DPLL i zastosować jej teorię na poziomie absurdalnym, odnosząc ją do naszego przypadku.

 

Tak patrząc, to nawet pomiędzy serwerem pocztowym, a klientem występuję pętla DPLL. No bo przecież, jeśli serwer padnie na minutę, to wygeneruje time outa u klienta i nastąpi zakłócenie w postaci przerwy w dostarczeniu maila, krótko mówiąc mail stanie się niekompletny i nieczytelny.

 

A i owszem, tak się stanie. Ale nie znaczy, że należy mówić w tym przypadku o pętli cyfrowej DPLL, bo to byłoby absurdalne.

 

Dokładnie to samo jest w naszym przypadku. Do tego, wysnuwasz teorię, że skoro jest pętla, nawet taka "dziwna", no ale jest skoro można przerwać transmisję całkowicie i uniemożliwić odbiór wiadomości, to niby jest pętla.... No to skoro jest taka "prawie" pętla, to wnosi ona zakłócenia ciągłe, zmienne, które mają zauważalny wpływ na sygnał, w tym wypadku wiadomość pocztową i powodują widoczne zafałszowanie jej treści, w zależności od poziomu hipotetycznych zakłóceń przenoszonych pętlą. Czyli że "bit nie zawsze bitowi równy", jak to już stwierdziłeś parokrotnie.

 

Co w tym przypadku oczywiście stanowi farmazon do potęgi Ntej. Tak samo jak w naszym systemie. Te dwie sytuacje niczym się nie różnią.

 

Przekroczenie możliwości bufora, owszem, spowoduje przerwę w transmisji, czyli błąd gruby. Ale wielkość bufora, jeśli tylko nie zostanie przekroczony, nie spowoduje stanów pośrednich, wpływających na brzmienie. Nie jest to żaden swoisty filtr cyfrowy, o różnej mocy działania, jak to twierdzisz. Bufor w tym przypadku to bufor, albo działa i błędy nie powodują jego przekroczenia, albo nie działa, bo jest zbyt mały i błędy powodują przerwę w transmisji. Nie ma opcji pośrednich zakłócających i teorii długiego fifio. Szczególnie w systemie, nie będącym systemem czasu rzeczywistego, asynchronicznym i z kanałem zwrotnym.

 

 

 

Czyli jesli jest mniejszy blad zrodla to i mniejszy wyjsciowy!!!!!!!!!!!!!!

 

Nie prawda. Mniejszy błąd źródła, brak błędu na wyjściu, większy błąd źródła, przekraczający możliwości korekcyjne bufora i transmisji asynchronicznej, przerwa w sygnale wyjściowym. Opcje pośrednie nie występują.

 

Tłumaczyłem Ci to już na przykładzie transmisji cyfrowej telewizji sat, gdzie zachodzą identyczne zjawiska. No ale jak grochem o ścianę, ech.

 

Czyli Jplayera moze byc slychac to wynika z teorii

 

Czyli Jplayera nie może być słychać, przynajmniej na podstawie tej teorii, gdyż jest ona błędna i pozbawiona logicznych podstaw.

 

A to ze slychac jest tylko dowodem potwierdzajacym teorie!

 

To że Twierdzisz że słyszysz różnicę, dowodzić może dwóch rzeczy, albo masz problem w systemie, innej natury, na przykład zasilającej. Problem z masami itd. I bardziej trywialne zjawiska powodują różnice brzmieniowe, występujące na przykład po stronie sekcji analogowej DACa. na co stawiam, że tak jest, widziałem Twój układ testowy na zdjęciu, przy okazji konwertera Kolegi Jarka. Zresztą sam przyznawałeś, że masz zakłócenia w analogu. Co można oczywiście poprawić normalnymi metodami, a niekoniecznie voodoo. Albo Twoje zmysły reagują tak jak u każdego człowieka na Ziemi, czyli są podatne na wiele czynników i sugestię.

 

EDIT

U każdego człowieka na Ziemi, oczywiście poza Chuckiem ;-))).

 

Koniec wiecej sie nieodzywam!

...

 

To oczywiście jest jakaś opcja, chociaż ja cały czas cierpliwie i grzecznie czekam, na odpowiedź na moje pytania, które zadałem 2 dni temu :).

No ale jak nie, to nie.

 

EDIT2

 

Dla ułatwienia kolejny przykład. Z mojego własnego podwórka, nie żaden wydumany.

 

1.Mam Macbooka Pro Unibody 15 cali, na nim MAC OS Lion, Itunes. wszystko połączone z siecią lokalną za pomocą Wifi.

 

2. Mam Dreamboxa HD800SE, z wyjściem cyfrowym, na nim system Enigma 2, wgrany plugin do obsługi protokołu Airplay. Drerambox połączony kablem z siecią LAN. Na jego wyjściu DAC i dalej reszta systemu.

 

Włączam odtwarzanie w Itunes muzyki, jako źródło wskazuję urządzenie Airplay widoczne w sieci, w tym wypadku Dreamboxa. Bufor w Dreamie się wypełnił, zaczyna grać muzyka. Ok, wyłączam Macbooka, idę sobie zrobić herbatę, wracam po minucie, włączam Macbooka, muzyka gra nieprzerwanie, bufor się doładował. Wyłączam Macbooka, idę na "siku". Wracam po minucie, włączam Macbooka, muzyka cały czas gra,nic się nie zmieniło, bufor się doładował.

 

Wedle Twojej teorii, pomiędzy źródłem (MacBookiem), a konwerterem asynchronicznym (Dreamboxem) zawsze występuje "swoista" pętla DPLL, dzięki której zakłócenia z Macbooka, będą wpływać na brzmienie. Ba, zmiana programu odtwarzającego, który jakoby timinguje odtwarzanie i keszuje pamięć Macbooka, zmniejszy zakłócenia.

 

A ja twierdzę, że jakość sygnału i brzmienie, zależą wyłącznie od jakości zegara, zasilania i wyjścia cyfrowego Dreamboxa. Macbook i soft odtwarzający nie ma znaczenia w tym przypadku.

 

Twierdzę, że nie ma pętli pomiędzy tymi urządzeniami, nawet jeśli jest możliwość całkowitego przerwania odtwarzania, poprzez zakłócenie, choćby w postaci padu sieci lokalnej i niedoładowania bufora na czas. To nie uprawnia jeszcze do twierdzenia o istnieniu pętli. I nie ma stanu pośredniego działania tej "niby" pętli, który to stan pozwoliłby wpływać na brzmienie, poprzez zakłócenia przez nią przenoszone.

 

"To se ne da" i tyle w tym temacie.

[Stasiop]

Twierdzę, że nie ma pętli pomiędzy tymi urządzeniami, nawet jeśli jest możliwość całkowitego przerwania odtwarzania, poprzez zakłócenie, choćby w postaci padu sieci lokalnej i niedoładowania bufora na czas. To nie uprawnia jeszcze do twierdzenia o istnieniu pętli. I nie ma stanu pośredniego działania tej "niby" pętli, który to stan pozwoliłby wpływać na brzmienie, poprzez zakłócenia przez nią przenoszone.

To jest petla!!! Mozesz sie denerwowac ale jest to petla panocku! Wolna bardzo petla ale petla!!!!!!

 

Mialem nie pisac ...

[marekzawa]

To jest petla!!! Mozesz sie denerwowac ale jest to petla panocku! Wolna bardzo petla ale petla!!!!!!

 

 

Panocku, tak na spokojnie to nie jest pętla :)

[Gość SlawekR]

To jest petla!!! Mozesz sie denerwowac ale jest to petla panocku! Wolna bardzo petla ale petla!!!!!!

 

Mialem nie pisac ...

 

Ja się nie denerwuję, jedyne uczucie jakie zaczyna we mnie kiełkować, to mieszanina niedowierzania, przerażenia i współczucia. Szczególnie po takiej odpowiedzi.

 

Nie przypuszczałem, że dyskusja zanurzy się do tego stopnia w oparach absurdu, przez Twoją totalną negację i nie dopuszczanie do wiadomości, jakichkolwiek racjonalnych faktów, tłumaczeń i przykładów .

 

Jeśli to jest pętla, to rozbłysk na słońcu, który wywoła paraliż energetyczny kraju, a tym samym spowoduje przerwę w zasilaniu i działaniu konwertera asynchronicznego, to takie zjawisko również będzie pętlą DPLL, wedle Twojej definicji. Pętlą pomiędzy słońcem, a konwerterem asynchronicznym. A jeśli jest pętla, również wedle Twojej definicji, to tym samym słońce wpływa w sposób ciągły na zmianę brzmienia konwertera.

 

W związku z powyższym, nie mam więcej pytań i uwag.

 

Udało Ci się, dostrzegłem wreszcie pętlę. Widzę tu pętlę, która zaciskając się na szyi, odcina niektórym dopływ krwi do mózgu, blokując opcję logicznego rozumowania. Przepraszam za sarkazm, ale na takie dictum, nie jestem w stanie inaczej zareagować :-(((((.

 

Ręce mi opadły. skutecznie udało ci się wywołać we mnie niechęć do jakiejkolwiek dalszej dyskusji. Dobranoc.

[mrfx]

SlawekR: "Nie przypuszczałem, że dyskusja zanurzy się do tego stopnia w oparach absurdu" - Sławku jak Ci się udało nie dostrzec, że opary absurdu zaczęły się unosić już na pierwszej stronie tego wątku, a 2 strony dalej mgła była gęstsza niż w Silent Hill. Tymczasem mamy tu 14 stron opowieści w stylu Alicji w Krainie Czarów na temat magicznego programu ulepszającego zera, jedynki i takty. :) Trolle mają taką naturę, że nigdy nie są syte, ale tutaj to chyba niedługo eksplodują z przejedzenia. :)

[Gość SlawekR]

SlawekR: "Nie przypuszczałem, że dyskusja zanurzy się do tego stopnia w oparach absurdu" - Sławku jak Ci się udało nie dostrzec, że opary absurdu zaczęły się unosić już na pierwszej stronie tego wątku, a 2 strony dalej mgła była gęstsza niż w Silent Hill.....

 

No niestety. Mam taką cechę charakteru, która powoduje, że na dzień dobry staram się pozytywnie patrzeć na świat. Co przenosi się też i na dyskusje na forach. Rozpoczynając dyskusję, z góry zakładam dobrą wolę współdyskutujących, ich otwartość na argumenty, szczególnie jeśli będą rzeczowe, realne i przede wszystkim logiczne. Brak zacietrzewienia itd. Konsekwencją tego, jest zwiększona tolerancja i cierpliwość, w przypadku wypowiedzi, hmm, mniej rzeczowych czy też mniej logicznych, albo zwykłej ucieczki w bok od tematu zasadniczego. Szczególnie jeśli nie towarzyszy temu agresja słowna i wycieczki osobiste, wtedy naprawdę wiele jestem w stanie znieść i wykazać cierpliwość anielską. Ale wszystko ma swoje granice. Ja nie mam nic personalnie do Kolegi Stasiop, ba wręcz darzę go sympatią za dokumentację, którą mi udostępnił, dotyczącą całkiem innej kwestii. Ale jest pewna granica, poza którą dyskusja przechodzi "jeden most za daleko" i staje nad przepaścią, za którą nie ma już nic, tylko totalny absurd. I tak właśnie się stało. A szkoda :-(.

[Stasiop]

Pomiedzy wylaczeniem urzadzen audio przykladowo z rana a wlaczeniem wieczorem i tak wkolko rowniez wystepuje petla. To tylko wasze malo przestrzenne myslenie nie pozwala Wam tego zobaczyc. Kazdy z Was powie ze nie bedzie tego slychac w sygnale a ja powiem i owszem jezeli przykladowo bedziemy ten sprzet wlaczac i wylacz raz na godzine to warunki termiczne urzadzen audio beda sie zmieniac. I tak przykladowo wzmacniacze maja ogromna bezwladnosc cieplna regulowany tam jest prad spoczynkowy polega to na tym ze pobierana jest temperatura z radiatora i zwierany lub rozwierany jest sygnal sterujacy baz tranzsytorow, wiele wzmacniaczy w szczegolnosci tych duzych dochodzi do rownowagi po okolo 0.5h i da sie to zmierzyc a sa i tacy audiofile ze nie wylaczaja sprzetu na okroglo aby wlasnie nie dopusci do zmiany warunkow pracy. czemu to slychac? Bo nagrzewaja sie elementy ktore zazwyczaj lepiej pracuja w stalych warunkach temperaturowych.

Nastepna sprawa to np przetworniki konwertery itp. one tez ulegaja petlom cieplnym bo np generatory one to lubia pracowac ze stala temperatura pracy pattrz na ten przyklad na generatory ovenowane, ovenowane generatory jak ogolnie wiadomo maja niskie jittery na niskich czestotliwosciach - taka jest rzeczywistosc pomiarowa. Brak stalych warunkow cieplnych powoduje to ze generator ma zwiekszony jitter. Wiec i tu znowu wystepuje swego rodzaju petla czasowo temperaturowa.

 

Oczywiscie te dywagacje nie maja wlasciwie nic wspolnego z naszym omawianym tematem JPLAYera ale Slawek podal przyklad ze jesli cos wlaczymy i wylaczymy petla nie wystepuje ja tlumaczac mu mechanizm petli, podaje ze petla wlasciwie moze byc wszedzie w przyrodzie takie zjawisko tez czesto wystepuje.

Ale wracajac do sedna sprawy bo od tematu jestesmy bardzo daleko a te przyklady z petlami byly podane tylko aby uzmyslowic sobie mechanizm petli rowniez tej wolnej. I tak jesli wlaczenie i wylaczenie sprzetu raz na godzine powoduje realne i pomiarowe znieksztalcenia. To czemu nie moze byc wplywu pobrania lub odczekania na probki w czasie milisekund przez konwerter asynchroniczny??? Przeciez tam zachodza milion razy szybsze zmiany. Kazde pobranie lub zwolnienie probek bedzie powodowalo swoiste zaklocenia ktore beda zmienialy minimalnie zbocza sygnalow cyfrowych - a te wlasnie minimalne zmiany zboczy to jest wlasnie nasz klasyczny jitter.

Taka jest teoria dzialania i zaklocen odzialujaych na petle i jesli ktos z tym sie nie zgadza to nie ja pisze farmazony tylko Wy Panocki nie macie ZIELONEGO pojecia o petlach analogowych i cyfrowych ;)

 

Pozdrawiam StasioP

 

Ale moze ktos z Panockow oprocz SlawkaR ktory potrafi prowadzic normalna i rzeczowa dyskusje. Podalby logiczna teorie ktora temu zaprzeczy czy wolicie sczekac za plotu jak psy o trollach czy tez redaktorach szpilek.

 

Ze swej strony nie przeszkadza mi to czy bede trollem czy redaktorem szpilek.

Jesli ktos udowodni tzn poda konkretne art. gdzie bedzie podana teoria ze takie zaklocenia nie zachodza w uladach cyfrowych i przekona mnie ja jestem gotow oswiadczyc publicznie - mylilem sie!

 

Prosze czekam na konkrety Panocki ;)

[prezi]

Ze swej strony nie przeszkadza mi to czy bede trollem czy redaktorem szpilek.

Jesli ktos udowodni tzn poda konkretne art. gdzie bedzie podana teoria ze takie zaklocenia nie zachodza w uladach cyfrowych i przekona mnie ja jestem gotow oswiadczyc publicznie - mylilem sie!

 

Ze swojej strony podpowiem, że logika ma wielką przyszłość. Nie możesz twierdzić, że twoje twoja teoria jest prawdziwa bo nie wykazano prawdziwości tezy przeciwnej. Przykład zastosowania (cytuję za wikipedią, którą tak cenisz):

"To oczywiste, że Bóg istnieje - czy jesteś w stanie udowodnić jego nieistnienie?"

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

 

A teraz bardziej osobiście. Odpaliłem laptopa żony z windowsem. Porównywałem jplaya z foobarem stawiając obok i na wzmacniaczu kubki fajansowe z ayranem i kefirem. Okazuje, się najlepiej gra foobar jeśli postawi się ayrana obok wzmacniacza. Muszę zaznaczyć, że ustępuje mu nieco jplay grający bez ayrana i bez kefiru. Ale dużo mniej mu ustępuje jplay jeśli postawię kefir w kubku NA wzmacniaczu. Co ciekawe, jplay z ayranem w ogóle nie grają. Ważne jest to jaki to jest ayran. Najlepiej gra sprowadzany z Niemiec. Produkowany w Polsce gra znacznie gorzej.

Jest tańszy i jest go więcej ale to już nie to. Różnice są znaczne. Dlatego dalej w testach posługiwałem się ayranem z Niemiec. Jeśli chodzi o kefir to jest to kefir 0% z Piątnicy.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[migrena]

I tak jesli wlaczenie i wylaczenie sprzetu raz na godzine powoduje realne i pomiarowe znieksztalcenia. To czemu nie moze byc wplywu pobrania lub odczekania na probki w czasie milisekund przez konwerter asynchroniczny???

Nie istnieje logiczne polaczenie miedzy zjawiskiem wspomnianym w pierwszym zdaniu i zjawiskiem opisywanym w drugim zdaniu. Ekstrapolujesz wnioski wyciagniete z obserwacji jednego zjawiska na zupelnie inne calkowicie z nim niezwiazane. Robisz to zreszta niepierwszy raz gdyz wczesniej rozciagnales pojecie petli do rozmiarow pozwalajacych objac nim wlasciwie wszystko.

 

PS

U mnie gra lepiej jesli niepoodkurzam dywanu i podleje kwiatki. Kazda z tych czynnosci z osobna nic nie zmienia ale w polaczeniu zmiany sa oczywiste. Moge podac kilka nieweryfikowalnych teorii dlaczego tak jest ale akurat musze kupic worki do odkurzacza. Podejrzanie szybko mi sie zapelniaja.

[marekzawa]

jesli ktos z tym sie nie zgadza to nie ja pisze farmazony tylko Wy Panocki nie macie ZIELONEGO pojecia o petlach analogowych i cyfrowych ;)

 

Tak się zapętliłeś że już się nie rozplączesz :)

Jesteś po ezoterycznej stronie mocy i szybujesz w kierunku hermetyzmu.

[Gość SlawekR]

Pomiedzy wylaczeniem urzadzen audio przykladowo z rana a wlaczeniem wieczorem i tak wkolko rowniez wystepuje petla. To tylko wasze malo przestrzenne myslenie nie pozwala Wam tego zobaczyc. Kazdy z Was powie ze nie bedzie tego slychac w sygnale a ja powiem i owszem jezeli przykladowo bedziemy ten sprzet wlaczac i wylacz raz na godzine to warunki termiczne urzadzen audio beda sie zmieniac. I tak przykladowo wzmacniacze maja ogromna bezwladnosc cieplna regulowany tam jest prad spoczynkowy polega to na tym ze pobierana jest temperatura z radiatora i zwierany lub rozwierany jest sygnal sterujacy baz tranzsytorow, wiele wzmacniaczy w szczegolnosci tych duzych dochodzi do rownowagi po okolo 0.5h i da sie to zmierzyc a sa i tacy audiofile ze nie wylaczaja sprzetu na okroglo aby wlasnie nie dopusci do zmiany warunkow pracy. czemu to slychac? Bo nagrzewaja sie elementy ktore zazwyczaj lepiej pracuja w stalych warunkach temperaturowych.

 

Problem jest w tym, że pętle o których wspominasz, podając jako przykład i potencjalne uzasadnienie, są to bardziej pętle w rozumieniu filozoficznym, a nie praktycznym. Ich charakter jest tak powolny, że są całkowicie przeźroczyste i niewidoczne dla zjawisk szybkozmiennych. Nie mogą więc nijak stanowić drogi przenoszenia szybkozmiennych zakłóceń.

 

Przykład wzmacniacza, jest o tyle prawdziwy co i nietrafiony w naszych rozważaniach. Nikt nie neguje wpływu tego typu pętli termicznej na brzmienie wzmacniacza. Ale jest małe ale, szybkość zachodzących zjawisk termicznych we wzmacnaiczu, zjawisk które mogą zmieniać brzmienie, jest zbliżona do szybkości działania pętli. Jasnym więc jest, że tego typu pętlę można uznać na nośnik zakłóceń termicznych i że można wykazać jej wpływ na brzmienie, ale to tylko dlatego, że pętla i zakłócenie mają zbliżony zakres.

 

 

Nastepna sprawa to np przetworniki konwertery itp. one tez ulegaja petlom cieplnym bo np generatory one to lubia pracowac ze stala temperatura pracy pattrz na ten przyklad na generatory ovenowane, ovenowane generatory jak ogolnie wiadomo maja niskie jittery na niskich czestotliwosciach - taka jest rzeczywistosc pomiarowa. Brak stalych warunkow cieplnych powoduje to ze generator ma zwiekszony jitter. Wiec i tu znowu wystepuje swego rodzaju petla czasowo temperaturowa.

 

Kolejny nie trafiony przykład. Owszem, nawet jeśli przyjąć korelację pomiędzy ilością włączeń i wyłączeń, a temperaturą generatora i w konsekwencji, brzmieniem. To nijak nie da się tego odnieść do wpływu na to wszystko Jplaya, jako czynnika "zbawiennego" dla usunięcia tychże zakłóceń.

 

Oczywiscie te dywagacje nie maja wlasciwie nic wspolnego z naszym omawianym tematem JPLAYera ale Slawek podal przyklad ze jesli cos wlaczymy i wylaczymy petla nie wystepuje ja tlumaczac mu mechanizm petli, podaje ze petla wlasciwie moze byc wszedzie w przyrodzie takie zjawisko tez czesto wystepuje.

 

To jest pętla w ujęciu filozoficznym, tak samo jak to że wszystkie przedmioty podlegają sile ciążenia, więc są w pętli grawitacyjnej. Ale taki rodzaj pętli, jest tak odległy od rozważanych zjawisk zakłócających, jak możliwość zarażenia grypą, za pośrednictwem wspomnianej pętli grawitacyjnej.

 

Taka wydumana pętla, jest totalnie niewidoczna i przeźroczysta, dla zjawisk totalnie odmiennych i z nią niezwiązanych.

Tak się nie da tłumaczyć, jednego zjawiska, drugim.

 

 

Ale wracajac do sedna sprawy bo od tematu jestesmy bardzo daleko a te przyklady z petlami byly podane tylko aby uzmyslowic sobie mechanizm petli rowniez tej wolnej. I tak jesli wlaczenie i wylaczenie sprzetu raz na godzine powoduje realne i pomiarowe znieksztalcenia. To czemu nie moze byc wplywu pobrania lub odczekania na probki w czasie milisekund przez konwerter asynchroniczny???

 

Jak to czemu, a to dlatego, że jedynym istotnym generatorem zakłóceń w naszym przypadku jest sam konwerter asynchroniczny. Bo to on generuje komendę pobrania danych, tak samo jak generuje komendę odczekania. To on jest urządzeniem master, a nie system przed nim. Więc wyłączenie tegoż systemu przed nim, nie będzie mieć wpływu na ten charakter zakłóceń. No chyba, że wyłączenie będzie zbyt długie, ale wtedy nie ma mowy o zakłóceniach zmieniajacych brzmienie, a o przerwie w odtwarzaniu, czyli mam błąd gruby transmisji.

 

Do tego wszystkiego, juz kompletnie nie może być mowy o wpływie na te zakłócenia jakiejś hipotetycznej aplikacji, gdyż nie działa ona w domenie konwertera, a w domenie systemu przed nim. Dla konwertera jest totalnie bez znaczenia aplikacja zarządzająca opcją włącz - wyłącz - przewiń, skoro nie zajmuje się ona porcjowaniem i timingowaniem danych dla konwertera. Tym zajmuje się sam konwerter master, na podstawie swojego zegara.

 

 

Przeciez tam zachodza milion razy szybsze zmiany. Kazde pobranie lub zwolnienie probek bedzie powodowalo swoiste zaklocenia ktore beda zmienialy minimalnie zbocza sygnalow cyfrowych - a te wlasnie minimalne zmiany zboczy to jest wlasnie nasz klasyczny jitter.

 

 

Oczywiście że tak. Masz rację, tyle że te zakłócenia wytwarzać będzie urządzenie zarządzające pobraniem i zwolnieniem próbek, czyli? Konwerter..... i to od jego jakości, jego zegara, zasilania itd. wszystko zależy. komputer nie ma tu nic do gadania, a tym bardziej jakiś programik na nim.

 

Taka jest teoria dzialania i zaklocen odzialujaych na petle i jesli ktos z tym sie nie zgadza to nie ja pisze farmazony tylko Wy Panocki nie macie ZIELONEGO pojecia o petlach analogowych i cyfrowych ;)

 

Pozdrawiam StasioP

 

Taka jest teoria, na temat czegoś co nie ma nic wspólnego z naszym przypadkiem. Tak samo teoria wielkiego wybuchu, nie ma wpływu na jakość mleka krowiego. I to pomimo, że krowa żyje na Ziemi, Ziemia jest we wszechświecie, a wszechświat powstał w wielkim wybuchu. Chociaż to ostatnie nie zostało wcale do końca udowodnione :).

 

 

Ale moze ktos z Panockow oprocz SlawkaR ktory potrafi prowadzic normalna i rzeczowa dyskusje. Podalby logiczna teorie ktora temu zaprzeczy czy wolicie sczekac za plotu jak psy o trollach czy tez redaktorach szpilek.

 

Ze swej strony nie przeszkadza mi to czy bede trollem czy redaktorem szpilek.

Jesli ktos udowodni tzn poda konkretne art. gdzie bedzie podana teoria ze takie zaklocenia nie zachodza w uladach cyfrowych i przekona mnie ja jestem gotow oswiadczyc publicznie - mylilem sie!

 

Prosze czekam na konkrety Panocki ;)

 

Ale coś się tak czepił tych pętli i jittera. Ciągle epatujesz wszystkich linkami do różnych z tym związanych opracowań. Tyle, że aby to miało sens, trzeba najpierw udowodnić związek przyczynowo skutkowy pomiędzy pętlami, jitterami i Jplayem, a dokładnie jego wpływem na te zjawiska, niezależnie czy realne, czy wydumane.

Poza tym, domagasz się konkretów? Dobrze, pogadajmy o konkretach dotyczących Jplaya.

 

Dlaczego producent nie dołącza do licencji, umowy licencyjnej EULA? Z powodu jittera?

Dlaczego program wykrzacza system tak wielu użytkownikom?

I ostatnie, dość istotne, dlaczego 3MB kawałek kodu, o funkcjonalności wołającej o pomstę do nieba, kosztuje tyle co kosztuje? Tylko dlatego, że został audiofilsko namaszczony przez sprzęt towarzyszący?

 

Pogadajmy o konkretach….. Sam okrzyk: "jedna pętla, jeden jitter, jeden Jplay, bo to słychać" nie wystarczy, wybacz, ale to za mało.