CPU kullanımı düşükken ses neden kesilir? — Arabellek ve zaman sınırı üzerinden düşünmek

Müzik dinlerken ses ara sıra “çıt” diye kesiliyor. Görev Yöneticisi’nde CPU kullanımı %10 civarında olduğu hâlde kararsız olan yalnızca ses. Böyle bir durumda, CPU’da boş kapasite varken ses neden kesilir?

CPU kullanımı düşük olsa bile, sonraki ses verisinin doldurulması zaman sınırına yetişmezse ses kesilebilir. Çünkü arabellekte kalan ses çalınırken sonraki verinin teslim edilmesi gerekir. Veri ya da kilit beklemeleri, gereken mantıksal CPU üzerindeki DPC/ISR gibi nedenlerle doldurmanın gecikmesi, CPU’nun tamamı kullanılmadan da yaşanır. Exclusive-Mode Streams, CPU Analysis

Ancak yalnızca duyulan “çıt” sesine bakarak bunun bir underrun olduğuna kesin olarak karar veremezsiniz. Benzer belirtiler ses kaynağından, uygulamadan, ses efektlerinden, çıkış cihazından ve benzeri etkenlerden de kaynaklanır. Önce aynı ses kaynağıyla koşulları birer birer değiştirip eski hâline döndürerek karşılaştırırız; bununla da daraltılamıyorsa ses kesintisinin öncesini ve sonrasını kaydederiz. Fix distorted or crackling audio in Windows

Bu makale bu soruyu ve onu izleyen “Arabelleği büyütmek yeterli mi?” ile “Nedeni daraltmak için neyi karşılaştırmalı, neyi kaydetmeli?” sorularını ele alıyor. Yalnızca CPU kullanımına ya da duyulan sese bakarak tek tek arızaların nedenini kesinleştirmeyi amaçlamıyor.

Kapsam ağırlıklı olarak Windows 11’deki ses çıkışıdır. Dahili, kablolu, USB, Bluetooth gibi çıkışları karşılaştırmaya dahil ediyoruz; müzik prodüksiyon yazılımlarında (DAW) da uygulama veya sürücü bir arabellek ayarı sunuyorsa bu ayarla yapılacak karşılaştırmayı ele alıyoruz. Kayıt tarafının tasarımının bütününü ve her cihaza özgü kablosuz iletişim teşhisini kapsamlı olarak ele almıyoruz.

Açıklamalarda temel örnek olarak paylaşılan modu kullanıyoruz. Gerçek yol, arabellek miktarı ve işleme periyodu uygulamaya, API’ye, sürücüye ve cihaza göre değişir; tüm uygulamalarda ortak olan bir arabellek ayar ekranı da yoktur. Low Latency Audio

Burada verilen CPU kullanımı, 10 milisaniyelik kalan miktar, doldurma zamanları gibi değerler açıklama amaçlı varsayımlardır. Belirli bir PC’de sorunun yeniden üretilmesini ya da iyileşmeyi ölçerek hazırlanmış bir rapor değildir. Makalenin ikinci yarısındaki işlemler, okuyucunun kendi ortamında uygulayacağı kontrol adımlarıdır.

İşleyişi, sıradaki “Ses çalma arabelleği” bölümünden başlayarak sırayla okuyabilirsiniz. Ses kesintisini incelemeye yönelik işlemler “Yeniden üretme koşullarını karşılaştırma” ve “Ses kesintisini WPR ile kaydetme” bölümlerindedir.

Diyagramda düz çizgi her zaman geçerli olan bir ilişkiyi, kesikli çizgi ise koşullu bir ilişkiyi gösterir (koşullar, ayrıntı sayfasında her ilişki için verilmiştir). İlişkilerin tam listesi (toplam 5, kanıt ve kesinlik derecesiyle birlikte) ve ana kavramların tanımları bilgi haritası ayrıntı sayfasında (Japonca) toplanmıştır. Veri: JSON-LD / Turtle

Ses çalma arabelleği

Bir müzik dosyasını kaydetmiş olmak hoparlörün çalması için yetmez. Uygulama ses verisini hazırlar ve Windows ile sürücü üzerinden çıkış cihazına ulaştırır. Ses çalma arabelleği, birazdan çalınacak veriyi geçici olarak biriktiren alandır. Cihaz mevcut veriyi çalarken besleyen taraf sonraki veriyi hazırlayıp arabelleği doldurur. Rendering a Stream

flowchart TB
    accTitle: Biraz sonrasının sesini biriktirip çalmak
    accDescr: Hazırlanan ses verisinin arabelleğe doldurulduğu ve cihaz tarafında çalma ilerlerken sonraki verinin hazırlandığı akış.
    A["Sonraki sesi hazırla"] --> B["Arabelleğe doldur"]
    B --> C["Biriken sesi çal"]
    C -.->|"Tükenmeden önce"| A

Şekil 1: Çalmanın sürmesi için doldurmanın, sesi tüketen tarafa yetişmesi gerekir.

Şekil 1, yalnızca doldurma ile tüketim arasındaki ilişkiyi gösteren kavramsal bir şemadır. Gerçek ses yolundaki birden çok arabelleği fiziksel olarak tek bir alanmış gibi gösteren bir şema değildir. Low Latency Audio

