Różnice w brzmieniu playerów pomimo transmisji bitperfect

[przemak]

Program to deltawav, sporo umie. Również inne ciekawe rzeczy tu:

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

[jar1]

57 minut temu, przemak napisał:

Tak być powinno i na przykład u mnie w zakresie tego tematu jest i działa. Więc tak jak pisałem - IMO to nie jest tak, że te playery z definicji różnie brzmią, tylko raczej w różnych warunkach sprzętowo-programowych wychodzą różne kwiatki. Podobnie jak z kablami - nie słychać, ale jak ktoś chce, żeby było słychać, to tak zaprojektuje urządzenie, żeby było "wrażliwe". 

To zupełnie inny temat i nie dotyczy bitpefect.  Niestety cyfra się kończy i zaczyna analog a ten jest znacznie bardziej czuły na to, co właśnie cyfra miała w dużym stopniu niwelować. Tym bardziej, że sama cyfra jest już zakłóceniem dla analogu.  A to się wszystko ze sobą łączy... kablami.

 

Edytowane 18 Października 2024 przez jar1

[Arkadix]

W dniu 16.10.2024 o 21:08, msankowski napisał:

Porównywane wersje:

v2.24 preview 2024-10-11 [64-bit], ASIO Output 2.2.3

v1.6.18 [x32-bit], ASIO Output 2.2.3

Windows 11 24H2

Karta dźwiękowa Lynx AES-16e (natywny i najnowszy driver) -> AES/EBU -> RME ADI-2 Pro -> Focal Solo 6be

Ten test jest ciekawy , bo nie występuje transmisja po USB. U  mnie zawsze sygnał przechodził przez transmisję USB. Inne różnice w stosunku do mojego testu to W11 ( u mnie W10 ) i najnowsza wersja Foobara2000 ( u mnie jedna z pierwszych wersji 64bit ).  Spróbuję zainstalować najnowszą wersję Foobara i porównam z wersją 32bit.   Jeśli nie będzie różnicy to oznacza bug w pierwszej wersji Foobara w wersji 64 bit . 

Arkadix  

[Misio38]

W dniu 18.10.2024 o 18:52, jar1 napisał:

Niestety cyfra się kończy i zaczyna analog

🤔

 

🤣

[soundchaser]

W dniu 19.09.2024 o 20:44, yayacek napisał:

Jestem skonfundowany, bo popełniłem na tym forum masę wpisów jakoby każdy odtwarzacz programowy grał tak samo. Ale teraz okazuje się, że nie miałem racji i niesłusznie wmawiałem innym, że się mylą.

Eureka! 😉

Dawno nie gościłem w tej zakładce. Odpuściłem ją sobie gdy skonfigurowałem swój system do odtwarzania plików tak, że brzmi perfekcyjnie i nie potrzebuję żadnych rad.
Pamiętam jednak Twoje wpisy, które "dowodziły", że cyfrowe playery nie mogą grać różnie jeśli zapewniony jest BP. Ja się z tym od początku nie zgadzałem, bo wyraźnie słyszałem różnice między np. Foobar, MediaMonkey czy JRiver.
Korzystam z tego ostatniego, bo jest najlepszy.

Pozdrawiam.

[Edson]

yayacek

 

Mógłbyś napisać jak odwracałeś fazę i w jakim programie porównywałeś oryginalny plik z finalnym odwróconym w fazie.

W jakim formacie były te testowo odtwarzane pliki (wave, flac)?

 

[rochu]

Mam gorzą satysfakcję czytając ten wątek.

Dobranoc.

[msankowski]

Mam gorzą satysfakcję czytając ten wątek.
Dobranoc.

Mógłbyś rozwinąć, skąd satysfakcja?

[il Dottore]

W dniu 19.09.2024 o 19:44, yayacek napisał:

Zawsze twierdziłem, że kazdy odtwarzacz programowy brzmi tak samo - teraz twierdzę inaczej. Każdy brzmi odmiennie.

Dlatego JRMC. 🙂

W dniu 12.11.2024 o 18:52, soundchaser napisał:

Korzystam z tego ostatniego, bo jest najlepszy.

To, to! 😄 

[Kirkor53]

Dla mnie za różnice w brzmieniu playerów audio odpowiada jitter. Powstaje on na styku systemu operacyjnego a interfejsu cyfrowego w DAC. Wszystkie obecne systemy operacyjne komputerów są systemami wielozadaniowymi. Opierają się one o przerwania procesorów i priorytety wątków systemu operacyjnego. Obecnie karty dźwiękowe w komputerach oraz DAC USB opierają się o przerwania tj. gdy zegar karty chce nową próbkę (np. przy próbkowaniu 44100Hz odbywa się to 44100 razy na sekundę) to wysyła sygnał żądania do procesora a system obsługuje to przerwanie za pomocą wątku, który ma priorytet wykonania ( od 1 do 31 tj. 31 jest najwyższy zawiesza wykonywanie wątków o niższym priorytecie). Priorytet 31 mają w systemach wielozadaniowych zazwyczaj wątki obsługujące najważniejsze zadnia systemu na poziomie sprzętowym. Zwykłe aplikacje uruchamiane są z priorytetem 8 do 10. Powracając do dźwięku karta dźwiękowa oraz DAC USB, gdy chce otrzymać nową próbkę z dźwiękiem (jest to paczka z pojedynczą próbką ale zawiera dane dla lewego i prawego kanału) wysyła sygnał żądania. System obsługuje to żądanie z priorytetem jaką ma uruchomiona aplikacja tzw. audio player. Gdy dane zostaną przesłane do karty lub DAC to on je natychmiast konwertuje do postaci analogowej, tak aby zdążyć przed następny okresem żądania. I tu właśnie jest problem, bo próbki mieszczą się pomiędzy tymi żądaniami, lecz ze względu na priorytety wątków (wielozadaniowość systemów operacyjnych) próbki jeśli mierzyć je od pojawienia się fizycznie w karcie lub DAC mają nierówne odstępy (mimo, że mieszczą się w ramkach czasowych) czyli powstaje jitter. Walczy się z tym w systemach operacyjnych ustawiając wysokie priorytety wątków aplikacji audio, przez co zmniejsza się jitter. Dla Windows WASAPI jest to 21 lub 24, a dla ASIO 31/26. Dlatego ASIO gra zazwyczaj lepiej niż WASAPI. Ktoś powie o czym gościu gadasz przecież są bufory. Tak, są bufory, ale one są w systemach operacyjnych lub aplikacjach i są uzależnione od priorytetów wątków. Powtarzam karta muzyczna lub DAC otrzymuje tylko 1 próbkę z danymi po żądaniu. Można to sprawdzić np. sprawdzając wątki playerów audio za pomocą np. aplikacji „Process Explorer” uruchomionego w trybie administratora. A co ma z tym wspólnego tzw. tryb „bitperfect”. Powiem tak, zasadniczo niewiele. Bitperfect oznacza, że program audio playera nie zmienia wartości oryginalnych próbek i jeśli są przesłane do karty lub DAC USB przed następnym żądaniem, to są prawidłowe i zapisują się na dysku do pliku idealnie, ale to nie oznacza, że nie ma na karcie lub DAC USB jitter-u.

