WASAPI Latensinställningar i Windows: Komplett guide

Om du arbetar med ljud i Windows kommer du förr eller senare att stöta på WASAPI-latens och den ändlösa jämförelsen med ASIO och WASAPI . Alla som spelar in i en DAW, streamar live, spelar onlinespel eller producerar musik vet att några millisekunders fördröjning kan förstöra en tagning, störa en röst eller förvandla ett spel till en prövning.

I Windows 10 och senare versioner har Microsoft förbättrat sin ljudstack avsevärt, och idag är det möjligt att uppnå mycket lägre latens med WASAPI i delat eller exklusivt läge , utan att offra webbläsarljud eller ljud från andra applikationer. Nyckeln är att förstå hur stacken fungerar, vad som har ändrats, vilka hårdvarubegränsningar den medför och vilka parametrar vi kan justera (som användare eller utvecklare) för att pressa ut de extra millisekunderna.

Vad är ljudlatens och varför är det så viktigt?

När vi pratar om ljudlatens syftar vi på den tid som går från att ett ljud genereras tills du hör det eller din applikation tar emot det. Denna tid mäts i millisekunder, och även om den kan verka nästan försumbar på pappret, så är den i praktiken skillnaden mellan en smidig upplevelse och något helt obekvämt.

Vid musikproduktion och inspelning behöver en instrumentalist höra sig själv nästan omedelbart medan de spelar . Om varje ton tar tiotals millisekunder att återvända genom hörlurarna börjar hjärnan kämpa med vad den hör och vad den känner, och att hålla rytmen blir en prövning.

Vid streaming , poddsändningar och videosamtal kan latens orsaka skillnader mellan video och ljud, irriterande ekon och känslan av att "prata in i en vägg ". Att ha sin egen röst fördröjd med några millisekunder i hörlurarna anstränger högtalaren, orsakar snubbling och låter onaturligt för lyssnaren.

För spelare, särskilt i skjutspel, tävlingsinriktade spel eller VR-upplevelser, innebär långsam ljudrespons att viktiga ljudsignaler (fotsteg, skott, varningar) missas eller att man märker att handkontrollens handling och ljud är osynkroniserade, vilket förstör fördjupningen. I dessa fall är det användbart att lära sig hur man mäter latens i videospel och agerar därefter.

Mer tekniskt sett brukar man skilja mellan uppspelningslatens, inspelningslatens, tur- och returlatens och latens i samband med beröring (till exempel att röra vid skärmen och höra ett ljudsvar). Alla dessa faktorer läggs ihop, och det är viktigt att förstå dem för att veta vart vår tid tar vägen.

Typer av latens i ljudvägen

Inom Windows ljudstack används flera koncept för att beskriva fördröjningarna i varje steg av ljudets väg . Detta är inte bara en akademisk fråga: varje typ av latens har olika orsaker och olika sätt att mildra dem.

Uppspelningsfördröjning är fördröjningen mellan när applikationen levererar en ljudbuffert för uppspelning och när du hör den via dina högtalare eller hörlurar . Buffertstorlek, formatkonvertering och eventuella effekter som tillämpas längs vägen spelar alla roll.

Inspelningslatens, å andra sidan, är den tid det tar för ljudet som fångas upp från mikrofonen att nå applikationen . Den omfattar tiden från det att ljudet kommer in i givaren, passerar genom gränssnittet, drivrutinen och ljudmotorn, tills programvaran kan läsa det datablocket.

Den så kallade round-trip latensen är summan av båda: inspelning, bearbetning i appen och uppspelning via högtalarna . Det är det som verkligen spelar roll i scenarier som monitorering i en DAW, där du spelar, signalen passerar genom datorn och återvänder till dina öron.

I pekskärmsgränssnitt talas det också ofta om latens mellan beröring och applikation och beröring och ljud: tiden mellan att man trycker på skärmen, att händelsen bearbetas och att systemet svarar med ljud . För virtuella instrument eller kreativa appar på Windows-surfplattor eller konvertibla datorer måste denna kedja vara så kort som möjligt.

