Ses Gecikmesi: Mikrofon ve Hoparlör Gecikmesini Ölçmek

2026-04-13 tarihinde yayınlandı 8 dk okuma

Özet (TL;DR)

Eski USB arayüzüm aracılığıyla akustik gitar çekimi kaydetmek, izleme kulaklıklarında 35 ms civarında gidiş-dönüş gecikmesiyle sonlanırdı — ritmik herhangi bir ifadenin ıslak kumda yürümek gibi hissetmesine yetecek kadar. Düzgün yapılandırılmış bir ASIO sürücüsüyle bir MOTU M2’ye geçmek bunu 5 ms aralığına indirdi ve aynı çekim hemen “çalınamaz”dan “doğal”a geçti. Fenomen bir hata değildir; gidiş-dönüş gecikmesi (RTT) olarak adlandırılan ölçülebilir, fiziksel bir gerçekliktir. RTT beş aşamanın toplamıdır: mikrofon sinyalinin bir girdi buffer’ını doldurması, ana bilgisayar yazılımının o buffer’ı işlemesi, işlenmiş sinyalin bir çıktı buffer’ını doldurması, DAC’ın onu tekrar analog’a dönüştürmesi ve son sesin havada kulağınıza yayılması (her 34 cm için yaklaşık 1 ms). Ayarlanabilir kısım çoğunlukla buffer boyutu ve sürücü modelinde yaşar; ASIO, WASAPI Exclusive, Core Audio ve JACK’in her birinin farklı tipik minimumları ve platform sınırları vardır. Bu rehber, bu bileşenlerin nasıl toplandığını, örnekleme hızı/buffer boyutu ödünleşiminin neden göründüğü kadar sezgisel olmadığını ve pazarlamanın “1 ms” iddialarına güvenmek yerine bir loopback kablosu, bir test tonu ve bir ses düzenleyicisiyle gerçek uçtan uca gecikmenin nasıl ölçüleceğini açıklıyor.

Arka plan ve kavramlar

Bir mikrofon ile bir hoparlör arasında, bir bilgisayar çoğu insanın fark ettiğinden fazlasını yapar. Bir ADC, mikrofon sinyalini seçilen bir örnekleme hızında (yaygın olarak 48 kHz) örnekler ve örnekleri bir girdi buffer’ında toplar. Buffer dolduğunda — diyelim ki 48 kHz’de 128 örnek, yaklaşık 2,67 ms ses — sürücü onu uygulamaya teslim eder.

Uygulama (bir DAW, bir iletişim istemcisi, bir tarayıcı) buffer’ı işler, efektleri uygular veya ağ iletimi için kodlar ve sonucu bir çıktı buffer’ına yazar. Çıktı buffer’ı dolduğunda DAC onu analog bir sinyale dönüştürür ve kulaklık veya hat çıkışından ayrılır.

Sonra bilgisayar dışındaki dünya var. Ses oda sıcaklığında kabaca 343 m/s hızla ilerler, bu da her 34 cm için yaklaşık 1 ms demektir. Kulaklıklar neredeyse hiç eklemez; odanın karşısındaki bir izleme hoparlörü her şeyin üstüne birkaç milisaniye ekler. 1,7 m oturma mesafesindeki bir izleme hoparlörü çifti kabaca 5 ms saf yayılım katkıda bulunur — özellik sayfasında görünmez ama kulaklarınızda vardır.

Yani gidiş-dönüş gecikmesi = girdi buffer’ı + işleme + çıktı buffer’ı + DAC + yayılım. Örnekleme hızı sabitken, küçük buffer’lar gecikmeyi azaltır ama CPU yükünü artırır; çünkü ses iş parçacığının daha sık uyanması gerekir. Buffer boyutu zaman yerine örnekte belirtilirse, örnekleme hızını yükseltmek aynı “N örnek” buffer’ını milisaniye cinsinden kısaltır ama daha yüksek örnekleme hızları da throughput’u yükseltir ve sürücüleri farklı şekilde zorlar; bu gecikmeyi azaltmak için ücretsiz bir yol değildir.

Sürücü modeli uygulama ile ses donanımı arasında oturur ve kendi gecikme özelliklerine sahiptir. Windows’ta klasik MME ve DirectSound yolları uyumluluk için önemli tamponlama ekler; WASAPI Shared daha düşüktür ama yine de karıştırıcı tarafından aracılanmıştır; WASAPI Exclusive ve ASIO bu ek yükün çoğunu atlar. ASIO4ALL, bir satıcı ASIO sürücüsü olmadığında yardımcı olan genel bir ASIO sarıcısıdır, ama gerçek bir satıcı ASIO sürücüsünün yerini tutmaz — aynı Focusrite Scarlett 2i2 3. Nesil üzerinde ölçülen RTT, ASIO4ALL’ın WASAPI üzerine eklemesinden çok, resmi sürücüyle anlamlı biçimde daha düşük iniş yapar. macOS’ta Core Audio, platform varsayılanı olarak zaten düşük gecikme için ayarlanmıştır. Linux’ta JACK ve PipeWire yığınları, yapılandırıldığında çok düşük gecikmeye ulaşabilir, ama tutarlı olmak için gerçek zamanlı çekirdek zamanlaması gerektirir.

