Audio Loopback Latency — Wat Afspeltests Je Niet Vertellen

De meeste audiotests controleren alleen of er geluid afspeelt en of de microfoon iets opneemt. Geen van beide meet de weerkaatste vertraging — de tijd tussen een geluidsevenement dat de microfoon binnenkomt en het verwerkte signaal dat de luidsprekers verlaat. Dit ene getal bepaalt of muzikanten kunnen opnemen tegen een clicktrack, of videogesprekken natuurlijk aanvoelen, en of ruimtelijk geluid in games accuraat klinkt. Een systeem kan elke afspeeltest halen en toch catastrofale vertraging vertonen, want functionaliteit en timing zijn aparte assen. Deze gids legt uit hoe je de weerkaatste vertraging meet, wat de cijfers betekenen, en hoe je ze verlaagt.

Elke hardwarecheck begint op dezelfde manier. Sluit de nieuwe speakers aan, speel de testtoon af, bevestig dat er geluid komt, ga verder. Sluit de microfoon aan, spreek, kijk naar het niveaublokdiagram dat omhoog springt, ga verder. Die twee tests bevestigen dat je uitgangspad werkt en dat je ingangspad werkt. Geen van beide meet de vraag die eigenlijk bepaalt of je audio-opstelling écht werk aan kan: hoe lang doet een geluid erover om van de microfoon, door de computer, naar de speakers te reizen?

Dat getal is weercatste vertraging, en het bepaalt stilletjes welke taken je systeem eerlijk aankan:

• Muziek opnemen. Meespelen met een click of een backingtrack vereist dat je eigen geluid bijna direct terug in je oren komt. Boven ongeveer veertig milliseconden weercatste vertraging drijft je timing weg, elke take klinkt traag, en geen hoeveelheid oefening helpt. Audio-interfaces die een USB-controller delen met andere apparaten kunnen ook last hebben van USB-bandbreedteconcurrentie, wat latentiepieken toevoegt bovenop de buffervertragingen.
• Gesprekken voeren. Videogesprekken voelen natuurlijk aan alleen wanneer de audiopijp strak blijft. Te veel vertraging veroorzaakt echo, overlappende spraak, en de strakke ritme van een satelliettelefoongesprek.
• Gamen met ruimtelijk geluid. Positioneel geluid werkt alleen wanneer audio aankomt in de pas met wat je ziet. Wanneer het audiospoor achterloopt op het beeld, losen voetstappen en schoten zich van de actie op scherm.

Je speakertest en microfoontest beantwoorden de vraag: “werkt het?” De loopback-vertragingstest beantwoordt: “hoe snel?” Deze pagina legt uit wat weercatste vertraging is, waar het vandaan komt, en hoe je het verlaagt. De cijfers hier komen uit algemene ervaring over talloze hardware- en softwareconfiguraties — een echte ASIO-opstelling op een Focusrite Scarlett 2i2 geeft andere getallen dan een onboard Realtek-codec op Windows 11. Je resultaten variëren met je specifieke interface, stuurprogramma en bufferinstellingen.

De toontest meet geen vertraging

Een speakertest speelt een toon, een sweep, of een muziekfragment af via je uitgang en bevestigt dat er geluid komt. Het is een functionaliteitstest met een ja-of-nee-uitslag: de kabel zit erin, het stuurprogramma is geladen, het volume staat niet op mute, de digital-analoog-omzetter werkt. Als je de toon hoort, werkt het uitgangspad. Dat is alles wat de test je kan vertellen.

Een microfoontest doet hetzelfde voor de invoerrichting. Het neemt op wat je zegt, toont een niveaublokdiagram, en bevestigt dat de microfoon, de voorversterker, en de analoog-naar-digitaal-omzetter functioneren. Ook hier: ja of nee.