Oczywiście wszystkie konwersje danych audio z liczb stałoprzecinkowych (16 lub 24 bit) na dane zmiennoprzecinkowe zwłaszcza na float 32 niesie za sobą ryzyko zmiany oryginalnych danych. Float 64, tu ryzyko jest już znikome.

Osobiście korzystam z playera OnlyWAV gdyż sprawdziłem, że w trybie WASAPI EXCLUSIVE na tzw. filtrze F3 ma najwyższy możliwy priorytet to 31. Ma on kilka dodatkowych funkcji, które mi się spodobały dźwiękowo i które działają tylko pod WASAPI. Oczywiście ASIO na filtrze F3 gra również lepiej niż inne audio playery.

[wyspa40]

Osobiście wyczuwam różnice między playerami w odsłuchu nawet tych samych plików czy strumieni w zależności od użytego playera. Na przykład taki Tidal i jego dedykowana aplikacja pod windowsa - ustawiając ją w trybie wyłączności mając zaimplementowaną kartę dźwiękową na PCI-e i  odtwarzając strumień z wybranej losowo płyty będzie brzmiał zupełnie inaczej niż ten sam strumień z tej samej płyty odtwarzany na przykład w Audirvanie - gdzie również aplikacja wymusza pełną kontrolę karty dźwiękowej omijając wszelkie miksery windowsa...

[fetek]

W dniu 2.02.2025 o 15:52, Kirkor53 napisał:

Dla mnie za różnice w brzmieniu playerów audio odpowiada jitter. Powstaje on na styku systemu operacyjnego a interfejsu cyfrowego w DAC. Wszystkie obecne systemy operacyjne komputerów są systemami wielozadaniowymi. Opierają się one o przerwania procesorów i priorytety wątków systemu operacyjnego. Obecnie karty dźwiękowe w komputerach oraz DAC USB opierają się o przerwania tj. gdy zegar karty chce nową próbkę (np. przy próbkowaniu 44100Hz odbywa się to 44100 razy na sekundę) to wysyła sygnał żądania do procesora a system obsługuje to przerwanie za pomocą wątku, który ma priorytet wykonania ( od 1 do 31 tj. 31 jest najwyższy zawiesza wykonywanie wątków o niższym priorytecie). Priorytet 31 mają w systemach wielozadaniowych zazwyczaj wątki obsługujące najważniejsze zadnia systemu na poziomie sprzętowym. Zwykłe aplikacje uruchamiane są z priorytetem 8 do 10. Powracając do dźwięku karta dźwiękowa oraz DAC USB, gdy chce otrzymać nową próbkę z dźwiękiem (jest to paczka z pojedynczą próbką ale zawiera dane dla lewego i prawego kanału) wysyła sygnał żądania. System obsługuje to żądanie z priorytetem jaką ma uruchomiona aplikacja tzw. audio player. Gdy dane zostaną przesłane do karty lub DAC to on je natychmiast konwertuje do postaci analogowej, tak aby zdążyć przed następny okresem żądania. I tu właśnie jest problem, bo próbki mieszczą się pomiędzy tymi żądaniami, lecz ze względu na priorytety wątków (wielozadaniowość systemów operacyjnych) próbki jeśli mierzyć je od pojawienia się fizycznie w karcie lub DAC mają nierówne odstępy (mimo, że mieszczą się w ramkach czasowych) czyli powstaje jitter. Walczy się z tym w systemach operacyjnych ustawiając wysokie priorytety wątków aplikacji audio, przez co zmniejsza się jitter. Dla Windows WASAPI jest to 21 lub 24, a dla ASIO 31/26. Dlatego ASIO gra zazwyczaj lepiej niż WASAPI. Ktoś powie o czym gościu gadasz przecież są bufory. Tak, są bufory, ale one są w systemach operacyjnych lub aplikacjach i są uzależnione od priorytetów wątków. Powtarzam karta muzyczna lub DAC otrzymuje tylko 1 próbkę z danymi po żądaniu. Można to sprawdzić np. sprawdzając wątki playerów audio za pomocą np. aplikacji „Process Explorer” uruchomionego w trybie administratora. A co ma z tym wspólnego tzw. tryb „bitperfect”. Powiem tak, zasadniczo niewiele. Bitperfect oznacza, że program audio playera nie zmienia wartości oryginalnych próbek i jeśli są przesłane do karty lub DAC USB przed następnym żądaniem, to są prawidłowe i zapisują się na dysku do pliku idealnie, ale to nie oznacza, że nie ma na karcie lub DAC USB jitter-u.

Mając to samo środowisko, ten sam sprzęt i drogę sygnału a tylko różne odtwarzacze w postaci oprogramowania słychać różnice. Więc jednak nie do końca jest jak piszesz.

AISO i WASAPI są pancerne jeśli chodzi o deficyty zasobów, KS potrafi rwać nawet przy niewielkim obciążeniu.

 

 

 

Edytowane 18 Lutego przez fetek

[J.Jerry]

Ja bym zmierzył thd dla każdego playera i w przypadku stwierdzenia identycznego spektrum dalej się zastanawiał....przy okazji szumy i pasmo.

Pamiętam takie ustrojstwo, co zmieniało brzmienie na plus i było bp...chyba poziom też można było i wymagało i7...teraz to by dopiero zagrało.

W dniu 2.02.2025 o 15:52, Kirkor53 napisał:

