Gecikme (Latency)

Gecikme, bir ses sinyalinin sisteme girdiği ve çıktığı zaman arasındaki süreyi ifade eder. Bu, bilgisayardan müzik üreten müzisyenler veya stüdyoda kayıt yapan mühendisler için bir başağrısı kaynağıdır. Benim bu yazıda vurgulamak istediğim, kayıt sürecinden çok işin bilgisayardan müzik dinleme tarafıyla ilgili. Kullanmakta olduğum sistem, öncelikli olarak Windows Server 2012 (Audiophile Optimizer yüklü) ve Windows 10 üzerinde Jriver Media Center içeriyor. Tabi ki başka kurgular için genellemeler yapmak mümkün, ama bu yazıyı kullanageldiğim sistem kapsamında değerlendirin lütfen.

Müzik dosyasının tutulduğu depolama biriminden, USB çıkışına kadar (veya DAC girişine kadar), bilgisayar içindeki çeşitli arabirimler gecikmeye sebep olur. Sayısal müzik verisinin depolama biriminden okunması, ara belleklerin doldurulması, medya oynatıcı programının komutlarının CPU’da işlenmesi, sayısal sinyal işleme gibi… Bütün arabirimlerde homojen bir gecikme olsaydı sorun daha kolaydı. Ancak, farklı bilgisayar unsurlarında oluşan farklı gecikme süreleri (milisaniyelerden bahsediyoruz) bazen tolerans sınırlarını zorlayabiliyor. Bunun etkisini analog olarak dinlediğimiz müzikte, “çıt”, “pıt” gibi sesler halinde duyabiliyoruz.

Çıt-pıt seslerinin dinlenilen müziğin hep aynı saniyesinde mi, yoksa rastlantısal olarak farklı zamanlarda mı oluştuğunu önemli. Parçanın hep aynı saniyesinde duyulan çıtırtı, kaynak müzik dosyasındaki bir hataya işaret eder. Çıtırtıların zamanlama olarak rastlantısal olması ise, bilgisayarın sesi işlediği süreçteki bir darboğaza işaret olabilir. Bu darboğaz büyük ihtimalle farklı birleşenler arasındaki gecikme (latency) kaynaklıdır. Yüksek çözünürlüklü (DSD128, DSD256, DXD gibi) dosyalar ile bu olasılık daha güçlüdür. Düşük güçlü bir CPU (örneğin Celeron işlemci) bahsettiğim darboğazın sebebi olabilir ama bazen güçlü bir CPU (örn. Intel Core i7) ile de bu durumu yaşayabilirsiniz. Güçlü bir CPU ile dengeli bir mimari farklı şeyler.

Optimizasyon için araçlar: Fidelizer ve Audiophile Optimizer

Donanımsal bileşenleri bir yana bırakacak olursak, müzik dinlenen bilgisayar sistemini dengeli kılmanın en pratik yolu, işletim sisteminin optimize edilmesidir. Yapılması gereken, müzik dinleme için gerekli olmayan bilgisayar işlevlerinin, geri plan görevlerinin, özelliklerin durdurulmasıdır. Onlarca alanda el ile yapılabilecek çeşitli iyileştirmeleri otomatikleştirmek üzere, Windows 10 için “Fidelizer“, Windows Server 2012 R2 veya Windows Server 2016 için “Audiophile Optimizer” gibi araçlar mevcut.

Audiophile Optimizer, işi daha da ileri götürerek, Windows Server masaüstü ortamını etkisiz kılabiliyor; işletim sistemini “Core” moduna geçirebiliyor. Yalnız, Audiophile Optimizer’ın yaptığı bazı değişiklikler kalıcı olduğu için gündelik kullandığınız işletim sistemi üzerinde uygulanması tavsiye edilmez. Ya müzik sunucu olaak ayrı bir bilgisayar düşünmelisiniz, ya da “dual boot” bir sistem düşünülebilir. Yani, müzik dinlemek için WS2012 + AO ile açılabilir; gündelik işler için Windows 10 ile boot edilebilir.

Ayrıca, DAC’ın bağlı olduğu USB portunun sürücülerinin güncel tutulması, medya oynatıcı yazılım ayarlarında, ön tampon belleğinin (buffer) ayarlanması ve hatta sistem BIOS’unun güncel tutulması da dengeli bir sistem için tavsiye edilir.