Vertragingmeting is een ander soort test. In plaats van te vragen of een signaal een pan kan passeren, vraagt het hoe lang de passage duurt. De procedure is simpel: stuur een bekend signaal — een impuls, een klik, een korte burst — via de uitgang, vang het aan de ingang, en bereken het tijdsverschil tussen uitzending en ontvangst. Dat verschil is de weercatste vertraging, uitgedrukt in milliseconden.

Het onderscheid telt omdat de twee metingen onafhankelijk zijn. Een systeem kan elke afspeeltest halen en toch catastrofale vertraging vertonen. Bluetooth-luidsprekers zijn het klassieke voorbeeld: ze reproduceren een toon trouw, zodat de speakertest succes rapporteert, terwijl de draadloze codec honderd tot honderd-achttien milliseconden vertraging toevoegt die geen enkele afspeeltest ooit opmerkt. Een toon die honderdvijftig milliseconden te laat aankomt, is strikt genomen nog steeds aan het spelen.

Daarom valt de gangbare aanname — “mijn speakers klinken prima, dus mijn audiosysteem is prima” — uiteen voor alles wat timinggevoelig is. Functionaliteit en timing zijn aparte assen. Voordat je je opstelling vertrouwt voor opnames, calls of gamen, heb je het getal nodig dat afspeeltests structureel niet kunnen produceren.

Kijk de buffer vullen

Weercatste vertraging is niet één enkele vertraging. Het is de som van vertragingen die op elke fase tussen de microfoonomhulzing en de speakermembraan worden opgebouwd. Het begrijpen van het pad vertelt je precies waar je milliseconden verborgen liggen:

1. Invoerbuffer. De analoog-naar-digitaal-omzetter sampelt continu, maar het besturingssysteem levert audio in blokken. Het stuurprogramma wacht op een volledige buffer voordat het data naar de applicatie geeft. Bij 48 kHz duurt een buffer van 128 samples 2,7 milliseconden om te vullen — zolang wacht je audio voordat iemand het verwerkt. De meeste systemen houden twee of drie buffers in vlucht. Verwacht ongeveer vijf tot acht milliseconden voordat je applicatie het eerste sample ziet.
2. Analoog-naar-digitaal-omzetting. De omzetter heeft tijd nodig om te sampelen, kwantificeren en klokken. Op consumentenhardware draagt dit typisch één tot drie milliseconden bij; dedicated interfaces doen beter.
3. Systeemplanning. De audio-engine wekt je applicatie wakker op een timer, en het opstartmoment valt onder normale thread-planning. In gedeelde modi mengt het besturingssysteem je stream ook met alle andere audio-bronnen in het systeem, met een eigen verwerkingsronde. Deze fase draagt overal tussen een paar milliseconden tot twintig of meer bij, afhankelijk van platform en belasting. Dit is de fase waarin Linux met PipeWire Windows voor kan blijven — en waar een rumoerige desktop-omgeving je vertraging stilletjes kan laten ontploffen.
4. Applicatieverwerking. De software aan de ontvangende kant — een digitale audiostream, een effectenketen, een browser-audiografi — verwerkt het blok voordat het doorgeeft. Klein, maar deel van het totaal.
5. Digitaal-naar-analoog-omzetting. De spiegel van fase twee, met nog eens één tot drie milliseconden terwijl het verwerkte signaal analoog wordt.
6. Uitvoerbuffer. De verwerkte samples wachten in de uitvoerbuffer tot de omzetter ze kan afspelen, met dezelfde buffergrootte-rekening als aan de invoerkant. Voeg nog vijf tot acht milliseconden toe in typische configuraties.

Tel de fasen bij elkaar op en gedeelde-modus weercatste vertraging valt typisch tussen dertig en zestig milliseconden op een gewone computer — de volgende gemeten cijfers zijn illustratief uit specifieke hardware, geen universele specificaties. Bij informele tests op een standaard Windows 11-laptop met een onboard Realtek ALC897-codec bij een 128-sample buffer, vielen gedeelde-modusmetingen rond de hoge kant van dat bereik. Met een Behringer U-Phoria UM2 via ASIO4ALL op dezelfde hardware daalde de meting naar dertien tot vijftien milliseconden. Dit zijn observaties op één machine zonder gecontroleerde omstandigheden; ze dienen als referentiepunten voor de typische kloof tussen gedeelde-modus en ASIO-paden, niet als gegarandeerde waarden voor jouw hardware. Geen enkel stuurprogramma verwijdert de omzettingsduur — maar de buffer- en planningsoverhead, die het totaal domineren, krimpen aanzienlijk.

