تركّز هذه الصفحة على العوامل المؤثرة في وقت استجابة الإخراج، ولكن يمكن تطبيق مناقشة مشابهة على وقت استجابة الإدخال.
بافتراض أنّ الدوائر التناظرية لا تساهم بشكل كبير، فإنّ العوامل الرئيسية التي تساهم في وقت استجابة الصوت على مستوى السطح هي:
- طلب الانضمام
- إجمالي عدد وحدات التخزين المؤقت في مسار الإرسال
- حجم كل ذاكرة تخزين مؤقت، بالإطارات
- وقت استجابة إضافي بعد معالج التطبيق، مثل وقت الاستجابة من وحدة معالجة الإشارات الرقمية
على الرغم من دقة قائمة المساهمين أعلاه، إلا أنّها قد تكون مضلِّلة أيضًا. والسبب هو أنّ عدد وحدات التخزين المؤقت وحجمها يمثّلان تأثيرًا أكثر من سببًا. يحدث عادةً ما يلي: يتم تنفيذ مخطط تخزين مؤقت معيّن واختباره، ولكن أثناء الاختبار، يتم سماع صوت نقص أو زيادة في حجم الصوت على شكل "نقرة" أو "فرقعة". للتعويض عن ذلك، يزيد مصمّم النظام أحجام ذاكرات التخزين المؤقت أو أعدادها. يؤدي ذلك إلى تحقيق النتيجة المطلوبة المتمثّلة في القضاء على حالات عدم اكتمال أو تجاوز الوقت المحدد، ولكنّه يؤدي أيضًا إلى التأثير الجانبي غير المرغوب فيه المتمثّل في زيادة وقت الاستجابة. لمزيد من المعلومات عن أحجام المخزن المؤقت، يمكنك الاطّلاع على الفيديو التالي: وقت استجابة الصوت: أحجام المخزن المؤقت.
من الأفضل فهم أسباب المدة الزمنية القصيرة أو الطويلة، ثم تصحيحها. ويؤدي ذلك إلى إزالة الصعوبات المسموعة وقد يسمح بتخزين مؤقت أصغر أو أقل وبالتالي تقليل وقت الاستجابة.
حسب خبرتنا، تشمل الأسباب الأكثر شيوعًا للوقت غير الكافي أو الزائد ما يلي:
- نظام التشغيل Linux CFS (جدولة عادلة تمامًا)
- سلاسل المحادثات ذات الأولوية العالية باستخدام جدولة SCHED_FIFO
- انعكاس الأولوية
- وقت استجابة طويل في تحديد المواعيد
- معالجات المقاطعات التي تستغرق وقتًا طويلاً
- وقت إيقاف المقاطعات الطويلة
- إدارة الطاقة
- نواة الأمان
جدولة CFS وSCHED_FIFO في Linux
تم تصميم نظام CFS في Linux ليكون عادلاً مع أعباء العمل المتنافسة التي تشترك في مورد وحدة المعالجة المركزية المشترك. يتم تمثيل هذه المساواة من خلال مَعلمة nice لكل سلسلة محادثات. تتراوح قيمة nice بين -19 (أقل قيمة مناسبة أو أكبر وقت مخصّص لوحدة المعالجة المركزية) و20 (أفضل قيمة مناسبة أو أقل وقت مخصّص لوحدة المعالجة المركزية). بشكل عام، تحصل جميع مؤشرات الترابط التي لها قيمة محددة من nice على وقت تشغيل وحدة المعالجة المركزية متساوٍ تقريبًا، ومن المفترض أن تحصل مؤشرات الترابط التي لها قيمة من nice أقل عدديًا على وقت تشغيل وحدة المعالجة المركزية أكثر. ومع ذلك، لا تكون طريقة CFS "عادلة" إلا على مدار مدّة مراقبة نسبتها نسبته طويلة نسبيًا. خلال فترات المراقبة على المدى القصير، قد تخصص 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). من النقاط الرئيسية أنّه يجب تخصيص الأولويات الثابتة استنادًا إلى الفترة فقط، مع منح الأولويات الأعلى للسلسلات التي تتضمن فترات أقصر، وليس استنادًا إلى "الأهمية" المتصورة. يمكن وضع نماذج للخيوط غير المتكررة على أنّها خيوط متكررة، باستخدام الحد الأقصى لعدد مرات التنفيذ والحد الأقصى للعمليات الحسابية لكل عملية تنفيذ. إذا تعذّر وضع نموذج لسلسلة مهام غير دورية على أنّها سلسلة مهام دورية (على سبيل المثال، يمكن تنفيذها بمعدّل تكرار غير محدود أو عملية حسابية غير محدودة لكلّ تنفيذ)، يجب عدم تحديد أولوية ثابتة لها لأنّ ذلك سيكون غير متوافق مع جدولة سلاسل المهام الدورية الحقيقية.
انعكاس الأولوية
قلب الأولويات هو أحد حالات الفشل الكلاسيكية للأنظمة المستندة إلى الوقت الفعلي، حيث يتم حظر مهمة ذات أولوية أعلى لفترة غير محدودة في انتظار مهمة ذات أولوية أقل لتحرير مورد مثل (حالة مشترَكة محمية من قِبل) متغيّر استبعاد متبادل. اطّلِع على المقالة تجنُّب انعكاس الأولوية للاطّلاع على أساليب للتخفيف من هذا التأثير.
وقت استجابة الجدولة
وقت الاستجابة في الجدولة هو الوقت الفاصل بين وقت استعداد سلسلاً مهام للقيام بالعمل ووقت اكتمال تبديل السياق الناتج حتى تتمكّن سلسلاً المهام من تنفيذ العمل على وحدة المعالجة المركزية. كلما كان وقت الاستجابة أقصر، كان ذلك أفضل، وأي وقت يتجاوز ملّيتين من الثانية يتسبب في مشاكل في الصوت. من المرجّح أن يحدث وقت الاستجابة الطويل لتحديد المهام أثناء عمليات النقل بين الأوضاع، مثل تشغيل وحدة المعالجة المركزية أو إيقافها، والتبديل بين نواة الأمان والنواة العادية، والتبديل من وضع الطاقة الكاملة إلى وضع الطاقة المنخفضة، أو ضبط تردد ساعة وحدة المعالجة المركزية وفولتيتها.
المقاطعات
في العديد من التصميمات، تعالج وحدة المعالجة المركزية 0 جميع عمليات المقاطعة الخارجية. وبالتالي، قد يؤدي معالج المقاطعات الذي يستغرق وقتًا طويلاً إلى تأخير المقاطعات الأخرى، ولا سيما مقاطعات اكتمال الوصول المباشر إلى الذاكرة (DMA) للصوت. تصميم معالجات المقاطعات
لإنهاء العمل بسرعة وتأجيل العمل الطويل إلى سلسلة محادثات (يُفضَّل
سلسلة محادثات CFS أو سلسلة محادثات SCHED_FIFO ذات الأولوية 1)
وبالمثل، يؤدي إيقاف عمليات المقاطعة في وحدة المعالجة المركزية 0 لفترة طويلة إلى تأخير معالجة عمليات المقاطعة الصوتية. تحدث أوقات إيقاف المقاطعات الطويلة عادةً أثناء انتظار قفل اللف في kernel. راجِع أقفال اللف هذه للتأكّد من أنّها محدودة.
إدارة الطاقة والأداء والحرارة
إدارة الطاقة هو مصطلح واسع يشمل الجهود المبذولة لمراقبة وخفض استهلاك الطاقة مع تحسين الأداء. تُعدّ الإدارة الحرارية وتبريد الكمبيوتر عملية متشابهة، ولكنّهما تسعى إلى قياس الحرارة والتحكّم فيها لتجنُّب حدوث تلف بسبب الحرارة الزائدة. في نواة Linux، يكون المشرف على وحدة المعالجة المركزية مسؤولاً عن السياسة على مستوى منخفض، بينما يضبط وضع المستخدم السياسة على مستوى عالٍ. تشمل التقنيات المستخدَمة ما يلي:
- التحسين الديناميكي للجهد
- التحسين الديناميكي للتردد
- تفعيل المعالج الأساسي الديناميكي
- تبديل المجموعات
- حظر الوصول إلى الطاقة
- hotplug (hotswap)
- أوضاع السكون المختلفة (إيقاف، وإيقاف مؤقت، وتعليق، وما إلى ذلك)
- نقل البيانات
- ربط وحدة المعالجة المركزية
يمكن أن تؤدي بعض عمليات الإدارة إلى "توقفات في العمل" أو أوقات لا يؤدي فيها معالج التطبيقات أي عمل مفيد. يمكن أن تتداخل حالات توقُّف العمل هذه مع الصوت، لذا يجب تصميم إدارة هذه الحالات لتكون مقبولة في أسوأ حالات توقُّف العمل عندما يكون الصوت مفعّلاً. بالطبع، عندما يكون حدوث عُطل حراري وشيكًا، يكون تجنُّب حدوث أضرار دائمة أهم من الصوت.
نوى الأمان
قد يتم تشغيل نواة أمان لميزة إدارة الحقوق الرقمية (DRM) على نواة معالج التطبيقات نفسها المستخدَمة في نواة نظام التشغيل الرئيسي ورمز التطبيق. أي وقت تكون فيه عملية نواة الأمان نشطة على أحد النوى يتسبب في توقُّف العمل العادي الذي كان سيتم تنفيذه عادةً على هذا النواة. وقد يشمل ذلك على وجه الخصوص الأعمال الصوتية. بحكم طبيعته، فإنّ السلوك الداخلي لوحدة أمان النظام غير قابل للفهم من الطبقات ذات المستوى الأعلى، وبالتالي، فإنّ أيّ شذوذ في الأداء ناتج عن وحدة أمان النظام يكون خطيرًا بشكلٍ خاص. على سبيل المثال، لا تظهر عادةً عمليات نواة الأمان في أثر تبديل السياق. نُطلق على ذلك اسم "الوقت المظلم"، وهو الوقت الذي يمر ولا يمكن رصده. يجب تصميم نوى الأمان للتعامل مع حالة الصعوبة القصوى المقبولة أثناء تشغيل الصوت.