Dla mnie za różnice w brzmieniu playerów audio odpowiada jitter. Powstaje on na styku systemu operacyjnego a interfejsu cyfrowego w DAC. Wszystkie obecne systemy operacyjne komputerów są systemami wielozadaniowymi. Opierają się one o przerwania procesorów i priorytety wątków systemu operacyjnego. Obecnie karty dźwiękowe w komputerach oraz DAC USB opierają się o przerwania tj. gdy zegar karty chce nową próbkę (np. przy próbkowaniu 44100Hz odbywa się to 44100 razy na sekundę) to wysyła sygnał żądania do procesora a system obsługuje to przerwanie za pomocą wątku, który ma priorytet wykonania ( od 1 do 31 tj. 31 jest najwyższy zawiesza wykonywanie wątków o niższym priorytecie). Priorytet 31 mają w systemach wielozadaniowych zazwyczaj wątki obsługujące najważniejsze zadnia systemu na poziomie sprzętowym. Zwykłe aplikacje uruchamiane są z priorytetem 8 do 10. Powracając do dźwięku karta dźwiękowa oraz DAC USB, gdy chce otrzymać nową próbkę z dźwiękiem (jest to paczka z pojedynczą próbką ale zawiera dane dla lewego i prawego kanału) wysyła sygnał żądania. System obsługuje to żądanie z priorytetem jaką ma uruchomiona aplikacja tzw. audio player. Gdy dane zostaną przesłane do karty lub DAC to on je natychmiast konwertuje do postaci analogowej, tak aby zdążyć przed następny okresem żądania. I tu właśnie jest problem, bo próbki mieszczą się pomiędzy tymi żądaniami, lecz ze względu na priorytety wątków (wielozadaniowość systemów operacyjnych) próbki jeśli mierzyć je od pojawienia się fizycznie w karcie lub DAC mają nierówne odstępy (mimo, że mieszczą się w ramkach czasowych) czyli powstaje jitter. Walczy się z tym w systemach operacyjnych ustawiając wysokie priorytety wątków aplikacji audio, przez co zmniejsza się jitter. Dla Windows WASAPI jest to 21 lub 24, a dla ASIO 31/26. Dlatego ASIO gra zazwyczaj lepiej niż WASAPI. Ktoś powie o czym gościu gadasz przecież są bufory. Tak, są bufory, ale one są w systemach operacyjnych lub aplikacjach i są uzależnione od priorytetów wątków. Powtarzam karta muzyczna lub DAC otrzymuje tylko 1 próbkę z danymi po żądaniu. Można to sprawdzić np. sprawdzając wątki playerów audio za pomocą np. aplikacji „Process Explorer” uruchomionego w trybie administratora. A co ma z tym wspólnego tzw. tryb „bitperfect”. Powiem tak, zasadniczo niewiele. Bitperfect oznacza, że program audio playera nie zmienia wartości oryginalnych próbek i jeśli są przesłane do karty lub DAC USB przed następnym żądaniem, to są prawidłowe i zapisują się na dysku do pliku idealnie, ale to nie oznacza, że nie ma na karcie lub DAC USB jitter-u.

Oczywiście wszystkie konwersje danych audio z liczb stałoprzecinkowych (16 lub 24 bit) na dane zmiennoprzecinkowe zwłaszcza na float 32 niesie za sobą ryzyko zmiany oryginalnych danych. Float 64, tu ryzyko jest już znikome.

Osobiście korzystam z playera OnlyWAV gdyż sprawdziłem, że w trybie WASAPI EXCLUSIVE na tzw. filtrze F3 ma najwyższy możliwy priorytet to 31. Ma on kilka dodatkowych funkcji, które mi się spodobały dźwiękowo i które działają tylko pod WASAPI. Oczywiście ASIO na filtrze F3 gra również lepiej niż inne audio playery.

Tak może być, skoro priorytety są i można je zmieniać w win lub playerach...no i bufor dla asio trzeba wybrać ręcznie jakby komp nie był świadom co się dzieje.

Bp chyba jest obecnie niskim priorytetem, bo chcemy mieć dużą dokładność przy regulacji poziomu, eq, interpolatora....

Kupujcie zatem daki zgodne z asio

[GT]

W dniu 19.09.2024 o 20:44, yayacek napisał:

