Počítače jsou samozřejmě dávno součástí jak zvukové praxe, tak běžného života. I v těch nejlepších studiích bude jako „vícestopý magnetofon“ sloužit DAW čili Digital Audio Workstation. A to i tam, kde bude k mixu využíván třeba velký analogový mixážní pult. Schopnosti a možnosti, které dnešní audio software nabízí, nebudeme v tomto článku rozebírat, rád bych se totiž zaměřil detailněji na to, jak vlastně tyto systémy fungují. Pouze stručně si připomeňme, co je potřeba k tomu, abychom mohli začít se zvukem pracovat. V základu je to skutečně jen počítač, příslušný software a AD/DA převodník. Když budeme korektnější, převodník jako takový není dostačující, co skutečně potřebujeme je zvukové rozhraní (angl. audio interface), tedy zařízení, které zvládá nejen AD-DA převod, ale bude data předávat do počítače a z počítače je zase přehrávat. Často se těmto zařízením říká zvuková karta, což je ale poněkud nevhodný termín, jelikož valná většina z nich klasickou zvukovou kartu z PC devadesátých let (tedy kartu do rozšiřujícího slotu, např. Creative SoundBlaster) ani trochu nepřipomíná, častá jsou plně externí zařízení atp.

ASIO, VST a další...
Podobně jako zvukové rozhraní sloužící pro komunikaci s vnějším světem, ať už analogovým nebo digitálním, je potřebný také určitý dorozumívací mezistupeň pro předávání informací mezi jednotlivými částmi softwarové strany DAW, samozřejmě v softwarové podobě. Pro propojení zvukového rozhraní a DAW softwaru ve Windows slouží převážně ASIO - Audio Stream Input Output. ASIO bylo vyvinuto firmou Steinberg, aby nahradilo pro audio práci nevhodné Microsoft DirectSound a další vlastní ovladače systému Windows. V Mac OS slouží pro správu audio hardwaru přímo Core Audio, čili základní rozhraní systému, do kterého se konkrétní ovládací software připojí. Další běžně vídanou zkratkou je jistě VST - Virtual Studio Technology. To je rozhraní opět vyvinuté firmou Steinberg a slouží pro předávání dat a parametrů mezi DAW a plug-iny neboli zásuvnými moduly (ať už efekty nebo nástroji). Konkurenty VST jsou AU - Audio Units, TDM - Time Division Multiplex a RTAS - Real Time Audio Suite. Audio Units je obdobou VST a je přímo od firmy Apple. Využívají ho tedy logicky aplikace této firmy a i některé další produkty na platformě Mac OS, většina z nich ale zároveň využívá VST. Naproti tomu další dvě jmenovaná rozhraní - TDM a RTAS - najdeme pouze a jedině v Pro Tools firmy Avid (dříve Digidesign). Rozhraní VST také v jejich produktech není přítomno vůbec. Problematika rozhraní firmy Avid má totiž nejen technickou, ale do značné míry také marketingovou a obchodní rovinu. Zdá se ale, že firma vytěžila ze zastaralého systému TDM maximum a přece jen se posune někam dále, což však přichází se značným zpožděním. Co do nabídky plug-inů strčí VST rozhraní TDM do kapsy, nemluvě o často až poloviční ceně za identické plug-iny.

S příchodem Pro Tools 10 se také objevuje nové rozhraní AAX - Avid Audio eXtension. Samozřejmě, že marketingová prohlášení jsou velikášská a mluví se opět o revoluci. Jelikož podobnou rétoriku používá Avid pokaždé, není třeba se nějak zvlášť vzrušovat. Připomeňme „revoluční“ vlastnosti Pro Tools 10 jako počítání crossfadů v reálném čase a možnost upravovat hlasitost jednotlivých audio regionů. V roce 2012 nezbývá než říci „wow“! Dá se tedy očekávat, že AAX je cestou, jak obnovit nadstandardní příjmy, které firmě dosud zajišťovala platforma TDM.

Dobrou zprávou pro uživatele je alespoň to, že od již zmiňované verze 9 byla dodána kompatibilita s rozhraním ASIO a možnost využívat i jiný hardware než Avid a pár do té doby povolených značek (vesměs velmi drahých jako Apogee atp.).

