Optymalizujemy i polepszamy dźwięk na kartach Asus Xonar Essence ST/STX

Dawno nie pisałem tak ogromnego, obszernego artykułu. I to jeszcze serii optymalizacji, modowania i ulepszania. Ale w dzisiejszej pogoni za nowościami, zwłaszcza z Chin, czasami zapomina się o rozwiązaniach starych, ale sprawdzonych i mających w sobie nawet dziś jeszcze sporo potencjału do wyciągnięcia.

Po co w ogóle zajmować się takimi kartami, czy może w ogóle takimi produktami? Na obu tytułowych kartach pracuję w dużej mierze od 2009 roku i użytkuję również w recenzjach na blogu, jako jeden z podstawowych punktów odniesienia. Choć karty te mają swoje bolączki, mają też wiele atutów i ukryte potencjały jakościowe, których być może sporo użytkowników zdążyło się już doszukać i odkryć samodzielnie, a może mających już karty z tej serii i wciąż borykających się z ich bolączkami albo działających na fabrycznych kościach i zwykłym odtwarzaniu via DirectSound, nie znając na dobrą sprawę drzemiącego w nich potencjału.

Opiszę zatem krok po kroku ustawienia, ulepszenia, optymalizacje i modyfikacje, które znam lub osobiście zastosowałem na STX oraz ST w celu uzyskania najbardziej satysfakcjonującego mnie osobiście dźwięku i rozwiązania różnych problemów trapiących te karty, czasami od lat i ku pełnej tego świadomości producenta. Postaram się też opisać mechanizmy na których opiera się nie tylko praca samych kart, ale też nieco trików i wskazówek na usprawnienie ich działania.

Artykuł podzielę na sekcje tematyczne, w których będę przechodził od rzeczy najbardziej podstawowych do tych bardziej zaawansowanych, mniej więcej w kolejności ich wykonywania i poczynając od świeżej instalacji. Każda sekcja będzie miała na początku krótką ściągawkę-streszczenie, aby można było szybko i sprawnie zastosować podane tam wartości i parametry, choć najlepiej zawsze byłoby przeczytać cały akapit, aby dowiedzieć się dlaczego w ogóle się to zrobiło. Ze względu na ogromną objętość, na początku będzie znajdował się wygodny spis treści prowadzący do konkretnych sekcji.

Po zastosowaniu wszystkich opisanych tu porad powinieneś zaobserwować:

• delikatną poprawę jakości odtwarzania w trybie DirectSound
• wyraźną poprawę jakości odtwarzania w trybie bit-perfect
• zauważalny spadek latencji
• bardzo wyraźną poprawę jakości po wymianie OPA
• bardzo wyraźną redukcję szumów i przebić na wydajnych słuchawkach po zastosowaniu filtracji
• wyraźnie mniejszą lub praktycznie zerową częstotliwość występowania trzasków lub niesławnego „pisku śmierci”

W artykule nie będą poruszane modyfikacje trwałe oraz tematyka DIY. To są rzeczy które mszczą się na takim sprzęcie na osi czasu i ponieważ cenię sobie stabilność oraz pewność działania – stąd być może od 11 lat posiadam wciąż sprawnie działającego STXa, w którym nie grzebałem i nie bawiłem się w inżyniera mądrzejszego, niż ten odpowiadający za ten projekt w fabryce. Karta podlegała jedynie wymianie wzmacniaczy operacyjnych, choć przeszła tyle komputerów, że po drodze aż straciła emblematy. No cóż, takie jest życie. Niemniej wraz z K240 MKII jest to mój swoisty wół roboczy, który uczestniczy w praktycznie każdej recenzji. Ma więc prawo nosić zewnętrzne ślady użytkowania. Nie jest to oznaka żadnych specjalnych modyfikacji, debrandingu czy mojej własnej jak pisałem wyżej myśli inżynierskiej.

Część linków do pobierania będzie kierowała do producentów aplikacji, ale też część tych najbardziej kluczowych do wirtualnego dysku z konkretnymi plikami. Jest to zabezpieczenie na wypadek sytuacji z AIM SC808, gdzie producent karty zniknął wraz ze stroną na której znajdowały się wszystkie sterowniki. Pliki umieszczone przeze mnie na dysku są używanymi przeze mnie aplikacjami i zostały przed wrzuceniem sprawdzone programem antywirusowym ESET Internet Security 13.

Spis treści:

1. Lista kart kompatybilnych
2. Zanim zaczniemy
3. Ogólna problematyka Xonarów
4. Najlepsze sterowniki do Xonar Essence ST/STX
5. Najlepsze ustawienia dźwięku dla Xonar Essence ST/STX (DirectStream)
6. Najlepsze ustawienia ASIO dla Xonar Essence ST/STX
   – Ogólna specyfika sterowników ASIO
   – ASUS Xonar ASIO driver 2.0.0.12
   – Natywne wsparcie dla DSD
   – Foobar + WASAPI 3.3 (push/event)
   – ASIO4ALL
   – Co będzie z tego najlepsze?
7. Optymalizacje systemu i PC pod kątem latencji
8. Wymiana wzmacniaczy operacyjnych
   – Sprawdzone kombinacje OPA
9. Redukcja podatności na szumy, buczenie i przebicia
   – Pokrywa EMI
   – Panel przedni obudowy i przedłużacze
   – Oddalenie od karty graficznej
   – Solidny przedłużacz MOLEX
   – Uziemienie w sieci elektrycznej
   – Filtracja i odszumianie
10. Niwelujemy tzw. „pisk śmierci”
    – Czym jest „pisk śmierci”
    – Co robić jeśli wystąpi „pisk śmierci”
    – Przeciwdziałania i zabezpieczenia
11. Podsumowanie

Lista kart kompatybilnych

Porady tu opisywane mają zastosowanie dla posiadaczy kart na układach C-Media CMI8786 oraz CMI8788. Wchodzą w to więc produkty Auzentech czy HT Omega, ale także Tempotec czy zapomniane już karty AIM SC8000, a które przecież też sprawdzały się swego czasu rewelacyjnie, póki producent najpierw ich nie porzucił w kwestii wsparcia, a potem nie porzucił sam siebie poprzez likwidację swojej firmy/marki, zostawiając użytkowników na lodzie i bez wsparcia tym razem jakiegokolwiek – od sterowników po serwis gwarancyjny i pogwarancyjny.

Lista kart ASUSa na jakich prawdopodobnie uda się zastosować większość, jeśli nie wszystkie opisane tu rzeczy (wytłuszczone urządzenia na bazie których pisany był artykuł):

• Xonar DG,
• Xonar DGX,
• Xonar DG SI,
• Xonar DS,
• Xonar DSX,
• Xonar D1,
• Xonar D2,
• Xonar DX,
• Xonar D2X,
• Xonar HDAV/Slim,
• Xonar Essence ST,
• Xonar Essence STX,
• Xonar Essence STX II,
• Xonar Xense.

Natomiast sterowniki UniXonar, na jakich będziemy operowali, mają szansę pasować także do:

• Auzentech: HDA X-Purity 7.1, X-Meridian 1G, X-Meridian 2G
• HTOmega: Claro, Claro Plus, Claro II, Claro Halo, eClaro
• Razer: Barracuda AC-1
• AIM: SC8000

Choć takie rzeczy, jak optymalizacja pod kątem latencji, dostosowanie częstotliwości próbkowania, konfiguracja systemu czy nawet dobre praktyki przy wybieraniu slotów, mogą mieć (i najpewniej będą miały) przełożenie na inne urządzenia dźwiękowe od innych producentów i w sumie nie powinno to nikogo dziwić, skoro działają w ramach tego samego środowiska (systemu operacyjnego), to niestety nie wszystko da się przełożyć. Tyczy się to chociażby opisów zachowania wzmacniaczy operacyjnych i strategii ich wymiany. Niemniej wciąż jestem zdania, że w wielu przypadkach porady będą na tyle uniwersalne i korzystne dla wszystkich urządzeń audio, że warto się pobawić nimi w wolnej chwili z czystej ciekawości, nawet jeśli ma się zwykły, zintegrowany z płytą główną układ Realteka.

Zanim zaczniemy

Artykuł jest naturalnie pisany z zastrzeżeniem, że wszystko co się tu znajdzie, wliczając w to wykorzystywane oprogramowanie, kości OPA i inne czynności, są wykonywane na własną odpowiedzialność użytkownika oraz bez żadnej gwarancji, że uda się uzyskać identyczne rezultaty. Niemniej wierzę, że tak się stanie. Wciąż jednak wiele rzeczy będzie wymagało własnego eksperymentowania z dobrymi ustawieniami, zwłaszcza że Xonar może ujawnić szereg problemów trapiących nieświadomie nasz PC i ujawnić także takie kwestie, które pojawiłyby się również i po zmianie sprzętu audio na inny.

Zalecam przede wszystkim zrobienie kopii zapasowej wrażliwych danych oraz stworzenie punktów przywracania na wypadek, gdyby coś poszło nie tak, a także zachowanie podstawowych zasad bezpieczeństwa podczas obchodzenia się z elektroniką lub przy wymianie wzmacniaczy operacyjnych.

Jeśli użytkownikowi brakuje wiedzy, umiejętności czy cierpliwości do wykonywania opisanych tu zagadnień w zakresie oprogramowania i sprzętu, nie powinien się za nie zabierać w ogóle lub przynajmniej robić tego samodzielnie. Zasada „nie znasz się to nie grzeb”.

Jeśli posiadana karta dźwiękowa wykazywała już wcześniej oznaki zużycia się elektroniki, jakiekolwiek ingerencje w nią, zwłaszcza na polu wymiennych wzmacniaczy operacyjnych, mogą skutkować dalszymi problemami i uszkodzeniem samej karty lub nawet komputera.

Jeśli karta posiadała już jakieś twarde modyfikacje, przeróbki i inne ingerencje w swoją konstrukcję, artykuł przybiera formę eksperymentalną i efekty końcowe mogą być tym bardziej odmienne od tych tu zaprezentowanych, gdyż zmienia się w sposób diametralny środowisko ich aplikacji.

Ogólna problematyka Xonarów

Karty te są w dużej mierze solidne i nie robią psikusów, zwłaszcza tych sprzętowych, ale nie znaczy to, że życie ich posiadaczy jest niczym kraina mlekiem i miodem płynąca. Karty te, jak wszystkie chyba urządzenia elektroniczne, mają swoje problemy, bolączki, kaprysy i ograniczenia, których intensywność i charakterystyka będą zależały od posiadanego sprzętu, oprogramowania, jego konfiguracji oraz wykorzystywania komputera jako całości. Nawet jeśli problemy co do zasady występują tu rzadko, należy mieć świadomość ich istnienia.

Najbardziej znaczące dla mnie osobiście problemy z jakimi się do tej pory borykałem to:

• problemy z działaniem i błędy oryginalnych sterowników (w ogromnej większości rozwiązane przez sterowniki UniXonar),
• wysoka latencja systemu, sterowników i ogólna podatność karty na jej wpływ skutkująca szarpaniem dźwięku, zwłaszcza przy korzystaniu z ASIO (pomaga konfiguracja buforów i kilka trików),
• niesławny „pisk śmierci” (bardzo głośny szum i pisk o wysokiej częstotliwości, pomagają różne zabiegi, głównie poprawna konfiguracja głębi bitowych, brak ulepszaczy w dźwięku oraz filtry zabezpieczające, tudzież tryb ASIO),
• niestabilność i problemy w grach przy korzystaniu z efektów/GX (pomaga po prostu nie korzystanie z takowych).

Dodatkowo, korzystając dawniej z Essence STX i SC808, zawsze pragnąłem wyciągnąć maksimum z kart z serii Essence pomimo przeciwności konstrukcyjnych i posiadania na papierze lepszej elektroniki przez propozycję AIMa. Choć może inaczej: chciałem wiedzieć gdzie leży kres owego maksimum. Artykuł będzie toteż nastawiony również na ten cel, głównie za sprawą wyboru odpowiednich metod dekodowania oraz ulepszeń sprzętowych nie będących twardymi i agresywnymi ingerencjami w elektronikę karty.

Najlepsze sterowniki do Xonar Essence ST/STX

1. zainstaluj alternatywne sterowniki UniXonar od MaxedTech, aby obniżyć latencję i rozwiązać szereg problemów ze sterownikami (w moim przypadku 1.75a R3)
2. korzystaj z panelu C-Media aby nie podnosić latencji w trakcie działania karty
3. korzystaj z panelu Asus Audio Center tylko jeśli chcesz ustawić początkowy gain dla swoich słuchawek, a po konfiguracji uruchom komputer ponownie
4. jeśli posiadasz kilka par słuchawek i bardzo często zmieniasz ustawienia wzmocnienia, spróbuj aplikacji XonarSwitch
5. w razie konieczności sprawdź inną wersję sterowników jeśli napotkasz problemy z działaniem karty na poziomie sprzętowym.

Zaczynając od najbardziej fundamentalnych rzeczy, przede wszystkim musimy wybrać odpowiednią wersję sterowników do zainstalowania. A żeby je zainstalować, urządzenie musi być widoczne w systemie operacyjnym. Po uruchomieniu naciskamy Win + R i wpisujemy devmgmt.msc. Xonar powinien być widoczny jeśli dobrze pamiętam jako kontroler multimediów z żółtym wykrzyknikiem.

Jeśli karta nie jest wykrywana, to albo karta jest uszkodzona, albo nie otrzymuje należytego zasilania (wtyczka MOLEX 4-pin), albo płyta główna ma problem z poprawną alokacją zasobów i następuje konflikt przerwań, tudzież jest skonfigurowana na sztywno i nie puszcza dalej zmian w alokacji zasobów na nowe urządzenia.

Bez widocznej karty w systemie, nie zainstalujemy sterowników.

Zakładając jednak, że na tym etapie nie będzie problemów, pozostaje nam wybór:

• oficjalne, fabryczne sterowniki ze strony Asusa
• nieoficjalne sterowniki UniXonar oparte na powyższych

Osobiście nie korzystam z fabrycznych sterowników oferowanych przez producenta karty. Zamiast tego wykorzystuję drugą opcję, czyli sterowniki UniXonar w różnych wersjach, dla STX najczęściej 1.75a Release 3 (link bezpośredni do pobrania). W przypadku ST, najwięcej szczęścia miałem natomiast z 1.71.1.

Sterowniki instaluję u siebie na systemach Windows 10 Home x64 v2004 (na dzień pisania artykułu) w takiej oto konfiguracji:

Opcja czyszczenia sterowników jest zdatna do zaznaczenia wówczas, gdy mieliśmy już jakieś inne sterowniki wcześniej zainstalowane, czy to fabryczne, czy nie. Przede wszystkim jednak interesuje nas opcja Low DPC latency, czyli zainstalowanie sterownika audio bez aktywowania uruchamianych wraz ze startem systemu paneli. Są one instalowane tak czy inaczej, więc wszystko można dzięki kim sobie poustawiać na żądanie w razie potrzeby. Jeśli zajdzie taka potrzeba, uruchamiam C-Media Panel, ponieważ uruchomienie centrum Asusa powoduje mocny wzrost latencji i wymaga uruchomienia komputera ponownie. Można też wybrać opcję C-Media Panel od razu, jeśli chcemy mieć panel rezydujący w zasobniku systemowym od startu. Obie te opcje są dobre, a do latencji wrócę jeszcze później przy okazji optymalizacji całego komputera.

Asus Audio Center ma praktycznie tylko jedno zastosowanie: kontrolę nad wzmocnieniem wyjścia słuchawkowego. Dlatego jeśli już muszę uruchomić tenże panel, to tylko z tego powodu. Essence ST/STX mają konfigurowany, trójstopniowy gain, który warto wykorzystywać. W SC808 był on ustawiony na sztywno na maksimum i powodował często problemy z wydajnymi słuchawkami, jeśli zapomnieliśmy obniżyć głośność. Groziło to uszkodzeniem słuchu i sprzętu. Nie zalecam jednak korzystania z Asus Audio Center (w skrócie AAC na potrzeby tego artykułu) ze względu na negatywny wpływ na latencję i rezydowanie w takim stanie aż do ponownego uruchomienia komputera.

