rt-sources

[nUmer_inaczej]

Witam!
Przeczytałem na forum audio co niżej:

Code: Select all

Polecam uzycie minimalistycznej wersji Gentoo Linux wraz z jadrem z latkami RT ktore zaczal opracowywac Ingo Molnar. Jak wiadomo kernel linuxa nie jest kernelem czasu rzeczywistego co automatycznie jest strzalem w kolona przy zastosowaniach audio/video, kilka lat temu rozpoczeta prace nad wersja RT jadra. Dodatkowo by zbalansowac dalej przydzielanie czasu poszczegolnym procesom mozna uzyc CPU i IO Schedulera opartego na implementacji algorytmow genetycznych.

Nalezy tez dodac ze niektore karty sa obslugiwane ciagle tylko via OSS.

Jako, że lubię słuchać dobrej muzy a system mam minimalistyczny oparty na WM zaryzykowałem - ....
Dodałem overlay pro-audio i zainstalowałem rt-sources w najnowszej wersji, przez wzgląd, że stabilna nie obsługuje mego sterownika dźwięku.
Oczywiście serwer jackd odpalony - opóźnienia mam rzędu 0.2 msec
Odpaliłem system i dźwięk stał się bardziej przestrzenny, wyraźny, bas schodzi niżej aniżeli wcześniej.
Słucham na Asus Xonar Essence STX → Harman Kardon HK980 → Mission 792 - flaki.

Pytanie - co gość miał na myśli pisząc o CPU i IO Schedulera opartego na implementacji algorytmów genetycznych?
Niestety nie znam na tyle języka obcego by to zrozumieć - nie mogę się z nim skontaktować, ponieważ tydzień musi upłynąć do czasu autoryzacji.

Pozdrawiam i dziękuję za uwagę.

[tomaszg]

Efekt placebo Te łatki mają wpływ na opóźnienia, a nie na brzmienie dźwięku. Być może przy okazji zmieniłeś wersję ALSY, albo włączyłeś OSS - to by mogło mieć jakiś wpływ (aczkolwiek też nie mam przekonania). Niektórzy mówią, że oss, zwłaszcza w nowej wersji, brzmi lepiej.

Wiem, o jakim forum piszesz (też wypowiadałem się w tamtym wątku ), więc wiem, że opinie niektórych należy traktować bardzo krytycznie. Niektórzy słyszą dźwięk wydawany przez plik swap

Te wszystkie algorytmy genetyczne przy IO i CPU mają znaczenie jak przez proc i dysk leci masa danych - czyli np. przy kodowaniu i obróbce A/V. Odtwarzanie flac czy mp3 absolutnie nie obciąża ani proca, ani dysku.

Radzę zrobić eksperyment - zabootuj losowo jajko i zobacz, czy po dźwięku poznasz, które się włączyło


PS. Tu pod koniec ktoś też wspomniał o RT: http://www.audiostereo.pl/forum_wpisy.h ... 7993&all=1

[nUmer_inaczej]

Również mi to przeszło przez myśl - mam nowsze jądro a co za tym idzie - prawdopodobnie nowsza alsa.

A mi się wydawało, że RTC - dokładniejsze od zmiennoprzecinkowego które można podyktować w mplayerze może mieć znaczenie.
Może nie to ucho


... spróbuję jak podpowiadasz

Dzięki za linka

[tomaszg]

Na mój rozum, RTC tu nie ma nic do rzeczy. Karta dźwiękowa ma przecież swój zegar.

Ja i tak mam swojego Xonara podpiętego światłowodem, więc te aspekty mam w nosie. (Od razu dodam, że jitter w audio to imho też bajka)

[nUmer_inaczej]

a czy aby nie chodzi o jakość otrzymanego przez kartę sygnału?

niewykluczone, że palnąłem straszną nawet głupotę - poszukam w sieci materiałów które rozjaśnią mi sedno problemu, popytam i się ustosunkuję nieco później.

[tomaszg]

Nie jestem inżynierem, ani nawet programistą, ale nie ma czegoś takiego jak "jakość sygnału" który dostaje karta. To tylko zera i jedynki. Albo karta dostaje je w porę (wtedy gra), albo ich nie dostaje w porę (i wtedy są słyszalne trzaski - słychać przekłamanie jednego bajta nawet!). Bajty nie muszą być dostarczane karcie w idealnych odstępach, od tego są rozmaite bufory.

[nUmer_inaczej]

kupiłem właśnie "Dźwięk cyfrowy. Systemy wielokanałowe" Wojciecha Butryna.
Mam nadzieję przestudiować i zbudować własną opinię na temat ew. różnic między
systemami operacyjnymi oraz podstawami systemów dźwiękowych.