Karşılaştırma ve veriler

KriterASIOWASAPI ExclusiveCore AudioJACK
PlatformÇoğunlukla WindowsYalnızca WindowsYalnızca macOSLinux merkezli, çapraz platform taşımaları mevcut
Tipik en düşük gecikmeÇok düşük, yaygın olarak düşük milisaniye aralığındaÖzel modda kullanıldığında düşükDüşük ve kararlı, düşük milisaniye aralığındaİyi yapılandırıldığında çok düşük, daha fazla kurulum karmaşıklığıyla
Paylaşım modeliSürücüye bağlı (tipik olarak özel)Paylaşılan veya özel; özel daha düşük gecikmelidirİyi ayarlanmış paylaşılan mod varsayılandırYönlendirme matrisi tabanlı, çok istemcili

Kesin milisaniye sayıları donanıma, sürücüye ve OS sürümüne güçlü biçimde bağlıdır, bu yüzden bir ürün sayfasındaki “1 ms gecikme” satırına güvenmek yerine bir taban çizgi kurmak için kendi sisteminizi bir kez ölçün. MOTU M2 ve Focusrite Scarlett 2i2 3. Nesil gibi uygun fiyatlı arayüzler, uygun bir ASIO veya Core Audio sürücüsüyle eşleştirildiğinde tek haneli milisaniye gidiş-dönüşe ulaşabilir, ama aynı donanım Windows paylaşılan modu WASAPI yolu üzerinden veya ASIO4ALL’a sarılarak tipik olarak fark edilir biçimde daha kötü performans gösterir. Gerçek RTT’niz üç değişkenin ortak sonucudur — arayüz, sürücü, buffer boyutu — ve bunlardan herhangi birini izolasyonda varsaymak nadiren doğrudur.

Gerçek senaryolar

Senaryo 1 — Canlı performans ve kulak içi izleme. Kulak içi izleyicilerle kendi sesini dinleyen bir şarkıcı birkaç milisaniyelik bir gecikmeyi bile bir zamanlama sorunu olarak hissedecektir. Buradaki hedef 10 ms altında RTT’dir ve bu genellikle düşük buffer boyutları, düşük gecikmeli bir sürücü (Windows’ta ASIO, macOS’ta Core Audio) ve — mümkün olduğunda — arayüzün donanım doğrudan izlemesini gerektirir; bu, izleme sinyali için yazılım yolunu tamamen atlar. MOTU M2’nin ön panel izleme düğmesi bunu tek dönüşle çözer ve Scarlett 2i2 3. Nesil’in “Direct” anahtarı aynısını yapar.

Senaryo 2 — Podcast kaydı. Birkaç sunucu birbirini canlı olarak izlemiyorsa, kayıt seansı sırasında 50 ila 100 ms RTT genellikle iyidir. Post-prodüksiyon yine de parçaları hizalar ve daha büyük bir buffer CPU baş boşluğunu iyileştirir, bu da uzun bir kayıtta düşüş riskini azaltır. Burada en düşük gecikme için optimize etmek çoğu zaman yardımdan çok zarar verir.

Senaryo 3 — Video konferans. Tarayıcı tabanlı WebRTC çağrıları, yerel ses gecikmesinin üstüne ağ, kodlama ve jitter tamponlaması nedeniyle tipik olarak uçtan uca kabaca 100 ila 200 ms aralığında çalışır. Bu, sohbet sırası almanın doğal hissettiği sınıra yakın oturur; eski bir codec ile Bluetooth kulaklıklar eklemek onu bu eşiğin ötesine itebilir ve bu yüzden katılımcılar birbirinin üstüne konuşmaya başlar.

Senaryo 4 — Çevrim içi müzik işbirliği. İnternet üzerinden uzak bir ortakla senkronize müzik çalmayı denemek bu spektrumun bağışlamayan ucudur. Kabaca 25 ila 30 ms tek yönlü gecikmenin ötesinde, istikrarlı bir tempo tutmak zorlaşır ve tipik ev interneti artı tüketici ses yazılımı düzenli olarak bunun üzerine iner. Özel düşük gecikmeli işbirliği platformları mümkün olan her milisaniyeyi tıraşlamak için özel olarak vardır ve o zaman bile genellikle kablolu ethernet, dikkatli sürücü ayarlaması ve internet omurgasında fiziksel yakınlık gerektirirler. Bir tüketici video çağrı yığınının bu iş için yanlış araç olduğunu tanımak genellikle ilk adımdır.