W sytuacji gdy mamy kilka różnych par słuchawek o różnych wymaganiach i zmusza nas to do częstego przełączania się między nimi, możemy rozważyć użytkowanie aplikacji XonarSwitch od MaxedTech (link bezpośredni do pobrania). Nie jest rozwijana od 2015 roku i nie wyszła spoza wersji beta, ale może okazać się bardzo użyteczna. Jeśli chodzi o mnie osobiście, preferuję korzystanie z niej bardziej niż z jakiegokolwiek innego panelu dostarczanego razem ze sterownikami. Wszystkie opcje mam pod ręką, a interfejs jest ładny i czytelny. Ponieważ AAC i CCP i tak się instalują, korzystanie z którejkolwiek opcji, tj. Asus Audio Center, C-Media Control Panel czy XonarSwitch, pozostaje wyłącznie w gestii użytkownika.

Nic nie stoi na przeszkodzie, aby próbować także i innych wersji sterowników, ale za każdym razem warto przeczytać opis techniczny wraz z poprawkami i usterkami jakie dana paczka posiada. Innych opcji, zarówno zdatnych do zaznaczenia podczas instalacji jak i później do skonfigurowania, nie omawiam, ponieważ mają one znaczenie bardziej w przypadku systemów wielokanałowych lub sytuacji, w których liczą się efekty i wirtualizacja dźwięku niż jego elementarna jakość. A ponieważ zależy mi przede wszystkim na jakości, tym samym w moim przypadku priorytetami będą odsłuchy słuchawkowe, stereo RCA oraz rola transportu cyfrowego. Konfigurację wielokanałową zostawię na późniejszy czas lub ew. uzupełnienia do artykułu, jeśli będzie taka potrzeba.

Najlepsze ustawienia dźwięku dla Xonar Essence ST/STX (DirectStream)

1. skonfiguruj system dźwiękowy w panelu C-Media oraz Windows adekwatnie do tego na jakim ustawieniu i materiale dźwiękowym pracujesz
2. ustaw głębię bitową odtwarzania i nagrywania na 24-bit
3. ustaw częstotliwości próbkowania odtwarzania i nagrywania na 1 kHz, jeśli nie posiadasz materiału nagranego w wyższym próbkowaniu
4. dezaktywuj wszystkie efekty, jeśli nie musisz z nich korzystać
5. zastosuj skrypt dezaktywujący kompensację głośników

Skoro mamy zainstalowane sterowniki i wraz z nimi natywne sterowniki ASIO, skonfigurujmy najpierw samą kartę w panelu oraz ustawieniach Windows.

Podstawowe rzeczy to przede wszystkim ustawienie panelu C-Media. Ponieważ interesuje nas praca ze słuchawkami, ustawiamy wejście sygnału na 2 CH oraz wyjście na Słuchawki. Częstotliwość próbkowania zarówno do odtwarzania jak i nagrywania zalecam ustawić na 44.1 kHz, ponieważ generalnie z takim materiałem będziemy zakładam pracowali w ramach nie tylko muzyki, ale też wszelkiej maści programów i gier.

Niekiedy wymagane będzie ustawienie 48 kHz, jeśli będziemy posiadali akurat taki materiał dźwiękowy lub filmowy (niektóre DVD Video czy BluRay chociażby), ale na tym tak naprawdę kończyć będą się typowe zastosowania wyższych częstotliwości próbkowania. Ustawienie wyższych częstotliwości w normalnym, że tak powiem, materiale audio nie spowoduje, że nagle uzyskamy jego super mega jakość i w ogóle dźwięk HD. Wręcz przeciwnie. Zmusimy wtedy kartę do upsamplingu i w najlepszym wypadku nie zyskamy nic, a w najgorszym doprowadzimy wręcz do degradacji jakości dźwięku. Jeśli posiadamy materiał nagrany w wyższej jakości próbkowania, z większą głębią bitową, wtedy jak najbardziej ustawiamy parametry adekwatne do materiału. W przeciwnym wypadku stosujemy ustawienia tu opisane.

Głębię bitową rekomenduję ustawić na 24 bity. Wpłynie to delikatnie na plus na jakość dźwięku. To ustawienie musimy już wykonać poprzez zasobnik systemowy. 24-bitowe próbkowanie ustawiamy ponownie dla odtwarzania i nagrywania. Odtwarzając materiał 16-bitowy nie powinniśmy notować żadnej penalizacji z tego tytułu, w przeciwieństwie do próbkowania.

Wszystkie efekty, w tym GX, warto mieć wyłączone. Tyczy się to głównie panelu Asus Audio Center, ale też efektów przestrzennych w panelu Windows. W panelu Asus Audio Center możemy zdefiniować też poziom wzmocnienia. Mamy do wyboru trzy przedziały impedancji, z czego wybieramy ten, który jest najbardziej zbliżony do posiadanych przez nas słuchawek. Jest to ustawienie które definiuje się raz i jest ono zapamiętywane, także po ponownym uruchomieniu komputera nie jest potrzebne ustawianie ponownie czegokolwiek.

Przypomnę w tym miejscu jeszcze raz, że samo Asus Audio Center oraz efekty GX wpływają negatywnie na latencję (ciągłe odpytywanie sterownika), a to z nią często właśnie będziemy się zmagać i w tym artykule chcemy (albo przynajmniej ja), aby była jak najmniejsza. Latencja wzrasta od samego uruchomienia Asus Audio Center i nie znika po jego zamknięciu/wyłączeniu, a dopiero po ponownym uruchomieniu komputera. Dlatego zalecam korzystanie albo z panelu C-Media, albo alternatywnego XonarSwitch, który ma w sobie wszystkie niezbędne opcje z Asus Audio Center. 

Na koniec zalecam wyłączenie systemu kompensacji głośników, który pełni rolę zabezpieczenia w sytuacjach nadmiernej amplitudy dźwięku wyjściowego, głównie w okolicach 21 kHz. Dzięki temu powinniśmy jeszcze nieco podnieść finalną jakość dźwięku. Ustawienia te nie są dostępne w żadnym panelu sterowników i są włączone domyślnie. Dlatego aby je wyłączyć należy:

1. pobrać bezpośrednio stąd i wypakować skrypt wyłączający,
2. uruchomić Disable SpeakerCompensation.exe,
3. jeśli korzystamy ze sterowników 1.80 lub starszych: zamknąć wszystkie aplikacje korzystające z karty i uruchomić Restart card.exe. Jeśli nic się nie stało i nie słyszeliśmy pracujących przełączników, uruchamiamy ponownie komputer,
4. jeśli korzystamy ze sterowników 1.81: od razu uruchamiamy komputer, nie restartujemy karty skryptem.

Najlepsze ustawienia ASIO dla Xonar Essence ST/STX

1. zainstaluj odpowiedni program do odtwarzania mogący pracować ze sterownikami ASIO i materiałem bit-perfect
2. korzystaj z natywnego sterownika ASUS Xonar ASIO driver aby uzyskać najlepszą jakość dźwięku i najniższą latencję
3. ustaw głębię bitową ASIO na 32-bit
4. pozostaw latencję na domyślnych 10 ms lub najniższą wartość na której nie słyszysz trzasków w dźwięku podczas pracy na komputerze
5. ustaw w swoim odtwarzaczu korzystanie ze sterowników 32-bit (jeśli Twój program audio pozwala na płynny wybór wersji bitowej sterowników ASIO)
6. pobierz ASIOCONFIG jeśli chcesz mieć możliwość ręcznego wywoływania konfiguratora trybu ASIO lub nie masz takowego dostępu w swoim programie audio
7. jeśli nie możesz skorzystać z natywnego ASIO lub innych sterowników bit-perfect, a używasz Foobara, zainstaluj wtyczkę WASAPI która da Ci tryb wyłączności oraz nadal dosyć niską latencję, ew. przetestuj ASIO4ALL, które są uniwersalne i często działają również z innymi urządzeniami audio

Ogólna specyfika sterowników ASIO

Generalnie zawsze preferuję korzystanie z natywnych sterowników ASIO ze swoimi urządzeniami audio i to właśnie wokół tego sposobu renderowania dźwięku będę się najbardziej rozpisywał. A choć będę tu pisał sporo o latencji, to jej badanie znajdzie się w następnym akapicie w sekcji poświęconej jej redukowaniu. Tymczasem interesować nas będzie w tej chwili ASIO i związane z nim aspekty.

Tryb ASIO pozwala na obejście miksera systemowego i uzyskanie bezpośredniego, niezmąconego dostępu do sterownika urządzenia dźwiękowego, rezerwując go na poziomie aplikacji na wyłączność i umożliwiając dekodowanie dźwięku w prawdziwym trybie bit-perfect.

Tak przynajmniej wygląda teoria. W praktyce sterowniki ASIO mogą być napisane naprawdę różnie i w niektórych przypadkach trudno byłoby mówić nawet o nich jak o sterownikach ASIO, ponieważ ich działanie bardziej przypominałoby zasadą zachowanie się wrapperów programowych. Przykładem są tutaj (może będzie to dla niektórych zaskoczeniem) WASAPI czy ASIO4ALL (oba swoją drogą tu omówimy). Sterowniki takie znaleźć można np. w produktach Audio-GD, ale nie jestem pewien czy w tym gronie nie znalazłyby się też karty AIM SC808.

Testów na poprawne działanie ASIO, albo raczej poprawne ich funkcjonowanie jako sterownik bit-perfect, jest przynajmniej kilka. Można np. nagrywać próbki dźwiękowe na wyjściu na dysk i porównywać je 1:1 np. w edytorze Exact Audio Copy (link do pobrania ze strony producenta). Można również podłączyć do danego układu, jeśli tylko ma on wyjścia S/PDIF, DAC mogący wskazywać otrzymywany na wejściu sygnał bit-perfect. Nie da się tu oczywiście wykluczyć, że z jakiegoś innego powodu nie będzie on w stanie rozpoznać sygnału, ale na ogół jest to dosyć pewny sposób (i drogi).

Sporo osób opiera się więc na teście głośności, a więc sprawdzeniu czy suwak głośności systemu Windows ma wpływ na natężenie dźwięku. Nie jest to do końca miarodajne, ponieważ część urządzeń może mimo wszystko opierać się na takim mechanizmie i jednocześnie pracować poprawnie w trybie ASIO. Dowód na to poniekąd znalazłem w dokumentacji deweloperskiej dla Windows w kontekście regulacji głośności:

Applications that manage exclusive-mode streams can control the volume levels of those streams through the IAudioEndpointVolume interface. This interface controls the volume level of the audio endpoint device. It uses the hardware volume control for the endpoint device if the audio hardware implements such a control. Otherwise, the IAudioEndpointVolume interface implements the volume control in software.

Niemniej ogólnie przyjmuje się, że poprawnie napisane sterowniki ASIO pozostają niewzruszone na głośność systemową i bez względu na położenie suwaka zawsze powinniśmy mieć maksymalną głośność. Jeśli takie zachowanie wystąpi, przyjmuje się je za pewnik i gwarancję, że mikser systemu Windows został pominięty i uzyskany dźwięk jest w istocie w duchu bit-perfect.

Dla pewności jednak można wykonać „test usługi”, a więc wyłączenie systemowej usługi Windows Audio. Jeśli po jej wyłączeniu urządzenie w trybie ASIO daje poprawnie dźwięk, to znaczy, że są to prawdziwe i poprawnie napisane sterowniki bit-perfect. Jeśli na wyjściu nie uzyskujemy żadnego dźwięku, to znaczy że dana metoda renderowania jest oparta o mikser systemowy i nie jest to prawdziwy odizolowany tryb dźwiękowy. Jest to prawdopodobnie najlepszy sposób aby sprawdzić wszystkie swoje urządzenia krok po kroku, a raczej ich sterowniki, choć zapewne bardziej dla zaawansowanych użytkowników.

Dla ciekawości dodam w tym miejscu, że Pathos Converto reagował na głośność systemową w trybie ASIO, sugerując że nie jest to prawdziwy tryb izolowany, ale zdawał test wyłączenia usługi Windows Audio, więc idealnie trafiał w ten przypadek, gdzie sterowniki wykorzystywały rzeczywiście interfejs IAEV, nie negując bycia jednocześnie trybem bit-perfect.

Zasadą nadrzędną jest praktyka korzystania ze sterowników dostarczonych wraz z urządzeniem, jeśli tylko jest to możliwe. Natywne sterowniki ASIO są pisane bowiem stricte pod konkretny sprzęt lub układ, dając potencjalnie najlepsze możliwości jakościowe i prawdziwy dźwięk bit-perfect. Takie właśnie sterowniki są zaimplementowane w UniXonary i z nimi też karta osiąga najlepsze efekty, a o czym zaraz opowiem dokładnie i z kilkoma ciekawostkami pomiarowymi.

ASUS Xonar ASIO driver 2.0.0.12

Moje preferencje za natywnym sterownikiem wynikają z faktu, że ze wszystkich metod odtwarzania dźwięku jakie przetestowałem z Xonarami, to właśnie tryb natywny szczycił się najniższą latencją efektywną, pomiarowo najlepszymi parametrami przenoszenia częstotliwości oraz brakiem wzrostu latencji sterownika na samym pliku cmudaxp.sys. Był to też jedyny w pełni odizolowany tryb renderowania dźwięku z pominięciem głośności systemowej.

Efektywna latencja natywnego trybu ASIO na Essence ST na najsłabszej maszynie wynosiła (wraz z innymi procesami) ok. 60 µs, kompletnie nie wpływając na jej poziom (system w spoczynku i bez odtwarzania wykazywał bardzo zbliżone wartości latencji). Tryb DirectSound, a więc domyślny systemowy, zgłaszał średnio ok. 120 µs, a więc dwa razy tyle. Identycznie jest przy trybie WASAPI. Z kolei ASIO4ALL notowało ok. 250 µs i znowu podwajało tym samym latencję poprzedniego trybu. Jeśli dobrze pamiętam, wartości te na STX były bardzo podobne na drugiej maszynie, więc nie była to kwestia ułożenia się konkretnego sprzętu w pewien schemat działania, a coś mającego, przynajmniej u mnie, cechy powtarzalnej obserwacji.

Dodatkowo sterowniki ASIO na kartach Xonar Essence ST i STX powodują, że pomiarowo zwiększa się na tym sprzęcie graniczne pasmo przenoszenia. Prócz testów syntetycznych, zmiany daje się również usłyszeć w praktyce. De facto to właśnie dzięki odsłuchom zdecydowałem się na wykonanie pomiarów, ponieważ podczas odtwarzania muzyki, natywne sterowniki ASIO podnosiły subtelnie jakość dźwięku i jego dynamikę oraz wpływały korzystnie na scenę i holografię. Przeprowadzone testy syntetyczne i porównanie ich z wynikami w trybie DirectSound wykazały, że w trybie ASIO zachodzą zauważalne zmiany:

1. zwiększenie efektywnego zakresu przenoszenia najwyższych częstotliwości (spadek od ok. 16 kHz vs spadek od ok. 20 kHz)
2. praktycznie całkowite wyeliminowanie fluktuacji najwyższych częstotliwości (punkt 17,88 kHz)
3. minimalnie niższe THD na niemal całej przestrzeni pasma przenoszenia (od ok. 70 Hz w górę) oraz najbardziej zmniejszony (tj. najbardziej wypłaszczony) szum tła (N)

Swego czasu miały miejsce różnorodne debaty na temat tego, czy sterowniki w trybie bit-perfect faktycznie coś dają, czy może jest to pogoń na koniec tęczy za garnkiem złota. Tymczasem okazuje się, że faktycznie jest coś na rzeczy. W bardzo mocnym zbliżeniu i po zmniejszeniu skali do konkretnego wycinka pasma, wygląda to następująco:

Zauważyłem to nie tylko przy tym konkretnym problemie, ale też przy kablach czy wzmacniaczach operacyjnych, że sporo twierdzeń o tym, iż coś czegoś nie daje, że to ułuda, placebo albo marketing, powstaje w umysłach i na klawiaturach osób podchodzących do tematu od bardzo wąskiej strony i tylko na podstawowym, budżetowym zakresie. Najtańsze kable czy najtańsza elektronika ma rywalizować o miano najlepszej/najgorszej, podczas gdy wszystko pochodzi tak naprawdę z tej samej fabryki w Chinach. I co gorsza ma to działać jako rozbudowane studium przypadku, najczęściej sceptyczne i odgórnie podważające istnienie danego zjawiska.