Arabelleğin görevi, sesi hazırlayan taraf ile kullanan taraf arasındaki kısa zaman farklarını sönümleyip kesintisiz çalmayı sağlamaktır. Ancak arabelleğin kapasitesi ile o anda içinde bulunan, henüz çalınmamış verinin miktarı ayrı şeylerdir. “10 milisaniyelik kapasite var” demek, her zaman 10 milisaniyelik veri kaldığı anlamına gelmez. Rendering a Stream

Bu makalede, çalınmakta olan veri tükenmeden önce gereken sonraki veriyi ulaştırmaya ilişkin zaman kısıtına doldurma zaman sınırı diyoruz. Ses işleme, “çalınacağı ana kadar hazırlanabilmiş olması” gereken bir işlemdir. “Sonunda hesaplanabildi” demek yetmez. Besleme yetişmediği için çalınacak verinin tükendiği duruma underrun denir; bu durum ses kesintisine veya tıklama seslerine yol açar. Veri gecikmeli olarak ulaşsa bile, duyulmuş bir kesinti sonradan doldurulamaz. Exclusive-Mode Streams

Ses verisinin izlediği yol

Olağan paylaşılan modda, oynatıcı uygulamanın hazırladığı veriyi Windows ses motoru alır; birden çok sesi karıştırıp efektleri uyguladıktan sonra sürücüye ve çıkış cihazına iletir. Oynatıcı uygulama hem ses kaynağının okunmasında hem de çıkış hedefinin beslenmesinde rol alır; sürücü ve çıkış cihazı ise veriyi cihaz tarafına taşıyıp çalar. Low Latency Audio

flowchart TB
    accTitle: Paylaşılan modda ses verisinin izlediği yol
    accDescr: Oynatıcı uygulamanın hazırladığı veriyi ses motoru karıştırma ve efekt işlemlerinden geçirip sürücüye iletir, çıkış cihazı da çalar.
    A["Oynatıcı uygulama: veriyi hazırlar"] --> E["Ses motoru: karıştırma, efekt"]
    E --> D["Sürücü: cihaza taşır"]
    D --> O["Çıkış cihazı: çalar"]

Şekil 2: Paylaşılan mod örneği. Aradaki işlemler ve arabellekler API’ye ve cihaza göre değişir.

Cihaz tarafında da işlemler ve arabellekler bulunabilir; toplam gecikme yalnızca uygulama tarafındaki arabellekle belirlenmez. Bu açıklama paylaşılan modun yolunu esas alır; her API’de aynı işlemlerden geçildiği anlamına gelmez. Low Latency Audio

10 milisaniye kalmışken doldurma

Arabellekte şu anda 10 milisaniyelik çalınmamış veri kaldığını varsayalım. Sonraki doldurma 8 milisaniye sonra gelirse veri bitmeden çalma kesintisiz sürer; ama 12 milisaniye sonrasına kadar doldurma yapılamazsa, bu basitleştirilmiş örnekte veri 10. milisaniyede tükenir.

flowchart TB
    accTitle: Kalan aynı 10 milisaniyede sonuç doldurma zamanına göre değişir
    accDescr: Açıklama amaçlı bir varsayım olarak, kalan 10 milisaniyelik çalma verisine karşı 8 milisaniye sonraki doldurmanın yetiştiğini, 12 milisaniye sonrakinin ise veri tükendikten sonra geldiğini gösterir.
    A["Kalan: 10 milisaniye"] --> B{"Sonraki doldurma"}
    B -->|"8 milisaniye sonra"| C["Kesintisiz sürer"]
    B -->|"12 milisaniye sonra"| D["10. milisaniyede tükenir"]

Şekil 3: Zamanı basitleştiren bir örnek. Önemli olan yalnızca doldurmanın yapılıp yapılmadığı değil, ne zaman yapıldığıdır.

CPU kullanımı ve doldurma gecikmesi

CPU kullanımı, belirli bir süre içindeki meşguliyeti gösterir. Ses işlemenin gerektiği anda çalıştırılıp çalıştırılamadığından farklı bir şeyi ölçer. Bir saniyenin büyük kısmında CPU’da boş kapasite olsa bile, yalnızca bir kez 12 milisaniye boyunca doldurma yapılamayan bir aralık varsa, o tek gecikme yüzünden ses kesilebilir. Sonradan kalan işlem kapasitesi, geçmiş çalma zamanını geri getiremez. CPU Analysis

flowchart TB
    accTitle: Ortalamadaki boş kapasite ve tek bir doldurma gecikmesi
    accDescr: Bir saniyenin büyük kısmında CPU'da boş kapasite olsa bile, bir kez 12 milisaniye boyunca doldurma yapılamayan bir aralık varsa o tek gecikmeyle ses kesilebilir.
    A["Saniyenin çoğunda CPU boşta"] --> B["Bir kez 12 milisaniye doldurulamaz"]
    B --> C["O tek seferde ses kesilir"]

Şekil 4: Ortalamada boş kapasite olsa da geçmiş çalma zamanı geri alınamaz.

Zaman sınırına kalan süreyi azaltan yalnızca hesaplama süresi değildir. İşlemin başlamasına kadar geçen bekleme ve gereken verinin gelmesine kadar geçen bekleme de buna dahildir. Bu yüzden inceleme sorusunu da yalnızca “CPU yüzde kaçtaydı?” olmaktan çıkarıp “Ses kesildiği anda sonraki ses neyi bekliyordu?” sorusuna çeviririz.

Veri ve kilit beklemeleri