Latence
Základní vlastností, která nás zajímá, je schopnost komunikovat přímo s audio softwarem bez využití běžných cest operačního systému. Chceme totiž, aby cesta audio dat z a do převodníku byla co nejkratší a také přímá, bez jakýchkoli zásahů a změn. Požadujeme totiž od celého systému co nejkratší odezvu, tzv. latenci. To je termín, se kterým se často pracuje a to zejména v propagačních materiálech výrobců zvukových rozhraní. Jako u všeho je potřeba brát takto prezentované hodnoty s určitou rezervou, v podobných situacích spojených s technologiemi je to ostatně nutné téměř vždy. Proč chceme mít co nejnižší latenci? Využijeme ji rozhodně při hraní na softwarové nástroje, kde může delší odezva hru znesnadňovat. Přece jen z klasických nástrojů jsme zvyklí na poměrně „okamžitou reakci“. To je také situace, kdy většina uživatelů pozoruje, že systém skutečně zpoždění má. Zpoždění ale nastává při jakékoli akci, tedy při změně parametru efektu nebo zastavení a opětovném spuštění přehrávání. Latence má dvě součásti, vstupní a výstupní. Při prostupu signálu z vnějšku DAW a zpět do vnějšího světa se započítávají obě tyto hodnoty (např. při efektování signálu kytary v počítači), reakce na ovládací povely uživatele jsou zatíženy pouze zpožděním výstupním.

Nastavení bufferu v ovladači MOTU při vzorkování 48 a 192 kHz.

Většina uživatelů se asi setkala s volbou velikosti bufferu v ovladači zvukového rozhraní. Pro ilustraci: u zvukového rozhraní MOTU Traveler MkII připojeného přes FireWire 400 jsou při vzorkovací frekvenci na výběr velikosti bufferů od 64 do 1024 vzorků. Máme tedy možnost nastavit latenci vstupní od 2,517 ms do 24,286 ms a výstupní od 3,084 do 46,621 ms, což jsou hodnoty zobrazené programem Steinberg Cubase 6 v menu Devices - Device Setup - VST Audio System. Platí, že čím menší buffer, tím menší latence, ale také vyšší výpočetní náročnost. Proto nám při nízkých hodnotách (a tedy i latencích) dříve dojde výpočetní kapacita našeho počítače. Proč tomu tak je? Zvuk v počítači necestuje jako nějaký kontinuální proud vzorků, ale předává a zpracovává se po částech, již zmiňovaných bufferech. Těch je ale hned několik různých druhů. Ten, nad kterým máme kontrolu v ovladači zvukového rozhraní, se týká jen komunikace mezi aplikací a rozhraním. Při nahrávání to má např. bezprostřední vliv na zpoždění, které bude interpret slyšet v odposlechu, když budeme monitorovací cesty vytvářet pomocí aplikace. Pokud ale využíváme směšovací a směrovací funkce integrovaného mixu, kterým je mnoho rozhraní dnes vybaveno, bude zpoždění většinou nižší a nezávislé na velikosti bufferu ovladače. Mix má totiž svůj vlastní buffer a je optimalizován, aby běžel pokud možno s neznatelným zpožděním - to je často inzerováno jako Zero Latency Monitoring. Je třeba mít na paměti, že při kombinování monitoringu řízeného zvukovým rozhraním a aplikací (např. dohrávání dalších stop k již natočenému materiálu) může dojít k časovým rozdílům!

Interní mix rozhraní MOTU Traveler MKII.

Jak je to s plug-iny?
Zdálo by se, že latenci můžeme v podstatě nastavit, ale je to o trochu složitější. To, že není problém každou stopu projektu zpracovávat velkým množstvím procesorů a efektů, je v dnešní době již naprostou samozřejmostí. Jednoduše zapojíme do cesty další plug-in a všechno funguje, jak má... Je ale dobré si uvědomit, že některé plug-iny signál zpožďují a to proto, že potřebují například delší čas pro uskutečnění výpočtů, nebo potřebují znát delší úseky signálu atp. To platí například pro ty, které využívají zpracování ve spektrální oblasti (např. práce s délkou signálu, s laděním signálu, vokodéry) a potřebují spektrum spočítat z úseku signálu konečné délky. Pro ilustraci uveďme, že nejčastěji se používají segmenty délky 512, 1024 nebo 2048 vzorků (což odpovídá cca 11, 22 a 44 ms při vzorkovací frekvenci 44,1 kHz). Také se pracuje s překryvem, např. 50 %. Ten se využívá pro dosažení plynulého zpracování, které by čistě po segmentech nebylo v tomto případě možné. Pro zpracování tzv. rychlou Fourierovou transformací musíme totiž signál na začátku a konci utlumit. Tyto křivky tlumení jsou vytvořeny tak, aby při součtu s překryvem segmenty dávaly opět původní signál. Dalším příkladem plug-inů zpožďujících signál jsou limitery s funkcí look-ahead (např. Waves L1, Sonnox Limiter atd.), které se, aby správně fungovaly, „dívají do budoucnosti“. Což samozřejmě nejde a je to vyřešeno zpožděním signálu, dalo by se říci posunutím současnosti.