Choć naturalnie nie wykonałem testów stricte laboratoryjnych, a jedyne podstawowe, wciąż będą to dane wymierne pokrywające się z odsłuchami. Nie jestem pewien czy zmiany da się usłyszeć także i na słabszym sprzęcie oraz mniej wytrawnym uchu. Zysk jakościowy jest tym większy, im lepszej klasy mamy słuchawki (testy wykonywałem na chociażby LCD-XC czy HD800).

Bez względu na to, w natywnym trybie ASIO karta w istocie zmieniła swoje parametry pracy w zakresie efektywnego pasma przenoszenia (nazwijmy je skrótowo EPP) na plus i nawet, jeśli ma to miejsce na skrajach kompletnie poza naszym użytecznym zakresem słyszenia i rezyduje w obszarze harmonicznych, nie pozostaje bez wpływu na dźwięk. Do tego nie bez korzystnego wpływu będą tu zniwelowana fluktuacja oraz lepsze THD+N. Niemniej to EPP odpowiada tu moim zdaniem za cały sekret związany z lepszymi wrażeniami odsłuchowymi.

Co ciekawe, przez całe lata nie korzystałem ze sterowników ASIO z racji ich problematyczności w działaniu. Aby bowiem ze sterowników dało się korzystać, należy je w ogromnej ilości przypadków należycie skonfigurować i tak samo uczynić z wykorzystywanym oprogramowaniem.

Natywny sterownik ASIO ma swój (bardzo prosty) panel konfiguracyjny, który można wywołać tylko z programu w którym realizujemy dekodowanie ASIO. W przypadku wykorzystywanego przeze mnie Foobara:

Domyślnie ustawiony jest on w tryb 16 bit / 10 ms. Mamy ogólnie do wyboru głębię bitową:

• 16 bit (domyślnie)
• 24 bit
• 32 bit

Zmiana tego parametru to pewien dylemat, przynajmniej jeśli chodzi o głębię. Z jednej strony układy Oxygen HD użyte na kartach Essence ST/STX wspierają próbki DMA w formacie 16 i 32-bitowej. Z drugiej strony komunikacja między OHD a układem DAC na karcie realizowana jest po szynie 24-bit. Powoduje to debaty nad tym jaka wartość bitowa powinna być ustawiona dla najlepszego efektu w sterowniku. Sam osobiście zalecam ustawienie wartości 32-bit. Raz że koresponduje to z obsługą jak pisałem próbek DMA, dwa że stawiałbym tą właściwość ponad wewnętrzną szyną danych, trzy że zauważalnie pomogło to obniżyć trzaski generowane podczas pracy z ASIO i uczyniło to najlepiej ze wszystkich trzech trybów bitowych.

Innych opcji poza wspomnianą 10 ms latencją niestety nie da się ustawić. Do latencji przejdę jeszcze za moment, ale na tym etapie, wartość 10 ms można pozostawić niezmienioną. Będziemy ją konfigurować za moment, jako że jest to tak naprawdę wartość bufora sprzętowego.

Możemy w razie konieczności uruchomić opcjonalny ASIOCONFIG (link bezpośredni do pobrania), dający nam możliwość wywołania panelu ASIO ręcznie, nie tylko do samej karty, ale do każdego urządzenia opartego o interfejs ASIO. Pamiętać należy, że jest to tylko plik wywołujący panel wbudowany w dane sterowniki, a nie panel alternatywny.

ASIO wbudowane w sterowniki mają niestety swoje przypadłości i uroki:

• konieczność zatrzymywania odtwarzania przed każdorazową chęcią zmian w opcjach
• ignorowanie regulacji głośności systemowej (choć z reguły jest to oznaka, że mamy tu do czynienia z poprawnie napisanym sterownikiem bit-perfect)
• ignorowanie programowego ustawienia gain (j.w.)
• brak dźwięku przy odtwarzaniu ścieżek mono
• trzaski i chwilowe zawieszanie się dźwięku przy np. przełączaniu się między zakładkami w przeglądarce
• ogólnie bardzo dużą wrażliwość na latencję pozostałych procesów systemowych
• tendencję do zawieszania dźwięku w specyficznych sytuacjach podczas pracy z wyjściem S/PDIF

Nie wszystko z powyższej listy będzie nam przeszkadzało, ale wyraźne przycięcia się dźwięku i trzaski podczas pracy, głównie pod obciążeniem CPU, ale nawet i przy przełączaniu się między zakładkami w przeglądarce internetowej, to rzeczy, które powodowały u mnie przez wiele lat omijanie natywnego trybu ASIO i traktowanie go jako wprost wadliwego i niezdatnego do użytku.

Na szczęście rozwiązań powyższych problemów jest jednak kilka, choć niektórych nie musimy specjalnie rozwiązywać.

Regulację głośności możemy realizować za pomocą albo podłączanych do Xonara urządzeń dodatkowych, albo programowego odtwarzacza z którego korzystamy (w przypadku Foobara ma miejsce regulacja 64FP). W razie czego przed odsłuchami warto ściągnąć głośność w odtwarzaczu na zero. Można też stosować specjalne filtry impedancyjne na wyjściu, które dodatkowo polepszają (choć nie wszystkie oczywiście) jakość dźwięku odcinając szum i redukując głośność, aczkolwiek dopasowanie ich w taki sposób, aby wstrzelić się na danej parze w idealną dla nas głośność bez konieczności regulowania jej ręcznie, będzie to bardzo trudną sztuką. Jeśli natomiast chcemy korzystać tylko z trybu S/PDIF albo wyjść RCA, ustawiamy wszystkie suwaki głośności na 100%.

Z kolei konieczność stopowania muzyki przed zmianami ustawień nie powinna być zbyt uciążliwa, ponieważ ilość opcji jest tak mała, że raz ustawione parametry bardzo rzadko będziemy musieli zmieniać, jeśli zrobimy to dobrze.

W przypadku odtwarzania dźwięku mono, przynajmniej Foobar posiada opcję konwersji mono do stereo za pomocą wbudowanej wtyczki DSP, co całkowicie rozwiązuje problem (wtyczka działa w trybie ASIO).

To tyle z tych pomniejszych problemów. Do rozwiązania trzasków i przycięć dźwięku potrzebne będą nam z kolei tryb administratora, ustawiona odpowiednio wartość Latency oraz jednoczesne strumieniowanie na wyjścia analogowe S/PDIF.

Aby pozbyć się przycięć dźwięku, konieczne jest uruchomienie naszego odtwarzacza w trybie administratora oraz ewentualne wyłączenie trybu kontroli użytkownika (UAC). Samą aktywację odtwarzacza w trybie administratora możemy zautomatyzować. Wystarczy edytować Zaawansowane ustawienia skrótu w Menu Start i ustawić wymuszony tryb administratora.

Ceną za to – przynajmniej przy Foobarze – będzie zablokowanie możliwości przeciągania katalogów wprost z Eksploratora Windows do widoku playlisty. Problem można obejść za pomocą modyfikacji układu dokerów tego konkretnego odtwarzacza tak, aby móc przeciągać katalogi z okna Media Library.

Pozostaje się więc temat trzasków. Tu pomagają z reguły drobne zabiegi optymalizujące pracę komputera i sam sposób działa systemu, które powinny przełożyć się na zmniejszoną latencję (to ona jest tu problemem i jak pisałem sterowniki natywne są dosyć mocno na to wyczulone), ale przede wszystkim ustawienie Latency w panelu ASIO.

Jest to ustawienie bufora sprzętowego i domyślnie pracuje on na wartości 10 ms. W przypadku nierozwiązania problemu trzasków dźwięku przez tryb administratora, warto sprawdzić wyższe wartości tego parametru. Przejście już na 20 ms może dać słyszalną różnicę na plus, a 30 ms rozwiązać całkowicie problem. W razie konieczności można ustawić także i wyższe wartości, ale nie przekraczałbym 50 ms. Wartość 50 ms można ustawić w sytuacji, gdy otrzymujemy błędy np. wizualizacji. Te będą chodzić wolniej, ale nie będą miały efektu „rozdygotania”.

Odbywa się to trochę kosztem nieco wyższej latencji, zaś przy większych wartościach niż podane wyżej – także i klatkowaniem różnego rodzaju wizualizacji (znów: Foobar). Wzrost latencji jest jednak na tyle symboliczny, że o ile większy niż w trybie 10 ms, o tyle wciąż zauważalnie mniejszy niż notują tryby DirectSound oraz ASIO4ALL.

W moim przypadku ustawienie wartości 20 ms praktycznie całkowicie rozwiązało problem i pozwoliło nadal utrzymywać latencję mniejszą niż w trybie DS. Chrupnięcia były słyszalne bardzo sporadycznie i związane już tylko i wyłącznie z niesławnymi problemami z latencją komponentów systemowych, jak ntoskrnl.exe itd.

Na sam koniec pozostaje problem wieszania się dźwięku w określonych sytuacjach gdy pracujemy z ASIO na wyjściu S/PDIF. Pojawiał się on u mnie w sytuacjach, gdy specyficzne procesy próbowały skorzystać z naszego urządzenia dźwiękowego, np. w przeglądarce Chrome podczas przeglądania naszego forum (właściwie wszystkich forów na IPB), a wybranym urządzeniem systemowym było wyjście S/PDIF właśnie.

Najprawdopodobniej koniunkcja jednego i drugiego powoduje próbę dostępu do tego samego urządzenia dźwiękowego i stąd zablokowanie wcześniej odtwarzanego na nim strumienia. W efekcie mamy kolizję miękkie zawieszenie dźwięku. To dlatego problem nie występuje w trybie wyjść analogowych, gdy te są wybrane jako urządzenie domyślne zamiast wyjścia S/PDIF. Jest to przypadłość wszystkich sterowników jakie testowałem na obu kartach i jedyną wspólną cechą w tym wszystkim była wersja natywnych sterowników ASIO.

Powszechnie sądzi się, że tryb ASIO „blokuje” sprzęt audio na jednym strumieniu i jednocześnie wstrzymuje pozostałe dźwięki obecne w systemie Windows. Tak się nie dzieje. ASIO nie blokuje w żaden sposób odtwarzania dźwięków Windows i innych aplikacji nie mających w danej chwili trybu wyłączności poprzez inny protokół, jak np. MME czy WDM. Teoretycznie cały czas może zajść więc konflikt między strumieniami i sterownik może nie wiedzieć jak się zachować.

Rozwiązania tego problemu znalazłem dwa:

1. praca tylko i wyłącznie sterownika ASIO z kompletnym i siłowym wyłączeniem systemowego miksera odgórnie poprzez aplet usług Windows,
2. ustawienie innego urządzenia systemowego niż S/PDIF, aby dźwięki systemowe szły przez mikser Windows na coś innego niż wykorzystywane w danej chwili urządzenie dźwiękowe w trybie ASIO.

W pierwszym przypadku realizujemy nic innego jak wspomniany wcześniej „test usługi”. Neutralizujemy owszem wszystkie inne dźwięki i jeśli wykonujemy wiele czynności na komputerze, który służy nie tylko do odtwarzania muzyki, będzie to de facto uniemożliwienie odtwarzania dźwięku z czegokolwiek, niż ASIO, a raczej skonfigurowany na potrzeby ASIO odtwarzacz muzyki. Jest to opcja brutalna, ale z perspektywy ogólnie chęci uzyskania absolutnie niezmąconej pracy karty – korzystna i nawet powiedziałbym, że rekomendowana w sytuacji, gdy komputer ma pełnić rolę stricte dedykowanej maszyny do odsłuchu muzyki (serwer muzyczny bit-perfect). Usługę bez żadnego problemu możemy włączyć w każdej chwili i przywrócić działanie miksera systemowego.

W drugim przypadku wykorzystujemy fakt równoczesnej transmisji dźwięku analog-S/PDIF na sterownikach od 1.80 w dół – po prostu nie przełączamy urządzenia wyjściowego na S/PDIF OUT i pozostajemy przy „Głośniki” jako domyślnym źródle systemowym lub jakimkolwiek innym, jeśli jest w danej chwili w systemie obecne. Co prawda wyjścia analogowe (słuchawki/głośniki) będą nam grały jednocześnie z wyjściami cyfrowymi i to na głośności dosyć sporej, ale problem nie powinien mieć już miejsca plus nie blokować nas w sytuacji konieczności zastopowania odtwarzacza i szybkiego przełączenia się na przeglądarkę lub komunikator.

Ostatnim problemem jest natomiast kwestia stabilności zachowania się sterowników i konieczność pracy jakby w zgodzie z trybem DS. Zdarzyło mi się, że odtwarzanie muzyki w trybie ASIO i zamknięcie systemu spowodowało niemożność jego uruchomienia (sprawdzanie dysku C, automatyczne restartowanie, automatyczna konsola naprawcza). Konieczne było fizyczne usunięcie karty i uruchomienie komputera bez niej. Błąd jaki popełniłem polegał na tym, że po zakończeniu odsłuchu w trybie ASIO, nie przełączyłem się w Foobarze na tryb DS. Dopiero wtedy można byłoby spokojnie wszystko powyłączać i pozamykać. Przełączenie się na źródło DS jest wskazane również wtedy, gdy chcemy włączyć pauzę lub zakończyć słuchanie muzyki, aby odtworzyć np. jakiś inny materiał dźwiękowy/filmowy np. z serwisu YouTube. Jeśli tego nie zrobimy, usłyszymy artefakty. Powoduje to więc konieczność zarówno wyrobienia sobie nawyku, jak i podatność całego komputera na awarię, jeśli np. nagle zgaśnie prąd lub się zapomnimy. Należy wtedy nie panikować, tylko zgodnie z tym co napisałem usunąć fizycznie kartę, uruchomić ponownie komputer, zamknąć, wsadzić kartę na powrót w to samo gniazdo.

Natywne wsparcie dla DSD/DoP

Warto podkreślić, że nie ma żadnych przeciwwskazań za używaniem natywnego trybu ASIO w koniunkcji z dekoderem plików DSD w Foobarze do odsłuchów normalnej muzyki zapisanej w formacie PCM i DSD. Nie daje to żadnych korzyści jakościowych i nie powoduje jeszcze większej „lepszości” ponad „gołym” trybem ASIO, ale umożliwia jakiekolwiek odtworzenie, a raczej konwersję, plików DSD, jeśli takowe posiadamy.

Konwersja jest niezbędna, ponieważ w przypadku plików DSD, format ten nie jest przez kartę obsługiwany w formie czystej/natywnej i musi być przekonwertowany w locie do PCM. Winę za to ponosi układ CMI8788, który nie wspiera natywnie plików DSD. Jest to o tyle bolesne, że sam układ DAC na karcie wg dokumentacji Texas Instruments technicznie ma taką możliwość, a do tego mamy tu jeszcze dedykowany sterownik ASIO, który definitywnie dałby sobie z tym radę.

O DSD wspominam dlatego, że Foobar pozwala na skorzystanie z wersji 64-bitowej ASIO oraz trybu najwyższego priorytetu procesu odtwarzania. Jeśli posiadamy w ramach urządzeń dźwiękowych zainstalowanego tylko Xonara, proponuję, przynajmniej w początkowej fazie pracy z ASIO nie zaznaczać wykorzystania sterowników 64-bit i zostawić to pole domyślnie odznaczone. Zaznacz tylko tą drugą opcję.

Taka decyzja wynika z kilku powodów:

• Xonar jak pisałem nie wspiera dekodowania natywnych plików DSD i nie są nam potrzebne komponenty typu DSDTranscoder itd., które mogą wymagać w ogóle istnienia urządzenia z prawdziwą obsługą DSD do poprawnej pracy,
• na wolniejszych systemach sterowniki 32-bit mogą czasami generować mniej trzasków niż wersje 64-bit.

Pierwszy punkt jest o tyle ciekawy, że na początku miałem ogromne problemy z wywołaniem panelu komponentu DSDTranscoder i w ogóle jego aktywacji (komunikat o braku poprawnie zainstalowanego sterownika). Udało się to dopiero wówczas, jak sądziłem, gdy ASIO zostało przeze mnie przełączone w tryb 64-bit. Okazało się jednak, że sterownik zaczął działać wyłącznie dlatego, że włączyłem w międzyczasie Converto MK2, który to obsługę natywną DSD posiada. Ponieważ i tak będziemy korzystali z konwersji do PCM w trybie bit-perfect, DSDTranscoder jak pisałem nawet nie będzie na dobrą sprawę potrzebny. Tym samym wybór wersji bitowej sprowadza się generalnie raczej do stabilności działania i braku trzasków. Teoretycznie więcej korzyści przyniesie nam sterownik 32-bit, jeśli to właśnie na nim zdarzy się usłyszeć mniej trzasków lub wcale. Ale i nie musi. Jeśli nie notujemy niczego złego po przejściu na sterownik 64-bit, możemy na nim spokojnie pozostać.