Eén getal, twee definities

Audiosoftware citeert zelden één getal. Open de instellingen van een professionele applicatie en je ziet typisch twee: input latency, de tijd van microfoon naar applicatie, en output latency, de tijd van applicatie naar speakers. Stuurprogramma’s zoals ASIO rapporteren beide waarden apart, en marketingmateriaal citeert meestal het getal dat het mooier eruitziet.

Weercatste vertraging is de som van beide, plus de eigen verwerkingstijd van de applicatie. Als een systeem twintig milliseconden in één richting citeert, is de weercatste vertraging ongeveer veertig milliseconden. Een gebruiker die “20 ms latency” leest en veronderstelt dat dat de vertraging is die hij hoort, zit een factor twee fout — en die fout komt vaak voor omdat één-weg-cijfers op specificatiebladen worden gedrukt.

Het onderscheid telt omdat wat je waarneemt altijd de weercatste vertraging is. Wanneer een muzikant zijn eigen stem of instrument monitoreert, moet het geluid de microfoon verlaten, het systeem passeren, en terugkeren naar de headphones voordat hij het hoort. Dat is het volledige traject. Een één-weg-cijfer beschrijft slechts de helft van de reis.

Om de discussie consistent te houden, verwijzen alle cijfers hier naar weercatste vertraging. Wanneer je je heting vergelijkt met een productspecificatie of benchmark, controleer dan altijd of beide cijfers dezelfde soort reis beschrijven. Een weercastemeting vergelijken met een één-weg-specificatie maakt je systeem twee keer zo langzaam zien als het eigenlijk is.

Het besturingssysteem beslist voordat jij

Dezelfde microfoon, dezelfde speakers, en dezelfde kabel produceren wild verschillende vertraging op verschillende besturingssystemen, omdat elk platform audio via een andere software-stack routeert. De stack bepaalt hoeveel buffer- en planningsoverhead op de onvermijdelijke omzettingsduur wordt toegevoegd.

Windows: gedeelde modus, exclusieve modus en ASIO

Windows biedt drie manieren om bij de hardware te komen, elk met een ander vertragingprofiel:

• WASAPI gedeelde modus is het standaardpad dat elke applicatie gebruikt tenzij het om iets anders vraagt (Microsoft Learn: WASAPI Shared Mode, 2023). Alle audio wordt gemengd en geleverd met voorzichtige buffering. Vaak waargenomen weercatste vertragingen lopen van dertig-twee tot zestig-vier milliseconden op typische systemen, afhankelijk van buffergrootte en belasting — dit zijn algemene ervaringsbereiken, geen gegarandeerde waarden. Web Audio, WebRTC en media-afspeling volgen elk een licht ander pad, maar ze beginnen allemaal bij deze gedeelde mixer.
• WASAPI exclusieve modus of ASIO omzeilt de mixer en geeft één applicatie directe toegang tot het apparaat, wat de vertraging typisch naar rond de tien milliseconden op typische hardware verlaagt (Microsoft Learn: WASAPI Exclusive Mode, 2023). Het is beschikbaar voor native applicaties die ernaar vragen; browsers kunnen niet.
• ASIO is een stuurprogrammaprotocol dat de Windows-audiostack volledig omzeilt en direct communiceert met de interfacehardware (Steinberg: ASIO Host and Driver Guide v2.3, 2021). Met een passende interface, ASIO behaalt typisch acht tot vijftien milliseconden, hoewel exacte cijfers afhangen van de specifieke interface, stuurprogrammarevisie en bufferconfiguratie. Browsers kunnen het niet gebruiken.

