Latency is een belangrijk concept voor digitale audio en video. Het is de vertraging in tijd die een signaal oploopt om van één punt naar een ander te geraken binnen digitale systemen. Bij analoge systemen met fysieke componenten is er geen echte meetbare vertraging. Maar digitaal is het niet te vermijden, want latency is grotendeels een gevolg van het gebruik van buffers, een basisbouwsteen van computersystemen.
Waarom is het belangrijk? Eind oktober 2024 startten The Eagles met een residentie in de MSG Sphere. Daar krijgt niet alleen het publiek via het HOLOPLOT speakersysteem geluid, ook de monitoring voor muzikanten gebeurt via gerichte speakers. Maar volgens bandlid Joe Walsh zat er teveel latency op het geluid via het HOLOPLOT systeem. De vertraging werkte het gevoel van timing tegen en maakte het onmogelijk voor de band om comfortabel samen te spelen. Omdat de latency niet verlaagd kon worden, hebben ze uiteindelijk via in-ear monitoring gespeeld.
Zelfs The Sphere met hun astronomisch budget is niet immuun voor het concept van latency, dus we willen dan ook het concept duidelijk uit te doeken doen in dit artikel.
Buffers
Wat en waarom?
Het brein van een computer is de processor (CPU). Die voert de basisberekeningen uit waarop alle softwareprogramma’s in de computer werken. De processor neemt data binnen (input data), verwerkt ze en stuurt het resultaat van de berekeningen uit (output data).
Een moderne processor is enorm complex en voert per seconde miljarden berekeningen uit, en doet dat voor meerdere programma’s tegelijk. Dat lijkt enorm veel, maar een handeling die voor ons simpel lijkt kan soms miljoenen berekeningen vereisen.
Het is moeilijk en gevaarlijk om een processor volledig realtime (zonder latency) te laten werken. Onderdelen zoals je harde schijf zijn gewoon niet zo snel als je processor of het RAM (geheugen) en daar moet je rekening mee houden. Bij een te zware belasting van de processor kan het ook zijn dat er berekeningen overgeslagen worden wat fouten zal introduceren. Daarom zijn buffers geïntroduceerd, om data tijdelijk weg te schrijven en uit te lezen wanneer die nodig is of verwerkt kan worden. Er zijn allerlei buffers – niet alleen binnen de processor – maar we focussen hier vooral op die van de processor.
Grootte van buffer en latency
Wie al een Digital Audio Workstation (DAW) heeft gebruikt, heeft sowieso al de buffer size, uitgedrukt in samples, ingesteld. De waarde die je kiest bepaalt met hoeveel samples per keer het achterliggende systeem zal werken: je audio interface software (drivers), de DAW en je plugins werken telkens met ‘blocks’ van die gekozen grootte.
Die grootte kiezen is een balans maken tussen latency en werkdruk van de processor. Hoe kleiner de buffer size, hoe minder vertraging maar ook hoe minder tijd je de processor geeft om alles te verwerken. De processor moet de huidige block verwerkt hebben voordat volgende komt. Lukt dat niet, dan riskeer je bij opname klikgeluiden en stukken waar het geluid wegvalt.
Het aantal samples waarmee per keer gewerkt wordt bepaalt de latency. Er moet namelijk gewacht worden tot de buffer gevuld is om een block te kunnen vullen. Er is dus een vaste wachttijd tussen opeenvolgende blocks, omdat het aantal samples tegen een vast tempo gegenereerd wordt op basis van de sample rate. Dat is dus de latency en die is simpel te berekenen met de volgende formule:
BUFFER SIZE / SAMPLE RATE = LATENCY.
Bij een buffer van 256 samples op sample rate 48kHz duurt het 256 / 48000 = 0,005333… seconden, oftewel 256 / 48 = 5.3 miliseconden (ms), voordat die gevuld is. Alle processing gebeurt dus telkens in intervallen van 5.3 ms.
Je vraagt je dan misschien af of het verdubbelen van de sample rate de latency zal halveren bij dezelfde buffer size. Dat is zo, maar er zijn dan dubbel zoveel samples om te verwerken binnen diezelfde tijd, dus is er veel meer druk op je processor. Bij buffer size van 512 samples op 96kHz zit je met dezelfde latency maar moet je processor nog altijd dubbel zoveel data verwerken binnen diezelfde tijd. Dat kost dus nog steeds meer rekenwerk. Bij opname moet je harde schijf ook dubbel zoveel data wegschrijven, wat tegenwoordig met SSD-schijven wel veel gemakkelijker gaan dan in het verleden.
Hoeveel buffers?
Elke buffer van dezelfde grootte die erop volgt voegt nog eens die hoeveelheid latency toe. Het resultaat uit de eerste buffer kan pas na 5.3ms verwacht worden en dan krijgt die volgende buffer nog eens 5.3ms om dat resultaat te verwerken. Dat geeft met 2 buffers al 10.6 ms latency bij 256 samples. Weet dat algemeen wordt aangenomen dat een vertraging vanaf 10 ms hoorbaar is.
Wanneer je audio binnenhaalt en meteen terug uitstuurt, zoals bij opname of tijdens liveshows, worden sowieso 2 buffers gebruikt: een inputbuffer en een outputbuffer. Bij 256 ms zitten we dan al aan die grens van een hoorbare vertraging. Een voldoende performante computer om de buffer size laag genoeg te kunnen zetten is dan ook noodzakelijk, want meestal is de latency nog iets hoger omdat de gebruikte kabels (zoals USB) en software nog een beetje extra latency genereren…
Immersive liveshows
Bij immersive audio werken we met immersive engines. Die vertalen virtuele posities die je toekent aan klankbronnen in de engine naar reële posities in je zaal of ruimte via de luidsprekerinstallatie. Er zijn daarvoor 2 soorten engines:
- Software engines die gewoon op je computer draaien, zoals de Dolby Atmos Renderer en Flux:: SPAT Revolution
- Dedicated hardwaretoestellen, zoals Adamsson FletcherMachine, Yamaha AFC, d&b Soundscape, Coda Audio Spacehub, …
Het voordeel van de hardware toestellen is dat ze de latency kunnen minimaliseren omdat het toestel specifiek voorzien is om enkel de berekeningen voor de werking van dat toestel te doen. Dat is zowel zo voor de immersive engines, maar even goed ook voor alles van digitale mengtafels, in-ear monitoring systemen, alles waar digitale signaalverwerking in gebeurt.
Fabrikanten zullen een specifieke configuratie van componenten kiezen om de werking van het toestel optimaal te laten gebeuren met een vaste lage latency. Je moet je bewust zijn van deze kleine latency, maar je kan die meestal niet aanpassen.
Bij software engines moet de engine concurreren met het besturingssysteem op de computer en andere programma’s die open staan of in de achtergrond lopen. Dat zorgt onvermijdelijk voor meer latency.
Wij kiezen toch stevast voor de Flux:: SPAT Revolution software engine omdat we daarbij niet gebonden zijn aan het ecosysteem van een fabrikant en het een fractie van de kost is om aan te kopen. SPAT draait gewoon op een Mac of Windows en integreert dan ook gemakkelijk in de systemen van een concertzaal, wat met de hardwaretoestellen niet altijd zo is door beperkingen van fabrikanten. Voor onze immersive liveshows in de AB Club en in Wilde Westen voor Unwrap moesten we dan ook de latency minimaliseren.
Dante en latency
Dante is een Audio-over-IP protocol waarbij toestellen die verbonden zijn met een netwerkswitch via gewone Ethernetkabels audio via pakketten (dus niet dezelfde blocks van daarjuist) kunnen uitwisselen. Omdat alles digitaal is, kan je complexe verbindingen maken, audio ontdubbelen zonder splitboxes en integraties tussen audio en video gemakkelijk mogelijk te maken. Dante is het meest vertegenwoordigde Audio-over-IP protocol in onze industrie, dus we maken er zelf ook gebruik van.
Latency werkt iets anders bij Dante. Per toestel kan je een latency instellen in milliseconden, tussen 0.25ms en 10ms. Dit is geen buffer size maar de maximum vertraging die we aanvaarden tussen transmitter en receiver, dus de maximale tijd dat de ontvanger zal wachten op een volgende pakket. Bij netwerkprotocollen ziet men namelijk latency meer via hops: een verbinding tussen 2 toestellen (= 1 hop) geeft vertraging, het aantal hops tot de bestemming bepaalt de totale mogelijke vertraging.
De latency die je instelt bij Dante is niet de vertraging dat een toestel introduceert, maar wordt dus de maximale tijd dat gewacht wordt tussen 2 toestellen op een volgend datapakket. De hoogst ingestelde latency van de twee toestellen zal de latency van de verbinding worden.
Als je transmitter 0.25ms latency heeft en de receiver 1.0ms, dan zal de totale latency van transmitter naar receiver 1.0ms zijn – of dat nu nodig is of niet.
Een pakket kan vroeger aankomen dan de latency van die verbinding en zal bij Dante gewoon verder doorgestuurd worden. Bij meerdere hops kan je pakket veel vroeger zijn aangekomen dan de totale latency van begin tot einde.
Maar als de latency van een hop zo laag ingesteld staat dat pakketten te laat aankomen, worden de pakketten weggegooid en zal het geluid soms wegvallen of hoor je klikgeluiden.
In de Dante Controller software kan je raadplegen of er pakketten verloren zijn gegaan, zodat je latency goed kan afstellen.