Ses verisini hazırlayan işlemin, bir dosya okumasının tamamlanmasını beklediğini düşünelim. Uygulama içindeki başka bir işlemin tuttuğu kilidi beklediği durum da aynıdır. Bekleyen işlemin kendisi CPU’yu pek kullanmaz; ama cihaz tarafında çalma sürer ve kalan ses azalır. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: CPU kullanılmayan bekleme sırasında da çalma ilerler
    accDescr: Ses işleme veri ya da kilit beklerken bu işlem CPU kullanmaz; ancak çalma ilerleyip kalan veri azalır ve doldurma gecikirse arabellek tükenebilir.
    A["Ses işleme veri bekler"] --> B["Bu işlem CPU kullanmaz"]
    B --> C["Bu arada çalma sürer"]
    C --> D["Doldurma gecikirse stok biter"]

Şekil 5: CPU’nun kullanılmıyor olması, gereken işin bittiği anlamına gelmez.

DPC, ISR ve ses iş parçacığı

ISR, cihazdan gelen bir kesmeye yanıt veren işlemdir. DPC ise kesme işlemesini kısa tutmak için kalan işi sonraya erteleyen mekanizmadır. Normal DPC’ler aynı mantıksal CPU üzerindeki normal iş parçacıklarından önce çalıştırılır; normal bir DPC veya ISR çalışırken o mantıksal CPU’da normal iş parçacıkları çalıştırılamaz. Introduction to DPCs, CPU Analysis

CPU’nun genelinde boş kapasite olsa bile, ses işlemenin ihtiyaç duyduğu CPU’da bunlar uzun sürer ya da sık sık yaşanırsa besleme gecikebilir. Microsoft’un ses ve video performans analizi belgesinde, ağ, depolama, grafik gibi sürücülerin neden olduğu uzun DPC/ISR’ler de ses kesintisinin olası nedenleri arasında sayılır. Yalnızca sesi çıkaran cihazı incelemek her zaman yeterli olmayabilir. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Cihaza verilen yanıtın ses yürütmesini geciktirdiği durum
    accDescr: Ses işlemenin ihtiyaç duyduğu CPU üzerinde normal DPC veya ISR uzun sürerse iş parçacığının yürütülmesi gecikir ve bu, doldurma zaman sınırını etkileyebilir.
    A["Aynı CPU'daki DPC/ISR"] -->|"Uzun sürerse"| B["Ses yürütmesi bekletilir"]
    B --> C["Sonraki sesin doldurması gecikir"]
    C --> D["Kalan biterse ses kesilir"]

Şekil 6: Sesi çıkaran cihaz dışındaki işlemler de ses doldurmayı dolaylı olarak etkileyebilir.

“DPC şu kadar mikrosaniyenin altındaysa hiçbir PC’de ses kesilmez” şeklinde herkes için geçerli bir sınır çizilemez. Performans değerlendirme belgesindeki uyarı değerleri o değerlendirmenin koşullarına ait değerlerdir; bunları gerçek doldurma zaman sınırından ve arabellekteki paydan koparıp bir güvenlik ölçütü olarak kullanmayız. Results for the Streaming Media Performance Assessment

Arabellek miktarı ve çalma gecikmesi

Aynı koşullarda önceden biriktirilen ses artırılırsa geçici doldurma gecikmeleri daha kolay sönümlenir; öte yandan yeni üretilen ses, zaten birikmiş olan sesin arkasında bekler. Yalnızca müzik dinlerken kabul edilebilir olan bir bekleme bile, tuşlu bir çalgı çalarken ya da mikrofondaki sesinizi işleyip kendiniz dinlerken, yaptığınız işlem ile ses arasındaki kaymayı fark edilir hâle getirir. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Arabellek payı ve tepki gecikmesi
    accDescr: Önceden biriktirilen ses artırılınca geçici doldurma gecikmeleri daha kolay sönümlenir; öte yandan yeni sesin çalınmasına kadar geçen bekleme süresi de artar.
    A["Önceden biriken sesi artır"] --> B["Doldurma gecikmesi kolay sönümlenir"]
    B -->|"Karşılığında"| C["Yeni ses arkada bekler"]
    C --> D["İşlemden sese süre uzar"]

Şekil 7: Arabelleği büyütmek, tepki hızından ödün vererek pay yaratan bir ayardır.

Ne “küçük olan daha yüksek performanslıdır” ne de “büyük olan doğrudur”. Gereken tepki hızını korurken kesinti olmayacak kadar pay bırakırız.

Arabelleği büyütme ayarı, geçici besleme gecikmelerine karşı pay yaratır. Ortalama beslemenin kendisi tüketime yetişemiyorsa, sınırlı bir arabelleği büyütmek yalnızca tükenene kadar geçen süreyi uzatır; cihaz bağlantısının kopmasını da çözmez. Bu, özel modu kullanmanın her şeyi çözeceği yönünde bir öneri de değildir. Exclusive-Mode Streams

48 kHz’de 480 çerçevelik ses

PCM çerçevesi, aynı anda çalınacak tüm kanalların örneklerini bir araya getiren birimdir. Stereo olduğu için çerçeve sayısı iki katına çıkarılarak süre hesaplanmaz. Çerçeve sayısının temsil ettiği sesin uzunluğu “çerçeve sayısı ÷ örnekleme hızı” ile bulunur; 48 kHz’de 480 çerçeve için bu 480 ÷ 48000 saniye, yani 10 milisaniyedir. 48 kHz sabit kalırken çerçeve sayısı artırılırsa biriktirilebilen sesin süresi de uzar. Rendering a Stream

