2. IDŐZÍTÉS

Ahogyan az életben nagyon sokszor a megfelelő időzítés jelenti egy dolog kulcsát, esetünkben is az időzítés határozza meg, hogy gépünkön tudunk-e normális módon zenei programokat futtatni, vagy sem. Vegyünk egy hétköznapi példát! Van egy vasútvonal, ahol a szerelvények közlekedését menetrend írja le. Ha a vonatok nem a menetrend szerint közlekednek, hanem össze-vissza, abból ugye nagy balhé lesz. Nézzük meg ezt a balhét közelebbről! Először tételezzük fel, hogy  csak 5-10 perc pontatlansággal érkeznek, illetve indulnak a szerelvények az állomásokról. Emiatt ugye jópár utas lemarad, mások pedig mérgelődni fognak, mert elkésnek valahonnan, illetve feleslegesen várakoznak az állomáson. Azért az utasok zöme eléri a vonatot, a késés pedig még azon a határon belül van, amit még elviselnek. Nagyobb lesz a baj, ha már órákat térnek el a menetrendtől, mert sok utasnak ez már messze kívül esik a tolerálható eltérés határától. Végül, előáll egy olyan kaotikus helyzet, amikor már a vasutasok sem tudják, hogy melyik vonat mikor jön, vagy megy, képtelenek lesznek a biztonságos közlekedést fenntartani, és a megfelelő irányítás hiányában súlyos balesetek következnek be.

Számítógépünk időzítése is hihetetlenül fontos ahhoz, hogy képes legyen megbizhatóan működni, vagyis a hardveren a szoftverek futása úgy történjen, ahogyan azt a programozók elképzelték. Minden számítógép processzorát egy kvarc oszcillátor vezérli, ez közismert, hiszen mindenki tudja, hogy gépében a processzor mekkora órajellel ketyeg. Még az is ismeretes, hogy a PC-kben a processzor órajele és az ún. "FSB" órajel nem azonos, hanem a kettő között van bizonyos összefüggés, de igazából ezek a kérdések a felhasználókat nem érdeklik. Azzal meg pláne nem foglalkozik az átlag számítógépező, hogy ezeken kívül még miféle órajelek és időzítő jelek határozzák meg a PC részegységeinek szinkron működését és a programok futásának szinkronitását. Baj csak akkor van, amikor a gép nem azt csinálja, mint amit elvárunk tőle, és keresni kezdjük a hiba okát. Mint korábban említettük, a zenei programok időzítés iránti igénye rendkívül nagy, hiszen egy megszólaló zenében sem midi, sem audio formában nem lehetnek lemaradások, vagy előre sietések, mert azt már kicsi ingadozás esetén is meghalljuk. A vonat hasonlatra visszatérve, másodperc pontosságra kell érkezniük a szerelvényeknek. Konkrét számokra fordítva: a midi események elcsúszását bizonyos körülmények között már jóval 10 ms alatt is észreveszzük. Audio jelnél pedig kívánatos a "sample" pontosság, vagyis pl. 44.1 kHz mintavételi frekvencia mellett az ingadozás ne haladja meg a 10 mikroszekundumot. Egyéb PC-s alkalmazásoknál ritkán van ilyen fokozott igény. Többnyire egy adott programrészlet végrehajtását kell csak a gépnek megoldania, az időtényező másodlagos. Legfeljebb annyit tapasztal a felhasználó, hogy gyorsabb gépen gyorsabban lefut egy bizonyos program, gyorsabban betölti ugyanazt a fájlt, simábban gördülnek a menük, meg ilyesmiket.

Vegyünk egy nagyon egyszerű példát!

Legyen egy midis számítógépünk, meg egy midis szintink. A PC-n inditsunk el egy dalszerkesztő (szekvencer) programot, és vegyük fel vele két kezi klampírozásunk eredményét! Ritkán gondolunk csak bele, hogy milyen időbeli folyamatok is zajlanak le ilyenkor. Tekintsük végtelenül leegyszerűsítve, hogy mi is történik ilyenkor!