Yaygın yanlış anlamalar

“Bluetooth sesi her zaman yüksek gecikmelidir.” Klasik A2DP akışı önemli gecikme ekler. Ama yeni LE Audio (LC3) ve aptX Low Latency kodekleri bunu önemli ölçüde düşürür, bu da hissedilen performansta bir kategori değişikliğidir. “Bluetooth” diyen iki kulaklık, destekledikleri kodeke bağlı olarak dramatik biçimde farklı olabilir. Yine de bir kayıt seansını izlemek için kablolu daha güvenli seçim olmaya devam ediyor.

“USB sesi her zaman analogdan daha iyidir.” USB ses, arayüzün iyi bir DAC’ı, temiz ön yükselticileri ve kararlı sürücüleri olduğunda yerleşik analogu geçer. Ucuz USB DAC’lar jitter, gürültü ve sürücü sorunları nedeniyle aslında daha kötü olabilir. “USB” tek başına kaliteyi ima etmez; bileşen seçimi eder.

“192 kHz örnekleme hızı daha düşük gecikmelidir.” Sezgiselin aksine ama önemli: buffer zaman (ms) cinsinden belirtilirse, örnekleme hızını yükseltmek fiziksel gecikmeyi azaltmaz. Yalnızca buffer örnekte sabitlendiğinde, daha yüksek bir örnekleme hızı buffer başına daha az milisaniye anlamına gelir — saniyede daha fazla veri, daha fazla CPU ve daha fazla sürücü baskısı pahasına. Düşük gecikme öncelikle daha küçük buffer’lar ve daha iyi bir sürücü modelinden gelir, daha yüksek bir örnekleme hızından değil.

“Yazılım izleme ve donanım izleme aynı hisseder.” Hissetmez. Yazılım izleme, mikrofon sinyalini DAW yolu üzerinden yönlendirir — girdi buffer’ı, eklenti işleme, çıktı buffer’ı — ve yol boyunca RTT biriktirir. Bir ses arayüzünde donanım izleme, mikrofon sinyalini doğrudan arayüzün içindeki kulaklık çıkışına gönderir, izleme yolu için bilgisayarı tamamen atlar. Performansçı kendini etkili olarak sıfır gecikmeyle duyar, bilgisayar ise parçayı daha sonraki üretim için hâlâ kaydeder. Birçok kurulum ikisini karıştırır ve donanım izlemenin tek bir ayar değişikliğiyle ortadan kaldıracağı gecikmeden buffer boyutunu suçlar.

Kontrol listesi

  1. Kullanım durumunuz için RTT hedefini tanımlayın. Canlı performans: 10 ms altında; kayıt: 50 ila 100 ms iyidir; konferans: 100 ila 200 ms gerçekçi.
  2. Sürücü modelini seçin. Windows’ta ASIO veya WASAPI Exclusive; macOS’ta Core Audio; Linux’ta JACK veya PipeWire. Varsayılan paylaşılan mod yığınları (MME, varsayılan paylaşılan WASAPI) genellikle en yüksek gecikmeye sahiptir.
  3. Buffer boyutunu adım adım düşürün, düşüşler başlamadan hemen önce. Bu, sisteminizin pratik tabanıdır.
  4. Bir loopback ölçümü yapın. Arayüzün çıkışını girişine bir kabloyla bağlayın, bir test tonu çalın ve yakalanan dalga biçiminden ses düzenleyicide gecikmeyi okuyun.
  5. Örnekleme hızını proje ihtiyacına eşleştirin. Video işi için 48 kHz tipiktir; müzik için 44,1/48 kHz. Belirli bir nedenle yalnızca üzerine çıkın.
  6. İzleme yolunu akıllıca kullanın. Mümkün olduğunda, performansçının kulakları için arayüzün doğrudan izleme özelliğini kullanın; bu, kayıt yolunun birkaç milisaniyelik gecikmesi olsa bile izleme RTT’sini etkili olarak sıfır yapar.

İlgili araç

Patrache Studio ses gecikme aracı, tarayıcıda gidiş-dönüş gecikmesini tahmin eder; donanım almadan kaba bir okuma almak kolaylaşır. Oyun bağlamındaki daha geniş “girdi gecikmesi” resmi için Oyun için Klavye NKRO ve Girdi Gecikmesi bölümüne bakın. Ses gecikmesinin A/V senkronizasyonunu etkilediği bir video çağrı kurulumunu ayarlıyorsanız, bu rehberi Webcam Tanılaması: Kare Hızı, Çözünürlük ve Aydınlatma ile eşleştirin; sesin üstüne binen kamera tarafı gecikmesini anlamak için.

Kaynaklar

İlgili araç

diagno.patrache.studio/audio/latency/