Bu süre, bir tuşa bastıktan sonra sesin duyulmasına kadar geçen toplam gecikmeyle aynı şey değildir. Çünkü uygulamanın, sürücünün, cihazın ve diğer arabellek ve işlemlerin süreleri de vardır. DAW’daki ayar değerlerini de birimini ve hangi arabelleğe ait olduğunu kontrol ederek okuruz. Low Latency Audio

flowchart TB
    accTitle: Çerçeve sayısından bulunan süre ve toplam gecikme
    accDescr: 480 çerçevenin 48000'e bölünmesiyle bulunan 10 milisaniye arabelleğin temsil ettiği süredir; buna uygulama, sürücü, cihaz gibi işlemler eklendiğinde tuştan sese toplam gecikme ortaya çıkar.
    A["480 ÷ 48000"] --> B["Arabelleğin temsil ettiği 10 milisaniye"]
    B -->|"Başka işlemler de eklenir"| C["Tuştan sese toplam gecikme"]

Şekil 8: Çerçeve sayısından bulunan süre, toplam gecikmenin bir parçasıdır.

Yeniden üretme koşullarını karşılaştırma

Önce sorunun ortaya çıktığı kombinasyonu daraltır, yalnızca gerektiğinde ayrıntılı kayda geçeriz. Aşağıdakiler nedeni doğrulamaya yönelik adımlardır; tüm ayar değişikliklerini topluca uygulamaya yönelik bir önlemler listesi değildir.

Çalışmanızı kaydedin, canlı toplantılarınızı veya kayıt oturumlarınızı bitirdikten sonra kulaklarınızı yormayacak bir ses düzeyinde deneyin. Özgün çıkış hedefini, ses geliştirmelerini, arabellek değerlerini ve benzeri ayarları not alarak geri dönülebilir bir durumda çalışın. Ayarı sunulmayan öğeleri atlayın; bir ayar seçeneğini ortaya çıkarmak için kayıt defteri gibi yerlerde değişiklik yapmayın.

1. Aynı kısa ses kaynağını ve gözlem süresini belirleyin, sorunun özgün koşullarda ortaya çıktığını doğrulayın.

   Windows sürümünü, uygulamanın adını ve sürümünü, çıkış cihazını, bağlantı yöntemini ve sürücü sürümünü kaydedin. Ses kesintisinin olduğu zamanı, o sırada yapılan işlemi ve kaç kez yaşandığını da not edin. Sorun özgün koşullarda ortaya çıkmıyorsa iyileştiğine hükmetmeyin; sorunun ortaya çıktığı koşulları belirlemeye geri dönün.

2. Aşağıdaki tablodan bir karşılaştırma seçin ve yalnızca o koşulu değiştirerek çalın.

   Karşılaştırılacak koşul	İncelenecek nokta
   Yerelde kayıtlı ses kaynağı ile ağ üzerinden çalma	Yalnızca ağ üzerinden çalarken mi oluyor? İçerik aynı olsa bile biçim veya işleme yolu farklıysa bunu da kaydedin.
   Aynı ses kaynağını başka bir uygulamada çalma	Belirli bir uygulamada mı yoğunlaşıyor?
   Bluetooth gibi bir çıkış ile dahili veya kablolu çıkış	Belirli bir çıkış yolunda mı yoğunlaşıyor?
   Ses geliştirmelerinin açık veya kapalı olması	Efekt işlemeyle birleşince değişiyor mu?
   DAW gibi bir yazılımdaki mevcut arabellek ile bir kademe büyük değer	Önceden biriktirme payı artırılınca değişiyor mu? İşlemden sese kadar geçen gecikme de kabul edilebilir mi?

3. Ses geliştirmelerini karşılaştıracaksanız, ilgili çıkışta ayarı geçici olarak kapatın.

   Windows’ta “Ayarlar” → “Sistem” → “Ses” bölümünde ilgili çıkışı seçin ve kullanılabildiği ortamlarda “Ses geliştirmeleri” seçeneğini kapatın. Görünüm veya öğelerin bulunup bulunmadığı farklıysa o sürümün ve cihazın yönergelerine bakın. Fix distorted or crackling audio in Windows

4. Değiştirdiğiniz ayarı eski hâline getirin ve aynı ses kaynağı ve gözlem süresiyle yeniden deneyin.

   “Özgün koşul”, “tek bir şeyin değiştirildiği koşul” ve “eski hâline döndürülen koşul” sonuçlarını yan yana koyun. Etkisi olmayan bir değişikliği eski durumuna getirdikten sonra başka bir karşılaştırmaya geçin. Ayar kombinasyonlarını değiştirip durursanız neyin işe yaradığını anlayamaz hâle gelirsiniz.

5. Sürücü değişikliği deneyecekseniz, resmî dağıtım kaynağını ve geri dönüş yöntemini doğruladıktan sonra yapın.

   Windows Update’i veya cihaz üreticisinin resmî dağıtımını kullanın; değişiklik öncesi ve sonrasındaki sürümü ve ayarları kaydedin. Geri alınıp alınamayacağını önceden kontrol edin; yönetilen PC’lerde yöneticiyle görüşün. Güncellemenin hemen ardından bir kez sorunsuz çalabilmiş olmayı çözüm saymayın; aynı yeniden üretme koşullarıyla doğrulayın. Fix distorted or crackling audio in Windows