[tomaszg]

Napisz, jak wyczytasz coś mądrego

Ja dziś bawiłem się dla odmiany dac-em na usb i sterownikami asio pod windowsem.

[fallow]

Hej.

W pierwszym poscie jest cytat "ze mnie".

Od razu wyjasnie, ze ten post na "zaprzyjaznionym" forum byl raczej napisany z lekka nutka sarkazmu dla panujacych tam wszechobecnych albo przynajmniej wielce obecnych audiofilskich tredow.

Ludzie slysza tam roznice w tasiemkach dyskow albo miedzy modulami RAM... ja przy czyms takim wysiadam )

Audio w ujeciu pro (produkcja) lub zakrawajacym troche o audiofilskosc (wole nazywac sie melomanem) tez juz troche sie zajmuje i wiele rzeczy juz mnie zaskoczylo. Wiele razy zdarzalo mi sie bagatelizowac wplyw jakiegos czynnika na SQ jednak nigdy nie bylo to takie Voodoo czy wirtualne karate jak na AS. Wszystkie z tych rzeczy da sie racjonalnie i logicznie wytlumaczyc jednak przyznam szczerze, ze jestem programista a nie elektronikiem wiec siegalem po pomoc kolegow elektronikow przy roznego rodzaju modyfikacjach.

Oczywiscie RT Kernel ma na celu nie poprawe walorow sonicznych a jedynie zmniejszenie opoznien. Co to daje ? Dla domowego uzytkownika nic, jednak w pracy z dzwiekiem w czasie rzeczywistym, nagrywaniu, monitoringu jest to rzecz kluczowa. Im mniejsze opoznienia tym po prostu wieksza szybkosc reakcji - to bardzo duza zaleta przy pracy z dzwiekiem i nagrywaniu.

Z drugiej strony moim zdaniem nie ma dobrych narzedzi obecnie dla Linuxa by zajmowac sie obrobka dzwieku na tym systemie, byc moze zmieni sie to kiedy RT kernel bedzie juz na tyle dojrzaly by byl sens pisac lub portowac takie oprogramowanie.

Co do tego co dostaje karta - jezeli API przez ktore przesylany jest strumien audio zapewnia Bit-Perfect to oczywiscie do karty trafia dokladnie to co mamy na dysku. Niestety w Windowsie wcale przez dlugi czas nie bylo to takie oczywiste i sam mikser Windowsa mogl w zauwazalny sposob degradowac jakosc dzwieku przy miksowaniu wielu probek. Dlatego np. w popularnych odtwarzaczach takich jak Foobar dodano "Kernel Streaming".
Obecnie na Viscie i w gore WASAPI nie powoduje juz takich problemow.

Co do transmisji cyfrowej via SPDIF czyli po coaxialu, toslinku etc. nie jest ona przeciez dwustronna i odbiornik nie moze sobie poprosic zrodla o przeslanie jakiegos pakietu w przypadku bledu jednak bledy takiej transmisji w warunkach domowych sa ....calkowicie pomijalne.

W studio oczywiscie uzywa sie transmisji symetrycznej po XLR - AES/EBU. Sygnal jest wzmocniony przez trafo oraz przesylany w roznych fazach (+,-). W bardziej zaawansowanych systemach transport oraz DAC jest jeszcze synchronizowany zewnetrznym zegarem o wysokiej precyzji. Znacznie wiekszej niz zegary pokladowych kart.

Jitter to akurat nie jest mit. Mozna sobie poczytac o tym ciekawym zagadnieniu i zobaczyc wyniki testow w internecie. Jednak jego wplyw jest znaaaaacznie wyolbrzymiony. Szczegolnie w zastosowaniach domowych. Nowoczesne urzadzenia stosuja wielostopniowy recloking na drodze sygnalu cyfrowego do przetwornika D/A a nowoczesne odbiorniki cechuja sie wysokim jitter rejection, sa nawet wyposazone w uklady odzyskiwania jittera. Np. DIR9001 czy odbiorniki Wolfsona.

Tolerancje Jittera dla odbiornikow okreslaja nawet specjalnie normy wedlug ktorych musza byc produkowane takie urzadzenia, wiec ...tym bardziej jego istnienie nie jest zadnym mitem

[tomaszg]

Obecnie na Viscie i w gore WASAPI nie powoduje juz takich problemow.

Chyba nie do końca. Pisałem już parokrotnie na AS - na win7 i xonarze nie udało mi się osiągnąć bit-perfect. Nie jestem specem windowsowym, więc może jakoś się to da, ale na pewno nie out of the box.