Od zawsze byłem twierdzenia, że playery softwarowe brzmią tak samo o ile zachowana jest transmisja bitperfect.
Moje niepokoje zaczęły się w momencie kiedy został wypuszczony Foobar 2.0/64bit - od razu poczułem, że coś jest nie tak jak było. Po uaktualnieniu do v2.0 wszystko zaczęło grac inaczej niż przedtem.
Sprawdzałem naście razy czy przesył bitperfect jest zachowany i oczywiście wszystko było OK -> vide

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) .
Bitpefect w Foobar 2.0 jest możliwy do uzyskania pod warunkiem odhaczenia kilku opcji. Oczywiście protokół ASIO jest zaprzęgnięty, więc wszelkie testy odbywały się za pośrednictwem ASIO.
Wpierw wmawiałem sobie, że to sugestia, potem szukałem innych rozwiązań typu różne wtyczki foobarowe do ASIO. 
Potem ściągnąłem inne playery - AIMP oraz MusicBee. Każdy gra inaczej pomimo bitperfect.
AIMP jest bitperfect o ile ustawi się w nim próbkowanie na sztywno czyli mamy plik 44.1kHz i musimy w AIMP ustawić w opcjach odtwarzania 44.1kHz. Kiedy potem włączymy plik np 96kHz to musimy przełączyć w AIMP próbkowanie na 96kHz - upierdliwe. Wynika to z faktu, że w AIMP jest zaaplikowany na stałe resampler, który nie jest aktywny tylko wówczas kiedy próbkowanie odtwarzanego pliku = próbkowanie ustawione w opcjach odtwarzania AIMPa
MusicBee zachowuje się poprawnie, ASIO działa w nim stabilnie i tak jak wyżej wspomniałem bitperfect jest pełną gębą.
Ale pomimo bitperfect pod ASIO każdy z tych odtwarzaczy brzmi kompletnie odmiennie. Foobar, AIMP, MusicBee, Foobar v1.6, Foobar v2.0/64bit - każdy brzmi inaczej, żaden z nich nie brzmi tak samo. Pięć odtwarzaczy i pięć różnych brzmień! Pokopałem w necie i okazuje się, że AIMP oraz MusicBee oparte są na bass audio library czyli na zupełnie innych fundamentach niż Foobar. Ponoć Winamp też był zbudowany w oparciu o bass library ale nie jestem pewien.
Aby wykluczyć omamy słuchowe przełączyłem się na zintegrowaną kartę dźwiękową - tu musiałem pod każdym programem posiłkować się ASIO4All. Karta zintegrowana a na niej wyjście cyfrowe (optyk) to najkrótsza droga by wypuścić audio z kompa. Windows zapewnia doskonałą integrację bo to jest część protokołu High Definition Audio i Windows sam zapewnia sterowniki do obsługi tej ścieżki.
Dalej to samo, każdy odtwarzacz brzmiał inaczej, pomimo (powtarzam ponownie) wielokrotnie sprawdzanej poprawności na transmisję bitperfect.
Mam w szafie stado przetworników D/A, więc pomyślałem, że ten którego używam (bo lubię najbardziej ze względu na brzmienie) obecnie jest za stary albo uszkodzony albo cholera wie co. Wpiąłem inny, potem jeszcze inny a potem wielki amplituner KD by SONY. Nic z tego, za każdym razem różnica pomiędzy odtwarzaczami była słyszalna.
Poddałem się i skupiłem się jedynie na Foobarze 1.6 vs 2.0/64bit - innych playerów i tak nie zamierzam używać (kwesta przyzwyczajenia). Cokolwiek bym nie zrobił i jakiegokolwiek DACa bym nie podpiął to zawsze jestem w stanie bezproblemowo wyłapać różnicę w brzmieniu. To nie jest jakiś niuans, to jest spora różnica w dynamice i tonalności.
Nie jestem w stanie sobie tego wytłumaczyć. Test na bitperfect przechodzą wzorowo, przechwycenie sygnału po cyfrze i potem sumowanie w przeciwfazie daje idealną ciszę cyfrową - czyli według fizyki/matematyki różnic nie ma. A jednak brzmi odmiennie.
Foobar 1.6 otwiera każdy plik w 32bit float a potem pcha go do małego programiku zwanego ASIO HOST (32 bit), z którym komunikuje się cyfrowe wyjście karty dźwiękowej.
W przypadku Foobar 2.0/64bit każdy plik otwierany jest w postaci 64 bit (float czy integer - nie mam pojęcia) a potem jest pchany do ASIO HOST (64 bit) a potem musi to zostać dostosowane do cyfrowego wyjścia karty dźwiękowej. A te zawsze pracuje pod ASIO w opcji 32 bit integer. Więc w przypadku Foobar 2.0/64 bit być może projektant coś namieszał i te konwersje pomiędzy 64 a 32 bit mu nie wyszły - choć zdaję sobie sprawę, że jest to dość głupie wyjaśnienie problemu.
Zasadniczo Foobar 2.0 to zupełnie inny odtwarzacz niż 1.6. Został niemal całkowicie przeprojektowany, dodano dodatkowe kodery, wywalono Direct Sound, wbudowano na stałe WASAPI, zaaplikowano dekodowanie odtwarzania wielokanałowego, zastosowano dodatkowy bufor dla WASAPI, dodano integrację z volume pod Windowsem - czyli takie bloatware, ale właściwie nie powinno mieć to wpływu na odtwarzanie.

Na forum Foobara ciężko się porozumieć. Twórca softu jest bardzo buńczuczny i wszelkie posty tyczące różnicy w brzmieniu są kasowane - sam miałem dwa takie przypadki. Odpowiedź jest zawsze taka sama - różnic nie ma. Gdzieś tam można znaleźć jakieś wpisy ale są one wyśmiane jako urojenia.
Ale aby było ciekawiej - mam cztery odtwarzacze CD marki SONY + jeden DVD też SONY. Nie jestem w stanie pomimo wielkiego wysiłku usznego wychwycić jakiejkolwiek różnicy pomiędzy nimi - oczywiście mowa o komunikacji odtwarzacz -> DAC. Wszystko zawsze łączę toslinkiem.

Zawsze twierdziłem, że kazdy odtwarzacz programowy brzmi tak samo - teraz twierdzę inaczej. Każdy brzmi odmiennie. Mimo bitperfect łatwo daje się wychwycić różnicę i Foobar v2.0 zupełnie nie brzmi dobrze. To jest zły dźwięk, kompletnie różny od dźwięku odtwarzacza CD Sony i kompletnie różny od Foobara 1.6. Nie jestem w stanie słuchać v2.0 bo mnie męczy i brzmi po prostu źle.

Oczywiście jestem w stanie zamieścić przechwycone sample z Foobara 1.6 i Foobara 2.0 ale myślę, że to trochę bez sensu. Przechwyt będzie obarczony podwójną konwersją D/A/D bo cyfra z karty -> DAC -> wyjście analogowe z DAC -> wejście analogowe do karty -> konwersja w karcie z analog na cyfrę. Różnica do wychwycenia będzie albo nie.
Jak ktoś chce sie pobawić to zalecam obok Foobara 2.0/64 bit postawić Foobara 1.6 (do ściągnięcia z oficjalnej strony) i sprawdzić samemu - nie pogryzą się.

Jestem skonfundowany, bo popełniłem na tym forum masę wpisów jakoby każdy odtwarzacz programowy grał tak samo. Ale teraz okazuje się, że nie miałem racji i niesłusznie wmawiałem innym, że się mylą. Z matematycznego punktu widzenia one grają tak samo - bit do bita identycznie. Ale kiedy te bity wchodzą na zewnętrzny przetwornik to dzieje się coś dziwnego i w zależności od programu odtwarzającego przetwornik gra zgoła odmiennie. Nie potrafię wyjaśnić tego zjawiska.
 

Przyczyn moze byc wiele pewnie, ale ta bardziej prawdopodobna (i juz wymieniona w tym watku) to glownie jitter. Sygnal bit perfect znaczy tylko tyle ze dane nie sa zmieniane, ale nie oznacza to, ze nie sa obarczone jitterem. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[J.Jerry]

Dac ma własne taktowanie,  player działa na innym oprogramowaniu i sprzęcie, a potem parę rzeczy po drodze i w końcu kabel do dac, dlatego dac ma swoje zegary.

[yayacek]

W dniu 1.04.2025 o 21:17, GT napisał:

to glownie jitter

To bardzo proste wytłumaczenie ale zarazem nie chce mi się w nie wierzyć.
Ten jitter musiałby powstawać w domenie software'owej. Jak więc niby miałby się tworzyć jitter w domenie programowej? Jak program odtwarzający X miałby mieć inny jitter od programu odtwarzającego Y?
Bo powtarzam po raz enty - nic się nie zmienia w konfiguracji. Nic, absolutnie NIC. Zmienia się tylko odtwarzacz - wpierw gra odtwarzacz X a potem gra odtwarzacz Y.