1. Játszunk a billentyűzeten. Ezt egy hasonló mátrix érzékeli, mint a PC billentyűzetet lekezelő mátrik, csak a lekérdezés sokkal gyorsabb, annak érdekében, hogy a billentyűk lenyomását, annak sebességét (dinamika), felengedését azonnal észlelje az erre hivatott chip, és ezeket az információkat továbbadja a hangkeltő áramkörnek, illetve kikódolja a kifelé küldendő midi üzeneteket. A billentyűk lekérdezését meg lehet elég gyorsan oldani, az utána következő feldolgozási munka azonban már kicsit bonyolultabb, hiszen több ujjunk is van (szerencsés esetben tíz), és ha nagyon gyorsan virgázunk a billentyűzeten, a játék követése bizony komoly feladat. A mai mikrokontrollereknek ez persze már meg se kottyan, ami alatt azt értjük, hogy a billentyűzet lekérdezése és a kívánt kódok előállítása nem fogja hallható mértékben fékezni a játék reprodukcióját, vagy megszólaltatását. Szóval, a midi kódok szépen, gyorsan előállnak, azonban ezeket nagyon gyorsan át is kell hajtani egy darab dróton a számítógépbe. Erre az átküldésre használjuk a MIDI-t, ami ugye egyrészt egy hardver (áramhurkos rendszer, hogy optocsatolóval földfüggetleníteni lehessen), másrészt meg egy protokoll. A protokoll magvát egy aszinkron soros átvitel képezi, vagyis a hangszerben előállt kódokat, amik hagyományosan 8 bites kódok sorozata, szét kell szedegetni bitekre, és kis csomagokban átzavarni a midi kábelen. A midi átvitel sebessége durván 31000 bit/s, tehát, ha figyelembe vesszük, hogy a 8 bites kódokat még előlről-hátulról megtoldjuk egy-egy bittel, akkor durván 3000 bájtot tudunk áthajszolni a rendszeren másodpercenént. Egy billentyű leütés 3 bájtot generál, nagyon durván másodpercenként ezer eseményt képes a midi átadni. Ez persze nagyon hasraütős számolás, mert nem vesszük figyelembe a futóstásuszt (Running Status), és egy csomó más tényezőt, de durva közelítésre alkalmas. Elméletileg tehát 1 ms az az időbontás, amire a midi képes. Térjünk azonban viszza a klampírozáshoz! Játsszunk valami kortárs zenét a billentyűn, vagyis csapkodjuk tíz ujjal vadul, ahogy csak bírjuk! Mondhatnánk, hogy itt az első probléma, hiszen, ha pl. jobbkézzel egyszerre leütünk 4 hangot, azt a midi eleve nem képes átvinni, hanem csak szorosan egymás után, mondjuk 4 ms idő alatt. Ettől még persze nem fogjuk bontott akkordként hallani a hangokat, de meglátjuk, hogy ez már nem túl egészséges így. A billentyűzet mátrix természetesen eleve időben elkülönülten érzékeli a billentyűk leérkezését, hiszen a mátrix lényegéből fakadóan nem is tehetné másként, nameg az ujjaink is tuti, hogy pici időeltéréssel érnek le, tehát a kódok időben egymás után állnak elő. Mindenestre lényegesen gyorsabban állhatnak elő, mint ahogyan a midi interfész chip, vagy a mikrokontroller sorosító mechanizmusa be tudná őket kebelezni és kiadni a soros jelfolyamot. Ezért előtárolni (pufferelni) kell a kódokat. Erre valamilyan FIFO áramkör, illetve logika szolgál, melynek a működtetése szintén igényel egy kis időt. Az érkező kódok tehát  egy picit várakoznak a folyosón, mielőtt beférnének a sorosító áramkörbe. Emiatt eleve a billentyűk leütése és a kódok kiküldése közti időintervallum picikét változhat, attól függően, hogy mekkora a tülekedés a midi kijárat előtt. A példánkban emlegetett egyszerű midis keyboard, vagy szintetizátor esetén persze nem tudunk nagy káoszt előidézni, de ha tömör jelfolyam árad kifelé, pl. egy hardver szekvencer, vagy kísérő automatika kimenetén, akkor lehet kisebb - nagyobb időcsúszkálás.

2. A midikábelen tehát szépen mennek a kódok a PC felé, aminek ezeket el kell kapkodnia. Ez a gyakorlatban jó esetben úgy néz ki, hogy amikor a soros interfészen beérkezik egy kód, azt az áramkör visszaalakítja párhuzamos kóddá, akkor keletkezik egy megszakítás (interrupt) a rendszerben. Erre a processzor hanyatt-homlok abbahagyja összes addigi ténykedését, megjegyzi, hogy hol tartott ezekkel, és rohan elvenni a bejövő kódot, hogy azt egy időadattal együtt letárolja a memóriába. Az időadat nem más, mint a "REC" gomb megnyomása óta eltelt idő.