Elde etmek istediğimiz sonuç, “bu uygulamada, bu çıkış kullanıldığında ortaya çıkıyor” gibi, belirtiyi koşullarla eşleştiren bir kayıttır. Durumu iyileştiren bir ayar bulunsa bile bunu nedenin kesinleşmesinden ayrı tutarız.

flowchart TB
    accTitle: Bir koşulu değiştirip geri alarak karşılaştırma
    accDescr: Aynı ses kaynağıyla sorunun ortaya çıktığı doğrulanır, uygulama veya çıkış gibi bir koşul değiştirilir ve eski hâline döndürüldüğündeki sonuç da kaydedilir.
    A["Özgün kombinasyonla çal"] --> B["Bir koşulu değiştirip çal"]
    B --> C["Geri alıp çal"]
    C --> D["Kesinti koşulunu ve zamanını kaydet"]

Şekil 9: Bir kez düzelmesinden çok, koşul ile belirtinin tekrar tekrar örtüştüğünü doğrularız.

Koşul değişikliği öncesi ve sonrası yeniden üretilebilirlik

“Belirti bastırıldı”, “koşullar daraltıldı” ve “kök neden belirlendi” birbirinden farklı aşamalardır. Sonucu, gözlemleyebildiğimiz kapsama uygun biçimde kaydederiz.

flowchart TB
    accTitle: Koşulla ilişkiye işaret eden üç sonuç
    accDescr: Sorun özgün koşulda ortaya çıkıyor, bir koşul değiştirilince iyileşiyor ve geri alınınca yeniden ortaya çıkıyorsa bu, o koşulla ilişkiye işaret eden bir ipucudur; ancak nedenin kesinleşmesinden ayrı tutulur.
    A["Özgün koşulda ortaya çıkar"] --> B["Bir şey değişince iyileşir"]
    B --> C["Geri alınca yine çıkar"]
    C --> D["O koşulla ilişki ipucu"]

Şekil 10: Üçü bir araya gelse bile elde edilen, ilişkiye dair bir ipucundan ibarettir.

Düşük CPU kullanımı, ses zaman sınırına uyulduğunun kanıtı değildir. Aynı şekilde, yalnızca ses kesintisi yaşandı diye kök nedenin doldurma gecikmesi olduğu da söylenemez. Ses kaynağını, uygulamanın işlemesini, efektleri, çıkış yolunu ve benzerlerini karşılaştırır, gözlemlenen kapsamda karar veririz. Fix distorted or crackling audio in Windows

Geçici bir çözüm benimsediğinizde özgün ayarı, yapılan değişikliği, gözlem süresini, sorunun tekrarlanıp tekrarlanmadığını ve kabul edilebilir gecikmeyi kayda geçirin. Kök neden henüz kesinleşmediyse bunu da kaydedin.

Ses kesintisini WPR ile kaydetme

Bu adım, koşul karşılaştırmasıyla daraltılamayan durumlarda ya da sürücü tarafındaki işlemleri incelerken uygulanır. WPR kayıt almak, WPA ise kaydedilen zaman çizelgesini analiz etmek için kullanılan araçtır. Windows Performance Toolkit’i, kayıt için gereken yetkileri ve ETL dosyalarının kaydedileceği yeri hazırlayın. Yönetilen bir PC’ye araç yükleyip kayıt alacaksanız bunu yöneticinizden isteyin. Görünen adları ve kullanılabilen profilleri, yüklediğiniz sürümde kontrol edin. Windows Performance Recorder

ETL dosyaları işlem adları, dosya yolları gibi bilgiler içerebilir. Kayıttan önce şirket içi kuralları ve kaydı kiminle paylaşacağınızı kontrol edin; kaydı herkese açık bir yere olduğu gibi eklemeyin. Başka bir kayıt oturumu çalışıyorsa onu kendi başınıza durdurmayın, sorumlu kişiye danışın. WPR How-to Topics

1. WPR’de “More Options” bölümünü açın ve amacınıza uygun kayıt profilini seçin.

   Yerleşik profiller arasında “Audio glitches” ve “CPU usage” bulunur. Sesteki süreksizlikleri ve CPU’nun davranışını inceleyebileceğiniz bir ayar seçin. Kullanılabilen profilleri, görünen adları ve toplanan içeriği yüklediğiniz sürümde kontrol edin; her türü uzun süre kaydeden bir ayar kullanmayın. Built-in Recording Profiles

2. Ses kesintisini yeniden üretmeden önce kaydı başlatın.

   Mevcut bir kaydın durdurulacağına dair bir onay istenirse devam etmeyin; başlatmaktan vazgeçip sorumlu kişiye danışın. Koşulları kayıt alınmayan durumla aynı tutun ve kaydın kendi yükünün belirtiyi değiştirebileceği olasılığını da göz önünde bulundurun. WPR How-to Topics

3. Karşılaştırmada bulduğunuz koşullarla çalın; kesintinin olduğu zamanı ve o sıradaki işlemi not edin.

   Belirtinin öncesinden ve sonrasından sorunsuz bir aralığı da biraz kayda dahil edin. Sorunun ortaya çıkmadığı bir kayıtta bunu açıkça belirtin ve o kaydı nedeni yakalamış bir kayıt olarak ele almayın.