Hur Windows ljudstacken är sammansatt

Under WASAPI, ASIO och liknande har Windows en ljudstack med en central motor som mixar strömmar, tillämpar effekter, skalar om format och kommunicerar med drivrutiner . Att förstå denna process hjälper till att se var latens uppstår och förloras.

Under uppspelning skriver programmet ljud till en buffert som exponeras av API:et. Windows ljudmotor läser dessa data, bearbetar dem (inklusive effekter i form av APO:er eller ljudbearbetningsobjekt) och dumpar dem sedan till en annan buffert som drivrutinen använder för att skicka till hårdvaran.

Latensen som är associerad med dessa APO: er beror på den bearbetning de utför (utjämning, brusreducering, 3D-effekter, etc.) . Ju mer komplex algoritmen är och ju större mängd tillstånd den behöver ackumulera, desto fler samplingar måste den lagra i en buffert, och desto större blir fördröjningen.

Före Windows 10 tog det cirka 12 ms att spela upp flyttalsdata och cirka 6 ms att spela helt enkelt genom ljudmotorn . Sedan Windows 10 har denna process optimerats drastiskt och tar nu cirka 1,3 ms, oavsett datatyp.

Efter bearbetning placerar motorn resultatet i en buffert vars längd också har en direkt inverkan. I äldre system var denna buffert fastställd till cirka 10 ms . I moderna versioner kan ljuddrivrutinen deklarera olika stödda storlekar och tillåta mindre värden, till exempel 2-3 ms.

Vid inspelning händer något liknande, men i omvänd ordning: hårdvaran tar signalen från mikrofonen , kan tillämpa effekter (AGC, ekodämpning etc.), styrenheten häller den informationen i en buffert, och ljudmotorn samlar in och bearbetar den med sina egna APO:er innan den görs tillgänglig för applikationen.

I äldre versioner lade ljudmotorn till cirka 6 ms för att fånga tid för flyttalsdata och praktiskt taget 0 ms för heltal. Sedan Windows 10 har detta bidrag minskat till den grad att det är praktiskt taget försumbart. Trots det bidrar buffertarna i drivrutinen och hårdvaran fortfarande till den totala tiden.

Det finns också ett dedikerat ljudstackläge. Om en app öppnar en slutpunkt i dedikerat läge kringgår den mixningsmotorn och kommunicerar direkt med hårdvarubufferten . Detta minimerar ytterligare latensen, men nackdelen är att inget annat program samtidigt kan använda den in- eller utmatningsenheten.

ASIO, exklusivt läge och varför WASAPI har förbättrats så mycket

I åratal har standardsättet för att uppnå låg latens i musikproduktion varit att använda ASIO eller enheter i dedikerat läge . Med ASIO kommunicerar DAW:n nästan direkt med gränssnittstillverkarens drivrutin, utan systemmixern däremellan.

Problemet är att den här metoden har sina nackdelar: den kräver vanligtvis specifika tredjepartsdrivrutiner , programvaran måste vara förberedd för att kommunicera med det API:et, och i allmänhet utelämnas systemljud (webbläsare, spel, spelare) eller så måste man tillgripa komplexa lösningar för att dirigera det.

Samtidigt erbjöd WASAPIs exklusiva läge något liknande: appens arbetsflöde gick nästan direkt till enheten . Men återigen förlorade andra applikationer åtkomst vid den tidpunkten, vilket inte är direkt praktiskt när du vill blanda DAW:er med YouTube-videor, Discord och så vidare.

För att undvika att tvinga fram ett val mellan latens och flexibilitet förbättrade Microsoft den delade stacken i Windows 10 för att sänka latensen även utan exklusiv användning . Motorn gjordes lättare och, viktigast av allt, möjligheten att förhandla om mindre buffertstorlekar mellan appen och drivrutinen lades till.

Dessutom finns det ett speciellt resurshanteringsläge: när ett program börjar arbeta med mycket korta buffertar prioriterar Windows trådarna relaterade till den ljudströmmen och förhindrar att andra systemuppgifter avbryter bearbetningen vid kritiska tillfällen.