Co się natomiast stanie, jeśli się uprzemy i spróbujemy zmusić kartę do dekodowania takiego materiału? Szybki test wykonany na prawdziwych plikach DSD daje takie rezultaty:

• DSD64: karta zwraca biały szum o lekkim zróżnicowaniu (wskazujący na sprzętowy błąd dekodowania)
• DSD128: Foobar zwraca błąd i brak obsługi częstotliwości
• DSD256: Foobar zwraca błąd i brak obsługi częstotliwości

Ponowny test wykonany z Converto MK2 via MUSBAudio ASIO Driver v4.12.0 (obsługa DSD64 i DSD128) aby stwierdzić czy problem leży w konfiguracji oprogramowania:

• DSD64: brak problemów, poprawne odtwarzanie (DSD+PCM)
• DSD128: brak problemów, poprawne odtwarzanie (DSD+PCM)
• DSD256: Foobar zwraca błąd dekodowania (wymagane jest użycie DSD Decodera z konwersją do DSD128)

Dlatego też opcja ta nie będzie nam przy Xonarze potrzebna. Do dekodowania materiału DSD w trybie PCM wystarczy jedynie odpowiednio skonfigurowana wtyczka foo_input_sacd.

Niestety więc jedyne, do czego możemy zmusić kartę podczas pracy z materiałem DSD, to jego konwersję w locie do PCM, definiując na sztywno próbkowanie docelowe na 176,4 kHz (maksymalna obsługa ze strony Xonara to 192 kHz, ale wtyczka SACD nie ma na swojej liście takiego trybu). Prawdopodobnie gdyby Xonar posiadał inny układ niż C-Media, tryb DSD64 byłby możliwy do wykorzystania i mieściłby się w specyfikacji oraz możliwościach samego DACa. Sugeruje to zwrócenie mi białego szumu zamiast zwykłego błędu dekodowania.

Tym samym jeśli posiadamy w swojej kolekcji albumy w DSD wymieszane z klasycznymi plikami PCM i chcemy odtwarzać za pośrednictwem Xonara wszystkie jednocześnie, bez zmieniania opcji lub przełączania trybów, można skorzystać z wtyczki DSD mapowanej na natywny sterownik ASIO w wygodny sposób obsługując oba formaty. Ograniczamy w ten sposób gęstość bitową materiału DSD i sprowadzamy go brutalnie w dół z bardzo dużych wartości, negując jakby jego sens, ale mimo wszystko wciąż poruszamy się jakby nie patrzeć w przestrzeni plików o bardzo dużej gęstości jako takiej i mamy w tym wszystkim natywny bit-perfect ze wszystkimi jego zaletami, które mogą okazać się bardzo korzystne ponad innym, znacznie gorzej napisanym sterownikiem ASIO nie dającym pełnego bit-perfectu i zachowującego się jak wrapper (to słowo za moment do nas jeszcze wróci i to parokrotnie). Także potraktować to należy jako swego rodzaju nagrodzę pocieszenia.

Foobar + WASAPI 3.3 (push/event)

Powszechnie uważa się tryb WASAPI za dosyć dobrą alternatywę dla sterowników ASIO. Jeśli korzystamy z Foobara, możliwe staje się zatem skorzystanie z wtyczki WASAPI (link do pobrania) w trybie Event lub Push.

WASAPI jest skrótem od Windows Audio Session API i jest niczym innym jak trybem wyłączności dla Foobara, pozwalając na uzyskanie dźwięku teoretycznie bit-perfect (opisywany jest jako „bit-exact”) oraz wytłumienie wszystkich pozostałych dźwięków. Tryb ten mapuje się na praktycznie wszystkie wyjścia/urządzenia audio, choć zdarza się, że nie ze wszystkimi chce działać.

Istnieje sporo debat który tryb jest lepszy (częściej rekomenduje się Event), ale oba mają tę zaletę, że są trybami na wyłączność i działają w tym względzie bardzo podobnie, jak ASIO. W razie czego można konfigurować je bardzo dokładnie i zmieniać ich wpływ na dźwięk w samym Foobarze w opcjach zaawansowanych.

Ponad natywnymi sterownikami ASIO, tryb WASAPI ma swoje zalety, odpowiednio w kontrze do poprzedniej listy problemów z poprzedniego akapitu:

• nie trzeba pauzować muzyki aby wprowadzać zmiany w jego ustawieniach
• nie ignoruje regulacji głośności systemu (może to być oznaka, że nie jest to tryb bit-perfect)
• nie ma problemów z odtwarzaniem ścieżek mono
• nie wymaga trybu administratora
• stosunkowo niewrażliwy na latencję procesów systemowych
• bezproblemowy po S/PDIF

Do tego nie wymaga konfigurowania po instalacji (poza zdefiniowaniem głębi bitowej) oraz wciąż nie powoduje przyrostu DPC Latency na procesie sterownika audio. Wydaje się więc idealnym rozwiązaniem na wymieniane wcześniej bolączki? I tak i nie. Mimo wszystko ma też swoje wady:

• teoretyczny bit-perfect (WASAPI mimo wszystko nie jest rozwiązaniem bit-perfect a wrapperem, sygnał HDCD nie jest przekazywany prawidłowo jako sygnał bit-perfect, wiele osób potwierdza też oblanie testu usługi Windows Audio)
• zastosowanie ograniczone wyłącznie do Foobara (w tym wypadku jest to tylko wtyczka fb2k-component) oraz innych programów które wybitnie tryb WASAPI wspierają
• skomplikowana konfiguracja z poziomu Foobara (jeśli będziemy chcieli już coś zmieniać)
• efektywna latencja na poziomie standardowego trybu DirectSound (co może nie jest złym wynikiem, ale to wciąż 2 razy więcej niż tryb natywny)
• wciąż pewna szczątkowa wrażliwość na wysoką latencję kluczowych elementów systemu operacyjnego
• generowanie bardzo długiej i mało czytelnej listy urządzeń, duplikującej się z wtyczką DSD
• nie ze wszystkimi urządzeniami jest możliwa bezproblemowa współpraca (np. Cipher v2)

Choć więc jak widać jest to bardzo ciekawa opcja do wykorzystania w praktyce, zwłaszcza na sprzęcie nie posiadającym swoich własnych sterowników ASIO, to jednak nadal będzie to tylko wyłącznościowy renderer dźwięku z użyteczną możliwością mapowania do urządzeń niededykowanych.

Jeśli tylko jest taka możliwość, rekomenduję nadal trzymać się dedykowanych sterowników ASIO i tyczy się to nie tyle Xonarów, co w ogóle wszystkich urządzeń audio które mogą pracować np. po złączu USB. Oczywiście wszystko finalnie zależy od tego jaki to sprzęt, jakie sterowniki, jak bardzo do wszystkiego przyłożył się producent itd.

Pewną alternatywą dla WASAPI może być Kernel Streaming, ale wtyczka (właściwie jedna biblioteka DLL) jest bardzo stara (bodajże 2006 rok), strasznie laguje na regulacji głośności, generuje artefakty przy przeskakiwaniu do punktu utworu na jego osi czasu i nawet sama ostrzega, że jest wtyczką eksperymentalną, mogącą doprowadzić do destabilizacji pracy systemu/sprzętu. Dlatego też jeśli już to raczej zalecałbym trzymać się WASAPI jako bardziej sprawdzonego i pewnego rozwiązania.

Jeśli zaś chcesz korzystać z WASAPI jako API w ogóle, ale mieć przy tym możliwość pracy z wieloma strumieniami audio, wypróbuj wtyczkę WASAPI-Shared.

ASIO4ALL

Druga opcja obok WASAPI/KS to instalacja ASIO4ALL (link do pobrania ze strony producenta). Są to sterowniki uniwersalne, od pewnego czasu nieaktualizowane co prawda, ale działające całkiem dobrze na Xonarach. Choć teoretycznie ASIO4ALL również powinny być sterownikami bit-perfect, tak samo jak przy WASAPI jest to co najmniej dyskusyjne. Według mojej najlepszej wiedzy, ASIO4ALL to również tylko tzw. „wrapper” dla sterowników audio Windows który udostępnia interfejs audio poprzez ASIO i jest tylko jego namiastką.

Zaletą ASIO4ALL jest przede wszystkim uniwersalność zastosowań jako wspomniany wrapper, dający bardziej rozbudowane możliwości pracy w trybie wyłączności. Wiele pozytywnych cech jest tu tożsamych z tymi, jakie notowałem wyżej przy WASAPI, jak chociażby fakt, że po instalacji nie trzeba nic konfigurować, choć sterowniki same w sobie dają takie możliwości i to spore oraz mają wygodny dostęp do w miarę estetycznego panelu konfiguracyjnego. Może to być więc dobra odpowiedź na problemy z buforami, problemy sprzętowe, a dzięki bardzo rozbudowanej informacji o strumieniach wejściowych i wyjściowych może być także źródłem cennych informacji o częstotliwościach i próbkowaniu.

W zakresie instalacji i konfiguracji, jest to na tyle myślę proste, że nie trzeba specjalnie się rozwodzić. Dlatego krótko i konkretnie: na początek wyłącz dymki komunikatów informujące o danych strumieniowych za każdym razem gdy rozpoczyna się odtwarzanie pliku. Ustawienia znajdziesz od razu na samym dymku (ikona koła zębatego). Te same dane znajdziesz po najechaniu na ikonkę ASIO4ALL w zasobniku systemowym, więc wyskakujące co rusz „rozpraszaczki” nie są potrzebne.

Jeśli i na ASIO4ALL notujesz wciąż sporadyczne problemy z trzaskami, możesz przełączyć się w tryb zaawansowany i zwiększyć Kernel Buffers z 2 na 3. Zwiększenie bufora winno odbywać się jedynie na słabszych maszynach. Standardowo wszystkie bufory warto trzymać albo z jak najniższymi wartościami, albo na ustawieniach domyślnych.

Niestety także i tutaj będziemy mieli do czynienia z ograniczeniami oraz problemami. Do tych najważniejszych zaliczyłbym:

• jak pisałem teoretyczny bit-perfect (ponownie, w praktyce jest to tylko wrapper, nie w 100% dedykowany sterownik czy mechanizm bit-perfect)
• nie na wszystkich urządzeniach działa lub nie działa w ten sam sposób
• słabo działający bufor sprzętowy (10 ms generuje tonę artefaktów, maksymalne 20 ms nadal nie maskuje trzasków)
• dwukrotnie większa efektywna latencja od standardowego trybu DirectSound (średnio ok. 250 µs)
• bardzo duża latencja ze strony samego sterownika (cmudaxp.sys, średnio ok. 500-900 µs)
• wciąż wykazują pewną szczątkową wrażliwość na wysoką latencję kluczowych elementów systemu operacyjnego

O ile sterowniki ASIO4ALL także mają pewien wpływ na dźwięk, tak samo jak WASAPI, to wpływ ten wynika w tym wypadku przede wszystkim z samego trybu wyłączności i obejścia systemowego miksera dźwięku wraz z całą kaskadą dowiązań strumieni audio. Co byśmy jednak nie uczynili, nie będzie to nic więcej niż pewna proteza w zastępstwie sterowników natywnych i ASIO4ALL nie zachowują się identycznie jak sterowniki natywne.

Nadal odnotujemy tu wspomnianą wyłączność oraz obniżone THD+N (w zasadzie to THD jest relatywnie najniższe względem natywnego ASIO oraz DS), mamy kontrolę nad głośnością systemową (znów: sugestia że może nie być to tryb bezpośredni), ale w zamian otrzymujemy wyraźny wzrost latencji względem natywnego ASIO zarówno w ramach wartości bieżących, jak i procesu cmudaxp.sys (czyli sterownika C-Media zarządzającego kartą).

Do tego pasmo przenoszenia praktycznie nie ulega zmianie (pomiarowo jest nawet minimalnie gorzej niż w trybie DS), zaś fluktuacja w punkcie 17,88 kHz zostaje nietknięta. Mogę tylko podejrzewać, że z WASAPI pomiarowo wypadłoby to podobnie, ale nie jestem niestety w stanie tego zmierzyć, jak również tego, czy z ASIO4ALL nie ma miejsca tu jakaś dziwna interferencja z samym ASUSem, tudzież średnio szczęśliwe dopasowanie jednego do drugiego, a co sugeruje też poniekąd wysoka latencja. Także niestety jeśli ktoś liczył na sensowną alternatywę dla natywnych sterowników ASIO (tak jak ja), to obawiam się, że w przypadku Xonara nie będzie do końca zadowolony.

Chciałbym powiedzieć, że być może z innymi urządzeniami będzie więcej szczęścia, ale także i tu bywa to różnie i nie ze wszystkimi urządzeniami ASIO4ALL sprawdza się w dokładnie ten sam sposób. Przykładowo:

• na STX wszystko działa idealnie (minus uwagi powyżej)
• na ST odnotowuję wyraźnie większy wzrost latencji sterownika
• na DragonFly Cobalt wszystko działa idealnie, choć czuć nieco mniejszą responsywność (czas do rozpoczęcia odtwarzania, przeskakiwanie na inny fragment utworu itd.)
• na Converto MK2 wszystko działa, choć responsywność utworów zauważalnie maleje (nowe odtwarzanie, seek bar itd.)
• na LCD-i3 z Cipherem v2 słychać mocne pofragmentowanie dźwięku i artefakty, ta kombinacja jest nieużywalna

Znów więc – testy i sprawdzanie co i jak będzie grało najlepiej lub w ogóle. Nie bez powodu opisałem wszystkie trzy sposoby odtwarzania muzyki w takiej kolejności. Niemniej, tak jak WASAPI, jako wrapper ASIO4ALL jest nadal warte spróbowania.

Co będzie z tego najlepsze?

Dobre pytanie. Tu już niestety każdy musi sam zdecydować w praktyce. Pomogą w tym proste zapytania do samego siebie:

• Z którego trybu korzysta Ci się najwygodniej?
• Na którym trybie czujesz najlepszą jakość dźwięku?
• Który tryb umożliwia Ci odsłuch bez trzasków i problemów?
• Czy jesteś w stanie poświęcić jakość dźwięku dla wygody, czy na odwrót?

Najwygodniejszy jest oczywiście tryb DirectSound. Wszystkie programy są w nim odtwarzane jednocześnie, na ogół bardzo wygodnie, nic nie trzeba przełączać, niespecjalnie trzeba coś konfigurować. Latencja jest utrzymywana na akceptowalnym względnie poziomie. Jakość dźwięku… no właśnie, tu już zaczynają się schody. O ile dzięki optymalizacjom jakie wcześniej wymieniłem praca z domyślnym trybem DirectSound powinna być przyjemniejsza, bardziej niezawodna i cechować się lepszą jakością dźwięku, ostatecznie wszystkie laury wylądowały na piersi natywnych sterowników ASIO, mimo że ich ustawienie metodą prób i błędów oraz przetestowanie w różnych warunkach zajęło mi mnóstwo czasu.

W moim przypadku odpowiedzi na powyższe pytania były odpowiednio następujące:

• DirectSound
• ASIO natywne
• po konfiguracji właściwie wszystkie
• na odwrót, jakość pierwsza, wygoda druga

Dlatego wybór padł na natywne ASIO. Przesłuchałem mnóstwo albumów przez czas pisania tego artykułu i wykonałem multum porównań z Converto MK2 w roli zarówno porównawczego DACa, jak i odbiornika sygnału cyfrowego z STXa skonfigurowanego wybitnie pod pracę z natywnym ASIO. Byłem naprawdę pod wrażeniem jak świetnie Essence STX wypadał w roli transportu cyfrowego bit-perfect. Oczywiście wyjście słuchawkowe, choć także będące ogromnym beneficjentem i grające wyraźnie lepiej niż przed rozpoczęciem pracy nad artykułem, nie prezentuje takiej samej jakości jak DAC Pathosa za 7400 zł. Ale to już jest wymaganie niemożliwego. Tym niemniej mam jeszcze trochę możliwości w zakresie zabawy OPA, ponieważ MUSES8820 mimo wszystko nie są szczytem możliwości do załadowania tu na pokład (o tym zresztą rozpiszę się na koniec tekstu).