4. Sorun ortaya çıktıktan sonra “Save” ile kaydı bitirin ve ETL dosyasını kaydedin.

   “Cancel” ile kayıt saklanmaz. Kayıt yerini, yeniden üretme koşullarını, kaydın alınıp alınmadığını ve olay kaybı uyarısı olup olmadığını not edin. Kayıp içeren bir kayıtta görünmeyen aralıkları normal saymayın. WPR How-to Topics

ETL dosyası ile ses kesintisinin zamanına, işlemine ve koşullarına dair notlar bir araya geldiğinde WPA’da karşılaştırma için hazırsınız. Kaydı saklamış olmanız, gereken olayların alındığı anlamına gelmeyebilir. İçeriği bir sonraki “Ses kesintisi öncesi ve sonrasında yürütme ve bekleme” bölümünde kontrol ederiz.

flowchart TB
    accTitle: Ses kesintisini içeren kısa bir kayıt almak
    accDescr: WPR ile kayıt başlatılır, belirti yeniden üretilip zamanı not edilir, durdurulup saklanan kayıt WPA ile incelenir.
    A["WPR ile kaydı başlat"] --> B["Aynı koşulda kesintiyi üret"]
    B --> C["Zamanı ve işlemi not edip kaydet"]
    C --> D["WPA'da öncesini ve sonrasını yakınlaştır"]

Şekil 11: Belirti geçtikten sonra bakılan CPU kullanımı yetmez; belirtinin yaşandığı aralığın kaydı gerekir.

Ses kesintisi öncesi ve sonrasında yürütme ve bekleme

Kaydettiğiniz ETL dosyasını ve sorunun ortaya çıktığı zamana dair notları hazırlayın. Aşağıdakiler WPA’daki incelemenin başlangıç noktasıdır. Çağrı yığınlarını ve sembolleri içeren ayrıntılı bir analiz gerekirse, kaydın nasıl ele alındığına dikkat ederek bunu yöneticiden veya geliştiricilerden isteyin.

1. ETL dosyasını WPA’da açın; kayda alınmış ses olaylarına ve sorunun ortaya çıktığı zamana dayanarak ses kesintisinin öncesini ve sonrasını yakınlaştırın.

   Belirtinin olmadığı bir aralığı da karşılaştırma için ayırın. Yalnızca en büyük değerlerin sıralamasına bakmayın; aynı zaman aralığına hizalayarak karşılaştırın.

2. Aynı aralıkta “DPC/ISR” ile “CPU Usage (Precise)” öğelerini kontrol edin.

   Gereken veri yoksa, bu veriyi toplayabilen bir profil olup olmadığını kontrol edin ve WPR ile kayda geri dönün. Kaydın olmaması, sorunun olmadığı anlamına gelmez. CPU Analysis, Built-in Recording Profiles

3. Sesle ilgili iş parçacığının çalışmaya hazır olduğu hâlde sıra mı beklediğini, yoksa veri gibi bir şeyi mi beklediğini ayırt edin.

   İlkiyse, ilgili mantıksal CPU’da DPC/ISR gibi işlemlerin uzun süre çalışıp çalışmadığını karşılaştırın. İkincisiyse, beklemeyi neyin sonlandırdığını kayda alınmış olaylar ve çağrı yığınları üzerinden izleyin. Çalışmakta olan bir iş parçacığı da bir kesmeyle yarıda kesilebileceğinden, yalnızca Ready süresine odaklanmayın; DPC/ISR aralıklarını da üst üste koyun. CPU Analysis

4. Ses kesintisiyle zaman eşleşmesini, ilgili CPU’yu ve koşul değiştirildiğinde alınan sonuçları birlikte kaydedin.

   Uzun DPC/ISR’nin modül adına bakarak tek başına belirli bir cihazı veya sürücüyü neden olarak kesinleştirmeyin. Başka bir zamana ait büyük bir değere ya da birden çok cihazın geçtiği ortak bir bileşene bakıyor olabilirsiniz.

flowchart TB
    accTitle: Ses kesintisi aralığında bekleme türünü incelemek
    accDescr: Ses kesintisinin öncesi ve sonrası yakınlaştırılıp ses iş parçacığının durumuna bakılır. Çalışmaya hazır hâlde sıra bekliyorsa aynı CPU'daki DPC veya ISR ile karşılaştırılır; veri gibi bir şeyi bekliyorsa beklemeyi sonlandıran işlem izlenir.
    A["Kesinti öncesini ve sonrasını yakınlaştır"] --> B{"İş parçacığının durumu"}
    B -->|"Sıra bekliyor"| C["DPC/ISR"]
    B -->|"Veri bekliyor"| D["Beklemeyi bitiren işlem"]

Şekil 12: Yalnızca en büyük değerleri almak yerine, ses işlemenin gerektiği aralıkla üst üste koyarak okuruz.

Nedeni belirleyemezseniz incelemeyi “kesinleşmedi” notuyla devredin. Eklenecek bilgiler şunlardır: işletim sistemi, uygulama, cihaz ve sürücü sürümleri; yeniden üretme adımları; değişiklik öncesi ve sonrası sonuçlar; olayın zamanı; toplama profili; kayıp uyarısı olup olmadığı. ETL dosyasını şirket içi kurallara uyarak yalnızca incelemeyi üstlenen kişiyle paylaşın.

Ses uygulamalarında önceden yükleme