Jitter to akurat nie jest mit. [...] Jednak jego wplyw jest znaaaaacznie wyolbrzymiony. [...]
Tolerancje Jittera dla odbiornikow okreslaja nawet specjalnie normy wedlug ktorych musza byc produkowane takie urzadzenia, wiec ...tym bardziej jego istnienie nie jest zadnym mitem

Zwrot o "micie" był oczywiście skrótem myślowym. Jitter jest faktem fizycznym, ale jego realny wpływ na odtwarzany dźwięk jest zupełnie pomijalny. Jeśli tylko jest poniżej progu tolerancji, to nic złego się nie dzieje i wpływ na dźwięk jest mniejszy, niż efekt burczenia w brzuchu słuchacza Nawet jitter zegara w dac ma wpływ minimalny - takie wahania mogą wprowadzić zakłócenia w spektrum sygnału - jednak częstości będą grubo powyżej Nyquista, więc zdecydowanie niesłyszalne.

Ostatnio na AS znowu rozgorzała dyskusja na ten temat. Podobno z jakiegoś powodu S/PDIF jest szczególnie podatny na przenoszenie jittera. Znowu odnoszę wrażenie, że dyskusja odbiega w abstrakcyjną stronę...

[fallow]

Chyba nie do końca. Pisałem już parokrotnie na AS - na win7 i xonarze nie udało mi się osiągnąć bit-perfect. Nie jestem specem windowsowym, więc może jakoś się to da, ale na pewno nie out of the box.

Moznaby rozwinac temat ale forum o gentoo linux chyba nie jest najlepszym miejscem na dyskutowanie zagadnien windowsowych na Lynxie Two, kartach RME i EMU oraz M-Audio uzywalem po prostu natywnego ASIO, WASAPI przerabialem przez jakis czas tak dla checy, obecnie z DACiem DIY ktorego odbiornik USB jest zrealizowany na PCM2902 uzywam DS bo z WASAPi sa problemy. Do sluchania muzyki w zupelnosci wystarcza. Do produkcji zostaje interface audio na PCI i ASIO.

Zwrot o "micie" był oczywiście skrótem myślowym. Jitter jest faktem fizycznym, ale jego realny wpływ na odtwarzany dźwięk jest zupełnie pomijalny. Jeśli tylko jest poniżej progu tolerancji, to nic złego się nie dzieje i wpływ na dźwięk jest mniejszy, niż efekt burczenia w brzuchu słuchacza Nawet jitter zegara w dac ma wpływ minimalny - takie wahania mogą wprowadzić zakłócenia w spektrum sygnału - jednak częstości będą grubo powyżej Nyquista, więc zdecydowanie niesłyszalne.

Ostatnio na AS znowu rozgorzała dyskusja na ten temat. Podobno z jakiegoś powodu S/PDIF jest szczególnie podatny na przenoszenie jittera. Znowu odnoszę wrażenie, że dyskusja odbiega w abstrakcyjną stronę...

Sprawa jest na wieksza dyskusje. Generalnie zgadzam sie, ze jego wplyw na odtwarzany dzwiek mozna po prostu pominac. Juz wiekszy wplyw moga miec pewnie tluste wtyki RCA hehe

Po prostu producenci audiofislkich sprzetow musza z czegos zyc i tworza oraz odgrzebuja problemy - tam gdzie generalnie ich nie ma by audiofile mieli na co wydawac pieniadze

Oczywiscie, jest wiele czynnikow ktore nie sa slyszalne przy pewnym niskim lub srednim poziomie jakosci sprzetu a dopiero przy hi-endzie lub rzeczy pozornie bagatelizowane ale moim zdaniem wiekszosc rzeczy do ktorych tak przywiazuja wage audiofile sa po prostu pomijalne i szkoda czasu by zawracac sobie nimi glowe, lepiej sluchac muzyki

[nUmer_inaczej]

Panowie - wracając do tematu - jedna rzecz nie daje mi spokoju.
Do odtwarzania muzyki wykorzystuję mplayer - skompilowany z flagą rtc

Code: Select all

media-video/mplayer:rtc - Enables usage of the linux real time clock. The alternative is software emulation of rtc

W jakim zakresie przetwarzania dźwięku zatem mplayer wykorzystuje jądro rt?
dodam, że mplayera odpalam następująco:

Code: Select all

mplayer -ao jack,alsa -rtc-device /dev/rtc0 [pozostałe opcje]

[canis_lupus]

rtc to nie rt. Flaga RTC powoduje,że mplayer używa sprzętowego generatora czasu a nie emuluje go programowo.

[nUmer_inaczej]

Przyznaję, że masz oczywistą rację - błąd z mej strony.