Home | 6-tehnologija | 62-inženirstvo
3.4 ZVOČNE KARTICE, GONILNIKI IN LATENCA Gonilnik predstavlja vmesno plast med operacijskim sistemom in določeno napravo. Gonilniki omogočajo standardiziran dostop do poljubne naprave; na najnižjem nivoju to funkcijo opravlja BIOS, oziroma Basic Input/Output System. To je skupek kode, vgrajene v poseben čip na matični plošči, ki skrbi za nizkoravensko komunikacijo med operacijskim sistemom in strojno opremo. Na nivoju operacijskega sistema do vhodno-izhodnih naprav dostopamo prek gonilnikov. Arhitektura gonilnika in njegova integracija v operacijski sistem je strogo odvisna od jedra operacijskega sistema in njegove modularnosti. Pri operacijskem sistemu Microsoft Windows je Microsoft razvil tako imenovani "Windows Driver Model" (WDM), ki je nekakšen API oziroma model, po katerem se piše gonilnike za posamezne naprave, da lahko Windows operacijski sistem do njih dostopa po svojih WDM standardih. Na žalost pa se je takšna integracija v jedru operacijskega sistema izkazala za mnogo prepočasno za razvoj realnočasovnih aplikacij. Zaradi močnega razvoja računalniških igric je bil Microsoft prisiljen omogočiti nižjenivojski dostop do strojne opreme ter tako zmanjšati mrtvi čas oziroma latenco pri uporabi vhodno-izhodnih enot. Ta standard je Microsoft poimenoval "Direct X"; uporabljal se je za dostop do zvočne in grafične opreme na računalniku zlasti na področju razvoja računalniških igric. S pomočjo "Direct X" standarda lahko do zvočnega signala dostopamo že v času 40 milisekund, medtem ko je bilo pri WDM standardu za to potrebnih 750 milisekund ali več. Standard je bil široko sprejet tudi pri proizvajalcih strojne opreme in tako so gonilniki za vse komercialno priljubljene zvočne kartice vedno podpirali tudi standard "Direct X". Ker pa je razvoj napredoval tudi na področju profesionalne glasbene tehnike, je postalo povpraševanje po nižjih latencah večje, zato se je nemški proizvajalec programske Steinberg Media Technologies GmbH odločil za Windows platformo postaviti standard, ki ga je poimenoval ASIO. ASIO je tako kot WDM in Direct X zgolj model (Application Programming Interface - API) za nizkonivojsko dostopanje do zvočne opreme. Mnogi proizvajalci zvočnih kartic (Teratec, Yamaha, EMU, itd.) so hitro ugotovili, da lahko ostanejo na tržišču le, če svojim zvočnim karticam napišejo tudi ustrezne ASIO gonilnike in s tem uporabnikom operacijskega sistema Windows omogočijo nizkonivojski dostop do opreme ter s tem mnogo nižjo latenco. Tovrstne zvočne kartice so z ASIO gonilniki in programsko opremo, kot je denimo Cubase, dosegale tudi dostopne čase 10 milisekund ali manj. Tudi na področju Applovih računalnikov in operacijskega sistema se je razvila izredno močna glasbena industrija, zlasti okrog Pro Tools imenovane programske opreme podjetja eMagic. Osnovni nizkonivojski API, ki je omogočal dostop do avdio opreme na Applovih računalnikih, se je imenoval Core audio. Ker je podjetje Apple že od nekdaj ponujalo tako strojno kot programsko opremo, je za kompatibilnost gonilnikov poskrbelo kar samo. Komercialni proizvajalci zvočnih kartic so sledili ASIO standardu in se s tem pridružili Steinbergovim programskim rešitvam na operacijskem sistemu Microsoft Windows. Microsoftov tržni pristop je bil namreč že od nekdaj bolj odprte narave, saj je omogočal, da Microsoftova okna tečejo na kateremkoli podprtem računalniku kateregakoli proizvajalca. Ker pa se je v zadnjih nekaj letih strojna oprema še toliko bolj pocenila, je postal trg uporabnikov mnogo večji, zahteve pa bolj raznolike in začel se je razvoj programja odprtega tipa, ki je bil osnovan na operacijskem sistemu Linux. V zadnjih nekaj letih se tudi na tem operacijskem sistemu pojavlja vrhunsko programsko orodje za obdelavo in sintezo zvoka, zato je bilo tudi na operacijskem sistemu Linux potrebno urediti nizkonivojski dostop do avdio opreme. Sprva je ta problem reševala platforma, imenovana OSS, ki je avtorjem odprtokodnih gonilnikov omogočala integracijo v jedro operacijskega sistema. Ker pa platforma OSS ni zadoščala strogim zahtevam potrošnikov na področju glasbene industrije, se je na pobudo razvijalca Jaroslava Kysela začel tako imenovani projekt Alsa (audio-linux-soud-architecture). Alsa je še vedno aktiven odprtokodni projekt, ki omogoča nizkonivojsko pretakanje zvočnih vsebin med jedrom in gonilniškim sistemom za vhodno-izhodne vmesnike. Današnji standard v glasbeni produkciji zahteva dostop do zvočnega signala v manj kot desetih milisekundah, saj je edinole tako mogoče delo v realnem času. Omenjene platforme, torej Core audio na Machintoshu, ASIO na Windowsih in Alsa na Linuxu, to omogočajo z zvočnimi karticami, ki so v teh sistemih podprte, in s programsko opremo, ki te platforme podpira. 3.5 OBDELAVA SIGNALOV V REALNEM ČASU Pri načrtovanju realnočasovnih sistemov, torej sistemov, ki se odzivajo v realnem času, moramo biti pozorni na časovno in matematično zahtevnost algoritma, ki ga ta sistem izvaja. Če je algoritem pretirano časovno zahteven, s tem v sistem uvedemo dodatni mrtvi čas, ki skupaj z mrtvim časom vhodno-izhodnih naprav ustvarja določen zamik med vzbujanjem sistema in njegovim odzivom. Ta mrtvi čas pogosto imenujemo latenca (latency). Poleg časovne zahtevnosti algoritma pa moramo biti, kot smo omenili zgoraj, pozorni tudi na tako imenovano matematično zahtevnost algoritma. Matematična zahtevnost algoritma nam pove, koliko procesorskega časa je potrebnega, da se lahko algoritem izvaja v realnem času in tudi pri daljšem delovanju ne povečuje svoje latence. V tehniki se takšnemu načinu obratovanja reče "inline" procesiranje za razliko od "offline" procesiranja, kjer sistem teče v podaljšanem času. Pri "offline" procesiranju je namreč za 2-minutno delovanje sistema potrebno več kot 2-minutno delovanje računalnika. Takšni sistemi so za kakršnekoli realnočasovne operacije vsekakor neuporabni. V nadaljevanju si bomo ogledali, katerim pogojem mora zadostiti realnočasovni sistem, pri katerem načrtujemo mrtvi čas, krajši od 10 milisekund. 3.5.1 ČASOVNA ZAHTEVNOST OBDELAVE SIGNALOV Pri tehniki digitalne obdelave signalov se za predstavitve signalov poslužujemo tako časovnih kot frekvenčnih prostorov. Algoritmi, ki tečejo v časovnem prostoru imajo praviloma najhitrejši odziv, saj potrebujejo za izračun akcije, ki jo izvajajo nad vzorcem, le nekaj zaporednih vzorcev. Časovna zahtevnost tovrstnih algoritmov je torej le nekaj vzorcev. Tipični primer algoritma v časovnem prostoru je filter drsečega povprečja (moving-average-filter). Mnogo bolj sofisticirani algoritmi pa potekajo v frekvenčnih in drugih prostorih. Za prehod iz časovnega v te bolj kompleksne prostore seveda potrebujemo nabor (okno) vzorcev, nad katerimi izvajamo določeno analizo, s pomočjo katere zgradimo signal v prostoru, kakršnega potrebujemo. Pri načrtovanju našega sistema smo se odločili za časovni prostor povprečnih moči, ki so izračunane kot povprečna moč okna velikosti 256 vzorcev. Za tako predstavitev smo se odločili iz sledečih razlogov: 1. Pri algoritmu bo potrebno odštevanje ambientalnih signalov, ki jih bomo v sistem dovedli s pomočjo referenčnih mikrofonov; pri tem postopku bi bilo odštevanje na posameznih vzorcih preveč nezanesljivo – za mnogo robustnejše se namreč izkaže odštevanje povprečnih moči oken 256 vzorcev. 2. Prehod v spektralni postor bi bil za naš namen matematično prezahteven. Za obdelavo signala smo torej izbrali prostor povprečnih moči. Za velikost okna smo izbrali 256 vzorcev, s čimer smo v sistem vnesli dodatni mrtvi čas trajanja 5,8 milisekund (s predpostavko, da delamo z vzorci, ki so bili vzorčeni pri frekvenci 44,1 kHz). Lahko bi izbrali manjše okno, na primer 128 vzorcev, in s tem dobili manjši mrtvi čas, seveda pa vnesli v sistem tudi dodatno nenatančnost. Ko smo časovni signal privedli v prostor povprečnih moči, smo se odločili, da bomo vse nadaljnje operacije, vključno z izračunom odziva sistema, opravljali le še v tem močnostnem prostoru. Če bi iz močnostnega prostora ponovno prehajali nazaj v časovni prostor, bi prišle do izraza vse napake in poenostavitve, ki smo jih ravno s tem prehodom odpravili. Pri prehodu v prostor povprečnih moči smo namreč izgubili nekoliko informacije o časovnem signalu, tako da bi pri rekonstrukciji le-tega naredili velikansko napako, ki se ji bomo raje ognili s tem, da bomo do nadaljnjega ostali v močnostnem prostoru. Obdelava signala v močnostnem prostoru je mnogo bolj preproste narave, zato s stališča časovne zahtevnosti algoritma ne predstavlja drastičnega poslabšanja in je v primerjavi z mrtvim časom 5,8 milisekund, ki smo ga v postopek vnesli z omenjeno transformacijo, zanemarljiva. 3.5.2 MATEMATIČNA ZAHTEVNOST OBDELAVE SIGNALOV Da bo lahko izvajalnik kode, v našem primeru torej centralno procesna enota osebnega računalnika, kodo izvajal v realnem času (inline procesiranje), moramo poskrbeti za to, da bo procesna enota kos vsem izračunom, ki jih mora v svojem času opraviti. Ker centralno procesna enota operira samo z binarnimi vrednostmi, kodo pa pišemo v okolju Pure-Data, kjer operiramo z 32 bitnimi števili s plavajočo vejico, je takšno vrednotenje izredno težko; omenimo le nekaj dejstev, na katere moramo biti pozorni. Med matematično zahtevnejše procese lahko štejemo prehod v prostor povprečnih moči, glajenje posameznih krivulj, odštevanje ambientalnih signalov in adaptivno filtriranje (določanje praga proženja). Pri vseh omenjenih procesih smo se trudili minimizirati število matematičnih operacij, ki so zanje potrebni. Pri glajenju krivulj to pomeni, da smo uporabili poenostavljen filter tekočega povprečja, ki uporablja za izračun trenutnega izhoda le dva vzorca, izogibali smo se nelinearnosti in kakršnim koli povratozančnim odvisnostim ter poleg tega poskrbeli za to, da se glajenje funkcije izvaja le na začetni ravni in je čimredkeje potrebno tudi na nivoju posameznih značilk. Vse omenjene algoritme si bomo natančneje ogledali v četrtem poglavju, pri opisu naprave in njenega delovanja. Omenimo le še, da smo za centralno procesno enoto v našem sistemu izbrali procesor Pentium Northwood, ki je znan predvsem po svoji sposobnosti matematične manipulacije 32-bitnih števil predstavljenih s plavajočo vejico in je zaradi tega v multimedijski produkciji najbolj pogosto uporabljan procesor. 3.6 ČLOVEŠKA PERCEPCIJA REALNEGA ČASA Ko govorimo o realnočasovnem odzivu, torej o tem, da se nek sistem odzove takoj, govorimo o sistemih, ki se odzovejo v manj kot desetih milisekundah in so se hkrati sposobni z istim mrtvim časom odzvati na več soslednih dogodkov. Da dosežemo to kritično mejo desetih milisekund mrtvega časa, moramo optimizirati časovno zahtevnost našega logaritma. Da pa poleg tega poskrbimo, da je sistem sposoben izračunati odzive za več soslednih dogodkov, moramo poskrbeti tudi za optimizacijo matematične zahtevnosti algoritma. Do kritične meje 10 milisekund je prišlo pri človeku preprosto zaradi tega, ker se večina našega fizičnega okolja odziva v rangu do 10 milisekund. Primer: pri igranju klavirja preteče od trenutka, ko pianist pritisne tipko, do tega, da zvok zazna s svojimi ušesi, približno 2,5 milisekund. Zaradi tovrstnih pojavov je tako človek v svoji psihoakustični interpretaciji okolice razvil določeno časovno toleranco. To toleranco s pridom izkoriščamo, ko načrtujemo realnočasovne sisteme, saj nam omogoča razvoj sistemov, ki so teoretično nemogoči (nekavzalni sistemi, filtriranje s predikcijo, feedforward regulacija). Omeniti pa moramo, da te stvari morda ne bi veljale, če bi načrtovali nevrofiziološko biofeedback aplikacijo: toleranca živčnega sistema (aferentnega in eferentnega živčevja) je namreč manjša, saj ni dodatnih mrtvih časov iz fizičnega okolja, na katere bi se živčni sistem z evolucijo adaptiral. Zahteve za delovanje našega algoritma so torej sledeče: • mrtvi čas mora biti krajši od 10 milisekund • naprava mora brez izpadov (dropouts) delovati na osebnem računalniku
Ta prispevek je na portalu Publikacije.net objavil/a leskovsek dne 2007-04-24.
Ocenite prispevek:
5 out of 54 out of 53 out of 52 out of 51 out of 5
# of Ratings = 1 | Rating = 4/5
Publikacije.net - portal svobodnega znanja