macOS: Core Audio

Apples Core Audio-framework is goed geoptimaliseerd, en native applicaties bereiken routinematig acht tot twintig milliseconden weercatste vertraging met redelijke bufferinstellingen. Het gedeelde pad is efficiënt, zodat zelfs browser-gemeten vertraging op macOS doorgaans beter is dan op Windows. Het ligt nog steeds boven het native minimum, want de browser kan geen exclusieve apparaattoegang claimen en de buffer niet naar eigen behoefte instellen.

Linux: ALSA, PulseAudio en PipeWire

Linux-vertraging is een bewegend doel. ALSA, de low-level stuurprogramma-interface, is snel maar applicatiespecifiek. PulseAudio voegde historisch merkbare bufferoverhead toe. PipeWire, de moderne opvolger, is ontworpen voor low-latency audio en kan de andere platforms matchen of verslaan wanneer het correct geconfigureerd is, maar resultaten variëren sterk met distributie en opstelling.

In de meeste configuraties is de browser beperkt tot het gedeelde pad. Het kan geen exclusieve modi aanvragen, kan geen ASIO-stuurprogramma’s laden, en kan de prioriteit van zijn audiostream niet verhogen. Browser-audiovertraging is daarom doorgaans dichter bij het gedeelde-modus-plafond van je platform — het beste wat de coöperatieve route kan leveren op standaardconfiguraties — terwijl native professionele software erop is ingericht om dat plafond te ontvluchten wanneer hardware en stuurprogramma het toelaten.

Wat 60 milliseconden écht betekent

Een rauwe millisecondewaarde betekent niets tot je het tegen je beoogde activiteit afzet. De grenzen hieronder zijn algemene richtlijnen, geen professionele certificatiestandaarden; de werkelijke geschiktheid hangt af van je specifieke taak, monitoringopstelling en luisteromgeving. Vier zones dekken het praktische bereik:

• Onder 20 ms — uitstekend. Professionele muziekproductie voelt zich hier comfortabel. Muzikanten kunnen tegen een click inspelen, zichzelf monitoren met effecten, en op tijd spelen omdat het terugpad effectief onmiddellijk is. Ruimtelijk geluid in games blijft op het beeld gelocked.
• 20–60 ms — aanvaardbaar voor de meeste toepassingsgebieden. Podcasting, videogesprekken, algemeen gamen en casual opnemen werken allemaal goed. Strakke muziektracking begint aan de bovenkant van dit bereik te lijden: spelers voelen dat hun eigen geluid iets trekt, en nauwkeurig werk wordt merkbare moeilijker boven ongeveer veertig milliseconden.
• 60–120 ms — problematisch voor productie, aanvaardbaar voor casual gebruik. Karaoke, voice chat en luisteren zijn prima. Opnemen tegen een backingtrack wordt écht moeilijk, en in games los het audio zich los van de actie, wat de positionele cues ondermijnt waarop ruimtelijk geluid gebaseerd is.
• Boven 120 ms — slecht. Timinggevoelig werk is effectief onmogelijk. Calls ontwikkelen hoorbare echo, optredens voelen ontkoppeld, en ruimtelijk geluid klinkt verkeerd zelfs bij casual gebruik. Deze zone is de natuurlijke thuishaven van Bluetooth-audio en verkeerd geconfigureerde gedeelde-modus systemen.

De zongrenzen zijn oordeelsvragen, maar de vorm is betrouwbaar: productie heeft de laagste getallen nodig, gesprek tolereert meer, en casual luisteren tolereert het meest. Je weercastemeting plaatst je systeem in exact één zone, en die plaatsing vertelt je welke van je beoogde toepassingen prettig zal aanvoelen en welke je tegen zal werken. Houd het getal bij de hand — het is het referentiepunt voor elke optimalisatie in het volgende hoofdstuk.