WASAPI-latensinställningar för DAW- och streaminganvändare

Ur slutanvändarens perspektiv presenteras WASAPI som ett av ljudenhetsalternativen i många DAW:er och inspelningsprogram . I Reaper är till exempel jämförelser mellan ASIO- och WASAPI-latenser (både i exklusivt och delat läge) vanliga.

I vissa fall kan ett byte från ASIO till dedikerad WASAPI uppnå ännu lägre latens än tillverkarens ASIO-drivrutin , förutsatt att hårdvaran och Windows-drivrutinen är korrekt konfigurerade. Detta är inte den vanligaste situationen, men det kan inträffa, och när det händer är det förståeligt att användaren inte vill återgå till ASIO.

Men när man växlar till delad WASAPI kan distorsioner, klick eller artefakter uppstå när man spelar upp eller spelar in ljud från DAW:n , medan andra systemljud (webbläsare, spel) spelas upp utan problem. Detta beror vanligtvis på formatmatchningar, alltför aggressiv buffring eller påtvingade konverteringar.

En typisk konflikt uppstår när systemet tvingar enheten att arbeta i ett annat bitdjupsformat än det som gränssnittet faktiskt stöder . Till exempel kan WASAPI presentera 24 bitar i DAW-dialogrutan, medan Windows ljudpanel bara erbjuder 16 bitar över alla sina samplingsfrekvenser.

I dessa fall, för att undvika distorsion i delad WASAPI, är det lämpligt att kontrollera bitdjupet och samplingsfrekvensen som är konfigurerade som standard i Windows ljudalternativ och se till att DAW:n använder ett format som är kompatibelt med vad gränssnittet faktiskt stöder.

I andra sammanhang, som att spela in voice-overs med en USB- mikrofon i enkla applikationer eller verktyg som Audacity, används WASAPI huvudsakligen för att fånga systemets eget ljud eller utdata från Windows-mixern , snarare än för att uppnå lägsta möjliga latens.

Latens, buffertar och mänsklig uppfattning

Latens mäts vanligtvis i millisekunder, och i praktiken anses fördröjningen under cirka 10 ms vara praktiskt taget omärkbar för de flesta . Mellan 10 och 20 ms börjar den bli märkbar i känsliga uppgifter, och över det blir den tydligt irriterande.

När du lyssnar på dig själv genom hörlurar medan du talar, börjar all latens över 10 ms skapa den där "interna ekokänslan" . Om den stiger till 30 eller 40 ms blir de flesta förvirrade, slutar prata eller tar av sig hörlurarna.

Samtidigt beskrivs digitala ljudsignaler med samplingsfrekvens (i Hz) och buffertstorlek (i samplingar) . Som referens betyder 44 100 Hz att vågformen är uppdelad i 44 100 samplingar per sekund; 48 000 Hz gör detsamma med 48 000 samplingar, och så vidare.

Bufferten är ett slags litet datalagringsområde genom vilket ljuddata flödar. Ju större den är, desto större säkerhetsmarginal har du mot CPU-toppar eller avbrott , men på bekostnad av att lägga till millisekunder till den totala latensen. Om du minskar den för mycket måste systemet vakna oftare för att fylla på den och är mer benäget för avbrott eller buggar.

Därför, när man konfigurerar en enhet i en DAW eller streamingapp, är det vanliga dilemmat att välja en buffertstorlek som är tillräckligt låg så att fördröjningen inte är märkbar , men inte så låg att klick eller droppar börjar under själva arbetet.

Hur man minskar ljudfördröjningen i Windows med hjälp av WASAPI

För att förbättra upplevelsen med WASAPI och generellt med ljud i Windows finns det ett antal åtgärder som bör tillämpas eller åtminstone ses över, både på hårdvaru-, mjukvaru- och systemnivå.