Kendi ses uygulamanızı geliştiriyorsanız, sonraki arabelleği dolduran işlemi her seferinde zaman sınırına yetişecek şekilde tasarlayın. WASAPI’de, arabelleğin işlenebileceği anın bir olayla bildirildiği bir yöntem vardır. Exclusive-Mode Streams

MMCSS, zaman kısıtı olan multimedya işlemlerinin iş parçacıklarına CPU kaynağı ayıran bir mekanizmadır. Veriyi diskten önceden hazırlamak veya kilit beklemelerini ortadan kaldırmak gibi işlevleri yoktur. MMCSS’in sağladığı kaynak ayırımından yararlanırken de veriyi hazırlamaya ve beklemeleri azaltmaya yönelik bir tasarım ayrıca gerekir. Multimedia Class Scheduler Service

flowchart TB
    accTitle: MMCSS'in üstlendiği kapsam
    accDescr: MMCSS zaman kısıtı olan işlemlerin iş parçacıklarına CPU kaynağı ayırır; veriyi hazırlamak ve kilit beklemelerini azaltmak ise ayrı bir tasarımla yapılır.
    M["MMCSS: CPU kaynağını ayırır"] -.->|"Ayrıca gerekli"| D["Veri hazırlığı ve beklemeyi azaltma"]

Şekil 13: CPU kaynağını ayırmak ile veriyi zamanında yetiştiren tasarım ayrı işlerdir.

Tasarım ilkesi, dosyadan veya ağdan okuyan işlem ile sesi teslim eden işlemi birbirinden ayırmaktır. Ne kadar süreceği kestirilemeyen hazırlıkları önceden yapın; aktarım için önceden ayrılmış bir arabellek kullanın. Ses tarafını, kullanıcı arayüzünün yanıtını, uzun kilitleri ve senkron log yazma işlemlerini beklemek zorunda kalmayacak şekilde kurun.

flowchart TB
    accTitle: Süresi kestirilemeyen hazırlığı ses beslemesinden ayırmak
    accDescr: Okuma gibi işler önden çalışan bir işlemde yapılır, hazırlanan veri arabellek üzerinden ses işlemeye aktarılır ve zaman sınırının hemen öncesindeki uzun beklemeler azaltılır.
    A["Önden çalışan işlem veriyi hazırlar"] --> B["Önceden ayrılmış aktarım alanı"]
    B --> C["Ses işleme gereken kadarını aktarır"]
    C --> D["Ses çıkış hedefine beslenir"]

Şekil 14: Uzun süren işleri ses aktarımının hemen öncesinden çıkarırız.

Hazırlık tarafı uzun süre durursa bu ayrıma rağmen stok tükenir. Yalnızca ortalama işlem süresini değil, uzun süren işlemlerin veya beklemelerin yaşandığı seferleri ve beslemenin yapılamadığı durumların sayısını da ses işlemeyi aksatmayacak bir yöntemle kaydedin. Gerçekte seçilen arabellek miktarını ve periyodu API’den veya sürücüden kontrol edin; belirttiğiniz değerin olduğu gibi benimsendiğini varsaymayın. Rendering a Stream, Low Latency Audio

Sayısal örnekler de tasarım örnekleri de açıklama amaçlıdır; belirli bir cihaz için önerilen ayar değerleri ya da herhangi bir ortamda ses kesintisi yaşanmayacağının güvencesi değildir.

Gerçek zamanlı önceliğin etkisi

Kullanıcının oynatıcının tamamını “Gerçek zamanlı” önceliğe almasını genel bir kural olarak önermiyoruz. Bu, diğer önemli işlemleri engelleme riski taşır; ayrıca normal bir iş parçacığının önceliğini yükseltmek, DPC/ISR’yi ya da veri ve kilit beklemelerini ortadan kaldırmaz. Geliştirme tarafında MMCSS gibi mekanizmalar ve uzun beklemeleri ses beslemesine taşımayan bir tasarım kullanılır. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Gerçek zamanlı önceliğe geçince de kalan beklemeler
    accDescr: Oynatıcı gerçek zamanlı önceliğe alınsa bile normal iş parçacıkları aynı CPU'daki DPC veya ISR'nin önüne geçemez, veri ve kilit beklemeleri de kalır; üstelik diğer önemli işlemleri engelleme riski de vardır.
    A["Oynatıcıyı gerçek zamanlı önceliğe al"] --> B["DPC/ISR'nin önüne geçemez"]
    B --> C["Veri ve kilit beklemesi de kalır"]
    C --> D["Diğer işlemleri engelleme riski"]

Şekil 15: Öncelik yükseltilse bile ses doldurmayı geciktiren beklemeler kalır.

İlgili makaleler

• Windows’ta “İşlemci zamanlaması” ve arka plan hizmetleri ayarı
• Windows’ta %100 disk kullanımını güvenli biçimde ayrıştırmak
• Bağlantı hızlı olduğu hâlde RDP neden yavaş?

Kaynaklar