Jeśli nadal masz problem z wyborem odpowiedniej metody, po prostu spróbuj wszystkiego, a w szczególności z takich powodów:

• DirectSound – jeśli chcesz po prostu słuchać muzyki i oglądać filmy, etc. Maksymalna wygoda jednym słowem. Wykorzystasz optymalizacje bitowe i brak kompensacji o których wcześniej mówiliśmy.
• WASAPI – jeśli chcesz pracować na odtwarzaczu w trybie wyłączności i bardziej ambitnie podejść do tematu konfiguracji za pośrednictwem Foobara.
• ASIO4ALL – jeśli za cenę największej latencji chcesz pracować w trybie wyłączności i z relatywnie najniższym THD, a korzystanie z innych trybów jest z jakiegoś powodu uciążliwe lub niemożliwe
• ASIO natywne – jeśli na pierwszym miejscu stawiasz absolutnie największą jakość dźwięku i chcesz mieć prawdziwy tryb bit-perfect

Osobiście, jeśli nie miałbym możliwości komfortowego korzystania ze sterowników natywnych, osobiście pracowałbym na ASIO4ALL jeśli nie generowałoby zbyt wysokiej latencji (o niej poniżej). Jeśli generuje, WASAPI. W ostateczności pozostałbym przy zwykłym trybie DS lub wypróbował WASAPI-Shared. W takiej kolejności można też spróbować testów u siebie.

Optymalizacje systemu i PC pod kątem latencji

1. zainstaluj LatencyMon aby kontrolować opóźnienia sprzętu i oprogramowania w czasie rzeczywistym
2. zaktualizuj wszystkie kluczowe sterowniki, zwłaszcza od WiFi/LAN, oraz BIOS płyty
3. wyłącz nieużywane urządzenia systemowe mogące rezerwować niepotrzebnie zasoby komputera
4. zdemontuj karty rozszerzeń, które notują wysoką latencję (o ile są niepotrzebne i możesz się bez nich obejść)
5. zredukuj szanse na współdzielenie przerwań (IRQ) z Xonarem wybierając te gniazda, w których zasoby są współdzielone w jak najmniejszym stopniu lub ustawiając przerwania na sztywno
6. skorzystaj z TCP Optimizera, aby zoptymalizować i usprawnić komunikację sieciową zmniejszając ryzyko interferencji z kartą
7. jeśli nie dbasz o pobór prądu i temperatury, przejdź w tryb wysokiej wydajności.
8. przetestuj komputer z kompletnie wyłączoną funkcją HPET oraz wpisami blokującymi jej wykorzystanie

Jak pisałem latencja będzie naszym głównym wrogiem i to właśnie z nadmiernej latencji wynika sporo problemów. Nawet jeśli nie notujemy jako takich kłopotów z kartą, trzymana jak najniżej latencja to szybkość, responsywność i generalnie brak niespodzianek. Latencja to nic innego jak opóźnienia, czas jaki jest potrzebny określonym procesom lub sterownikom w zakresie dostępu do zasobów sprzętowych komputera, głównie cykli procesora. Im mniejsze wartości, tym mniejsze ryzyko trzasków lub przerw w odtwarzaniu muzyki.

Aby dowiedzieć się jakie procesy mają największą latencję i czy przypadkiem któreś z nich nie dotyczą Xonara, rekomenduję zainstalować darmowy program LatencyMon (link do katalogu pobierania producenta) i zweryfikować uzyskane wartości. Jeśli mieszczą się w granicach do 300 mikrosekund – jest bardzo dobrze. Opóźnienia w przedziale 300-500 µs są jakkolwiek jeszcze akceptowalne. Powyżej 500 jest źle, a powyżej 1000 jest już tragicznie.

W moim przypadku problem pojawia się na drugim komputerze, na którym notowałem niestety artefakty podczas korzystania z Essence ST:

Jest to oczywiście sytuacja negatywna, ale z perspektywy tego artykułu korzystna, jako że nie teoretyzuję, a faktycznie opieram się na empirycznych doświadczeniach. Winowajcą jest tam jednak nie Xonar czy jego sterowniki, ale sam system operacyjny. Po to właśnie potrzeby był LatencyMon, aby móc to ustalić.

Jeśli wysoką latencję notujesz na procesie cmudaxp.sys, to niestety dotyczy to sterowników C-Medii i  samego Xonara. W moim wypadku problem rodzi się u źródła, bo na ntoskrnl.exe. Nie jest to problem związany z mocą obliczeniową komputera (a przynajmniej nie do pewnego stopnia), bo choć procesor jest tam leciwy (Phenom II X2 570) i ogólnie cały komputer jest złożony z części dawno już odłożonych na półkę (acz wciąż przydatnych i dających się zdumiewająco dobrze na dzień dzisiejszy zagospodarować), to problem jest dosyć znany i związany bezpośrednio z systemem operacyjnym, tj. jego producentem i brakiem umiejętności rozwiązania problemu. Użytkownicy nawet na i9 mają z tym bolączki, a więc sporadycznie i skokowo notowaną bardzo wysoką latencją procesów systemowych, takich jak właśnie ntoskrnl.exe, wdf01000.sys itd. Jest to szeroko opisywane na forach od kompilacji 1903.

Jednego uniwersalnego rozwiązania na te kwestie jeszcze nikt jak widziałem nie przedstawił, a jeśli już coś komuś pomagało, to bardzo losowe rzeczy, wliczając w to instalację starej kompilacji i aktualizowanie jej do nowszych zamiast bezpośredniej instalacji wprost do kompilacji docelowej. Dlatego powinniśmy skupić się na palecie czynności polegających na zredukowaniu jak największej liczby elementów, które mogą w jakikolwiek sposób nam przeszkadzać podczas słuchania muzyki i wpływać na efekt szarpania, trzasków czy chwilowego zapętlania się dźwięku tak, jakby na ułamek sekundy się zawiesił.

Często problemy są złożone i nie mają jednego konkretnego umocowania. Niestety ze względu na ogromną rozpiętość płyt głównych, konfiguracji sprzętowych, programowych, systemowych, ustawień BIOS, sterowników oraz innych zmiennych, nie sposób jest wszystkie opcje udokumentować czy nawet wskazać te, które na 100% spowodują ograniczenie lub rozwiązanie występowania problemu.

W temacie przerwań natomiast, w razie czego można posiłkować się tym artykułem.

Przed rozpoczęciem jakiejkolwiek zabawy z ręcznymi zmianami przerwań i ich typem, radzę zrobić backup danych oraz punkt przywracania, ponieważ nie wszystkie urządzenia mogą ucieszyć się na myśl, że zostaną przez nas przełączone w tryb MSI (Message-Signaled Interupts). To właśnie ten tryb może pozwolić na zwolnienie cennych zasobów dla Xonara. Aczkolwiek nie wolno przełączać samych kart w ten tryb – system się już nie uruchomi i będzie konieczne ratowanie się konsolą odzyskiwania (F8). Zabawa przerwaniami ma więc cel bardziej ku zwolnieniu czego tylko się da i zredukowaniu ryzyka konfliktu z Xonarem, niż Xonara z czymś innym.

Najczęstszym i najprostszym sposobem na redukcję konfliktów przerwań i alokowania wspólnie zasobów jest po prostu utrzymanie jak najmniejszej liczby urządzeń na magistralach PCI/PCIe oraz wybieranie takich slotów, które nie mają nadmiernej ilości przerwań współdzielonych. Każde gniazdo może bowiem pracować pod różnymi zasobami zarządzanymi w różny sposób. Jeśli na danym przerwaniu pracuje sam Xonar, jest to sytuacja idealna. Jeśli mamy tam zaś 2 lub więcej urządzeń, może to powodować problemy.

Bardzo często problemem takim jest interferencja z interfejsami sieciowymi. Nie chodzi tu o wpływ zakłóceń, ale o sam fakt jestestwa w systemie. Mocny ruch sieciowy, praca pod obciążeniem, różne standardy komunikacyjne takie jak np. Bluetooth, mogą powodować zwiększoną latencję i alokację zasobów, które przy fakcie współdzielenia mogą mocno uderzyć w płynność odtwarzania dźwięku. Używam w celu zniwelowania takiego ryzyka darmowej aplikacji TCP Optimizer (link do pobrania ze strony producenta), która jednym kliknięciem w zasadzie aktualizuje wpisy rejestrów i zasady działania sieci.

Warto również w ramach testów pobawić się opcją High Precision Event Timer (HPET). Istnieje kilka sytuacji w których różnych użytkownikom pomagało a to włączenie, a to wyłączenie tej funkcji, jednak w większości spotyka się przypadki, gdzie wyłączenie tejże funkcji w BIOSie oraz systemie operacyjnym skutkowało pozytywnymi rezultatami. W BIOSie oczywiście trzeba się tejże opcji doszukać i nie jest nawet powiedziane, że płyta główna będzie posiadała takową opcję na liście. Jeśli jej nie ma, to znaczy to najprawdopodobniej, że płyta główna nie wspiera sprzętowego zegara wysokiej precyzji. Obojętnie czy jest ona widoczna w BIOSie czy nie, staramy się ją wyłączyć, a następnie załadować system, uruchomić wiersz poleceń (cmd, nie wykonamy tego przez Power Shell) z poziomu administratora i zaaplikować 3 poniższe komendy:

bcdedit /set useplatformclock false

bcdedit /set tscsyncpolicy legacy

bcdedit /set disabledynamictick no

Każda komenda powinna zakończyć się informacją o pomyślnym wykonaniu operacji. Po aplikacji powyższych komend należy uruchomić ponownie komputer. Zauważyłem na jednej z maszyn poprawę latencji po ich zastosowaniu oraz wyłączeniu HPET w BIOSie płyty, a jak pisałem wcześniej walczymy krok po kroku o jak najlepsze wyniki całościowe, więc warto spróbować.

Wymiana wzmacniaczy operacyjnych

1. rozważ wymianę wzmacniaczy operacyjnych jeśli chcesz ostatecznie ponieść jakość dźwięku i wprowadzić subtelne zmiany tonalności
2. wybieraj takie OPA, które nie powodują konieczności ściągnięcia osłony EMI i zwiększenia podatności na zakłócenia
3. unikaj ekstenderów OPA DIL8/DIP8, ponieważ mogą powodować mocne przebicia i wzbudzanie się układów
4. unikaj układów niewiadomego pochodzenia kupowanych z niesprawdzonych źródeł
5. zawsze upewnij się że poprawnie i bezpiecznie aplikujesz wzmacniacz operacyjny
6. wzmacniacze na sekcji I/V zawsze trzymaj sparowane i pochodzące z jednej serii

Wymiana wzmacniaczy operacyjnych to najdroższa operacja do przeprowadzenia w ramach tych kart, ale też dająca najwięcej satysfakcji i słyszalnej jakości. Swego czasu pisałem prosty artykuł na ten temat na łamach bloga, ale miało to miejsce 10 lat temu i przydałoby się jego odświeżenie, a raczej powrót do tej tematyki przy tejże okazji.

Przede wszystkim stosujmy tu trzy zasady:

1. najpierw posłuchaj karty w stanie fabrycznym, tak jak jest
2. nie podejmuj się wymiany elektroniki bez podstawowych narzędzi, zabezpieczenia przeciwko wyładowaniom elektrostatycznym (ESD) oraz elementarnej wiedzy co i jak musisz wymienić
3. zamawiaj układy mając absolutną pewność, że są one w 100% kompatybilne z Xonarem Essence ST/STX

Najczęściej ogranicza się to sprawdzenia parametrów Voltage Swing oraz tego, czy układ jest wzmacniaczem operacyjnym podwójnym, bipolarnym, z nóżkami DIL8 (płaskimi). Oczywiście parametrów jest znacznie więcej, toteż najlepiej ograniczać się do układów rekomendowanych na forach dla entuzjastów i potwierdzających we wiarygodny sposób, że dany układ faktycznie dobrze się sprawuje na karcie, nie przegrzewa się i nie wzbudza, a jego użytkownik ma go na karcie od dłuższego czasu. Co prawda ta ostatnia rzecz nie musi o niczym przesądzać, ale testy długofalowe również są cenne i nawet jeśli wszystko od startu działa, to nie jest powiedziane, że kłopoty nie zaczną się później. Przykładowo niektóre karty SC808 po dołożeniu stolika w miejsce niewymiennego LM4562 i żonglerce układami potrafiły przeżyć potem już tylko parę miesięcy. Zależy też myślę jaki kto układ tam stosował, ale nie bez powodu producent zainstalował tam kość na stałe. Znów: bycie mądrzejszym od inżynierów projektujących te karty. Pytanie, czy gdyby użytkownik wiedział, że zabawa w małego lutownika spowoduje awarię karty w przeciągu pół roku, zdecydowałby się na taki krok? Raczej wątpię.

Tak czy inaczej, na kartach takich jak SC808, ale właśnie i na Xonarach, powinno stosować się układy przede wszystkim podwójne. Stosowanie układów pojedynczych na Xonarach jest możliwe, ale tylko i wyłącznie pod warunkiem, że układy znajdują się na specjalnym stoliku i są lutowane parami, tworząc w efekcie układ podwójny.

Xonary mają na pokładzie 3 kości wymienne: dwie z nich znajdujące się jedna przy drugiej to układy należące do sekcji I/V (oznaczone są na PCB symbolami ZU14 i ZU16). Samotna kość znajdująca się bliżej wyjść słuchawkowych to układ buforujący (ZU15). Essence są tak skonstruowane, że wykorzystywane są różne kości w zależności od wybranego toru audio na samej karcie:

• dla słuchawek wykorzystywana jest para kości z sekcji I/V (ZU14+ZU16) oraz niewymienny wzmacniacz TPA6120A2 (U30),
• dla RCA wykorzystywana jest ponownie para kości z sekcji I/V (ZU14+ZU16), ale zamiast TPA swój udział w torze dźwiękowym ma kość buforująca (ZU15).

Układy i ich oznaczenia widać dokładnie na poniższym zdjęciu:

Powoduje to, że Xonary Essence ST/STX teoretycznie lepiej sprawdzają się w roli źródeł RCA dla dalszych urządzeń niż jako karty nastawione stricte na słuchawki. W praktyce jednak, o ile układ TPA faktycznie przeszkadza trochę w uzyskaniu pełnego potencjału dźwiękowego z faktu wymienności kości OPA, o tyle jest to układ sprawdzony, stabilny i bezpieczny, przez co odpadają nam niektóre ryzyka, jakie niosły ze sobą SC808 oraz ich modyfikacje (może w szczególności właśnie te ostatnie).

1. RCA OUT – Jeśli interesuje nas tylko tor RCA, wymienić musimy wszystkie trzy kości, przy czym sekcja I/V musi mieć kości sparowane (identyczne) i najlepiej (najbezpieczniej) jeśli obie będą pochodziły z jednej serii (oznaczenia numeryczne na kościach muszą być zgodne, w moim przypadku obie fabryczne kości są z serii K009B). Bufor może być już dowolną inną kością (na zdjęciu jest to układ LM4562NA, a więc zupełnie inny niż fabryczne JRC2114D), ale o ile przy buforze może mieć miejsce dowolność wyboru, nie wolno mieszać ze sobą różnych kości na gniazdach I/V.
2. HP OUT – Jeśli interesuje nas tylko tor słuchawkowy, odpada nam kość buforująca i możemy ograniczyć wydatki inwestując jedynie w sekcję I/V. Obostrzenia będą tu identyczne jak powyżej – obie kości muszą być sparowane i najlepiej pochodzić z jednej serii. Nie ma znaczenia że pochodzą z tego samego źródła (od tego samego sprzedawcy), ponieważ on także może mieć wymieszane serie między sobą.
3. S/PDIF OUT – Jeśli interesuje nas tylko tor S/PDIF, wymiana kości OPA nie jest wymagana. S/PDIF oraz mikrofon pracują na wlutowanych na stałe układach, których nie wymienimy inaczej jak poprzez trwałą ingerencję w kartę. Karta może spokojnie pracować na układach fabrycznych, a zaoszczędzone pieniądze możemy przeznaczyć w lepsze kable, dodatkowe akcesoria albo po prostu zakup lepszych słuchawek lub głośników.