Osobiście twierdzę, że to nie jitter bo to bez sensu jest.
Bardziej do mnie przemawia sposób przetwarzania pliku przez dany program. Bo plik można otworzyć w 32 bit float, 32 bit, w 64 czy w 64 float. Każdy player otwiera (nie mylić z odtwarza) plik a potem podaje go na tzw. pipeline by na samym końcu wypluć plik na wyjście fizyczne w formacie zgodnym z formatem źródłowym.
Czyli przykładowo mamy plik 16 bit/44.1 kHz. Odtwarzacz otwiera ten plik w postaci 64bit float/44.1 kHz, plik przechodzi przez wewnętrzną architekturę programu by na końcu upchać ten plik do formatu zgodnego dla danego protokołu - w przypadku ASIO będzie to 16 bit w kontenerze 32 bit / 44.1 kHz.
I teraz są różne sposoby traktowania tego 64 bit float by stał się na powrót stałoprzecinkowym 16 bit. I ewidentnie coś jest na rzeczy bo foobar 32 bit który każdy plik otwiera w 32 bit float brzmi inaczej niż foobar 64 bit, który to każdy plik otwiera w 64 bit float.

Najzabawniejsze jest to, że utrzymywany jest bit perfect. Powyższe operacje nie wpływają na zgodność bitową. Pliki są idealnie identyczne niezależnie od tego jakim programem są odtwarzane. Przechwycenie sygnału po cyfrze i tzw. sumowanie w przeciwfazie daje idealną ciszę cyfrową = pliki identyczne.

Różnica objawia się nausznie kiedy sygnał przejdzie przez DAC. Dopiero na wyjściu analogowym DACa słychać i można łatwo zmierzyć róźnicę. Dopóki pozostajemy w domenie cyfrowej zmian nie ma - pomiar wykazuje zawsze ciszę cyfrową.

Czas temu widziałem na gearslutz dość długą kilkustronicową dyskusję na temat brzmień DAWów. Wszystkie sumują się po cyfrze do zera - i nie ma w tym nic dziwnego. Tak samo jest przecież w przypadku odtwarzaczy plikowych. Dodatkowo zgranie w jednym DAW sumuje się do zera ze zgraniem z innego DAW czyli różnic najmniejszych brak.
Jednakże zauważono tam, że różnice brzmieniowe występują tak samo jak w naszym przypadku dopiero wtedy kiedy sygnał przejdzie do domeny analogowej - czyli po DACu. Bardzo wiele zdań i kilka stron dyskusji zajęło zanim uczestniczący w dyskusji zrozumieli, że chodzi o różnicę w brzmieniu po DACu, bo przecież jak przechwytują i sumują sygnał to wychodzi cisza cyfrowa.
Chyba właśnie tam (albo gdzieś indziej bo jakoś linka do gearslutz znaleźć nie mogę) też padła teza o sposobie w jakim program traktuje dane - czy silnik jest 32 bit float czy 64 bit float czy jest stosowane ucinanie czy zaokrąglanie bitów podczas przejścia z float do 16 czy 24 bit.

Zasadniczo nie jestem w stanie rozwiązać problemu. Zakładam, że problem jest nierozwiązywalny. Musiałby chyba zajrzeć do kodów źródłowych jakiś łebski człek, ale to i tak nie jest możliwe z racji, że te programy są zamkniete.
Różnice brzmieniowe między odtwarzaczami programowymi istnieją - boli mnie ten fakt ale już się z nim pogodziłem. I cholera wie co jest tego przyczyną, ale stawiam że nie jitter bo ciągle nie jestem sobie w stanie wyobrazić jak ów jitter miałby się narodzić w silniku odtwarzacza.

W dniu 2.04.2025 o 11:23, J.Jerry napisał:

a potem parę rzeczy po drodze i w końcu kabel do dac

To zupełnie nie ma nic wspólnego z tematem.
I proszę nie popełniać wpisów o kablach czy o różnych DACach.

Edytowane 3 Kwietnia przez yayacek

[J.Jerry]

Pomiary zrobić na wyjściu dac, żeby sprawdzić czy idzie to samo z playerów, na czym polega różnica. A może były już pomiary analogu?

[GT]

Godzinę temu, yayacek napisał:

To bardzo proste wytłumaczenie ale zarazem nie chce mi się w nie wierzyć.
Ten jitter musiałby powstawać w domenie software'owej. Jak więc niby miałby się tworzyć jitter w domenie programowej? Jak program odtwarzający X miałby mieć inny jitter od programu odtwarzającego Y?
Bo powtarzam po raz enty - nic się nie zmienia w konfiguracji. Nic, absolutnie NIC. Zmienia się tylko odtwarzacz - wpierw gra odtwarzacz X a potem gra odtwarzacz Y.

Osobiście twierdzę, że to nie jitter bo to bez sensu jest.
Bardziej do mnie przemawia sposób przetwarzania pliku przez dany program. Bo plik można otworzyć w 32 bit float, 32 bit, w 64 czy w 64 float. Każdy player otwiera (nie mylić z odtwarza) plik a potem podaje go na tzw. pipeline by na samym końcu wypluć plik na wyjście fizyczne w formacie zgodnym z formatem źródłowym.
Czyli przykładowo mamy plik 16 bit/44.1 kHz. Odtwarzacz otwiera ten plik w postaci 64bit float/44.1 kHz, plik przechodzi przez wewnętrzną architekturę programu by na końcu upchać ten plik do formatu zgodnego dla danego protokołu - w przypadku ASIO będzie to 16 bit w kontenerze 32 bit / 44.1 kHz.
I teraz są różne sposoby traktowania tego 64 bit float by stał się na powrót stałoprzecinkowym 16 bit. I ewidentnie coś jest na rzeczy bo foobar 32 bit który każdy plik otwiera w 32 bit float brzmi inaczej niż foobar 64 bit, który to każdy plik otwiera w 64 bit float.

Najzabawniejsze jest to, że utrzymywany jest bit perfect. Powyższe operacje nie wpływają na zgodność bitową. Pliki są idealnie identyczne niezależnie od tego jakim programem są odtwarzane. Przechwycenie sygnału po cyfrze i tzw. sumowanie w przeciwfazie daje idealną ciszę cyfrową = pliki identyczne.

