Késés és monitoring
A számítógép alapú zenekészítés kőkorszakában (’70-es évek) a késés percekben, órákban vagy napokban volt meghatározható. A számítógépes zenészek leültek megkomponálni a zenét a QWERTY billentyűzetükön és kimentek kávézni vagy aludni egy jót, amíg a CPU elkészítette ebből a hanganyagot. A ’90-es évek vége felé a késés (latency – az időbeli különbség a hallani kívánt hang elvárt ideje és annak tényleges megjelenése között) egy másodpercnél rövidebb intervallumra csökkent.
A késés egy komoly, idegesítő probléma volt mindazok számára is, akik szerettek volna valamit felvenni és lekeverni a számítógép segítségével, nem beszélve az élő effektek használatáról.
Azóta a gyártók óriási lépéseket tettek és fénysebességgel fejlődik a technika a számítógép alapú zenekészítést figyelembe véve. Példának okáért a Steinberg cég ASIO és az Apple Core Audio szolgáltatásai nagyon kis késésű be- és kimeneti hangot eredményeznek. (Ha még mindíg a Windows MME-t használod, akkor nem is érdemes tovább olvasnod.) Az a tény, hogy a számítógépek központi egysége, a CPU az elmúlt évtized alatt 10-szer gyorsabb és biztosabb teljesítményre képesek, már csak hab a tortán. A késés ma nem probléma mindaddíg, amíg nem okoz problémát. Utóbbi esetben is több lehetőség van a megoldásra. Ahhoz, hogy a megfelelő megoldást kivitelezni tudd, meg kell értened a probléma okát és milyenségét.
Sokat gondolunk arra, hogy a mai számítástechnika hihetetlen mód gyors és ez csak fejlődni fog, mégis a “jó öreg” analóg audio sokkal gyorsabb. Egy analóg rendszerben az analóg jel fénysebességgel terjed (nem szó szerint). Az ellentét a digitális rendszer, ahol az egész csak adathalmaz – bináris számrendszerben. Az adatok egyik helyről a másikra való utaztatása időigényes és a feldolgozásuk is az.
Tudjuk, hogy egy digitális audió rendszerben a késést az adatok egyik helyről a másikra történő eljuttatása okozza (és adott esetben ez az út visszafelé is megjelenik, hisz jó az elkészített anyagot élőben hallgatni). Egy tipikus feladat a merevlemezről kiolvasni egy hangsávot, majd zengetőt alkalmazni rajta és összekeverni más hasonló sávokkal, amik együtt kerülnek a hangkártyába vissza a monitorozást (visszahallgatást) segítendő. A késés egy rendszerben olyan, mint a zajszint: ha minden elem csak kicsit zajos, akkor a sok elem esetében ez természetesen többszöröződik és miért ne lenne ugyanez a helyzet a késéssel? Ha több adatot kell küldeni, nehezedik a feladat és minden sávnál annyival kevesebb idő jut a feldolgozásra.
Minden audió jel, mint például a mikrofonból érkező egy konverterbe jut, ami azt digitálissá alakítja. Ez az A/D (analóg-digitális) konverter. A számítógép által már értelmezhető adat így bekerül egy bufferbe, “raktárba”. Ezután a képzeletbeli raktárvezető szól az operációs rendszernek (pl. Windows), hogy megjött az áru és be lehet cipelni. Ha a becipelés megtörtént, jöhet a következő szállítmány. Ez a leegyszerűsített példa a valóságban egy komolyabb folyamatot jelent, de a lényege ez.
Késés a visszahallgatásnál
Sokkal komolyabb problémát jelenthet egy zenész számára a késés, ha például az ének közben szeretné magát visszahallani a fejhallgatón keresztül. Ha ez az élő jel bekerül a számítógépbe, annak más sávokkal való keverése és a monitorozás céljából történő visszaküldése kétszeresen is lelassítja azt: először, amikor a számítógépbe kerül (jön az áruszállító bácsi), majd a visszaküldéskor. Ez a be-ki irányba történő jelfolyam egy zavaró tényezőt jelent mindenki számára.
Két egyszerű megoldás létezik a probléma orvosolására; a harmadik túl drága. Legelőször is jó tudni, hogy a legtöbb audió interfész (külső hangkártya) zero latency, azaz “nulla késés” visszahallgatásra is alkalmas. Ez egy analóg busz, ami a beérkező jelet annak digitalizálása vagy számítógépbe küldése nélkül egy kimondottan visszahallgatási célra tervezett fejhallgató (vagy egyéb) kimenetre is átküldi. Amint beállítod ezt a funkciót az interfész beállításainál, a zenész a játékkal egyidejűleg hallhatja szinkronban a zenét. Ilyenkor a felvételi sáv egy picit késhet, de ez senkinek nem lesz észrevehető, hisz a felvételre kerülő anyagot a monitoring buszon keresztül hallgatja a zenész vagy aki akarja.
Növekvő késés a terhelés függvényében
Abban az esetben, ha az interfész nem rendelkezik hasonló adottságokkal, hasonlóképp megoldhatod a problémát egy hardware eszközzel; talán egy kis átalakítás is szükséges lehet. Mindenek előtt érdemes a hangkártyát egy aux vagy busz kimeneten keresztül egy keverőpulthoz csatlakoztatni, hogy a teljes hanganyag lekeverését elkerüld. A digitális keverőpultoknál a rendszer optimalizáltsága miatt ugyan nem 0, de annyira kicsi a késés, hogy az szinte észrevehetetlen. A Yamaha már évekkel ezelőtt is gyártott 2ms késésű külső eszközöket. A keverőpultok többsége már rendelkezik hasonló funkcióval: a bemeneti jelet két helyre vezérelheted ki, így azt, amelyik a számítógépbe kerül késést előidézve neked már nem kell figyelned, csak a másikat, ami nagy sebességgel visszakerül feléd.
A legtöbb hangkártya megengedi, hogy a buffer (raktár) méretét beállítsd. Jogos lehet a kérdés, hogy “Miért ne állítanám a legkisebbre, hogy lecsökkentsem a be és kimenet közti időt?” Nyugodtan próbáld ki, de minél kisebb a buffer mérete, annál többet kell a processzornak (CPU) dolgoznia. Egy bizonyos pont után (ezt ki kell tapasztalni a saját rendszereden), a buffer méretének csökkentése pattogó zajos hanghoz vezet. Ezek a zajok átvitt értelemben azért keletkeznek, mert a processzornak ennél a tempónál el kell dobálnia egy-két “árut”, hogy tartani tudja a tempót.
Ebben az esetben (ha a késés hallható és a processzor már nem bírja a tempót,) a megoldás az, hogy venni kell egy gyorsabb számítógépet. Ettől függetlenül nem szabad elfelejteni, hogy minél több sávval dolgozol, több (akár virtuális) hangszerrel, szükséges lesz a buffer méretének növelése, pláne ha a mintavételezési rátát magasabbra veszed.
A MIDI esetében nem szabad figyelmen kívül hagyni, hogy a késés jelentősebb lehet, mert a MIDI eszköznek 1ms-ra is szüksége lehet a MIDI adat előállítására, majd a rendszernek újabb pár, hogy azt feldolgozza és audió jellé alakítsa. A MIDI eszközök használata esetén sokkal zavaróbb lehet a késés. Ez egy gyors rendszerrel és megfelelő interface-el kevésbé érezhető, de kis késést általában mindenki tapasztal. Ez a késés a megszoksz vagy megszöksz kategóriába tartozik: egy templomban játszó orgonista sem káromkodik folyton, mert később hallja a játékot (- a visszhangokról nem is beszélve). Egy koncerten a 20-30 méterre lévő hangfal kb. 20 ms késést követ, mégse zavar senkit.
A szoftware szintikkel a késés tovább csökken és mivel legtöbbünk ezt használja, nem kell a falat kaparni. A softwares effektek viszont egy újabb adag késést jelentenek. Az élő felvételeknél semmiképp ne vedd fel a hangot élő effektel, ha a számítógéped nem bírja, mert csúnya vége lehet! Ezt csak erős gépnél és indokolt esetben szabad megtenni. Ez olyan, mintha a raktárosnak minden csomagra még egy masnit is kéne tegyen. A hardware-es effektek ugyan gyorsabbak, de ott is érdemes a felvételt követően beállítani a végső hangzást, finomítani azt.
A mai világban a hang késésének drasztikus csökkenése mellett egy új probléma lépett fel: a vizuális késés. Amikor a hangot a rendszer feldolgozza, nem fog azon idegeskedni, hogy annak a képét időben meg is jelenítse a drága főnök úr kénye-kedvére. A késés ugyan a hangban nem jelentkezik, de a felvett anyagot a monitoron jóval később látjuk, mint halljuk (élő felvételnél). Ez lenne a legkevesebb probléma, de az automatizáló görbék adatainak változtatása úgyszint lelassul a CPU túlterheltsége miatt. Ilyenkor szakadozva fog elhalkulni egy adott sáv, ha az élő felvételnél ezt rögtön paramétereztük. Emiatt is érdemes a sávokat és automatizálókat utólag megszerkeszteni és paraméterezni. A finomítást tehát mindíg hagyd a végére és próbáld meg a késés szempontjából lényeges dolgokat elhagyni. Állítsd egy picit magasabbra a buffert és optimalizáld a rendszered és a felvételt!