Przy wymianie kości należy zawsze patrzyć na polaryzację, wskazywaną kropką lub wcięciem na kości, które muszą zgadzać się orientacją z wcięciem w stolikach DIL8. Odwrócenie kości lub nieprawidłowa aplikacja i wystawanie niektórych nóżek może skończyć się całkowitym spaleniem karty lub nawet pożarem, a w najlepszym wypadku spaleniem samego wzmacniacza operacyjnego. 

Podczas szukania kości OPA wybieraj takie, których aplikacja nie będzie wiązała się z koniecznością zdjęcia osłony EMI. Tyczy się to zwłaszcza wzmacniaczy dyskretnych. Układy takie owszem, mają bardzo duży potencjał dźwiękowy i z reguły grają lepiej niż małe układy mieszczące się pod osłoną, ale w wielu sytuacjach eksponują przez to elektronikę karty i siebie również na szkodliwe działanie pola elektromagnetycznego.

Osobiście przez lata stosowania różnych wzmacniaczy operacyjnych finalnie bardzo ceniłem sobie takie, które grają świetnie, a jednak nie powodują problemów i zmartwień lub wspomnianego demontowania jakichś części karty. Tyczy się to nie tylko Xonarów, ale też i SC808.

Jakie układy wybrać – tutaj już trzeba zdecydować samemu. Osobiście bardzo ceniłem sobie SS V5i, natomiast w testach i na co dzień używam duetu oryginalnych, zamawianych jeszcze w Japonii MUSES 8820. Należy jedynie uważać mocno na podróbki układów scalonych, zarówno MUSES, jak i innych.

Moje własne podejście jest następujące: jeśli wzmacniacz operacyjny jest tak duży, że nie mieści się na karcie lub wymaga stosowania ekstenderów, skreślam go z listy rzeczy pożądanych przeze mnie do finalnego zamontowania. Choćby grał najlepiej na świecie, zbyt wiele złych rzeczy już mi się zdarzyło usłyszeć po zastosowaniu ekstenderów, aby stosować je jako regularne elementy używane na co dzień w moich kartach. A historie niedziałających lub palących się układów dyskretnych na np. STX II jedynie potwierdzają słuszność obranej przeze mnie drogi.

Sprawdzone kombinacje OPA

Choć pisałem o tym wiele razy, generalnie sprawdzały mi się na przestrzeni lat określone kombinacje wzmacniaczy operacyjnych, z których wylistować mogę przede wszystkim trzy połączenia:

1. 2x MUSES 8820 + 1x LM4562NA, obszernie opisane w recenzji Essence STX
2. 3x Burson SS V5i
3. 2x Burson SS V5 + SIL 994Enh

Ostatnie połączenie pracowało u mnie bardzo długo i było bardzo dobrze brzmiącym, choć miało swoje obostrzenia – bardzo mocno grzejący się układ SILa oraz czynienie z karty konstrukcji 2,5-slotowej. Nie można było oczywiście zamontować też osłonki EMI, a cały zestaw sumarycznie podchodził pod 1000 zł, przekraczając jakiekolwiek granice zdrowego rozsądku względem tej karty. Karta wymagała też dla bezpieczeństwa aktywnego chłodzenia oraz obudowy gwarantującej należytą cyrkulację w miejscu jej położenia (bardzo dobrze sprawdzała się w tym leciwa Fractal Design Core 3000).

Połączenie drugie bardzo mocno chwaliłem na SC808 i choć na ST/STX będzie taka kombinacja nadal ograniczana w pewnym zakresie przez sam DAC oraz niewymiennego TPA6120A2, wciąż, przynajmniej duet V5i, ma spory sens ze względu na wysoką jakość dźwięku uzyskiwaną na wyjściu. Będzie z jednej strony neutralnie od TPA, ale z drugiej z muzykalnym i jakościowym sznytem od samych kości na sekcji I/V. Idzie to poniekąd w kierunku Soloista mówiąc z pamięci, a więc pojawia się wypełnienie i relaks. Bez problemu zamontujemy kości na karcie oraz później na wszystko wciąż wejdzie pokrywa EMI. Dlatego uważam taką kombinację, ew. z jednym LM4562 lub nawet fabrycznym LM6172/LM4562, za najbardziej rozsądną w temacie stosunku wydatków do jakości dźwięku. Alternatywnie powinny sprawdzić się tu układy MUSES02 jak przypuszczam, a do tego wyjdą finalnie taniej i jeszcze bardziej rozsądnie.

Połączenie pierwsze jest natomiast wykorzystywane przeze mnie w STX i jeszcze raz je opisując, jest to nic innego jak uproszczone wydanie Aune S6, idące dokładnie w tym samym kierunku dźwiękowym, ale jedynie z mniejszą dynamiką oraz sceną, a co zresztą jest dosyć zrozumiałe. Różnica w cenie jednak, jeśli nie liczyć znacznie większych możliwości mocowych i wyjść BAL, była ostatecznie tym, co po części zadecydowało o sprzedaży Aune na rzecz STX. Skoro i tak najczęściej pracowałem na Essence i który to uruchamiał się wraz z PC, nie widziałem specjalnego sensu egzystencji tego urządzenia, zaś być może komuś moja S6 byłaby bardziej przydatna i pełniłaby rolę głównego elementu toru, a nie tylko dodatku lub nadmiarowego klocka testowego (a co też się potem ziściło i trwa do dziś).

Na MUSESach brzmienie jest więc, także po wyjściu słuchawkowym, bardzo neutralne, rzetelne, dokładne i mające lepszą jakość niż na kościach fabrycznych, wyrównując się na basie i sopranie. Nie ma już tej „tendencji do techniczności” w basie i „tendencji do jasności” w sopranie. Dźwięk przestaje być właśnie taki „tendencyjny” a staje się bardziej profesjonalny. Odsłuchowo ma to duże zalety przy słuchawkach cieplejszych i lubiących bardziej neutralne tory.

Przy czym konieczne jest nakreślenie, że dochodziły do mnie sygnały od innych użytkowników o innym zachowaniu się kości MUSES niż czyniły to one w moich własnych doświadczeniach. Trudno powiedzieć czy jest to spowodowane pechem i trafieniem na podróbki, czy różnicami w seriach między tymi układami (swoje 8820 mam od wielu lat), czy może po prostu dziwnym zbiegiem okoliczności, że parę różnych osób o różnym sprzęcie odbiera te kości podobnie i inaczej niż ja. Własne odsłuchy weryfikowałem swego czasu z innymi osobami, słuchającymi również tych samych nawet kości, i wszystko było w porządku. Trzeba byłoby po prostu poświęcić pieniądze i kupić dodatkową parę 8820 celem testów porównawczych, a na to w tej chwili szkoda mi przyznam czasu i środków, nawet jeśli to groszowe sprawy. Niemniej warto mieć to na uwadze.

Niektóre układy mam opisane na blogu w formie recenzji (linki powyżej), inne zaś ujęte zbiorczo w bardzo starym artykule o przykładowych wzmacniaczach operacyjnych na kartach Essence STX. Zachęcam więc do lektury.

Oczywiście można testować sobie także inne kombinacje układów, byle tylko mieściły się w specyfikacji urządzenia i były poprawnie aplikowane w stoliki. Powyżej opisałem tylko przykładowe kombinacje które posiadałem lub posiadam i które sprawdziły się w moich zastosowaniach najbardziej na przestrzeni lat. Bez żadnego problemu można testować także i inne układy, o ile będą zgodne ze specyfikacją karty. A jak zagra na niej układ X lub Y? Tego już nie wiem. Od tego są testy samodzielne i własne uszy, zwłaszcza przez pryzmat multum słuchawek i możliwych kombinacji OPA dających zawsze inne rezultaty. Ponownie wypada przypomnieć, że w razie czego wszelkie modyfikacje wprowadzane na kartach wykonuje się na własną odpowiedzialność.

Zapewne kusić będzie też opcja wykorzystania toru RCA jako wyjścia słuchawkowego, aby zyskać możliwość wykorzystania wszystkich trzech układów wymiennych i obejścia TPA6120A2. Z odpowiednią przejściówką jest to możliwe i wygląda następująco:

Musimy jednak pamiętać, że zetkniemy się wtedy z dużą impedancją wyjściową, więc warto aby słuchawki miały trochę więcej Ohm, ale też i z brakiem jednoznacznego wzmocnienia lub sterowania tymże wzmocnieniem z poziomu karty. Powstaje trochę paradoks, ale z wieloma słuchawkami takie rozwiązanie mimo wszystko obiecująco nawet się sprawuje.

Temat OPAMPów jest w każdym razie bardzo rozległy i mogący wydatnie zwiększyć objętość tego artykułu, a jeśli uwzględnić różnice w aplikacji na różnorodnych platformach, wręcz zwielokrotnić jego i tak spory rozmiar. Trzeba więc pamiętać, że wymiana wzmacniaczy operacyjnych to tak naprawdę eksperymentowanie w pojedynkę, na własnych uszach i własnym sprzęcie, uzyskując unikatowe często doświadczenia o różnym stopniu przekładalności na inne osoby i ich z kolei własne doświadczenia. Nie ma jednej skutecznej receptury i kombinacji, zawsze coś będzie komuś grało świetnie, a innemu źle. Dodatkowe informacje, a także uwarunkowania historyczne czy praktyczne porady jak wymieniać wzmacniacze operacyjne, można znaleźć w obszernym tzw. małym poradniku na temat wzmacniaczy operacyjnych.

Redukcja podatności na szumy, buczenie i przebicia

1. trzymaj cały czas zamontowaną osłonę EMI
2. unikaj podłączania słuchawek/mikrofonu pod panel przedni obudowy podpięty do Xonara jeśli notujesz przebicia i piski
3. stosuj dobrej jakości przedłużacze kablowe, jeśli nie masz wyjścia i chcesz mieć wszystko pod ręką
4. unikaj bliskiego sąsiedztwa karty graficznej oraz innych urządzeń powodujących duże zakłócenia elektromagnetyczne
5. rozważ dobrej jakości przedłużacz MOLEX o mniejszej podatności na zakłócenia
6. korzystaj z zabezpieczonej i uziemionej sieci elektrycznej
7. zastosuj filtr rezystancyjny na wyjściu słuchawkowym lub filtr dolnoprzepustowy aby jeszcze przy tym dodatkowo ocieplić nieco dźwięk i zabezpieczyć się przed tzw. „piskiem śmierci”

Szumy i przebicia są bardzo nieprzyjemną i niewdzięczną materią, mogącą mieć bardzo różne źródła. Co do zasady jest to interferencja elektromagnetyczna między układami/ścieżkami, powodująca specyficzne szumy i skwierczenie, piszczenie, bzyczenie, bardzo często uzależnione od tego co dzieje się na ekranie, np. zwykłego ruszania myszką.

Problem ten raczej nie dotyczył nigdy Xonarów z serii Essence w jakimś szczególnym stopniu, ale przy SC808 miałem już takie sytuacje, że karta u mnie sprawowała się bardzo dobrze na jednym komputerze, a na drugim potrafiła notować wspomniane przebicia.

Obojętnie co nie byłoby bezpośrednią przyczyną w sensie podatności układu czy wrażliwych ścieżek, istnieje szereg drobnych rzeczy jakie możemy zastosować, aby takie przebicia ograniczyć, a nawet jeśli ich nie notujemy, to i tak warto obniżyć maksymalnie poziom zniekształceń i szumów elektromagnetycznych by uzyskać jeszcze lepszy dźwięk, zwłaszcza na czułych słuchawkach wyłapujących notorycznie wszelkie śmieci z tła.

Od razu jednak adnotacja, że obojętnie co byśmy nie zrobili, Xonar Essence ST i STX zawsze będą wykazywały się delikatnym szumem tła podczas ciszy i przy zastosowaniu bardzo wydajnych i czułych słuchawek. Wynika to z konstrukcji układu wzmacniacza na tych kartach, impedancji wyjściowej oraz stopnia wzmocnienia.

Pokrywa EMI

Asus nie bez powodu zastosował na swojej karcie osłonkę z aluminium. Ma ona chronić elektronikę przed negatywnym wpływem zakłóceń pola elektromagnetycznego. Tak samo wlutowany na kartę miedziany grzebień oddzielający sekcję wzmacniaczy od elektroniki zasilającej. Radziłbym więc jej nie zdejmować w typowym komputerze użytkowym. Nawet więcej, można spróbować wzmocnić jej właściwości tłumiące poprzez wyklejenie środka taśmą miedzianą, aczkolwiek nigdy tej opcji nie stosowałem i na szczęście nie było takiej potrzeby. Jeśli natomiast mamy całkiem dobry komputer z minimalną ilością stwierdzonych szumów od elektroniki, spokojnie można ją ściągnąć.

Taka ciekawostka związana z osłonką EMI, że jeden z użytkowników notował pomiarowo o 1-2 dB większą dynamikę z założoną osłonką, niż bez. I było to powtarzalne zjawisko. Tym samym zakładając, że jest to relacja prawdziwa, tego typu elementy mają więc sens.

Panel przedni obudowy i przedłużacze

Wyprowadzenie słuchawek i mikrofonu na przód jest wygodne, ale niekoniecznie korzystne dla sygnału audio. Panele przednie są oparte o płytki scalone robione w bardzo różnej jakości i na ogół po tej marnej stronie. Taki panel jest podłączany kabelkiem do płyty/karty, więc to już jest jeden element na którym będziemy mogli nałapać sporo śmieci po drodze. Tuż obok gniazd jack są też często diody oraz gniazda USB, które muszą być odpowiednio zasilone. One także mogą powodować koszmarną interferencję. Jeśli notujemy przebicia na przednim panelu po podłączeniu słuchawek lub mikrofonu, sprawdźmy po kolei:

• przepięcie się na tył karty i sprawdzenie, czy rozwiązuje to problem
• j. w. + odpięcie fizyczne złączki HD AUDIO od karty
• j. w. + odłączenie kompletnie gniazd USB 2.0/3.0 od płyty (całkowita izolacja panelu)
• czysto dla testu: odłączenie diody zasilania i diody aktywności dysku twardego

Gniazda na tyle karty oferują nam i tak najlepszą jakość dźwięku, toteż lepiej jest zainwestować w jakiekolwiek przedłużacze dobrej jakości, aby nie rezygnować z wygody przedniego panelu i wyprowadzić sobie w ten sposób gniazda na biurko czy stół na którym pracujemy.

Dałem tu przykład takiego kabla z własnej oferty, jako że z obydwoma Xonarami wykorzystuję je prywatnie z bardzo dużym powodzeniem. Mam też tą zaletę, że nie zużywam gniazda w karcie, a jedynie gniazdo w kablu, które zawsze mogę wymienić jeśli coś się stanie. Znane są chociażby przypadku ułamywania wtyków w gniazdach minijack w laptopach i urządzeniach przenośnych przez przypadek i nieuwagę. W Xonarze musiałbym w takiej sytuacji rozbierać kostkę gniazda lub nawet je kompletnie przelutowywać. Nietrudno zgadnąć co jest mniej czasochłonne i skomplikowane.

Oddalenie od karty graficznej

Ogólnie dobrą praktyką jest odsunięcie od Xonara innych układów generujących bardzo duże zakłócenia elektromagnetyczne. Jednym z najczęstszych źródeł takich problemów jest karta graficzna. Dlatego rekomenduję trzymanie Essence ST/STX w jak najniższych slotach, jeśli tylko to możliwe i jeśli nie ma ku temu żadnych przeciwwskazań (np. blokowanie wentylatorów albo konflikty sprzętowe). Albo po prostu najdalej od karty graficznej, tunera TV, karty WiFi itd. Jest to prosta rzecz którą w sumie od samego początku można wyegzekwować, nawet czysto profilaktycznie.

Solidny przedłużacz MOLEX

O przedłużaczu MOLEX 4-pin chciałem napisać tu głównie w charakterze ciekawostki, ale karta lepiej zachowuje się gdy jest podłączona samodzielnie wykonanym przeze mnie adapterem. Na początku miałem wrażenie, że tło jest delikatnie cichsze po jego zastosowaniu, ale potwierdzenie znalazłem poniekąd w wynikach pomiarów THD+N, które średnio są o 2 dB mniejsze, niż gdy przedłużaczem był czarny BitFenix 45 cm.

