این صفحه بر مشارکت کنندگان تأخیر خروجی تمرکز دارد، اما بحث مشابهی در مورد تأخیر ورودی اعمال می شود.
با فرض اینکه مدار آنالوگ به طور قابل توجهی کمک نمی کند، عوامل اصلی در سطح سطح به تأخیر صوتی عبارتند از:
- کاربرد
- تعداد کل بافرها در خط لوله
- اندازه هر بافر، در فریم
- تأخیر اضافی پس از پردازشگر برنامه، مانند یک DSP
به همان اندازه که فهرست مشارکت کنندگان در بالا ممکن است دقیق باشد، گمراه کننده است. دلیل آن این است که تعداد بافر و اندازه بافر بیشتر یک اثر هستند تا یک علت . آنچه معمولاً اتفاق می‌افتد این است که یک طرح بافر معین پیاده‌سازی و آزمایش می‌شود، اما در حین آزمایش، یک زیر اجرا یا overrun صوتی به صورت «کلیک» یا «پاپ» شنیده می‌شود. برای جبران، طراح سیستم سپس اندازه بافر یا تعداد بافر را افزایش می دهد. این کار نتیجه مطلوبی دارد که باعث از بین رفتن زیر انداز یا بیش از حد می شود، اما عوارض جانبی نامطلوب افزایش تاخیر را نیز دارد. برای اطلاعات بیشتر در مورد اندازه‌های بافر، به ویدیوی تأخیر صوتی: اندازه‌های بافر مراجعه کنید.
یک رویکرد بهتر این است که دلایل زیر و رو شدن و بیش از حد را درک کنید و سپس آنها را اصلاح کنید. این آرتیفکت های قابل شنیدن را حذف می کند و ممکن است بافرهای کوچکتر یا کمتری را مجاز کند و در نتیجه تاخیر را کاهش دهد.
در تجربه ما، شایع‌ترین علل ریزش و بیش از حد شامل موارد زیر است:
- لینوکس CFS (زمانبندی کاملاً منصفانه)
- رشته‌های با اولویت بالا با زمانبندی SCHED_FIFO
- وارونگی اولویت
- تأخیر برنامه ریزی طولانی
- کنترل کننده های وقفه طولانی مدت
- زمان غیرفعال کردن وقفه طولانی
- مدیریت قدرت
- هسته های امنیتی
لینوکس CFS و زمانبندی SCHED_FIFO
لینوکس CFS طوری طراحی شده است که برای بارهای کاری رقیب که یک منبع CPU مشترک را به اشتراک می گذارند منصفانه باشد. این انصاف با یک پارامتر خوب در هر رشته نشان داده می شود. مقدار خوب از -19 (کمترین زمان اختصاص داده شده به CPU) تا 20 (بهترین یا کمترین زمان اختصاص داده شده به CPU) متغیر است. به طور کلی، تمام رشته‌هایی که مقدار خوب مشخصی دارند، تقریباً زمان CPU برابری دریافت می‌کنند و رشته‌هایی با مقدار خوب عددی پایین‌تر باید انتظار دریافت زمان CPU بیشتری را داشته باشند. با این حال، CFS فقط در دوره های نسبتا طولانی مشاهده "عادلانه" است. در پنجره‌های مشاهده کوتاه‌مدت، CFS ممکن است منبع CPU را به روش‌های غیرمنتظره‌ای تخصیص دهد. به عنوان مثال، ممکن است CPU را از یک رشته با زیبایی عددی کم به یک رشته با زیبایی عددی بالا بردارد. در مورد صدا، این می‌تواند منجر به افت یا بیش از حد شود.
راه حل واضح این است که از CFS برای رشته های صوتی با کارایی بالا اجتناب کنید. با شروع Android 4.1، چنین رشته‌هایی اکنون از خط‌مشی زمانبندی SCHED_FIFO به جای سیاست زمانبندی SCHED_NORMAL (همچنین SCHED_OTHER نامیده می‌شود) استفاده می‌کنند که توسط CFS اجرا می‌شود.
اولویت های SCHED_FIFO
اگرچه رشته‌های صوتی با کارایی بالا اکنون SCHED_FIFO استفاده می‌کنند، اما همچنان در معرض سایر رشته‌های SCHED_FIFO با اولویت بالاتر هستند. اینها معمولاً رشته‌های کارگر هسته هستند، اما ممکن است چند رشته کاربر غیرصوتی با خط‌مشی SCHED_FIFO نیز وجود داشته باشد. اولویت‌های SCHED_FIFO موجود از 1 تا 99 متغیر است. رشته‌های صوتی در اولویت 2 یا 3 اجرا می‌شوند. با این کار اولویت 1 برای موضوعات با اولویت پایین‌تر و اولویت‌های 4 تا 99 برای موضوعات با اولویت بالاتر در دسترس است. توصیه می‌کنیم در صورت امکان از اولویت 1 استفاده کنید و اولویت‌های 4 تا 99 را برای رشته‌هایی رزرو کنید که تضمین می‌شود در مدت زمان محدودی تکمیل شوند، با دوره‌ای کوتاه‌تر از دوره رشته‌های صوتی اجرا می‌شوند و شناخته شده‌اند که در زمانبندی تداخلی ندارند. از رشته های صوتی
زمانبندی نرخ یکنواخت
برای اطلاعات بیشتر در مورد تئوری تخصیص اولویت‌های ثابت، به مقاله ویکی‌پدیا زمانبندی نرخ یکنواخت (RMS) مراجعه کنید. یک نکته کلیدی این است که اولویت‌های ثابت باید دقیقاً بر اساس دوره تخصیص داده شوند، با اولویت‌های بالاتر به رشته‌هایی از دوره‌های کوتاه‌تر، نه بر اساس «اهمیت» درک شده. رشته‌های غیر تناوبی ممکن است به‌عنوان رشته‌های دوره‌ای، با استفاده از حداکثر فرکانس اجرا و حداکثر محاسبه در هر اجرا، مدل‌سازی شوند. اگر یک رشته غیر تناوبی را نتوان به عنوان یک رشته دوره ای مدل کرد (برای مثال می تواند با فرکانس نامحدود یا محاسبات نامحدود در هر اجرا اجرا شود)، نباید اولویت ثابتی به آن اختصاص داد زیرا با زمان بندی رشته های دوره ای واقعی ناسازگار است. .
وارونگی اولویت
وارونگی اولویت یک حالت شکست کلاسیک سیستم‌های بلادرنگ است، که در آن یک کار با اولویت بالاتر برای مدت زمان نامحدودی مسدود می‌شود و منتظر یک کار با اولویت پایین‌تر برای انتشار منبعی مانند (حالت مشترک محافظت شده توسط) یک mutex است. برای تکنیک‌های کاهش آن، مقاله « جلوگیری از وارونگی اولویت » را ببینید.
زمانبندی تأخیر
تأخیر زمانبندی، زمانی است که بین زمانی که یک رشته برای اجرا آماده می‌شود تا زمانی که سوئیچ زمینه به‌دست‌آمده تکمیل می‌شود، به طوری که موضوع در واقع روی یک CPU اجرا می‌شود. هرچه تأخیر کمتر باشد بهتر است و هر چیزی بیش از دو میلی ثانیه باعث ایجاد مشکل برای صدا می شود. تأخیر زمانبندی طولانی به احتمال زیاد در هنگام انتقال حالت رخ می‌دهد، مانند بالا آوردن یا خاموش کردن یک CPU، جابه‌جایی بین هسته امنیتی و هسته معمولی، تغییر از حالت کامل به حالت کم مصرف، یا تنظیم فرکانس و ولتاژ ساعت CPU .
قطع می کند
در بسیاری از طراحی ها، CPU 0 همه وقفه های خارجی را سرویس می کند. بنابراین یک کنترل کننده وقفه طولانی مدت ممکن است وقفه های دیگر، به ویژه وقفه های تکمیل دسترسی به حافظه مستقیم صوتی (DMA) را به تاخیر بیاندازد. کنترل کننده های وقفه را طوری طراحی کنید که به سرعت تمام شود و کار طولانی را به یک نخ موکول کنید (ترجیحاً یک رشته CFS یا رشته SCHED_FIFO با اولویت 1).
به همین ترتیب، غیرفعال کردن وقفه ها در CPU 0 برای مدت طولانی، نتیجه مشابهی با تاخیر در سرویس وقفه های صوتی دارد. زمان‌های غیرفعال کردن وقفه‌های طولانی معمولاً در زمان انتظار برای قفل چرخش هسته اتفاق می‌افتد. این قفل های چرخشی را بررسی کنید تا مطمئن شوید که محدود هستند.
قدرت، عملکرد و مدیریت حرارتی
مدیریت توان یک اصطلاح گسترده است که شامل تلاش برای نظارت و کاهش مصرف برق در عین بهینه سازی عملکرد است. مدیریت حرارتی و خنک کننده کامپیوتر مشابه هستند اما به دنبال اندازه گیری و کنترل گرما برای جلوگیری از آسیب ناشی از گرمای بیش از حد هستند. در هسته لینوکس، فرماندار CPU مسئول خط‌مشی سطح پایین است، در حالی که حالت کاربر، خط‌مشی سطح بالا را پیکربندی می‌کند. تکنیک های مورد استفاده عبارتند از:
- مقیاس بندی ولتاژ دینامیکی
- مقیاس بندی فرکانس پویا
- فعال کردن هسته پویا
- سوئیچینگ خوشه
- دروازه برق
- هات پلاگ (هات‌سوآپ)
- حالت های خواب مختلف (توقف، توقف، بیکار، تعلیق و غیره)
- مهاجرت فرآیند
- میل پردازنده
برخی از عملیات های مدیریتی می توانند منجر به "توقف کار" یا زمان هایی شوند که طی آن هیچ کار مفیدی توسط پردازنده برنامه انجام نشده است. این توقف های کاری می توانند با صدا تداخل داشته باشند، بنابراین چنین مدیریتی باید برای توقف قابل قبولی در بدترین حالت در زمانی که صدا فعال است طراحی شود. البته، زمانی که فرار حرارتی قریب الوقوع است، جلوگیری از آسیب دائمی مهمتر از صدا است!
هسته های امنیتی
یک هسته امنیتی برای مدیریت حقوق دیجیتال (DRM) ممکن است روی همان هسته(های) پردازنده برنامه کاربردی اجرا شود که برای هسته سیستم عامل اصلی و کد برنامه استفاده می شود. هر زمانی که در طی آن یک عملیات هسته امنیتی بر روی یک هسته فعال باشد، عملاً توقف کار معمولی است که معمولاً روی آن هسته اجرا می‌شود. به ویژه، این ممکن است شامل کار صوتی نیز باشد. طبیعتاً رفتار داخلی یک هسته امنیتی از لایه‌های سطح بالاتر غیرقابل تشخیص است و بنابراین هرگونه ناهنجاری عملکرد ناشی از یک هسته امنیتی بسیار خطرناک است. به عنوان مثال، عملیات هسته امنیتی معمولاً در ردیابی سوئیچ زمینه ظاهر نمی شود. ما این زمان را "زمان تاریک" می نامیم - زمانی که می گذرد اما نمی توان آن را مشاهده کرد. هسته های امنیتی باید برای توقف قابل قبول کار در بدترین حالت در حالی که صدا فعال است طراحی شوند.