Różnica objawia się nausznie kiedy sygnał przejdzie przez DAC. Dopiero na wyjściu analogowym DACa słychać i można łatwo zmierzyć róźnicę. Dopóki pozostajemy w domenie cyfrowej zmian nie ma - pomiar wykazuje zawsze ciszę cyfrową.

Czas temu widziałem na gearslutz dość długą kilkustronicową dyskusję na temat brzmień DAWów. Wszystkie sumują się po cyfrze do zera - i nie ma w tym nic dziwnego. Tak samo jest przecież w przypadku odtwarzaczy plikowych. Dodatkowo zgranie w jednym DAW sumuje się do zera ze zgraniem z innego DAW czyli różnic najmniejszych brak.
Jednakże zauważono tam, że różnice brzmieniowe występują tak samo jak w naszym przypadku dopiero wtedy kiedy sygnał przejdzie do domeny analogowej - czyli po DACu. Bardzo wiele zdań i kilka stron dyskusji zajęło zanim uczestniczący w dyskusji zrozumieli, że chodzi o różnicę w brzmieniu po DACu, bo przecież jak przechwytują i sumują sygnał to wychodzi cisza cyfrowa.
Chyba właśnie tam (albo gdzieś indziej bo jakoś linka do gearslutz znaleźć nie mogę) też padła teza o sposobie w jakim program traktuje dane - czy silnik jest 32 bit float czy 64 bit float czy jest stosowane ucinanie czy zaokrąglanie bitów podczas przejścia z float do 16 czy 24 bit.

Zasadniczo nie jestem w stanie rozwiązać problemu. Zakładam, że problem jest nierozwiązywalny. Musiałby chyba zajrzeć do kodów źródłowych jakiś łebski człek, ale to i tak nie jest możliwe z racji, że te programy są zamkniete.
Różnice brzmieniowe między odtwarzaczami programowymi istnieją - boli mnie ten fakt ale już się z nim pogodziłem. I cholera wie co jest tego przyczyną, ale stawiam że nie jitter bo ciągle nie jestem sobie w stanie wyobrazić jak ów jitter miałby się narodzić w silniku odtwarzacza.

To zupełnie nie ma nic wspólnego z tematem.
I proszę nie popełniać wpisów o kablach czy o różnych DACach.

Czy te playery korzystają z tego samego priorytetu systemowego? 

[yayacek]

3 godziny temu, GT napisał:

Czy te playery korzystają z tego samego priorytetu systemowego? 

Gdyby to było takie proste i zależało od priorytetu systemowego. Programy mają inne priorytety, można je przestawiać ale to nic nie zmienia.
Ważniejszy jest poprawnie zaaplikowany priorytet protokołu dla sterowników ASIO.
ASIO wymaga by priorytet był najwyższego rzędu czyli 26, co każdy testowany player grając po ASIO spełnia jak widać na przykładowym obrazku.

Foobar 64 bitowy i protokół ASIO
 

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

[miksti]

Pozwole sobie dorzucic kilka spostrzezen. Przede wszystkim - roznice miedzy playerami istnieja i nie sa urojeniami ani bledem w pomiarze. Ich przyczyna lezy IMO nie w zmodyfikowanych danych (najczesciej ;)) tylko w roznicach w architekturze przetwarzania (float32 vs 64), algorytmach konwersji na wyjsciu, sposobie przekazywania danych do ASIO/WASAPI i, w szczegolnych przypadkach, w jitterze zaleznym od pracy playera/os z DAC. To wszystko wplywa nie na 'bit' ale na timing i analogowy efekt koncowy. Jezeli komus zalezy na obiektywnej weryfikacji sugeruje pomiar THD+N i widma szumu na wyjsciu DAC'a z roznych playerow przy tym samym sygnale wejsciowym.

W dniu 3.04.2025 o 15:20, yayacek napisał:

I ewidentnie coś jest na rzeczy bo foobar 32 bit który każdy plik otwiera w 32 bit float brzmi inaczej niż foobar 64 bit, który to każdy plik otwiera w 64 bit float.

Najzabawniejsze jest to, że utrzymywany jest bit perfect. Powyższe operacje nie wpływają na zgodność bitową. Pliki są idealnie identyczne niezależnie od tego jakim programem są odtwarzane. Przechwycenie sygnału po cyfrze i tzw. sumowanie w przeciwfazie daje idealną ciszę cyfrową = pliki identyczne.

Różnica objawia się nausznie kiedy sygnał przejdzie przez DAC. Dopiero na wyjściu analogowym DACa słychać i można łatwo zmierzyć róźnicę. Dopóki pozostajemy w domenie cyfrowej zmian nie ma - pomiar wykazuje zawsze ciszę cyfrową.

Mysle ze to swietna obserwacja i wlasciwie sedno zjawiska. Bitperfect nie oznacza identycznych sciezek przetwarzania wewnatrz odtwarzacza tylko zgodnosc na wyjsciu. Pomiedzy otwarciem pliku a wyslaniem danych do drivera ASIO/WASAPI moze zachodzic szereg konwersji, kazda niosaca potencjalnie mikroskopijne przesuniecia (dithering, rounding, nawet typ filtra cyfrowego uzytego w downcastingu float -> int). Te roznice sa niemierzalne cyfrowo a moga miec wplyw na zegar wewnetrzny DACa jezeli pracuje w trybie asynchronicznym opierajac sie czesciowo na timingach USB/SPDIF. Dosc istotne moze byc tez to, ze 64bit float jest precyzyjniejsze ale bardziej niestabilne przy konwersji na staloprzecinkowe 16/24bit (oczywiscie zaleznie od algorytmu). Rozne playery moga to robic na rozne sposoby i to moze dawac roznice na wyjsciu analogowym mimo zgodnosci cyfrowej.

Istotny jest tez sam sposob implementacji ASIO, niektore playery realizuja to natywnie (np Roon albo Audirvana) a np w Foobarze przez zewnetrzny komponent, gdzie wtyczka foo_out_asio ma swoje ograniczenia. Moga byc spore roznice w dzialniu przy kolejkowaniu danych (pre buffer), rozmiarze i cyklicznosci bufora i trybie operacji (event based vs time based callbacki). 
 

W dniu 2.02.2025 o 15:52, Kirkor53 napisał:

Dla mnie za różnice w brzmieniu playerów audio odpowiada jitter. Powstaje on na styku systemu operacyjnego a interfejsu cyfrowego w DAC. Wszystkie obecne systemy operacyjne komputerów są systemami wielozadaniowymi. Opierają się one o przerwania procesorów i priorytety wątków systemu operacyjnego. Obecnie karty dźwiękowe w komputerach oraz DAC USB opierają się o przerwania tj. gdy zegar karty chce nową próbkę (np. przy próbkowaniu 44100Hz odbywa się to 44100 razy na sekundę) to wysyła sygnał żądania do procesora a system obsługuje to przerwanie za pomocą wątku, który ma priorytet wykonania ( od 1 do 31 tj. 31 jest najwyższy zawiesza wykonywanie wątków o niższym priorytecie). Priorytet 31 mają w systemach wielozadaniowych zazwyczaj wątki obsługujące najważniejsze zadnia systemu na poziomie sprzętowym. Zwykłe aplikacje uruchamiane są z priorytetem 8 do 10. Powracając do dźwięku karta dźwiękowa oraz DAC USB, gdy chce otrzymać nową próbkę z dźwiękiem (jest to paczka z pojedynczą próbką ale zawiera dane dla lewego i prawego kanału) wysyła sygnał żądania. System obsługuje to żądanie z priorytetem jaką ma uruchomiona aplikacja tzw. audio player. Gdy dane zostaną przesłane do karty lub DAC to on je natychmiast konwertuje do postaci analogowej, tak aby zdążyć przed następny okresem żądania. I tu właśnie jest problem, bo próbki mieszczą się pomiędzy tymi żądaniami, lecz ze względu na priorytety wątków (wielozadaniowość systemów operacyjnych) próbki jeśli mierzyć je od pojawienia się fizycznie w karcie lub DAC mają nierówne odstępy (mimo, że mieszczą się w ramkach czasowych) czyli powstaje jitter. Walczy się z tym w systemach operacyjnych ustawiając wysokie priorytety wątków aplikacji audio, przez co zmniejsza się jitter. Dla Windows WASAPI jest to 21 lub 24, a dla ASIO 31/26. Dlatego ASIO gra zazwyczaj lepiej niż WASAPI. Ktoś powie o czym gościu gadasz przecież są bufory. Tak, są bufory, ale one są w systemach operacyjnych lub aplikacjach i są uzależnione od priorytetów wątków. Powtarzam karta muzyczna lub DAC otrzymuje tylko 1 próbkę z danymi po żądaniu. Można to sprawdzić np. sprawdzając wątki playerów audio za pomocą np. aplikacji „Process Explorer” uruchomionego w trybie administratora. A co ma z tym wspólnego tzw. tryb „bitperfect”. Powiem tak, zasadniczo niewiele. Bitperfect oznacza, że program audio playera nie zmienia wartości oryginalnych próbek i jeśli są przesłane do karty lub DAC USB przed następnym żądaniem, to są prawidłowe i zapisują się na dysku do pliku idealnie, ale to nie oznacza, że nie ma na karcie lub DAC USB jitter-u.

Oczywiście wszystkie konwersje danych audio z liczb stałoprzecinkowych (16 lub 24 bit) na dane zmiennoprzecinkowe zwłaszcza na float 32 niesie za sobą ryzyko zmiany oryginalnych danych. Float 64, tu ryzyko jest już znikome.

Osobiście korzystam z playera OnlyWAV gdyż sprawdziłem, że w trybie WASAPI EXCLUSIVE na tzw. filtrze F3 ma najwyższy możliwy priorytet to 31. Ma on kilka dodatkowych funkcji, które mi się spodobały dźwiękowo i które działają tylko pod WASAPI. Oczywiście ASIO na filtrze F3 gra również lepiej niż inne audio playery.

W kontekscie 'jitter powstaje na styku system operacyjny - dac. I zwiazku z wielozadaniowoscia os i priorytetami watkow'.

Warto rozdzielic dwie rzeczy - jitter na poziomie systemu (timing probek do DAC) i na poziomie fizycznego interfejsu (USB/SPDIF/I2S). Wiekszosc nowoczesnych DAC'ow z asynchronicznym USB (xmos, Amanero, Thesycon itd) eliminuje jitter systemowy bo to DAC generuje zegar, ALE jezeli dac pracuje w trybie synchronizacji z transportem (np spdif) to rzeczywiscie to jak player/os buforuje i nadaje sygnal moze miec wplyw na zegar przy odbiorze. Do tego nie wszystkie DAC'i z USB sa naprawde asynchroniczne. Czesc tanszych konstrukcji (w drozszych tez sie zdarza przez fikolki firmware/softu) korzysta z adaptive albo wrecz trybu synchro z hostem i tu jitter playera/os moze byc slyszalny.

W dniu 3.04.2025 o 20:27, yayacek napisał:

Gdyby to było takie proste i zależało od priorytetu systemowego. Programy mają inne priorytety, można je przestawiać ale to nic nie zmienia.
Ważniejszy jest poprawnie zaaplikowany priorytet protokołu dla sterowników ASIO.
ASIO wymaga by priorytet był najwyższego rzędu czyli 26, co każdy testowany player grając po ASIO spełnia jak widać na przykładowym obrazku.

Foobar 64 bitowy i protokół ASIO
 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Cenna obserwacja. To ze sam sterownik pracuje na najwyzszym mozliwym priorytecie powinno zapewnic stabilnosc i precyzyjne przekazywanie probek, ale nie zamyka sprawy. Istotne jest tez to co sie dzieje wczesniej w samym odtwarzaczu zanim dane trafia do ASIOhosta. Priorytet Foobar'a (czy dowolnego playera w innym przpyadku) nie zawsze jest taki sam jak hosta ASIO. Jezeli sam odtwarzacz ma np. Normal a wystapi jakies obciazenie w systemie to moze dochodzic do mikroopoznien w dostarczaniu danych do hosta. Druga sprawa, o ktorej bylo na poprzednich stronach - kazdy odtwarzacz ma inna architekture przetwarzania danych. Case Foobar 64 vs 32 bit, AIMP i Musicbee ktore korzystaja z BASS Library z wlasnymi buforami, resamplingiem i przetwarzaniem (zazwyczaj) niezaleznie od ustawien systemowych. Nawet jesli dane na wyjsciu sa identyczne sposob w jaki dochodzi do ich przygotowania (buforowanie, konwersja float->int) moze wplywac na timing. I/O priority i Ideal processor tez moga miec wplyw, jezeli player jest przypisany do 'zajetego' rdzenia lub ma domyslne normal I/O priority to tez wplynie na precyzje dzialania real time. + to co zauwazyles, roznice wychodza dopiero na wyjsciu analogowym daca gdzie wlasnie ma znaczenie stabilnoisc zegara, timing danych i ewentualne opoznienia w ich przesyle.