I když ale nasázíme tyto procesory ve velkém na jednu stopu projektu, zpožděna nebude. To proto, že audio aplikace disponují ve velké většině kompenzací tohoto zpoždění. Platí to pro všechny hlavní aplikace využívající plug-iny rozhraní VST. U Avid Pro Tools je to trošku komplikovanější. U nižších verzí předcházejících verzi 8 (LE a M-Powered) nebyla kompenzace zpoždění pro plug-iny rozhraní RTAS žádná. Přitom RTAS plug-iny se stejně jako VST plug-iny počítají nativně, čili v hlavním procesoru počítače. Důvod byl tedy marketingový, což u firmy Digidesign (dnes Avid) není nic nestandardního. Kompenzace latence fungovala u Pro Tools až v plné (a velmi drahé) verzi HD a navíc ještě omezeně.

Předpokládá se totiž využívání plug-inů rozhraní TDM, čili počítaných ne v jádru počítače, ale na výpočtových kartách osazených procesory Motorola řady 56k, z dnešního pohledu již poněkud zastaralých. Vzhledem k paralelním výpočtům je kompenzace zpoždění komplikovanější. Výsledkem je tedy fakt, že samotná kompenzace nejenom zabírá určitou nezanedbatelnou část výpočetní kapacity, ale také je omezena na krátké (1023 vzorků) a dlouhé (4095 vzorků) zpoždění. Pokud zpoždění dané stopy tuto hodnotu přesáhne, máme problém, protože systém kompenzuje stále jen zmiňovanou maximální hodnotu. Po vydání verze 9 byla tato funkce roku 2011 (!) s velkou pompou uvedena i v základní verzi (z jejíhož názvu bylo označení LE odstraněno), a to se stejně omezenou maximální velikostí kompenzace, což je zarážející vzhledem k tomu, že se týká pouze rozhraní RTAS, které je, jak jsme již zmiňovali, počítáno v hlavním procesoru počítače.

Pojďme si ale popsat situaci, která nastává v hostiteli využívajícím rozhraní VST (Cubase, Logic, Digital Performer apod.). Ve chvíli, kdy je vytvořen nový plug-in, se hostitel informuje, jaké je zpoždění signálu. Tato informace je v plug-inu nastavena vývojáři a to na hodnotu, která je potřebná pro plné využití plug-inu, není tedy závislá na využití či nevyužití jednotlivých funkcí. Někdy je tato hodnota propojena s velikostí již zmiňovaného ASIO bufferu (např. UAD), jindy se vzorkovací frekvencí. Hostitelský software komunikuje s plug-iny samozřejmě také po segmentech, taktéž často zvaných „buffery“. Ty překvapivě nemusejí mít onu velikost, kterou nastavujeme v ovladači, ještě překvapivěji nemusejí být ani po sobě jdoucí segmenty stejně dlouhé. Vývojáři musejí tedy plug-iny vytvořit dostatečně robustní a odolné vůči změnám délky přijímaných dat. To nás jako uživatele nemusí ale tolik zajímat, berme to jako jednu z příčin latence.

Jaké jsou tedy velikosti zpoždění jednotlivých plug-inů? Lze to zjistit např. v Cubase v Devices - Plug-in Information. Jaké tam můžeme najít hodnoty? Často je přítomna nulová hodnota. To je případ všech standardních efektů na bázi zpoždění, tedy Delay, Flanger, Reverb atd. Opačným extrémem je např. balík dílčích plug-inů rekonstrukčního softwaru iZotope RX 2, kde najdeme hodnoty 14 253-22 655 vzorků. Solidní hodnoty, byť ne takové (5-8 tisíc vzorků), najdeme například u vícepásmových kompresorů (Steinberg Multiband Compressor 5426) či transpozičních efektů (Waves UltraPitch - 8239 vzorků). Při vzorkovací frekvenci 44,1 kHz se tedy budeme s těmito hodnotami pohybovat v hodnotách až do 0,5 sekundy pro iZotope RX 2, kde se samozřejmě jedná o komplexní zpracování signálu a nemá cenu požadovat provoz s nízkou latencí. Zásadním faktem je, že pokud takový plug-in přidáme do projektu, zvýšíme celkovou odezvu systému a to i výrazně, např. o zmiňovaných 0,5 sekundy! O kolik to přesně bude závisí na konkrétním zapojení celého projektu, protože systém kompenzace musí udržovat správnou synchronizaci stop vůči sobě, což závisí na délce zpoždění jednotlivých stop a také na směrování signálu.

