Bu sayfada çıkış gecikmesine katkıda bulunan faktörlere odaklanılmaktadır ancak giriş gecikmesi için de benzer bir tartışma geçerlidir.
Analog devrelerin önemli bir katkıda bulunmadığı varsayıldığında, ses gecikmesine yüzey düzeyinde en çok katkıda bulunanlar şunlardır:
- Uygulama
- Ardışık düzendeki toplam arabellek sayısı
- Her bir arabelleğin kare cinsinden boyutu
- Uygulama işlemciden sonra ek gecikme (ör. DSP'den)
Yukarıdaki katkıda bulunanlar listesi ne kadar doğru olursa olsun yanıltıcı da olabilir. Bunun nedeni, arabellek sayısı ve arabellek boyutunun neden olmaktan çok etki olmasıdır. Genellikle, belirli bir arabellek şeması uygulanıp test edilir ancak test sırasında "tıklama" veya "patlama" şeklinde bir ses eksikliği ya da taşması duyulur. Sistem tasarımcısı, bu durumu telafi etmek için arabellek boyutlarını veya arabellek sayılarını artırır. Bu, istenmeyen gecikmelerin artması gibi yan etkileri olsa da istenilen sonucu verir. Arabellek boyutları hakkında daha fazla bilgi için Ses gecikmesi: Arabellek boyutları videosunu izleyin.
Daha iyi bir yaklaşım, yetersiz ve fazla harcamaların nedenlerini anlayıp bunları düzeltmektir. Bu sayede, sesli artefaktlar ortadan kaldırılır ve daha küçük veya daha az arabelleğe izin verilerek gecikme azaltılabilir.
Deneyimlerimize göre, bütçe aşımlarının ve bütçe aşımlarının en yaygın nedenleri şunlardır:
- Linux CFS (Tamamen Adil Planlayıcı)
- SCHED_FIFO planlamasıyla yüksek öncelikli iş parçacıkları
- öncelik ters çevirme
- uzun planlama gecikmesi
- uzun süreli kesinti işleyicileri
- uzun kesinti devre dışı bırakma süresi
- güç yönetimi
- güvenlik çekirdekleri
Linux CFS ve SCHED_FIFO planlaması
Linux CFS, ortak bir CPU kaynağını paylaşan rekabet halindeki iş yükleri için adil olacak şekilde tasarlanmıştır. Bu adalet, iş parçacığı başına bir nice parametresi ile temsil edilir. nice değeri -19 (en az uygun veya en fazla CPU zamanı ayrılmış) ile 20 (en uygun veya en az CPU zamanı ayrılmış) arasında değişir. Genel olarak, belirli bir nice değerine sahip tüm iş parçacıkları yaklaşık olarak eşit CPU süresi alır ve nice değeri sayısal olarak daha düşük olan iş parçacıkları daha fazla CPU süresi almayı beklemelidir. Ancak CFS, yalnızca nispeten uzun gözlem dönemlerinde "adil"dir. CFS, kısa süreli gözlem aralıkları boyunca CPU kaynağını beklenmedik şekillerde ayırabilir. Örneğin, CPU'yu sayısal olarak düşük nicelik değerine sahip bir iş parçacığından, sayısal olarak yüksek nicelik değerine sahip bir iş parçacığına geçirebilir. Ses söz konusu olduğunda bu durum, sesin eksik veya fazla yayınlanmasına neden olabilir.
Bunun için en iyi çözüm, yüksek performanslı ses iş parçacıkları için CFS'den kaçınmaktır. Android 4.1'den itibaren bu tür mesaj dizileri, CFS tarafından uygulanan SCHED_NORMAL (SCHED_OTHER olarak da bilinir) planlama politikası yerine SCHED_FIFO planlama politikasını kullanır.
SCHED_FIFO öncelikleri
Yüksek performanslı ses ileti dizileri artık SCHED_FIFO kullansa da daha yüksek öncelikli diğer SCHED_FIFO ileti dizilerinden etkilenmeye devam eder.
Bunlar genellikle çekirdek çalışan iş parçacıklarıdır ancak SCHED_FIFO politikasına sahip birkaç ses dışı kullanıcı iş parçacığı da olabilir. Kullanılabilir SCHED_FIFO
öncelikleri 1 ile 99 arasındadır. Ses ileti dizileri 2 veya 3 öncelikli olarak çalışır. Bu durumda, 1. öncelik düşük öncelikli ileti dizileri için, 4 ile 99 arasındaki öncelikler ise yüksek öncelikli ileti dizileri için kullanılabilir. Mümkün olduğunda 1. önceliği kullanmanızı ve 4 ile 99 arasındaki öncelikleri, sınırlı bir süre içinde tamamlanacağı garanti edilen, ses iş parçacıklarının süresinden daha kısa bir süreyle yürütülen ve ses iş parçacıklarının planlamasını etkilemediği bilinen iş parçacıkları için ayırmanızı öneririz.
Oran monoton planlama
Sabit önceliklerin atanması teorisi hakkında daha fazla bilgi için Rate-monotonic scheduling (RMS) başlıklı Wikipedia makalesine bakın. Sabit önceliklerin, algılanan "önem"e göre değil, kesinlikle döneme göre atanması önemli bir noktadır. Daha kısa dönemlere ait ileti dizilerine daha yüksek öncelikler atanır. Periyodik olmayan iş parçacıkları, maksimum yürütme sıklığı ve yürütme başına maksimum hesaplama kullanılarak periyodik iş parçacığı olarak modellenebilir. Periyodik olmayan bir iş parçacığı, periyodik iş parçacığı olarak modellenemiyorsa (örneğin, sınırsız sıklıkta veya yürütme başına sınırsız hesaplama ile yürütülebiliyorsa) sabit bir öncelik atanmaz. Bu, gerçek periyodik iş parçacıklarının planlanmasıyla uyumlu olmaz.
Öncelik ters çevirme
Öncelik ters çevirme, gerçek zamanlı sistemlerin klasik bir hata modudur. Bu modda, daha yüksek öncelikli bir görev, daha düşük öncelikli bir görevin mutex (ortak durum tarafından korunan) gibi bir kaynağı serbest bırakmasını beklerken sınırsız bir süre boyunca engellenir. Bu sorunu azaltmaya yönelik teknikler için "Öncelik tersine çevirme sorununu önleme" makalesine bakın.
Planlama gecikmesi
Planlama gecikmesi, bir iş parçacığının çalışmaya hazır hale gelmesi ile iş parçacığının bir CPU'da gerçekten çalışabilmesi için ortaya çıkan bağlam değiştirme işleminin tamamlanması arasındaki süredir. Gecikme ne kadar kısa olursa o kadar iyidir. İki milisaniyeden uzun gecikmeler sesle ilgili sorunlara neden olur. Uzun planlama gecikmesi, büyük olasılıkla bir CPU'yu başlatma veya kapatma, güvenlik çekirdeği ile normal çekirdek arasında geçiş yapma, tam güçten düşük güce geçme veya CPU saat frekansını ve voltajını ayarlama gibi mod geçişleri sırasında ortaya çıkar.
Kesintiler
Birçok tasarımda CPU 0 tüm harici kesintileri işler. Bu nedenle, uzun süre çalışan bir kesme işleyici, özellikle ses doğrudan bellek erişimi (DMA) tamamlanma kesmelerini olmak üzere diğer kesmeleri geciktirebilir. Kesme işleyicileri, hızlı bir şekilde bitecek ve uzun süreli işleri bir iş dizisine (tercihen önceliği 1 olan bir CFS iş dizisi veya SCHED_FIFO iş dizisi) erteleyecek şekilde tasarlayın.
Benzer şekilde, CPU 0'da kesintileri uzun süre devre dışı bırakmak da ses kesintilerinin işlenmesini geciktirecektir. Uzun kesinti devre dışı bırakma süreleri genellikle bir çekirdek spin kilidi beklenirken gerçekleşir. Sınırlandırıldıklarından emin olmak için bu spin kilitlerini inceleyin.
Güç, performans ve termal yönetim
Güç yönetimi, performansı optimize ederken güç tüketimini izleme ve azaltma çalışmalarını kapsayan geniş bir terimdir. Termal yönetim ve bilgisayar soğutma benzer olsa da aşırı ısıdan kaynaklanan hasarı önlemek için ısıyı ölçmeyi ve kontrol etmeyi amaçlar. Linux çekirdeğinde, CPU yöneticisi düşük düzey politikadan sorumludur. Kullanıcı modu ise üst düzey politikayı yapılandırır. Kullanılan teknikler şunlardır:
- dinamik voltaj ölçeklendirme
- dinamik sıklık ölçeklendirmesi
- Dinamik çekirdek etkinleştirme
- Küme değiştirme
- güç denetimi
- hotplug (sıcak değiştirme)
- çeşitli uyku modları (duraklatma, durdurma, boşta kalma, askıya alma vb.)
- işlem taşıma
- işlemci yakın ilgi alanı
Bazı yönetim işlemleri, "çalışmanın durmasına" veya uygulama işleyici tarafından yararlı bir çalışmanın yapılmadığı zamanlara neden olabilir. Bu çalışma kesintileri sesi etkileyebilir. Bu nedenle, bu tür yönetimler ses etkinken kabul edilebilir en kötü duruma göre tasarlanmalıdır. Elbette, termal kaçak söz konusu olduğunda kalıcı hasarlardan kaçınmak sesten daha önemlidir.
Güvenlik çekirdekleri
Dijital hak yönetimi (DRM) için bir güvenlik çekirdeği, ana işletim sistemi çekirdeği ve uygulama kodu için kullanılanlarla aynı uygulama işlemcisi çekirdeklerinde çalışabilir. Bir çekirdekte güvenlik çekirdeği işleminin etkin olduğu her zaman, normalde bu çekirdekte çalışacak olan normal çalışmanın durdurulmasına neden olur. Özellikle ses çalışmaları bu kapsamdadır. Güvenlik çekirdeğinin doğası gereği, iç davranışı daha üst düzey katmanlardan anlaşılamaz. Bu nedenle, güvenlik çekirdeğinin neden olduğu performans anormallikleri özellikle zararlı olur. Örneğin, güvenlik çekirdeği işlemleri genellikle bağlam değiştirme izlerinde görünmez. Buna "karanlık zaman" diyoruz. Bu, geçen ancak gözlemlenemeyen zamandır. Güvenlik çekirdekleri, ses etkinken kabul edilebilir en kötü durumda çalışmanın durdurulması için tasarlanmalıdır.