A baj az, hogy egy mai windowsos PC-n eleve van egy halom interrupt (gyárilag 16, manapság ezek még szaporodnak az IRQ holderek által), és nem csak a midi feldolgozó chip kiabál feldolgozást kérve, hanem még egy csomó más áramköri elem is. Ráadásul több programszál (thread) fut egyidejűleg (látszólag legalábbis), vagyis egy megszakítás végrehajtásához a processzornak túl sokat kell molyolnia, mielőtt az érdemi ténykedéshez hozzá tudna kezdeni. Majd, természetesen az éppen felfüggesztett szálak futását ott kell folytatni, ahol abbahagyta. Figyelembevéve, hogy a szerencsétlen processzornak a Windows mennyi munkát ad akkor is, ha az ember nem csinál semmit a gépen, érthető, hogy komoly problémák lehetnek már a bájtok elkapkodásánál és letárolásánál is. A midi fogadó és adó eszközök kezelését a Windows természetesen drájvereken keresztül végzi, tehát nagyon sok múlik azon is, hogy az illető eszköz (midi port) driverei mennyire jól vannak megírva, illetve, hogy az ezeket hívó program mennyire hatékonyan tud bánni a rendelkezésre álló időszeletekkel.

A hardver szekvencereknek hatalmas helyzeti előnyük van a midi bemenő jelek feldolgozásakor, hiszen nekik a bejövő jelek elkapkodásán kívül alig van dolguk. Ezen a tényen az sem változtat sokat, hogy az illető szekvencer emellett a meglevő sávok anyagát már a kimenetre juttatja, mert ennek az információnak a mennyisége eltörpül a windows képernyők átrajzolgatása miatt mozgatott adatok mennyisége mellett. A programozóknak tehát gondoskodniuk kell arról, hogy a midi bemenő jelek elvétele rendkívül precízen megtörténjen. Nem csak arra kell törekedniük, hogy a lehető legnagyobb prioritást adják az illető IRQ-nak, hanem arra is, hogy ez a helyzet ne buggyanjon meg néhány windows struktúra módosítás után. Mert ha más program szintén ilyen erőszakosan ragaszkodik saját eszközének azonnali kiszolgálásához, akkor máris kész a baj. Itt természetesen az együtt futó alkalmazások, illetve thread-ek kavarhatnak be. Vagyis, a Windows tisztán tartásával mi magunk is sokat tehetünk azért, hogy a gép azt csinálja, amit a programozó kitalált.

3. Képzeljük el, hogy a bejövő midi jeleket mégis frankón elkapkodta a proci, és a pontos időkódokkal együtt szép sorjában letárolta a memóriában. Most nem foglalkozunk a formátumokkal, szerkesztési furmányokkal, hanem játsszuk vissza a felvett anyagot!

Említettük már, hogy az általunk egyidejűként leütött hangok elméleti okokból úgysem egyidejüként kerültek továbbításra, és pláne nem egyidejűként kerültek letárolásra. Most a visszajátszásnál ez tulajdonképpen megkönnyíti a helyzetet, hiszen a beérkezett kódok között biztosan nincsenek olyanok, amelyek a midi vonalon ne tudnák szépen, torlódás nélkül egymást követni. Hiszen egyszer már átestek a midi vonal gyötrelmein, vagyis szétrázódtak egymástól időben biztos követési távolságra. Csakhogy:

- Amint egynél több sávot játszunk le egyidejűleg, az előbbi kép már nem lesz igaz

- A feljátszási pontatlanságot kikvantálva (a zenei hangokat helyükre igazítva) a letárolt, egymástól időben kissé szétcsúszott kódok ismét egy időben akarnak kimenni a midi porton, tehát újabb tumultus képződhet.

- A szerkesztési műveletek közben gyakran helyezünk el kontrollereket, vagyis paraméter változtatásokat, melyekkel borzasztó gyorsan bedugíthatjuk midi kimenetünket.

