این صفحه بر عوامل مؤثر بر تأخیر خروجی تمرکز دارد، اما بحث مشابهی برای تأخیر ورودی نیز صدق می‌کند.
با فرض اینکه مدار آنالوگ نقش قابل‌توجهی ندارد، عوامل اصلی در سطح سطحی که به تأخیر صوتی کمک می‌کنند عبارتند از:
- برنامه
- تعداد کل میان‌گیرها در خط لوله
- اندازه هر میان‌گیر، برحسب قاب
- تأخیر اضافی پس‌از پردازنده برنامه، مثلاً از DSP
هرچند فهرست بالا از همیاران ممکن است دقیق باشد، اما گمراه‌کننده نیز هست. دلیل این است که تعداد بافر و اندازه بافر بیشتر یک تأثیر هستند تا یک علت. معمولاً اتفاقی که می‌افتد این است که یک طرح میان‌گیر معین پیاده‌سازی و آزمایش می‌شود، اما درطول آزمایش، یک سرریز یا کم‌ریز صوتی به‌صورت «کلیک» یا «پاپ» شنیده می‌شود. برای جبران، طراح سیستم سپس اندازه‌های میان‌گیری یا تعداد میان‌گیری را افزایش می‌دهد. این کار نتیجه مطلوب حذف کردن کم‌رسانی‌ها یا بیش‌رسانی‌ها را دارد، اما همچنین اثر جانبی نامطلوب افزایش تأخیر را دارد. برای اطلاعات بیشتر درباره اندازه‌های میان‌گیر، ویدیو تأخیر صوتی: اندازه‌های میان‌گیر را ببینید.
رویکرد بهتر این است که دلایل کم‌رسانی و بیش‌رسانی را درک کنید و سپس آن‌ها را اصلاح کنید. این کار مصنوعات شنیداری را حذف می‌کند و ممکن است حتی میان‌گیرهای کوچک‌تر یا کمتری را مجاز کند و درنتیجه تأخیر را کاهش دهد.
طبق تجربه ما، رایج‌ترین دلایل کم‌نمایش و بیش‌نمایش عبارت‌اند از:
- Linux CFS (Completely Fair Scheduler)
- رشته‌های اولویت بالا با زمان‌بندی SCHED_FIFO
- وارونگی اولویت
- تأخیر طولانی در زمان‌بندی
- مدیریت‌کننده‌های وقفه طولانی‌مدت
- زمان غیرفعال کردن وقفه طولانی
- مدیریت مصرف
- هسته‌های امنیتی
زمان‌بندی Linux CFS و SCHED_FIFO
Linux CFS به‌گونه‌ای طراحی شده است که با حجم‌های کاری رقیب که از منبع CPU مشترک استفاده می‌کنند منصفانه رفتار کند. این انصاف با پارامتر nice به‌ازای هر رشته نشان داده می‌شود. مقدار nice از -۱۹ (کمترین nice، یا بیشترین زمان CPU اختصاص‌داده‌شده) تا ۲۰ (بیشترین nice، یا کمترین زمان CPU اختصاص‌داده‌شده) متغیر است. به‌طورکلی، همه رشته‌های دارای مقدار nice یکسان تقریباً زمان CPU یکسانی دریافت می‌کنند و رشته‌های دارای مقدار nice عددی پایین‌تر باید انتظار داشته باشند زمان CPU بیشتری دریافت کنند. بااین‌حال، «سی‌اف‌اس» فقط در دوره‌های نسبتاً طولانی مشاهده «منصفانه» است. در بازه‌های زمانی کوتاه مدت، CFS ممکن است منبع CPU را به روش‌های غیرمنتظره‌ای تخصیص دهد. برای مثال، ممکن است واحد پردازش مرکزی را از رشته‌ای با مقدار عددی پایین نیکویی به رشته‌ای با مقدار عددی بالای نیکویی منتقل کند. درمورد صدا، این امر می‌تواند منجر به کم‌ریزی یا سرریز شدن شود.
راه حل واضح این است که از CFS برای رشته‌های صوتی با عملکرد بالا اجتناب کنید. از Android 4.1 به بعد، چنین رشته‌هایی اکنون از خط‌مشی زمان‌بندی
SCHED_FIFO به‌جای خط‌مشی زمان‌بندی SCHED_NORMAL (که
SCHED_OTHER نیز نامیده می‌شود) که توسط CFS پیاده‌سازی شده است استفاده می‌کنند.
اولویت‌های SCHED_FIFO
اگرچه رشته‌های صوتی با عملکرد بالا اکنون از SCHED_FIFO استفاده می‌کنند، اما همچنان دربرابر رشته‌های SCHED_FIFO با اولویت بالاتر آسیب‌پذیر هستند.
این‌ها معمولاً رشته‌های کاری هسته هستند، اما ممکن است چند رشته کاربر غیرصوتی با خط‌مشی SCHED_FIFO نیز وجود داشته باشد. اولویت‌های SCHED_FIFO دردسترس
از ۱ تا ۹۹ است. رشته‌های صوتی با اولویت
۲ یا ۳ اجرا می‌شوند. این کار باعث می‌شود اولویت ۱ برای رشته‌های با اولویت پایین‌تر،
و اولویت‌های ۴ تا ۹۹ برای رشته‌های با اولویت بالاتر دردسترس باشد. توصیه می‌کنیم
هرزمان ممکن بود از اولویت ۱ استفاده کنید و اولویت‌های ۴ تا ۹۹ را برای
رشته‌هایی رزرو کنید که تضمین شده است در مدت زمان محدودی تکمیل می‌شوند،
با دوره‌ای کوتاه‌تر از دوره رشته‌های صوتی اجرا می‌شوند،
و مشخص است که با زمان‌بندی رشته‌های صوتی تداخل ندارند.
زمان‌بندی نرخ یکنواخت
برای کسب اطلاعات بیشتر درباره نظریه تخصیص اولویت‌های ثابت، به مقاله ویکی‌پدیا زمان‌بندی نرخ یکنواخت (RMS) مراجعه کنید. نکته کلیدی این است که اولویت‌های ثابت باید صرفاً براساس دوره اختصاص داده شوند، و اولویت‌های بالاتر به رشته‌های دوره‌های کوتاه‌تر اختصاص داده شوند، نه براساس «اهمیت» درک‌شده. رشته‌های غیردوره‌ای ممکن است به‌عنوان رشته‌های دوره‌ای مدل‌سازی شوند، بااستفاده از حداکثر بسامد اجرا و حداکثر محاسبات در هر اجرا. اگر یک رشته غیردوره‌ای نتواند به‌عنوان یک رشته دوره‌ای مدل‌سازی شود (برای مثال، ممکن است با فرکانس نامحدود یا محاسبات نامحدود در هر اجرا اجرا شود)، نباید اولویت ثابتی به آن اختصاص داده شود زیرا این امر با زمان‌بندی رشته‌های دوره‌ای واقعی ناسازگار خواهد بود.
وارونگی اولویت
وارونگی اولویت یک حالت خرابی کلاسیک در سیستم‌های هم‌زمان است، که در آن یک وظیفه با اولویت بالاتر برای مدت نامحدودی مسدود می‌شود و منتظر می‌ماند تا وظیفه‌ای با اولویت پایین‌تر منبعی مثل (وضعیت مشترک محافظت‌شده توسط) یک mutex را آزاد کند. برای آشنایی با روش‌های کاهش این مشکل، مقاله «جلوگیری از وارونگی اولویت» را ببینید.
تأخیر زمان‌بندی
تأخیر زمان‌بندی عبارت است از فاصله زمانی بین زمانی که یک رشته برای اجرا آماده می‌شود و زمانی که تعویض بافت حاصل تکمیل می‌شود تا رشته درواقع در یک CPU اجرا شود. هرچه تأخیر کمتر باشد بهتر است، و هر چیزی بیشتر از دو میلی‌ثانیه باعث ایجاد مشکل در صدا می‌شود. تأخیر در زمان‌بندی طولانی به‌احتمال زیاد درطول انتقال حالت‌ها رخ می‌دهد، مثلاً راه‌اندازی یا خاموش کردن واحد پردازش مرکزی، جابه‌جایی بین هسته امنیتی و هسته عادی، جابه‌جایی از حالت تمام توان به حالت کم‌توان، یا تنظیم فرکانس و ولتاژ ساعت واحد پردازش مرکزی.
قطع می‌کند
در بسیاری از طراحی‌ها، CPU 0 به همه وقفه‌های خارجی خدمات ارائه می‌دهد. بنابراین، یک
گرداننده وقفه طولانی‌مدت ممکن است وقفه‌های دیگر را به‌تأخیر بیندازد، به‌ویژه
وقفه‌های تکمیل دسترسی مستقیم به حافظه (DMA) صوتی. گرداننده‌های وقفه را طوری طراحی کنید که سریع تمام شوند و کارهای طولانی را به رشته‌ای (ترجیحاً رشته CFS یا رشته SCHED_FIFO با اولویت ۱) موکول کنند.
به‌طور معادل، غیرفعال کردن وقفه‌ها در CPU 0 برای یک دوره طولانی همان نتیجه تأخیر در سرویس‌دهی وقفه‌های صوتی را دارد. زمان‌های طولانی غیرفعال بودن وقفه معمولاً هنگام انتظار برای قفل اسپین هسته اتفاق می‌افتد. این قفل‌های چرخش را مرور کنید تا مطمئن شوید محدود هستند.
مدیریت حرارتی، عملکرد، و مصرف باتری
مدیریت مصرف برق اصطلاحی کلی است که تلاش‌ها برای نظارت و کاهش مصرف برق را دربرمی‌گیرد و درعین‌حال عملکرد را بهینه‌سازی می‌کند. مدیریت حرارتی و خنک‌سازی رایانه مشابه هستند اما به‌دنبال اندازه‌گیری و کنترل گرما برای جلوگیری از آسیب ناشی از گرمای بیش‌ازحد هستند. در هسته Linux، کارگزار CPU مسئول خط‌مشی سطح پایین است، درحالی‌که حالت کاربر خط‌مشی سطح بالا را پیکربندی می‌کند. تکنیک‌های استفاده‌شده عبارت‌اند از:
- مقیاس‌بندی پویای ولتاژ
- مقیاس‌بندی پویای بسامد
- فعال‌سازی هسته پویا
- تعویض خوشه
- دروازه‌بندی توان
- اتصال داغ (تعویض داغ)
- حالت‌های مختلف خواب (توقف، ایست، بیکار، تعلیق، و غیره)
- انتقال پردازش
- وابستگی پردازنده
برخی‌از عملیات‌های مدیریت می‌توانند منجر به «توقف کار» یا زمان‌هایی شوند که درطول آن‌ها پردازنده برنامه کار مفیدی انجام نمی‌دهد. این توقف‌های کاری می‌توانند با صدا تداخل ایجاد کنند، بنابراین چنین مدیریتی باید برای بدترین حالت قابل‌قبول توقف کاری درحالی‌که صدا فعال است طراحی شود. البته وقتی فرار حرارتی قریب‌الوقوع است، جلوگیری از آسیب دائمی مهم‌تر از صدا است!
هسته‌های امنیتی
هسته امنیتی برای مدیریت حقوق دیجیتال (DRM) ممکن است در همان هسته(های) پردازنده برنامه که برای هسته سیستم‌عامل اصلی و کد برنامه استفاده می‌شود اجرا شود. هر زمانی که عملکرد هسته امنیتی در هسته‌ای فعال باشد، درواقع توقف کار عادی است که معمولاً در آن هسته اجرا می‌شود. به‌طور خاص، این ممکن است شامل کار صوتی باشد. به‌دلیل ماهیت آن، عملکرد داخلی هسته امنیتی از لایه‌های سطح بالاتر قابل تشخیص نیست، و بنابراین هرگونه ناهنجاری عملکردی که توسط هسته امنیتی ایجاد می‌شود به‌ویژه مخرب است. برای مثال، عملیات هسته امنیتی معمولاً در ردگیری‌های تعویض بافت نشان داده نمی‌شود. ما این را «زمان تاریک» می‌نامیم — زمانی که می‌گذرد اما نمی‌توان آن را مشاهده کرد. هسته‌های امنیتی باید برای توقف کار قابل‌قبول در بدترین حالت ممکن درحین فعال بودن صدا طراحی شوند.