• Microsoft Learn, Rendering a Stream. Çalma arabelleğinin beslenmesi, kalan miktar, gerçek arabellek boyutu ve PCM çerçevesinin tanımı.
• Microsoft Learn, Exclusive-Mode Streams. Arabellek besleme zamanlaması ve ses aksaklıkları, gecikmeyle dengelenmesi, olay güdümlü besleme. Özel modun kendisinin genel bir kural olarak önerildiği anlamına gelmez.
• Microsoft Learn, Low Latency Audio. Windows ses yolu; arabellekler, cihazlar ve efekt işleme ile gecikme; düşük gecikmenin getirdiği ödünleşimler.
• Microsoft Learn, CPU Analysis. Mantıksal CPU, iş parçacıklarının Ready/Waiting durumları, DPC/ISR ile iş parçacığı yürütmesi arasındaki ilişki, WPA’da CPU analizi.
• Microsoft Learn, Introduction to DPCs. Kesme işlemesini kısa tutup kalan işi DPC’ye devreden mekanizma.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Uzun veya sık DPC/ISR’ler, yetersiz veri beslemesi ve ses aksaklıkları. Değerlendirmenin uyarı değerleri, tüm cihazlar için bir güvenlik ölçütü olarak genellenmez.
• Microsoft Support, Fix distorted or crackling audio in Windows. Ses geliştirmeleri, biçim, sürücü gibi noktaların kontrolü.
• Microsoft Learn, Windows Performance Recorder. ETW kaydı ve WPA ile analiz, Windows Performance Toolkit’in kullanımı.
• Microsoft Learn, Built-in Recording Profiles. WPR’deki More Options ile Audio glitches, CPU usage gibi yerleşik profiller.
• Microsoft Learn, WPR How-to Topics. Kaydı başlatma ve Save ile saklama, mevcut oturumlarla çakışma, kişisel bilgiler ve olay kaybına ilişkin uyarılar.
• Microsoft Learn, Multimedia Class Scheduler Service. Zaman kısıtı olan multimedya işlemlerine CPU kaynağı ayrılması.
• Microsoft Learn, Scheduling Priorities. İşlem ve iş parçacığı öncelikleri ile gerçek zamanlı önceliğe ilişkin uyarılar.

İlgili Makaleler

Aynı etiketleri paylaşan en yeni makaleler. Birbirine yakın konularla bilginizi derinleştirebilirsiniz.

İlgili Konular

Bu konuya yakın konu sayfaları. Makaleden yola çıkarak ilgili hizmetlere ve diğer makalelere geçebilirsiniz.

Bu Konunun Bağlantılı Olduğu Hizmetler

Bu makale aşağıdaki hizmet sayfalarıyla ilişkilidir. Size en yakın başlangıç noktasından göz atabilirsiniz.

Sık Sorulan Sorular

Bu makalenin konusuyla ilgili olarak danışmanlık sırasında sık sorulan soruları derledik.

CPU kullanımı %10 civarındayken ses neden kesiliyor?

Seste, çalınmakta olan veri tükenmeden önce sonraki verinin doldurulması gereken bir zaman sınırı vardır. CPU'nun genel kullanımı düşük olsa bile, ses işleme o anda çalıştırılamazsa ya da gereken veriyi bekliyorsa doldurma yetişmeyebilir. Her ses kesintisinin nedeni bu olmayabilir; çıkış cihazını veya uygulamayı değiştirerek karşılaştırma yapmak da gerekir.

Ses arabelleğini büyütmek ses kesintisini giderir mi?

Doldurma geçici olarak gecikiyorsa büyük bir arabellek bunu sönümleyebilir. Ancak biriktirilen sesin çalınmasına kadar geçen bekleme süresi de artar. İşlem kapasitesindeki sürekli bir yetersizliği ya da cihaz bağlantısının kopmasını da çözen bir ayar değildir. Değiştirilebilen uygulama ve sürücülerde özgün değeri not alıp kademe kademe karşılaştırın.

48 kHz'de 480 çerçeve kaç milisaniyelik sese karşılık gelir?

480 ÷ 48000 saniye olduğundan 10 milisaniyelik sese karşılık gelir. PCM'de bir çerçeve, aynı andaki tüm kanalların örneklerini bir araya getiren birimdir. Bu değer o çerçeve sayısının temsil ettiği sesin uzunluğudur; cihazı ve uygulamayı da içeren toplam gecikme değildir.

DPC veya ISR çalışma süresi uzun olan sürücü, ses kesintisinin suçlusu mudur?

Bir aday olabilir, ancak yalnızca çalışma süresi sıralamasına bakarak kesinleştirilemez. Ses kesintisinin yaşandığı aralığı, ses iş parçacığının beklemeleriyle ve aynı CPU'daki DPC/ISR yürütmesiyle karşılaştırın. Yalnızca modül adına bakarak belirli bir cihazın veya sürücünün hatalı olduğuna hükmetmeyin; yeniden üretme koşulları değiştirildiğinde alınan sonuçları da kontrol edin.

Oynatıcıyı gerçek zamanlı önceliğe almak durumu iyileştirir mi?

Genel bir kural olarak önermiyoruz. Normal bir iş parçacığının önceliğini yükseltmek, onun aynı CPU'daki normal DPC'lerin veya ISR'lerin önüne geçmesini sağlamaz; veri ve kilit beklemelerini de ortadan kaldırmaz. Geliştiriciler MMCSS gibi mekanizmaları ve beklemeleri ses tarafına taşımayan bir tasarımı kullanır; kullanıcılar ise önce yeniden üretme koşullarını ve çıkış yolunu karşılaştırır.

Yazar Profili

Makale yazarının profil sayfası.

Go Komura

KomuraSoft LLC Temsilcisi

Windows yazılım geliştirme, teknik danışmanlık ve hata araştırması odaklı çalışır; mevcut varlıkların korunduğu projelerde ve nedeni kolay anlaşılamayan arızaların araştırılmasında güçlüdür.