Sprawdzilbym jeszcze ile CPU zuzywa kazdy player podczas odtwarzania tego samego pliku, z jakim priorytetem dzialaja same procesy odtwarzaczy i czy player korzysta z wlasnych buforow niezaleznych od ASIO. Mozna tez przypisac inny 'ideal processor' testowo albo zablokowac affinity tylko do czystych rdzeni audio (najlepiej fizyczne, nie watki hyperthreading), powiedzmy, ze foobar'a i ASIOhost64 np do rdzeniu 4 i 5 a reszta systemu na pozostalych rdzeniach. 

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 9 Kwietnia przez miksti

[Genezyp]

@miksti

Wiele Twoich informacji i wskazówek zawartych jest w działaniu Fidelizera czy Hq Playera, używam obu z bardzo dobrym skutkiem😉.

 

[miksti]

Przy okazji natknalem sie na slepy test (Head-Fi sprzed 2 lat) z trzema identycznymi plikami granymi przez: Foobar 2.0, JRiver Media Center i Daphile. 70% trafnie odroznilo Daphile jako 'najbardziej analogowe i pelne'. Za tym poszla dokladna analiza i wyszlo na jaw, ze Daphile mial najkrotszy stos warstw (brak GUI, optymalizowany kernel) i dedykowane watki realtime dla transmisji USB.
2 ciekawa rzecz - na Gearspace niektore DAC'i z analiza bledow (RME ADI-2/Weiss DAC502 - raportuja bledy ramek, jitter i nawet wplyw bufora ASIO) pokazuja roznice w identycznym sygnale SPDIF zaleznie od playera i dlugosci kabla Toslink.

Edytowane 12 Kwietnia przez miksti

[J.Jerry]

@miksti

Te ostatnie mogą być efektem zbyt małego bufora i jakiegoś pomysłu na maskownice trzasków. Z jakichś powodów bufor asio trzeba ręcznie ustawiać jakby specjalnie...pewnie żeby znać dokładnie aktualne opóźnienie.

[przmor]

70% to nadal zgadywanie.

[miksti]

4 godziny temu, J.Jerry napisał:

Te ostatnie mogą być efektem zbyt małego bufora i jakiegoś pomysłu na maskownice trzasków. Z jakichś powodów bufor asio trzeba ręcznie ustawiać jakby specjalnie...pewnie żeby znać dokładnie aktualne opóźnienie.

Imo trafne spotrzezenie z buforem. Przyklad Daphile byl ciekawy, bo sytuacja byla troche inna - system dzialal na bardzo uproszczonym jadrze z realtime patchem i mial dedykowane watki dla transmisji USB audio. Dzieki temu pipeline byl ekstremalnie waski z minimalna preemptive schedule'acją. Zakladam, ze im bardziej calosc zoptymalizowana pod single purpose audio tym mniejszy bedzie wplyw bufora.
Weiss i RME pokazujace bledy ramek przy zmiennym buforze i dlugosci kabla toslink to imo jest juz konkret ktory mozna powtorzyc.
 

4 godziny temu, przmor napisał:

70% to nadal zgadywanie.

Masz racje, statystycznie to nadal moze podpadac pod educated guess. Warto dodac ze to byla slepa proba a nie ABX, bardziej w stylu 'co brzmi najbardziej analogowo i pelnie'. Ciekawsze bylo to, ze wynik byl spojny a nie losowy i wskazanie pokrywalo sie z obiektywnymi roznicami architektury playback engine (doslownie kilka wartw miedzy plikiem a interfejsem USB w przypadku Dahpile).

 

Edytowane 12 Kwietnia przez miksti

[miksti]

Nie zdazylem z Editem...

Jeszcze odnosnie ASIO (sporo osob w temacie moze sobie zdawac z tego sprawe, ale ktos moze nie). Malo kto wspomina, ze bufor ASIO jest podwojny albo nawet potrojny = dane nie leca bezposrednio 'na zywo' z aplikacji do DAC'a tylko przechodza przez tzw circular buffer. ASIO host prosi o zapelnianie jednej polowy bufora, a w tym czasie DAC odczytuje druga, po czym nastepuje zamiana. To znaczaco minimalizuje dropy ale jednoczesnie 'jitter software'owy' moze sie materializowac jezeli ten ring nie jest na czas nadpisywany przez player'a. I to jest roznie zaimplementowane w samych palyerach - jak efektywnie watki audio karmia bufor ASIO i z jakim priorytetem. Tu wlasnie pojawiaja sie roznice pomiedzy nimi. Dlatego jezeli bufor jest zbyt maly a watek player'a nie zdazy go zapisac na czas to ASIO host generuje underrun i niektore DAC'i potrafia to zarejestrowac. 
Rozmiar bufora to imo dobry wskaznik kondycji calego toru audio. Jezeli go musisz zwiekszac zeby nie 'trzeszczalo' to cos gdzies nie domaga - cpu zapchane innymi watkami, slaby driver samego DAC, czy wlasnie sam player zle obsluguje watki albo nie trzyma real-time.


 

[J.Jerry]

@miksti

Bufor asio w jednej karcie mam w ma, w drugiej podaję ilość próbek, więc w pierwszym przypadku bufor zależy od bitrate, a w drugim maleje ilość ma przy większym bitrate. Pierwsza karta służy min do nagrywania i przez lata nagrywania nic nie zauważyłem poza hmm....jitterem. 

W czasach mody na ustawianie mixera na max i buforów asio na min znam efekt za małego bufora, to trzaski i urywanie dźwięku. Zresztą ustawianie mixera na max w niektórych przypadkach pogarszało dźwięk i oczywiście wpływało na brzmienie, ale o tym było cicho....a wystarczyło zrobić pomiary thd.  Warto by zrobić porównanie z playera mi ustawionymi na 80 50 i 30 i pomiary thd.  Mam też urządzenie z wyjściem słuchawkowym, które ma regulacje volume i tu na max są najmniejsze thd także reguły tu nie ma.