Drie hefbomen: samplingfrequentie, buffer, stuurprogramma

Drie schakelaars bepalen waar in het pad je vertraging landt, en ze zijn niet gelijkelijk krachtig.

Samplingfrequentie zet de doorvoer van de pijplijn — hoeveel keer per seconde het geluid wordt gemeten — in plaats van de vertraging direct. Het wisselt wel van invloed met buffertiming, want een buffer wordt gemeten in samples: 128 samples duren 2,9 milliseconden bij 44,1 kHz maar slechts 1,3 milliseconden bij 96 kHz, zodat dezelfde buffergrootte bij verschillende samplingfrequenties andere tijdsduur vertegenwoordigt. De valkuil is dat een hogere frequentie meer verwerking per seconde vereist, wat je vaak dwingt de buffer weer hoger te zetten om stabiel te blijven, waardoor de winst wordt tenietgedaan. Het jagen naar 96 of 192 kHz dwingt vaak een grotere buffer af om de stream stabiel te houden, wat de theoretische winst kan tenietdoen of het zelfs langzamer kan maken. Behandel de samplingfrequentie als een werkvloerinstelling, typisch 48 kHz, niet als de primaire vertragingregelaar. 48 kHz werd de de facto standaard voor video-gesynchroniseerde audio omdat het scherp overeenkomt met videoframerates van 24, 25 en 30 fps, reden waarom de professionele audio-video pijplijn daar standaard stopt.

Buffergrootte is de primaire vertraginghefboom. Het bepaalt hoeveel audio wordt opgebouwd voordat het systeem het verwerkt, en het verschijnt twee keer in de weercatste vertraging — één keer aan de invoerkant en één keer aan de uitvoerkant. Halvering van de buffer halveert dat deel van de vertraging, maar het halveert ook de tijd die het systeem heeft om elk blok aan te leveren, wat het risico op buffer-underruns verhoogt: klikken, pops en dropouts. De praktische matrix bij 48 kHz ziet er als volgt uit:

• 64 samples — ongeveer 8–12 ms weercatste vertraging op bekwaame hardware met ASIO of exclusieve modus. Budget-interfaces produceren vaak klikken bij deze grootte.
• 128 samples — ongeveer 12–20 ms. Een veelgebruikt ASIO-sweet spot voor productie.
• 256 samples — ongeveer 20–35 ms. Vaak de kleinste stabiele grootte in gedeelde modus.
• 512 samples — ongeveer 35–60 ms. Veilig maar merkbare traag.
• 1024 samples — ongeveer 60–100 ms. Alleen voor streaming of afspelen waar vertraging niet telt.

Stuurprogramma zet de ondergrens. ASIO en exclusieve modus staan buffergroottes van 32 tot 128 samples toe; gedeelde modus stopt hoger; Bluetooth-codecs voegen honderd milliseconden of meer toe voordat buffers überhaupt worden overwogen. Geen enkele bufferfijining kan de minimumwaarde van het stuurprogramma overtreffen, wat de reden is dat het stuurprogramma de eerste hefboom is, niet de laatste.

De browser is geen DAW

Een browser kan weercatste vertraging schatten met de Web Audio API (MDN: Web Audio API, 2024), die een impuls via de uitgang planteert en het aankomende signaal aan de microfooninput vangt. Een typische Web Audio loopback-meting op een laptop in gedeelde modus rapporteert doorgaans 55–70 ms — veelvuldig de ASIO-waarde — een kloof die de gedeelde-pad-heffing van de browser illustreert. De gemeten tijd omvat het akoestische pad door de lucht, speaker- en microfoontransducers, room echo cancellation-verwerking, en de volledige systeemaudiostack. Dit wordt de akoestische weercatste vertraging genoemd, en het is het relevante cijfer voor browsergebaseerde calls, karaoke, en in-browser games, maar het is niet equivalent aan de ASIO weercatste vertraging die professionele audiosoftware meet. Houd er rekening mee dat deze meting een écht akoestisch pad tussen speaker en microfoon vereist; automatic gain control, noise suppression en echo cancellation kunnen de impulsvorm veranderen, terwijl microfoonafstand, kamers Reflecties en volume-instellingen het resultaat allemaal beïnvloeden.