Oznacza to, że Xonary wykazują się pewną podatnością na zakłócenia idące bezpośrednio od zasilania, a mające miejsce dlatego, że kable znajdują się w komorze właściwej obudowy komputera i są nastawione na działanie bardzo silnego pola elektromagnetycznego. Mój adapter posiada:

• grubsze i znacznie wyższej klasy przewodniki
• złocone piny kontaktowe

Nie zastosowałem przy tym żadnego specjalnego ekranowania. Wykorzystuję same właściwości przewodnika i jego grubość. Na razie jedna sztuka pracuje wraz z STX i szukam sobie na spokojnie komponentów mogących być zawieruszonymi gdzieś w mieszkaniu, a zdatnymi by posłużyć do skonstruowania drugiej sztuki, tym razem dla ST. Być może zastosowanie zasilaczy z lepszym okablowaniem fabrycznym dałoby podobne rezultaty, ale znacznie szybciej i taniej (oraz ładniej) jest mi zrobić sobie taki adapter samodzielnie.

W ramach małego uzupełnienia do powyższego twierdzenia, bardzo duże problemy z przebiciami notowały AIM SC808 na karcie-córce, która była podpięta do karty-matki za pomocą dwóch cienkich taśm w stylu starych IDE. Nie było żadnego innego połączenia, zasilania, niczego. Karta pracowała tylko na tych dwóch taśmach i była podłączona tylko do karty głównej, a i to już wystarczało, aby przebicia były gorsze niż na układzie zintegrowanym z płytą. To są rzeczy które się z reguły kompletnie bagatelizuje, ale lepiej jest moim zdaniem mieć taki czy inny przedłużacz, niż nie mieć. W moim przypadku wykonałem go tylko z potrzeby, ponieważ miałem 3 urządzenia (kontroler USB i dwie karty dźwiękowe) i tylko 2 przedłużacze BitFenixa, więc bardzo się cieszę, że było to okazją do poczynienia takich testów.

Uziemienie w sieci elektrycznej

Jeśli słyszymy problem z buczeniem w tle, zwłaszcza na wydajnych słuchawkach, możemy zrobić prosty test i dotknąć obudowy komputera. Buczenie ustało? Zatem problem jest z uziemieniem w instalacji elektrycznej. Warto przyjrzeć się temu problemowi i od razu ustalić, czy jest to po prostu niepodłączone gniazdko, pokój bez odpowiednio położonych kabli czy może przypadłość całego domu. Czasami pomagają dodatkowe filtry i urządzenia zorientowane na stabilizację prądową, mające w efekcie korzystny wpływ na poziom przebić i niechcianych zjawisk mających swoje umocowania w energii elektrycznej. Ale tylko wówczas, gdy zakłócenia powstają w danym pomieszczeniu i problem nie jest związany z nieprawidłowo położoną instalacją w budynku.

Filtracja i odszumianie

Jeśli mimo wszystko masz wciąż problemy z szumami i przebiciami, możesz pokusić się o zastosowanie filtrów na wyjściu słuchawkowym, takich jak mój autorski IEM-Guard. Jest to adapter skutecznie odcinający szumy i przebicia, choć robiący to za cenę głośności. Słuchawki używane dotychczas np. na 20% głośności muszę podkręcić na 40-50%, aby uzyskać tą samą głośność. Ale właśnie taki jest cel, bo w skuteczny sposób przesuwa się efektywny zakres regulacji głośności (headroom). 50% daje przy tym wciąż ogromny zapas.

Adapter jest tak zaprojektowany, aby poziom tłumienia był dobierany automatycznie i adekwatnie do impedancji wyjściowej. Im wyższa wartość impedancji, tym lepiej IEM-Guard sobie poradzi i mocniej wytłumi bez negatywnego wpływu na dźwięk.

Na Xonarach szum czy przebicia generalnie nigdy nie były problematyczne, a sporo więcej problemów notowałem już prędzej na SC808, stąd mam dosyć dobre zdanie o TPA6120A2 i ogólnie konstrukcji samej karty, niemniej z czułymi słuchawkami, słuchając w ciszy i na niskich poziomach głośności, daje się usłyszeć iż tło nie jest idealnie „czarne”. IEM-Guard powoduje, że jest i efekty są o tyle na Xonarach Essense wyśmienite, że układy te mają 10 Ohm na wyjściu. Sam adapter ma natomiast 1,6 Ohma. Daje to dobry stosunek wartości parametrów impedancji i sam adapter ma skąd „brać”.

Można pójść jeszcze o krok dalej i zastosować mocny filtr dolnoprzepustowy, który nie tylko ponownie będzie bardzo skutecznie tłumił wszelkie szumy i przebicia, ale też dodatkowo ocieplał i łagodził dźwięk. Jest to rozwiązanie komplementarne ze wzmacniaczami operacyjnymi, jeśli i te wymienialiśmy na uzyskanie jak największego ocieplenia, jak również z kablami, które także potrafią zmodyfikować sygnał elektryczny tak, aby słuchawki zagrały nam przyjemniej. Filtr aplikuje stałe obciążenie na wzmacniacz słuchawkowy Xonara, także może się tak zdarzyć, że karta będzie notowała wyższą temperaturę pracy.

Przykładem takiego filtru jest, także mojego autorstwa, prototypowy LPF63. Umieszcza się go albo w przedłużaczu na jego wyjściu, albo bezpośrednio w karcie dźwiękowej. Adapter ten zrobił kolosalną różnicę w połączeniu ze zintegrowanym układem na płycie głównej (ALC892), który siał niesamowicie przebiciami i przejawiał chyba wszystkie możliwe problemy opisane w tym akapicie.

Oba te rozwiązania należy jednak zostawić na sam koniec i próbować w pierwszej kolejności zdiagnozować problem lub ograniczyć go wcześniej opisanymi metodami, ponieważ nic nas one nie kosztują. Jeśli wszystko to na nich i nadal mamy problem z szumami oraz przebiciami, adaptery na pewno sobie z tym poradzą. A jeśli dochodzi do tego problem z tzw. „piskiem śmierci”, taki adapter jest w stanie uratować nam słuchawki i zaoszczędzić sporo nieprzyjemności. Wtedy im mocniejszy filtr i mniejszy zapasowy zakres głośności, tym mniejsze zaskoczenie.

I o tym właśnie będzie następny, ostatni już akapit.

Niwelujemy tzw. „pisk śmierci”

1. zastosuj próbkowania wymienione w akapicie o najlepszych ustawieniach dla DirectSound
2. w razie potrzeby spróbuj także innych ustawień bit/kHz
3. wyłącz kompensację głośników wymienioną w akapicie o DirectSound
4. dezaktywuj wszystkie efekty GX wymienione w akapicie o DirectSound
5. testowo wyłącz wejścia dźwięku oraz mikrofonowe i przełącz się na gniazda zintegrowane z płytą główną lub zewnętrzny mikrofon USB
6. zastosuj porady związane z obniżeniem latencji
7. unikaj współdzielenia przerwań IRQ i zastosuj porady związane z tym aspektem
8. ustaw 100% głośności w systemie jeśli korzystasz z urządzeń po RCA
9. zastosuj filtrację na wyjściu słuchawkowym jako zabezpieczenie głośności i tym samym swojego słuchu oraz sprzętu jeśli korzystasz z wyjścia jack 6,3 mm
10. sprawdź kartę po ustawieniu trybu wysokiej wydajności oraz wyłączeniu dynamicznej zmiany zegarów oraz napięcia
11. spróbuj ręcznego ustawienia taktowania parametru BCLK na swojej płycie głównej
12. sprawdź kartę na innym systemie komputerowym (płycie głównej), preferencyjnie lepszej jakości niż posiadana
13. albo po prostu stosuj aplikację Xonar Switch

Czym jest „pisk śmierci”

Inne nazwy tego zjawiska to „White Noise Scream of Death” albo „High Pitched Ringing Noise”, choć przydomków może być więcej. Sam nazywam go po prostu „piskiem śmierci”, gdyż określenie „krzyk diabła” czy „szum zagłady” nadają mu i tak niepotrzebnego rozmachu i patosu. Jeśli miałbym wskazać jedną rzecz, która byłaby najpoważniejszym mankamentem kart spod znaku Xonar (problem z tego co wiem nie dotyczy tylko serii Essence), to właśnie byłaby takowa rzecz. Co prawda posiadacze STX II mają jeszcze gorzej, bo tam ma z kolei miejsce problem kompatybilności z platformami na procesorach Ryzen, ale brakuje mi informacji aby pisk dotykał także i tych użytkowników (zresztą, tego mogłoby już być za wiele).

Ogólnie jest to bardzo głośny szum i pisk o wysokiej częstotliwości, który pojawić się może w najmniej dogodnym momencie, losowo i niesprowokowanie, nawet podczas ciszy. Co więcej, nie wiadomo nawet dlaczego problem powstaje. Potrafi wystąpić zarówno na Windows 7, 8 oraz 10. Występuje jak na razie chyba na wszystkich sterownikach, zarówno oryginalnych jak i alternatywnych.

Na temat genezy powstawania pisku śmierci krążyło wiele hipotez. Również mam swoje własne w tym zakresie. To jednak, co udało mi się ustalić na ten moment, to:

• problem na pewno nie jest związany z systemem operacyjnym Windows (występuje na wszystkich systemach od Windows 7 w górę),
• problem występuje losowo i niekoniecznie musi być czymś widocznym wywołany,
• problem występuje bez względu na wybrane wyjście analogowe i ma miejsce tak samo na RCA jak i po wyjściu słuchawkowym,
• problem najczęściej występuje w trybie DirectSound,
• problem prawdopodobnie nie jest związany z zastosowaniem określonych wzmacniaczy operacyjnych (choć miałem wrażenie, że stosowanie układów LM/LME na buforze lub I/V potrafi częściej wywołać pisk śmierci),
• problem raczej nie jest wskaźnikiem dogorywania karty (przez lata na STX miałem mniej sytuacji im starszy był mój egzemplarz, co przeczy teorii o zużytej elektronice),
• problem prawdopodobnie ma (przynajmniej częściowe) podłoże programowe i jest związany z konfliktem między sterownikiem a mikserem systemu Windows lub ogólnie usługą Windows Audio,
• problem nie powoduje ryzyka uszkodzenia samej karty,
• problem może spowodować za to pewne ryzyko uszkodzenia bardzo czułych słuchawek lub słuchu użytkownika,
• problem jest bardzo skutecznie redukowany w skutkach przez zastosowanie filtrów impedancyjnych,
• problemu nie udało mi się jeszcze zaobserwować podczas korzystania z trybu ASIO,
• problemu nie udało mi się jeszcze zaobserwować po wyjściu cyfrowym S/PDIF,
• problem może mieć związek z jakością używanej płyty głównej i podatnością na stabilność taktowania BCLK oraz skokami napięcia i zmiany taktowania procesora

Na jednym komputerze (STX) problem pojawiał się bardzo rzadko i tylko przy próbie odtworzenia jakiegoś utworu w Foobarze. Czyli inicjatorem było rozpoczęcie nowego strumienia dźwiękowego. Z kolei na drugim komputerze (ST) pisk potrafił ujawnić się nawet na pulpicie, bez żadnego powodu i bez żadnego działania z mojej strony, przy wyłączonych wszystkich aplikacjach. Co ciekawe, maszyna ta miała problemy z okresowo strzelającą w powietrze latencją i bardzo możliwe, że ma to ze sobą związek, tj. to właśnie było inicjatorem. Nie odbywało się wtedy nic dźwiękowego, ani jeden komunikat. Jeśli byłoby to wzbudzanie się wzmacniaczy operacyjnych, to przełączenie się na inne źródło i powrót na Xonara nie powinno nic robić i problem winien nadal występować, tymczasem znikał. Prowadzi to do wniosku, że problem z piskiem śmierci jest uwarunkowany programowo i powstaje w momencie zbiegu różnych okoliczności i mechanizmów.

Moim zdaniem, bo cały czas opieram się na swoich obserwacjach i domysłach, coś musi dziać się na styku latencji (być może w momencie otrzymania „strzału” latencji od procesów systemowych) i sterowników samej karty oraz systemowego miksera. Znacznie większa częstotliwość występowania, w tym bez żadnego inicjatora, na słabszym komputerze notującym wielokrotnie częstsze problemy z latencją procesów systemowych, nie jest tu bez znaczenia.

Aktualizacja 06.09.2020
Po rozmowie z użytkownikiem @Art385 oraz dokonanej w międzyczasie wymianie płyty głównej oraz procesora w maszynie pomocniczej, która do tej pory sprawiała najwięcej problemów z Essence ST i służyła za platformę testową w zakresie tego co pomaga, co może pomóc, a co nie ma znaczenia, zrodziła się trochę dokładniejsza teza, że prawdopodobnie coś dzieje się nie tyle na styku jak pisałem latencji oraz sterowników, co powodu jej występowania, mającego swoje zakorzenienie w:

• wahaniach taktowania BCLK (skrót od ang. Base CLocK),
• dynamicznej zmianie napięcia procesora pod obciążeniem,
• dynamicznie zmianie taktowania procesora pod obciążeniem.

Testowy komputer z Essence ST, który służył mi do napisania tego artykułu w swojej ogromnej części, był oparty o procesor Phenom II X2 560 (2 rdzenie, 2 wątki, taktowanie 3,3 GHz). Przejście na Phenoma X4 960T (4 rdzenie, 4 wątki, taktowanie 3,0/3,4 GHz) wprowadziło dużą poprawę w zakresie trzasków, ale nie rozwiązało tego problemu całkowicie. Pisk potrafił pojawić się bardzo rzadko i samoczynnie (pulpit, brak jakichkolwiek próbek dźwiękowych czy muzyki oraz uruchomionych roboczo programów), ale też dziwne artefakty podczas długiego odtwarzania dźwięku w trybie ASIO. Nie miał na to wpływu także okres zabaw z napięciami procesora, od nominalnych po dosyć mocne odvoltowanie. To zasugerowało mi głębszy problem z ogólnie samą platformą.

Po drodze sprawdzony został zasilacz w formie nowszej i mocniejszej jednostki innego producenta. Trochę lepiej całościowo dla działania komputera, ale generalnie bez zmian. Przejście nastąpiło zatem na inną płytę główną, tu akurat na tego samego producenta co poprzednia. Spowodowane było to przez brak jakichkolwiek alternatyw z chłodzonymi VRMami w formie nowych i nieużywanych płyt dla maksymalnej gwarancji, że sprzęt przyjedzie do mnie sprawny i takowym pozostanie przez dłuższy czas. Cóż, jak się nie ma co się lubi… ale ogólnie udało się trafić na naprawdę solidną konstrukcję bez specjalnych problemów i tylko z kilkoma rzeczami które mi osobiście się nie podobały z punktu widzenia całościowej koncepcji komputera docelowego (brak możliwości UV, gorsza wydajnościowo grafika zintegrowana, wciąż brak SATA3).

Dopiero tutaj problem zniknął, zarówno z piskiem, jak i trzaskami. Skoki latencji procesów systemowych pozostały, ale system radzi sobie na tym samym procesorze i słabszej zintegrowanej grafice lepiej. Wskazują to także proste testy wydajnościowe CPU-Z, notujące nieco lepsze rezultaty na nowej płycie. Nie były przy tym wprowadzane żadne zmiany co do taktowania czy napięć (jak pisałem płyta na te ostatnie w dużej mierze nie pozwala). Problem musiał mieć więc swoje główne podłoże w tym jednym komponencie komputera, kluczowym jakby nie patrzeć.