Det första steget är att se till att din ljudhårdvara (gränssnitt, integrerat ljudkort, USB-mikrofoner) och dess drivrutiner är korrekt installerade och uppdaterade . Många av förbättringarna med låg latens i Windows 10 förlitar sig på DDI:er och egenskaper som bara finns i moderna drivrutiner; att använda LatencyMon för att diagnostisera latens och upptäcka drivrutinsproblem är en bra idé.

Inom musikbranschen är det fortfarande standard att använda gränssnitt med högkvalitativa ASIO-drivrutiner när man arbetar med DAW:er, virtuella instrument eller komplexa mixar. ASIO fortsätter att erbjuda finjusterad kontroll över buffertstorlekar och är generellt stabil om datorn är dedikerad till ljud och inte utsätts för överklockning eller andra tunga uppgifter.

Inom streaming och spel blir ASIO dock opraktiskt eftersom de flesta applikationer (spel, OBS, webbläsare) använder inbyggda Windows-drivrutiner (DirectSound, WASAPI). När man blandar dessa källor är det att föredra att hålla sig inom operativsystemets inbyggda ekosystem.

En regel som sällan misslyckas är att undvika att kedja ihop fler enheter och program än nödvändigt i signalvägen . Varje analog-till-digital-omvandling, varje steg genom en effektprocessor eller varje hopp från en app till en annan medför en liten fördröjning och risk för avvikelser.

Att till exempel tala in i en XLR-mikrofon ansluten till ett dedikerat gränssnitt med direkt hårdvarumixning är inte detsamma som att gå igenom en USB-mikrofon, en programvarubaserad röstväxlare, en virtuell ljudrouter och USB-spelhörlurar . I det andra fallet orsakar den kumulativa effekten oundvikligen att latensen ökar avsevärt.

Latens och specifika förbättringar i Windows 10 och senare

Microsoft har inte bara finslipat ljudmotorn i Windows 10; de har också lagt till mekanismer för att program och drivrutiner ska kunna arbeta tillsammans för att minska tur- och returlatens utan att helt offra flexibiliteten hos den delade stacken.

För det första, även utan att ändra kod, har många applikationer sett en minskning på mellan 4,5 och 16 ms i tur och riktningslatens jämfört med Windows 8.1 , helt enkelt på grund av interna motoroptimeringar. De som använder flyttaldata gynnas mest.

För det andra, om systemet har uppdaterade drivrutiner, kan dessa annonsera buffertstorlekar som är mindre än standard 10 ms . Detta gör det möjligt för applikationer som kräver låg latens att förhandla fram värden på 5 ms, 3 ms, 1 ms, etc., för både uppspelning och inspelning.

Dessutom, när en app börjar fungera med mycket små buffertar, aktiverar Windows ett resurshanteringsläge som prioriterar ljudundersystemet : det skyddar trådarna i motorn, drivrutinen och appar som markerats som ljudkritiska för att minimera avbrott och fel.

Allt detta innebär att om du utvecklar en app som kräver snabb respons kan du lita på att den nya infrastrukturen uppnår mycket låg latens utan att ge upp delat läge, förutsatt att hårdvaran stöder det.

AudioGraph: det moderna API:et för skapande och multimedia

AudioGraph är Universal Windows Platform API:et som är utformat för interaktiva scenarier och scenarier för musikskapande, och erbjuder ett mer användarvänligt abstraktionslager än att direkt använda WASAPI. Det är tillgängligt i C++, C#, JavaScript och andra .NET-språk.

För mål med låg latens exponerar AudioGraph en egenskap som heter AudioGraphSettings::QuantumSizeSelectionMode , som låter dig ange om du vill ha systemets standardbuffertstorlek, lägsta möjliga latens eller ett specifikt värde nära det önskade.

Den kan konfigureras för att använda standardbuffertstorleken (cirka 10 ms), för att välja det minimum som stöds av ljuddrivrutinen , eller för att försöka komma närmare det antal samplingar som appen önskar i varje bearbetningskvantum.