Wat de browser niet kan, is de best-case-waarde van de hardware bereiken. Het moet het gedeelde audiopad van het besturingssysteem gebruiken, kan geen exclusieve apparaattoegang claimen, kan geen ASIO-stuurprogramma’s laden, en kan zijn eigen audiobuffergrootte of threadprioriteit niet controleren. De meting weerspiegelt daarom het gedeelde-modus-plafond van je platform in plaats van het echte minimum van de hardware.

Dat plafond is exact het juiste getal voor browsergebaseerd werk. Webcalls, browsergames, webkaraoke, en alles wat binnen een tabblad draait, delen op systeemniveau het audiospoor van de browser, hoewel Web Audio, WebRTC en media-afspeling in details verschillen. Als het browser-gemeten getal goed is, voelt elke browser-toepassing goed aan. Als het slecht is, kan native software je nog redden — maar de browser zal doorgaans langzamer zijn dan native software op dezelfde hardware en configuratie.

Zes manieren om vertraging te verlagen

Bewerk het probleem in volgorde van impact, en stop zodra je getal in een zone landt die je kunt accepteren:

1. Verstel eerst de stuurprogrammamodus. Op Windows installeer je het ASIO-stuurprogramma voor je audio-interface, of schakel je over naar WASAPI exclusieve modus. Dit is de grootste hefboom en het is gratis.
2. Verklein de buffergrootte. Stap van 512 naar 256 naar 128 naar 64 samples, test elke instelling, tot je klikken of pops hoort. Stap dan weer één niveau omhoog naar de grootste buffer die schoon blijft.
3. Controleer de samplingfrequentie. Gebruik 48 kHz voor muziek- en videowerk. Het jagen naar 96 kHz het 192 kHz dwingt vaak een grotere buffer af en eindigt langzamer.
4. Sluit concurrerende applicaties. Streaming, opname en drukke brosertabbladen stelen CPU-tijd van de audiostream en veroorzaken underruns bij kleine buffergroottes.
5. Overweeg een audio-interface. Dedicated hardware brengt betere omzetters, correcte ASIO-stuurprogramma’s, en buffergroottes die onboard audio niet kan bereiken.
6. Voorkeur aan bekabelde verbindingen. Voor alles wat timinggevoelig is, slaan bekabelde headphones Bluetooth met honderd milliseconden of meer, ongeacht elke andere instelling.

Elke stap compenseert. Het verplaatsen van gedeelde modus bij 512 samples naar ASIO bij 128 samples verschuift een systeem doorgaans van vijftig milliseconden naar onder de twintig — het verschil tussen ontoereikend en professioneel.

Het eindoordeel

Een afspeeltest bevestigt dat je speakers werken. Een loopback-test bevestigt dat ze op tijd werken — en dat zijn verschillende vragen met verschillende antwoorden. Voer de speaker-test uit om het uitgangspad te valideren en de microfoontest om het ingangspad te valideren. Houd er rekening mee dat deze site momenteel geen speciale loopback-vertragingstool aanbiedt; de bovenstaande Web Audio API-benadering vereist een aparte implementatie of een browserconsole-opstelling. Gebruik het om de akoestische weercatste vertraging te leren die bepaalt of opnames, gesprekken en ruimtelijk geluid natuurlijk aanvoelen op jouw machine.

Meet één keer en houd het resultaat vast. Onder twintig milliseconden betekent professionele timing. Twintig tot zestig dekt de meeste dagelijkse taken. Boven de honderdtwintig zal elke timinggevoelige taak tegen je werken, en de fix begint meestal bij het stuurprogramma in plaats van bij de hardware. Als je het getal nooit hebt gemeten, gok je over elke audiotak die van timing afhangt.