Bellekten oynatma (memory playback) iyi bir şey olarak bilinir ve tavsiye edilir. Eğer, bellekten oynatma özelliği etkin ise, bir müzik dosyasının oynatılmaya başlandığı ile saniyelerde, CPU bir yandan parçanın tümünü belleğe çekmekle uğraşırken bir yandan da parçayı çalmak ile uğraşır. Parça belleğe çekilene kadar işlemci üzerinde fazladan bir stres oluşur. Yüksek çözünürlüklü dosyalarda (DSD) bu stres daha fazladır. Bu stres, seste çıtırtı-pıtırtı’lara sebep olabilir veya olmayabilir. Bellekten çalma özelliğinin etkinleştirirken iyileştirme mi getiriyor yoksa sese yansıyan bir olumsuzluk mu yaratıyor denemek lazım.

Genel olarak, sistemin/yazılımın tampon bellek (buffer) ayarlarına dikkat etmek lazım. Tampon bellek miktarının arttırılması, müzikte atlama gibi bazı sıkıntıları giderirken, gecikmeyi arttıracaktır. Yani, durma, arama vb. işlevler biraz daha geç yanıt verecektir. Örneğin, JRiver yazılımında bunun için iki üç tane tampon bellek ayarı mevcut. Optimum çözümü bunları ayarlayarak bulmak gerekiyor. Örnek olarak, kullanıdığım DAC için önerilen JRiver ayarları burada.

Eğer rip edilmiş SACD .ISO dosyaları kullanıyorsanız, uygun araçlar kullanarak .ISO albüm dosyasını, parça bazında .DSF dosyalarına çevirerek,  oynatma anında sistem üzerindeki yükü azaltabilirsiniz. Çünkü, sistem albümün tümünü değil, sadece ilgili parçayı oynatmakla uğraşacaktır. Web günlüğümde böyle bir araçtan bahsetmiştim. Bkz: ISO’dan DSD’ye Çevirmek.

Bilgisayarda gecikmeleri teşhis etmek için bir araç: LatencyMon:

Konuyu biraz daha somutlaştıralım. Bir bilgisayardaki birçok ses problemi, DPC gecikmesinden kaynaklanabilir. DPC, (Delayed Procedure Call) Ertelenmiş Yordam Çağrısı anlamına gelir (ne kadar açıklayıcı oldu değil mi?). En basit haliyle DPC, Windows sisteminizin sürücü verimliliğini sağlayan bir parçasıdır. Görevini normalden daha uzun sürede gereçekleştiren bir sürücü varsa, diğer sürücülerin görevlerini zamanında yapmalarını engelleyebilir. En kötü durum, ses arabirim sürücünüzün zaman içinde yanıt vermesine ve tıklamalar, çıtlamalar ve distorsiyona neden olabilmesidir.

DPC gecikmesini teşhis etmede yardımcı olabilecek bazı programlar mevcut. Windows 7 veya daha üstü için Resplendence ürünü LatencyMon önerilebilir. Bu program sadece bir DPC sorunu olup olmadığını değil, aynı zamanda hangi sürücünün gecikmeye neden olduğunu da teşhis edebiliyor.

Yukarıdaki LatencyMon ekran örnekleri bu yazıda belirttiğim çıt-pıt seslerinden muzdarip bir sistemden alınmış. Özetle, sistemin gerçek zamanda ses işlemlerini yapmakta zorlandığı belirtiliyor. İlk ekranda, WLAN adaptörünü etkinsizleştirme, CPU hız ayarlarını (CPU throttling) gözden geçirme gibi öneriler verilmiş. Genel istatistiklerin verildiği ikinci ekranda, sistemin potansiyel CPU hızı ile gerçekteki CPU hızı arasında bir fark olduğu, bu nedenle CPU frekansının veya ısısının ölçülmesi önerilmiş. Gayet yerinde bir öneri. Söz konusu sistemi bildiğimden, ısınma nedeni ile CPU hızının düşürüldüğü, bu nedenle performans düşüklüğü yaşandığını anlıyorum. Başka durumlarda, bir sürücüden kaynaklı bir darboğaz da ortaya çıkabilirdi.

Yazıyı sonlandırıken – ata sözü gibi olacak ama – odyofil bakış açısı ile bakarsak “en iyi yol, en kısa olandır” düşüncemi yinelemek isterim.