De officiella exemplen visar hur man med bara några få rader kod kan skapa en ljudgraf med låg latens genom att helt enkelt välja läget LowestLatency . Det här alternativet kontrollerar internt vilka storlekar enheten stöder och väljer den mest aggressiva storleken utan att överskrida de tillåtna gränserna.

AudioGraph hanterar även hanteringen av ljudtrådar internt med prioritet , så utvecklaren behöver inte explicit välja MMCSS eller arbeta direkt med realtidsköer för att dra nytta av systemets låglatensläge.

WASAPI och IAudioClient3: finjustering av periodicitet

För de som behöver mer kontroll på låg nivå, specifika funktioner eller till och med lägre latenser än de som uppnås med AudioGraph , utökade Microsoft WASAPI med ett nytt gränssnitt: IAudioClient3, härlett från det redan välkända IAudioClient2.

Det här gränssnittet lägger till metoder för att fråga efter ljudmotorns aktuella format och periodicitet i delat läge , hämta intervallet för perioder som tillåts för ett givet format och öppna delade strömmar med en specifik periodicitet, istället för att acceptera standardvärdet.

I praktiken gör detta att appen kan ta reda på vilka buffertstorlekar som är tillåtna (multiplar av en grundperiod mellan ett minimum och ett maximum) och välja ett specifikt värde som balanserar stabilitet och latens enligt dess behov.

Med IAudioClient3 kan du också ange att strömmen ska använda det format som anges av applikationen utan omsampling i motorn , förutsatt att enheten stöder exakt det formatet. Detta undviker mellanliggande konverteringar som kan öka komplexiteten och ge mindre fördröjningar.

Dessutom rekommenderar Microsoft att WASAPI-applikationer som kräver låg latens skapar sina bearbetningsuppgifter via köerna för realtidsarbetsfunktioner (RT Work Queue) eller Media Foundation , och märker dem som "Audio" eller "ProAudio" istället för att starta sina egna okoordinerade trådar.

Denna märkning gör det möjligt för Windows att centralt hantera prioriteringar och affiniteter för dessa trådar inom sitt speciella ljudläge, vilket minskar risken för att ett annat delsystem avbryter dem mitt i bearbetningen av en begränsad buffert.

Förbättringar behövs i drivrutiner med låg latens

Användarprogramvarukomponenten är bara halva historien. För att ett system verkligen ska fungera med buffertar på några millisekunder under optimala förhållanden måste även ljuddrivrutinerna göra sin del.

Från och med Windows 10 kan drivrutiner, genom specifika egenskaper, ange den absolut minsta buffertstorleken de stöder i varje bearbetningsläge . Denna information inkluderar allmänna begränsningar och specifika begränsningar för standardläget, bioläget etc.

Till exempel kan en drivrutin ange ett absolut minimum på 2 ms, men i standardbearbetningsläget kan den effektiva samplingsstorleken vara 128 samplingar vid 48 kHz (ungefär 3 ms). Ljudstacken respekterar dessa gränser och kommer aldrig att försöka gå under det angivna minimumet.

Utöver buffertstorlek finns det DDI:er som gör det enklare för styrenheten att korrekt rapportera vilken del av bufferten som är ledig eller full, tillhandahålla exakta tidsstämplar baserat på dataflödesräknaren och, i vissa scenarier, ladda ner data snabbare än i realtid om information har ackumulerats internt.

Dessa funktioner är särskilt användbara i konstruktioner med komplexa DSP:er eller icke-triviala dataöverföringar mellan minne och hårdvara, där strömmens position och interna latens beror på flera mellanliggande block . Tidsstämpelberäkningen måste ta hänsyn till dessa fasta fördröjningar så att systemet kan justera data korrekt.

Slutligen, för att Windows ska kunna skydda ljudundersystemet ordentligt i scenarier med mycket låg latens, måste drivrutiner registrera sina strömmande resurser med PortCls : deras egna avbrott och trådar som används för att säkerställa dataflöde.

Denna registrering kan göras när drivrutinen laddas eller vid körning, och det är obligatoriskt att alla drivrutiner i strömningskedjan deltar på ett eller annat sätt. I stackar med HDAudio-bussar, till exempel, utförs en del av detta arbete av bussdrivrutinen själv, medan miniporten registrerar sina egna trådar.