Czemu akurat BCLK jest tu typowany na złoczyńcę? Zegar bazowy zastępuje chociażby FSB i jest to podstawowa jednostka taktowania, która przekłada się na taktowanie np. procesora czy pamięci RAM poprzez mnożenie o określony mnożnik. W przypadku podkręcania, zaleca się albo nie dotykać tego parametru, albo robić to na samym końcu, ponieważ jest to główna magistrala, mająca swoje przełożenie także na np. gniazda PCIe. One także mają swoje taktowanie czerpane u źródła w BCLK. Zmiana tego parametru z nominalnych 100 MHz na coś innego skutkuje automatycznie taktowaniem wyżej/niżej pozostałych komponentów i urządzeń. Zmiana BCLK może wpłynąć na przezwyciężenie niektórych progów częstotliwości taktowania, np. jeśli podkręcimy procesor na stabilne 4,50 GHz, ale już na 4,51 GHz system kompletnie nie wstanie bez względu na wszystko. Może też czasami pomóc na takie sytuacje jak nasza. Niemniej jeśli system jest niepodkręcony lub nawet pracuje ze zmniejszonym jakkolwiek napięciem, skutkując potencjalnie mniejszym obciążeniem, a mimo to fluktuacja BCLK jest wysoka, może to prowadzić do niestabilności całej platformy i samo w sobie jest wskaźnikiem, że płyta może mieć swoje lata za sobą, tudzież miała lub ma na sobie podzespół, który wykraczał/wykracza poza jej specyfikację. Zmiana parametru ze 100 MHz na np. 101 MHz powinna być jeszcze jakkolwiek wykonywalna. Zmiana zaś na coś więcej, np. 102 czy 103 itd., może powodować efekty zupełnie przeciwne do zamierzonych.

Finalnie wydaje mi się więc, że piski (i trzaski) są zależne nie tylko od rzeczy, które obszernie tu przez wiele akapitów opisywałem, a które nadal pozostają w mocy, ale faktycznie od jakości i stabilności samej platformy w postaci użytej płyty głównej i procesora oraz wpływu modulowanych częstotliwości taktowania i napięć na fluktuację parametru BCLK, który winien wynosić 100 MHz. Na komputerze na którym pracuję na Essence STX, zegar bazowy również notuje fluktuację, ale w ramach 99,91 do 99,94 MHz w spoczynku. Jest to całkowicie w ramach tolerancji. Na nowej płycie zegar szyny systemowej waha się zaś od 201,31 do 201,35, czyli znów w bardzo małej tolerancji. Dodatkowo, te 0,04 MHz pojawia się niezmiernie rzadko. Nie pamiętam przyznam jakie odczyty były na poprzedniej płycie, ale pamiętam coś koło 200,80 MHz ze skokami do 201 z groszem. Tu już jest całe jedno miejsce po przecinku więcej i żadna z pozostałych płyt, zarówno pod Intela, jak i AMD, nie wykazywała tak dużych skoków w spoczynku. A co dopiero musi dziać się pod jakimś obciążeniem lub przy procesach działających w tle.

Teza jest zatem następująca: przy obciążeniu lub czymkolwiek, co może powodować gwałtowne zmiany BCLK, karta najprawdopodobniej reaguje błędem sprzętowym generującym albo „pisk śmierci”, albo artefakty które opisywałem wcześniej w ASIO.

Co to były za artefakty? Kompletnie wariujące wizualizacje w Foobarze pokazujące co rusz maksymalne natężenie na wszystkich zakresach (korzystam z wizualizacji Spectrum), co chwilę przywieszanie się i odwieszanie dźwięku w formie losowych mikro-przywieszek, wreszcie serwowanie losowych dźwięków o maksymalnym natężeniu przez ułamek sekundy rodem z komputerów 8-bitowych. Nigdy mi się coś takiego nie zdarzyło i był to pierwszy raz od początku jak używam tych kart, tj. 2009 roku.

Potwierdzenie, że nie jest to wina samej karty, przyszło ze strony Realteka i AudioQuesta, gdzie zintegrowany układ nawet w trybie DS notował sporadyczne trzaski, a Cobalt co jakiś czas łapał artefakty po USB. Tu także mogłem tylko zakładać, że jest to spowodowane fluktuacją zegara bazowego, a nie np. problemem z kontrolerem USB. Ale dla pewności w ruch poszedł zewnętrzny kontroler Axagon USB 3.0 na układzie VIA. Problem nadal istniał, bez zmian. Nie była to też jednoznacznie nadwrażliwość samego Essence ST, choć osobiście uznaję te karty za w istocie wrażliwe na stabilność magistrali systemowej. Albo po prostu wrażliwsze od innych urządzeń. Choć znów, jest to jedyny przypadek problemów z trzaskami na układzie zintegrowanym. Nie miałem też żadnych problemów tego typu na Cobalcie. Jeśli natomiast po wymianie procesora (wykluczony problem z uszkodzonym rdzeniem i błędnie wykonywanymi instrukcjami) i zasilacza (wykluczony problem ze stabilnością prądową) problem nadal istnieje i zmienia się jedynie jego częstotliwość lub skala, a pomaga ostatecznie wymiana całej płyty głównej (od tygodnia brak problemów jak na razie), to chyba mamy swoją odpowiedź. Nadal bez ostatecznego dowodu, ale czuję, że chyba trafiłem w dziesiątkę.

Co można zatem poradzić na bazie tego co napisałem? Obserwować zachowanie się parametru Bus Speed / Base Clock / BCLK, najlepiej w jakimś programie monitorującym, testować występowanie trzasków na innych urządzeniach, być może nawet przetestować kartę na innej platformie (np. dać ją znajomemu na obserwację na miesiąc), a także sprawdzić kartę w sytuacji, gdy wyłączymy jakiekolwiek oszczędzanie energii, dynamiczne taktowania, dynamiczne zmiany napięć i spróbujemy ugruntować parametr BCLK ręcznie lub starając się go skompensować. Jeśli będziemy widzieli, że np. ze 100 skacze nam czasami na 104, być może warto będzie ustawić ręcznie 99 MHz. Jeśli to nie pomaga, to 101 MHz. Metodą prób i błędów, krok po kroku. Zwłaszcza gdy mamy sprzęt leciwy i o niewiadomej historii/przebiegu.

Aktualizacja 27.05.2022
Problem pisku śmierci rozwiązuje permanentnie stosowanie aplikacji Xonar Switch.

Co robić jeśli wystąpi „pisk śmierci”

Gdy otrzymamy na wyjściu taki pisk i szum, przede wszystkim natychmiast ściągnijmy słuchawki, aby nie wystawiać swoich uszu na długotrwałe działanie takich częstotliwości. Nic nie jest warte uszkodzenia sobie ośrodka słuchu i nabawienia się problemów ze zdrowiem.

Wbrew pozorom skasowanie efektu szumu nie wymaga uruchomienia komputera ponownie. Wystarczy uruchomić aplikację restartującą której poprzednio używaliśmy przy wyłączeniu funkcji kompensacji głośników.

Jeśli nie mamy jej pod ręką, czasami wystarczy po postu przełączenie się na inne urządzenie dźwiękowe (jeśli takowe posiadamy) i powrót w zasobniku systemowym do Xonara. Pisk powinien zniknąć.

Aktualizacja 27.05.2022
Problem pisku śmierci rozwiązuje permanentnie stosowanie aplikacji Xonar Switch.

Przeciwdziałania i zabezpieczenia

Cokolwiek by nie było powodem, pytanie zasadnicze brzmi: jak sobie z tym radzić? No i tutaj niestety zaczynają się schody. Producent o problemie wie, ale jest to sprzęt już nieprodukowany i nie jest specjalnie nim zainteresowany. Było, się sprzedało, tyle, dobranoc. Gdyby wsparcie w zakresie oprogramowania było bardzo dobre, nie potrzeba byłoby ani alternatywnych sterowników, ani być może nawet tego artykułu.

Także niestety nie ma na to oficjalnego lekarstwa i prawdopodobnie nigdy nie będzie. Poza naturalnie rzeczami które sobie tutaj wypisaliśmy w akapicie wyżej. Niemniej jest trochę zabiegów które można zastosować, więc na szczęście nie jesteśmy całkowicie bezbronni nawet, jeśli wszystko powyższe nie przyniesie efektów.

Właściwie większość tychże czynności już wymieniłem, ponieważ jeśli korzystamy z DirectSound, pomaga wg moich obserwacji chociażby poprawna konfiguracja głębi bitowych czy brak ulepszaczy w dźwięku. Ponownie korzystnie wpływa tu też i walka o jak najniższą latencję. Poprawna konfiguracja systemu, stabilna maszyna i brak kolizji IRQ pozwalają na skuteczne zminimalizowanie ryzyka wystąpienia „pisku śmierci” i tak, jak np. na Essence ST miałem raz-dwa dziennie taką sytuację, tak teraz nie pamiętam już kiedy nawet miało to miejsce. Na STX także nie odnotowywałem od bardzo długiego czasu żadnych problemów po zastosowaniu porad tu opisywanych. Prawdopodobnie działa tu suma wszystkich tych czynności i starań, a sam problem nigdy nie miał umocowania w jednej konkretnej rzeczy będącej jego przyczyną.

Niektórym osobom zdaje się pomagały specjalne zabiegi polegające na wyłączeniu wszystkich urządzeń operujących na strumieniu wejściowym, a więc wejście mikrofonowe, AUX, Stereo Mix itd., po czym przełączenie się na wejście mikrofonowe zintegrowane z płytą główną, ustawiając je jako domyślne urządzenie rejestrujące i komunikacyjne. Mi akurat na ST nie dało to żadnego profitu i nie zniwelowało problemu, w przeciwieństwie do zastosowania pozostałych zabiegów jakie tu opisałem, a więc poprawnej konfiguracji i optymalizacji.

Być może jest to jakaś też nadzieja dla niektórych użytkowników, ale nie zanotowałem jeszcze wystąpienia problemu w sytuacji korzystania z natywnych sterowników ASIO. Tu trzeba będzie wykonać zapewne sporo testów odsłuchowych na bardzo długiej osi czasu, ale osobiście jestem przekonany, że taki sposób odsłuchu jest dla Xonarów najwłaściwszy.

Natomiast jeśli wszystko zawiedzie i problem nadal będzie nas trapił, a mimo to nie będziemy chcieli czy to korzystać z ASIO, czy w ogóle rezygnować z korzystania z samego urządzenia, pozostają nam zabezpieczenia zdatne do zaaplikowania na samej karcie, a dokładnie na jej wyjściu. Bardzo skutecznym zabezpieczeniem będą opisywane wcześniej filtry impedancyjne, ponieważ ich rola nie kończy się na zadaniach filtracyjnych co do szumu i przebić, ale na Xonarach pełnią również rolę elementów zabezpieczających. W zasadzie nie tylko, bo i przy dużych wzmacniaczach, np. stereo, może to być duże zabezpieczenie dla słuchawek.

Zasada jest tu prosta: zanim podłączymy słuchawki do karty, podłączamy pod nią filtr i dopiero do niego wpinamy słuchawki. Nie ma tu znaczenia kolejność. Taki filtr będzie pełnił jak pisałem rolę wieloraką:

• filtrację szumu tła,
• filtrację przebić,
• uelastycznienie zakresu głośności szczególnie dla słuchawek wysokowydajnych,
• zabezpieczenie przed piskiem śmierci (wynikające z powyższego),
• zmniejszenie impedancji wyjściowej,
• zmiękczenie i ocieplenie dźwięku (tylko LPF).

Mówiąc wprost z własnego doświadczenia, zdarzyło mi się przetestować LPF63 w praktyce na STX, gdy miałem podłączone pod wyjście słuchawkowe chyba LCD-XC albo K240 MKII, jedną z tych par na pewno. Z głośnością byłem ustawiony na ok. 80% przy konfiguracji na Low Gain i w trybie DirectSound. Gdy nastąpił pisk, z racji małego zakresu dzielącego mnie od maksymalnej głośności, pisk kompletnie mną nie wzruszył i stał się bardzo cichy, niewiele głośniejszy od słuchanej jeszcze moment temu przeze mnie muzyki. LPF63 ma co prawda bardzo agresywnie ustawione tłumienie i jest to ogólnie filtr dolnoprzepustowy, mający za zadanie ocieplić przy okazji brzmienie (dedykowany jest do jasnych urządzeń), ale w praktyce zastopował kompletnie destrukcyjny wpływ pisku śmierci na moje uszy. Można powiedzieć, że potrzeba była tu matką wynalazku.

Oczywiście zawsze lepiej zapobiegać niż leczyć i nawet jeśli komuś brakuje już sił czy cierpliwości, mimo wszystko znacznie lepiej podejść do tematu od punktów które wcześniej listowałem, a które możemy robić za darmo i przetestować normalnym użytkowaniem karty. Dopiero gdy nie ma wyjścia, można zastosować wspomniane już wcześniej przeze mnie filtry:

• IEM-GUARD – jeśli to głównie szumy i przebicia dają się nam we znaki, niekoniecznie na słuchawkach dokanałowych, a nie chcemy przy tym zmieniać brzmienia sprzętu
• LPF (zdjęcie poniżej wersji tylko przelotkowej pozbawionej filtracji) – jeśli to głównie pisk śmierci daje się nam we znaki, a przy okazji chcemy też dodatkowo ocieplić być może zbyt ostre brzmienie

Naturalnie można stosować także filtrację firm trzecich i nic nie stoi ku temu na przeszkodzie. Ważne jest wtedy aby adapter był dopasowany do naszego urządzenia i nie powodował degradacji lub ograniczeń dźwięku. To bowiem rodzi często sceptycyzm wobec takich rozwiązań, a niekoniecznie musi w ogóle występować. Wszystko zależy od konstrukcji i użytych komponentów.

Zapewne rodzi to w tym miejscu wątpliwości, że skoro potrzebna jest tak wielka kombinatoryka przy tych kartach, to czy nie lepiej zostawić je w spokoju na bocznicy historii audio i zakupić jakiś zewnętrzny DAC? Owszem, można, ale nie będzie tam wejścia mikrofonowego, nie będzie ASIO (chyba że rzucimy się na interfejs studyjny, ale kosztem wtedy gwarancji jakości dźwięku), najczęściej nie będzie wymiennych OPA, a komunikacja po USB także nie będzie wolna od przebić, może nawet będzie jeszcze gorzej niż na kartach wewnętrznych.

Nie mówię że Xonar lub inne karty dźwiękowe są lepsze od DACów zewnętrznych (choć de facto są, jeśli w porównywalnych cenach), ale każde urządzenie, czy nam się to podoba czy nie, będzie miało swoje wady i zalety, zastosowania i przywary, kaprysy i sekrety. Artykuł jest pisany pod kątem posiadacza takich kart, aktualnego ich użytkownika, a nie mając na celu przekonywać kogokolwiek do ich zakupu. Od tego będą znacznie bardziej subiektywnie napisane recenzje, czy to Essence STX, czy Essence ST. Aczkolwiek jeśli ktoś się przymierza do zakupu, ten artykuł też może dać mu pewien pogląd jak czasochłonna w konfiguracji może okazać się karta z tej serii i szansę na ocenę, czy gra będzie dla niego warta świeczki. Ja na tą kwestię odpowiedź już zdążyłem poznać.

Aktualizacja 27.05.2022
Problem pisku śmierci rozwiązuje permanentnie stosowanie aplikacji Xonar Switch.

Podsumowanie

Tak jak obiecałem, artykuł porusza praktycznie wszystkie aspekty korzystania z kart Asus Xonar na przykładzie Essence ST i STX. Omówiłem w nim tematykę zoptymalizowania samej karty do pracy w trybie DirectSound, wykorzystania wbudowanych sterowników ASIO, rozwiązywania problemów z jej działaniem, dostosowania systemu operacyjnego, ograniczenia latencji, a także wyciągnięcia możliwie maksymalnego potencjału bez bezpośredniej ingerencji w samą kartę.

Na koniec chciałbym jeszcze raz podkreślić, że powyższy artykuł powstał na bazie przede wszystkim moich 11-letnich doświadczeń z pracą na tych kartach i jest on z tego powodu w pewnym zakresie limitowany do rzeczy, które sprawdziły się u mnie w moim systemie i na bazie mojej platformy komputerowej z Essence STX. Dopiero od niedawna uzupełniam je o doświadczenia z platformy drugiej, starszej i opartej na modelu Essence ST, gdzie wiedza pierwotna uzupełnia się z tą nową i pomaga lepiej zrozumieć podatności oraz wrażliwości tychże kart, jak też ich wciąż skrywane po latach możliwości.

Choć liczę, że przyda się on posiadaczom tych układów i że opisane tu zagadnienia będą dla nich ostatecznie korzystne, ostatecznie każdy powinien sam spróbować odnaleźć własne ustawienia w swoim systemie, które grają mu najlepiej lub po prostu są najwygodniejsze w użytkowaniu.