Zpoždění plug-inů zobrazené v informačním okně v Cubase 6.

V jakých případech skutečně využijeme provoz s nízkou latencí? Obecně ve chvíli, kdy výstupní signál slouží pro monitorování nějakých vstupů uživatele nebo interpreta, tedy při nahrávání a také hraní na virtuální nástroje ať při vystoupení, nebo při tvorbě hudby ve studiových podmínkách. Máme sice často hardware s již zmiňovanou „nulovou“ latencí, ten nás ale zachrání pouze tehdy, pokud nenecháme signál před návratem do odposlechu projít hostitelem, v opačném případě bude rovnou zpožděn v závislosti na velikosti bufferu ovladače. Pokud navíc do stopy přidáme zpracování, začne zpoždění narůstat a nastavení v ASIO ovladači na to nebude mít vliv. Latence naopak nevadí při mixu. Při masteringu nám dokonce nevadí ani nekompenzované zpoždění, protože pracujeme pouze s jedním stereofonním signálem. Jedinými vstupy uživatele jsou při takové práci změny parametrů, jejichž vliv se tak projevuje se zpožděním, a reakce na ovládání přehrávání, které je taktéž zpožděno. Ani při nejvyšších nastavených hodnotách bufferu ovladače (většinou 2048 vzorků) to ale v praxi není nic hrozného. Stejně tak je při ladění parametrů třeba dobře poslouchat a v klidu vše nastavit, takže nás zpoždění, které by bylo již nepříjemné při hře na virtuální nástroje, asi nerozhodí.

Trošku jiné je to u scrubbingu, ale dá se na to zvyknout a spolu s vizuální kontrolou lze nalézt co hledáme. V některých DAW (např. Steinberg Cubase) je navíc přítomen přepínač na potlačení kompenzace zpoždění (Constrain Delay Compensation), jehož přepnutím okamžitě zlepšíme odezvu systému, kdykoliv to potřebujeme. Realizováno je to jednoduše, všechny plug-iny zanášející zpoždění jsou vypnuty. Jde o velmi pohodlnou funkci, jelikož nemusíme přemýšlet, které z použitých procesů systém zpomalují a jedním kliknutím je všechny vyřadíme, systém pak bude mít zpoždění pouze dle bufferu ovladače. Mezitím si uděláme vše potřebné a jedním kliknutím se opět vrátíme do původního stavu.

Jak tedy pracovat s nastavením bufferu ovladače? Obecně lze jednoduše vždy nastavit nejmenší možnou hodnotu a tu v případě potřeby zvyšovat. K tomu jsme nuceni ve chvíli, kdy systém přestane být schopen vše stíhat a bude docházet k jeho přetížení a výpadkům signálu. Provoz s nízkou latencí vyžaduje větší výpočetní kapacitu, protože vše musí být hotovo rychleji. Zvuk musí stále běžet a veškeré zpracování funguje na principu „tady je x vzorků, vrať mi x vzorků teď“. Pokud nějaký plug-in pracuje například interně se segmenty o délce 1024 vzorků a buffer mezi ním a hostitelem bude najednou jen 64 vzorků, musí dokázat velmi rychle vše spočítat, čili celých 1024 vzorků, které pak postupně odebírá a vrací hostiteli. Toto je však velmi zjednodušený popis míněný čistě pro ilustraci. V dnešních počítačích je stále velmi málo využíváno paralelních výpočtů, procesory mají sice několik jader, ale to stejně znamená třeba dvě nebo čtyři paralelní zpracování. V DAW jich ale běží mnohem více. Zabývat se touto problematikou detailněji je nad rámec tohoto článku, řešení si představme jako sekvenci velmi mnoha dílčích výpočtů, které probíhají za sebou a to tak rychle, že z hlediska uživatele probíhá vše zároveň.

Příště
V příštím dílu tohoto seriálu se podíváme trochu detailněji na měření úrovně digitálního signálu a na problematiku hlasitosti a špiček signálu.

Jindřich Kravařík


Další díly seriálu
1. díl - ./recenze/stoparuv-pruvodce-digitalnim- ... 18487.html
2. díl - ./recenze/stoparuv-pruvodce-digitalnim- ... 18556.html
4. díl - ./recenze/stoparuv-pruvodce-digitalnim- ... 18902.html
5. díl - ./recenze/stoparuv-pruvodce-digitalnim- ... 19337.html
6. díl - ./recenze/stoparuv-pruvodce-digitalnim- ... 19447.html