Verktyg och tekniker för att mäta latens i Windows

För att avgöra om WASAPI-justeringar och ändringar av drivrutiner faktiskt gör någon skillnad är det vanligt att mäta tur- och returlatens med hjälp av testpulser som spelas upp genom högtalarna och fångas upp av en mikrofon . Programvaran beräknar fördröjningen mellan sändning och mottagning, och om du observerar mikrobortfall är det värt att granska hur man specifikt mäter DPC-latens.

Den här metoden låter dig jämföra olika buffertstorlekar, driftlägen och drivrutinsversioner, förutsatt att ljudenheten stöder de nödvändiga små buffertintervallen . Annars återgår systemet till standardbuffertstorleken på 10 ms. För en mer djupgående analys kan du lära dig hur du analyserar Windows noggrant med WPR/WPA.

På system med standard HDAudio-hårdvara har den generiska Microsoft HDAudio-inboxdrivrutinen uppdaterats för att stödja samplingsstorlekar mellan 128 samplingar (ungefär 2,66 ms vid 48 kHz) och 480 samplingar (10 ms vid 48 kHz). I vissa fall kan det vara användbart att installera den här generiska drivrutinen för testning.

Processen innebär att öppna Enhetshanteraren , lokalisera enheten som representerar de interna högtalarna och tvinga fram installationen av Microsofts drivrutin "High Definition Audio Device" istället för tillverkarens codec. Efter en omstart kommer systemet att använda denna generiska drivrutin för den slutpunkten.

Det är en bra idé att notera vilken drivrutin som användes innan så att du kan återställa ändringen om det behövs. Även om Microsofts drivrutin är användbar för att experimentera med små buffertstorlekar, erbjuder tillverkarens drivrutin vanligtvis ljudkvalitet eller specifika funktioner som är bättre lämpade för hårdvaran.

WASAPI, AudioGraph och praktiska latensskillnader

Även om båda API:erna förlitar sig på samma ljudmotor, beter sig AudioGraph och WASAPI i praktiken inte alltid likadant vad gäller latens , även med samma underliggande buffertstorlekar.

AudioGraph lägger till en latensbuffert på inspelningssidan för att synkronisera uppspelning och inspelning . Detta förenklar applikationskoden avsevärt eftersom det säkerställer att båda sökvägarna är i linje, men det lägger till några millisekunder.

I uppspelningsvägen, när systemet använder buffertstorlekar större än cirka 6 ms, kan AudioGraph introducera ytterligare en säkerhetsbuffert , återigen med idén att erbjuda en stabil och förutsägbar schemaläggningsmodell till bekostnad av lite extra latens.

WASAPI, å andra sidan, exponerar rutten med mindre abstraktion. Detta innebär mer manuellt arbete för utvecklaren , men i gengäld möjliggör det maximering av latensreduktion under vissa förhållanden, särskilt i lågfrekvent delat läge och med IAudioClient3.

Dessutom, till skillnad från AudioGraph, möjliggör WASAPI mer detaljerad hantering av inspelningseffekter, användning av råbearbetning och samordning med andra API:er som Media Foundation , vilket öppnar dörren för specifika optimeringar i professionella projekt.

I samtliga fall är Microsofts rekommendation tydlig: använd inte råbearbetningsläget lättvindigt . Att inaktivera OEM-effekter kan förbättra latensen, men det kan också leda till mindre optimerade uppspelningssignaler eller inspelningsformat som är svåra för appen att hantera.

Genom att sammanställa alla dessa delar blir det tydligt att vägen till att bemästra WASAPI-latensinställningar ligger i att noggrant förstå Windows-stacken, din hårdvarus beteende och de tillgängliga API:erna. Först då kan du identifiera de områden där varje millisekund verkligen vinner (eller förlorar) och finjustera konfigurationen för att möta de specifika behoven hos varje applikation, utan att offra stabilitet eller ljudkvalitet.