- Közben Windows-unk teszi a dolgait, vagyis kever-kavar, figyel, variál, tehát a kimenet előtt várakozó kódoknak még arra is várniuk kell, amíg a megfelelő rutinok kiküldik őket. A kiküldést mégis egyszerűbb leprogramozni, mint a bemeneti jelek kezelését, mert nem egy véletlenszerűen érkező jere kell vadászni, hanem a memóriában tárolt adatokat kell (lehetőleg) helyes időzítéssel kiadni.

4. A jelek tehát ismét a midi kábelen futnak, most a PC-ből a hangszerbe. Most ne bonyolódjunk bele a nem szabványos midi kábelek, illesztő áramkörök és routerek által okozott botrányokba, hanem tételezzük fel, hogy minden a nagy könyvben (MIDI szabvány) leírtak szerint zajlik. A hangszer midi bemenetének tényleg nincs más dolga, mint a bejövő adatok fogadása. Ezek után viszont egy nagyon cikis művelet történik: a jelek értelmezése. A régi szintik általában a NOTE ON/OFF üzeneteken és a PROGRAM CHANGE-en kívül másra nem reagáltak. Ennek a pár kódnak az értelmezésére nagyon egyszerű volt pici és gyors programot írni a hangszer mikrovezérlőjéhez, ami a feldolgozott utasításokat a hangkeltő csipnek adta át. Ma már alapvetően fontos a hangszerek lehető legteljesebb midi implementációja, vagyis, nagyon sok midi parancsot kell igen gyorsan értelmezni, és végrehajtásra átadni. Mindezt multitimbrális és 64, 128, vagy még ennél is magasabb polifónia fokú hangkeltő rendszernek kell tálalni. Maga a hangkeltő rendszer is el lehet foglalva a saját bajaival, és a hangszeren belül is lehetnek belső adatátviteli torlódások, ezért aztán igen könnyen előfordul, hogy a bemenő jelek 8-10 ms múlva adnak csak ki hangot. Több midi bemenet, illetve belső szekvencer együttes használata még jobban bekavar.

A hangszer operációs rendszerének fejlesztője ismét csak nem tehet mást, mint a korlátozó tényezők figyelembevételével olyan megoldásokat alkalmaz, melyek legalább a normális körülmények között biztosítják a hangkeltő rendszert meghajtó jelfolyam lehető legkisebb időbeli csúszkálását.

Látjuk tehát, hogy a midi jelútban nagyon sok lehetőség van arra, hogy az időzítés elromoljon. A midi szabvány kitalálása óta hangszerekben alkalmazott mikrokontrollerek sebessége kb. 50-szeresére, a PC-k órajele 100-200-szorosára nőtt. Közben a midi még mindig 31k-val cammog, és az időzítési problémák ugyanúgy megvannak, mint annak idején. A hangszerek mikrokontrollerei és a számítógépek processzorai is annyi minden plusz feladattal terhelődtek meg időközben, hogy a hajdanán legfontosabb midi lekezelés már lassan csak melléktevékenységet jelent.

És a fenti eszmefuttatás csak a midiről szól! Ezután következik a hang digitalizálás, a tárolás, és visszajátszás nemes feladata, amely egy egyszerű sztereo jel esetében is 2 nagyságrenddel nagyobb terhelést jelent a számítógép számára. Könnyű belátni, hogy a hanggal való bánás már igazi virtuozitást igényel a programozó részéről. Akkor is, ha "csak" egy egyszerű rögzítő/visszajátszó programról van szó, de azt a Windows dzsungelében futtatjuk. A helyzet még tovább fokozódik, akár Pelikán elvtárs idejében, ha:

- több hangsávval dolgozunk, esetleg képes a rendszerünk több sáv egyidejű felvételére és/vagy lejátszására

- a processzor real time hangfeldolgozást is végez, pl. effektek, tömörítés, stb.

- midi szekvencert is futtatunk a hangsávokkal szinkronban

- képi anyagot is rögzítünk, szerkesztünk mindezek mellett (a mazochisták itt eljutnak a csúcsra!)

Ha az ember végiggondolja a fent vázolt borzalmakat, nemhogy a fejlesztéstől, de még a használattól is elmegy a kedve. Azért a helyzet nem annyira borzasztó. A következőkben azt nézzük át, mit tehetünk annak érdekében, hogy PC-nk mégis alkalmas legyen mindezen feladatokra.

Vissza a PCMusic kezdőoldalára

Vissza a Zenei PC konfigurációk kezdőoldalára