المساهمين في الكمون الصوت

تركز هذه الصفحة على المساهمين في زمن استجابة الإخراج، ولكن تنطبق مناقشة مماثلة على زمن استجابة الإدخال.

بافتراض أن الدوائر التناظرية لا تساهم بشكل كبير، فإن المساهمين الرئيسيين على مستوى السطح في زمن الوصول الصوتي هم ما يلي:

• طلب
• إجمالي عدد المخازن المؤقتة في خط الأنابيب
• حجم كل المخزن المؤقت، في الإطارات
• زمن الوصول الإضافي بعد معالج التطبيق، مثل DSP

على الرغم من دقة قائمة المساهمين المذكورة أعلاه، إلا أنها مضللة أيضًا. والسبب هو أن عدد المخزن المؤقت وحجم المخزن المؤقت لهما تأثير أكثر من كونهما سببًا . ما يحدث عادة هو أنه يتم تنفيذ واختبار نظام المخزن المؤقت المحدد، ولكن أثناء الاختبار، يتم سماع تجاوز أو تجاوز الصوت على أنه "نقرة" أو "فرقعة". للتعويض، يقوم مصمم النظام بزيادة أحجام المخزن المؤقت أو عدد المخزن المؤقت. يؤدي هذا إلى النتيجة المرجوة المتمثلة في إزالة التجاوزات أو التجاوزات، ولكن له أيضًا تأثير جانبي غير مرغوب فيه يتمثل في زيادة زمن الوصول. لمزيد من المعلومات حول أحجام المخزن المؤقت، راجع الفيديو زمن انتقال الصوت: أحجام المخزن المؤقت .

النهج الأفضل هو فهم أسباب التجاوزات والتجاوزات، ثم تصحيحها. يؤدي هذا إلى التخلص من التشويش المسموع وقد يسمح بمخازن مؤقتة أصغر أو أقل وبالتالي تقليل زمن الوصول.

من خلال تجربتنا، تتضمن الأسباب الأكثر شيوعًا للتجاوزات والتجاوزات ما يلي:

• Linux CFS (جدولة عادلة تمامًا)
• سلاسل المحادثات ذات الأولوية العالية مع جدولة SCHED_FIFO
• انعكاس الأولوية
• الكمون جدولة طويلة
• معالجات المقاطعة طويلة الأمد
• مقاطعة طويلة تعطيل الوقت
• إدارة الطاقة
• حبات الأمن

جدولة Linux CFS وSCHED_FIFO

تم تصميم Linux CFS ليكون منصفًا لأحمال العمل المتنافسة التي تتقاسم مورد وحدة المعالجة المركزية المشترك. يتم تمثيل هذا الإنصاف من خلال معلمة لطيفة لكل خيط. تتراوح القيمة الجيدة من -19 (الوقت الأقل تخصيصًا أو الأكثر تخصيصًا لوحدة المعالجة المركزية) إلى 20 (الوقت الأفضل أو الأقل تخصيصًا لوحدة المعالجة المركزية). بشكل عام، تتلقى كافة سلاسل العمليات ذات القيمة المحددة وقتًا متساويًا تقريبًا لوحدة المعالجة المركزية (CPU) ويجب أن تتوقع سلاسل العمليات ذات القيمة الأقل عدديًا تلقي المزيد من وقت وحدة المعالجة المركزية (CPU). ومع ذلك، فإن متلازمة التعب المزمن تكون "عادلة" فقط خلال فترات المراقبة الطويلة نسبيًا. خلال نوافذ المراقبة قصيرة المدى، قد تقوم CFS بتخصيص موارد وحدة المعالجة المركزية (CPU) بطرق غير متوقعة. على سبيل المثال، قد يأخذ وحدة المعالجة المركزية بعيدًا عن خيط ذو دقة منخفضة عدديًا إلى خيط ذو دقة عالية عدديًا. في حالة الصوت، يمكن أن يؤدي ذلك إلى تجاوز أو تجاوز.

الحل الواضح هو تجنب CFS لخيوط الصوت عالية الأداء. بدءًا من Android 4.1، تستخدم هذه المواضيع الآن سياسة الجدولة SCHED_FIFO بدلاً من سياسة الجدولة SCHED_NORMAL (وتسمى أيضًا SCHED_OTHER ) التي يتم تنفيذها بواسطة CFS.

أولويات SCHED_FIFO

على الرغم من أن سلاسل العمليات الصوتية عالية الأداء تستخدم الآن SCHED_FIFO ، إلا أنها لا تزال عرضة لسلاسل عمليات SCHED_FIFO الأخرى ذات الأولوية الأعلى. هذه عادةً ما تكون سلاسل عمليات kernel، ولكن قد يكون هناك أيضًا عدد قليل من سلاسل رسائل المستخدم غير الصوتية مع السياسة SCHED_FIFO . تتراوح أولويات SCHED_FIFO المتوفرة من 1 إلى 99. تعمل سلاسل الرسائل الصوتية على الأولوية 2 أو 3. وهذا يترك الأولوية 1 متاحة لسلاسل الرسائل ذات الأولوية المنخفضة، والأولويات من 4 إلى 99 لسلاسل الرسائل ذات الأولوية الأعلى. نوصيك باستخدام الأولوية 1 كلما أمكن ذلك، وحجز الأولويات من 4 إلى 99 لتلك المواضيع المضمونة لإكمالها خلال فترة زمنية محددة، والتنفيذ بفترة أقصر من فترة المواضيع الصوتية، والمعروفة بأنها لا تتعارض مع الجدولة من المواضيع الصوتية.

جدولة معدل رتابة

لمزيد من المعلومات حول نظرية تعيين الأولويات الثابتة، راجع مقالة ويكيبيديا جدولة المعدل الرتيب (RMS). النقطة الأساسية هي أنه يجب تخصيص الأولويات الثابتة بشكل صارم على أساس الفترة، مع تعيين أولويات أعلى لسلاسل الفترات الأقصر، وليس على أساس "الأهمية" المتصورة. يمكن تصميم سلاسل العمليات غير الدورية على أنها سلاسل رسائل دورية، باستخدام الحد الأقصى لتكرار التنفيذ والحد الأقصى للحساب لكل تنفيذ. إذا لم يكن من الممكن تصميم خيط غير دوري كخيط دوري (على سبيل المثال يمكن تنفيذه بتردد غير محدود أو حساب غير محدود لكل تنفيذ)، فلا ينبغي تعيين أولوية ثابتة له لأن ذلك سيكون غير متوافق مع جدولة سلاسل الرسائل الدورية الحقيقية .

انعكاس الأولوية

انقلاب الأولوية هو وضع فشل كلاسيكي لأنظمة الوقت الفعلي، حيث يتم حظر المهمة ذات الأولوية الأعلى لفترة غير محدودة في انتظار مهمة ذات أولوية أقل لتحرير مورد مثل (الحالة المشتركة المحمية بواسطة) كائن المزامنة ( mutex ). راجع المقالة " تجنب انعكاس الأولوية " للتعرف على تقنيات تخفيفها.

جدولة الكمون

زمن الوصول الجدولي هو الوقت بين الوقت الذي يصبح فيه مؤشر الترابط جاهزًا للتشغيل ووقت اكتمال تبديل السياق الناتج بحيث يتم تشغيل مؤشر الترابط فعليًا على وحدة المعالجة المركزية. كلما كان زمن الوصول أقصر كلما كان ذلك أفضل، وأي شيء يزيد عن 2 مللي ثانية يسبب مشاكل في الصوت. من المرجح أن يحدث زمن انتقال طويل للجدولة أثناء انتقالات الوضع، مثل تشغيل وحدة المعالجة المركزية أو إيقاف تشغيلها، أو التبديل بين نواة الأمان والنواة العادية، أو التبديل من وضع الطاقة الكاملة إلى وضع الطاقة المنخفضة، أو ضبط تردد ساعة وحدة المعالجة المركزية والجهد الكهربي .

يقاطع

في العديد من التصميمات، تخدم وحدة المعالجة المركزية 0 جميع المقاطعات الخارجية. لذلك قد يؤدي معالج المقاطعة الذي يعمل لفترة طويلة إلى تأخير المقاطعات الأخرى، وخاصة مقاطعات إكمال الوصول المباشر إلى الذاكرة الصوتية (DMA). صمم معالجات المقاطعة للانتهاء بسرعة وتأجيل العمل المطول لسلسلة رسائل (يفضل أن يكون مؤشر ترابط CFS أو مؤشر ترابط SCHED_FIFO ذي الأولوية 1).

وبالمثل، فإن تعطيل المقاطعات على وحدة المعالجة المركزية 0 لفترة طويلة له نفس النتيجة المتمثلة في تأخير خدمة المقاطعات الصوتية. عادةً ما تحدث أوقات تعطيل المقاطعة الطويلة أثناء انتظار قفل دوران kernel. قم بمراجعة أقفال الدوران هذه للتأكد من أنها مقيدة.

الطاقة والأداء والإدارة الحرارية

تعد إدارة الطاقة مصطلحًا واسعًا يشمل الجهود المبذولة لمراقبة استهلاك الطاقة وتقليله مع تحسين الأداء. الإدارة الحرارية وتبريد الكمبيوتر متشابهان ولكنهما يسعيان إلى قياس الحرارة والتحكم فيها لتجنب الضرر الناتج عن الحرارة الزائدة. في نواة Linux، يكون حاكم وحدة المعالجة المركزية مسؤولاً عن السياسة ذات المستوى المنخفض، بينما يقوم وضع المستخدم بتكوين السياسة عالية المستوى. التقنيات المستخدمة تشمل:

• تحجيم الجهد الديناميكي
• تحجيم التردد الديناميكي
• تمكين الأساسية الديناميكية
• التبديل العنقودي
• بوابة الطاقة
• هوت بلج (هوت سواب)
• أوضاع النوم المختلفة (إيقاف، توقف، خامل، تعليق، إلخ.)
• عملية الهجرة
• تقارب المعالج

يمكن أن تؤدي بعض عمليات الإدارة إلى "توقف العمل" أو أوقات لا يتم خلالها تنفيذ أي عمل مفيد بواسطة معالج التطبيق. يمكن أن تتداخل عمليات توقف العمل هذه مع الصوت، لذلك يجب أن يتم تصميم هذه الإدارة لتوقف العمل المقبول في أسوأ الحالات أثناء نشاط الصوت. بالطبع، عندما يكون الهروب الحراري وشيكًا، فإن تجنب الضرر الدائم يكون أكثر أهمية من الصوت!

حبات الأمن

قد يتم تشغيل نواة الأمان لإدارة الحقوق الرقمية (DRM) على نفس نواة (معالجات) معالج التطبيقات كتلك المستخدمة في نواة نظام التشغيل الرئيسي ورمز التطبيق. أي وقت تكون فيه عملية نواة الأمان نشطة على أحد المراكز هو في الواقع توقف للعمل العادي الذي يتم تشغيله عادةً على هذا المركز. على وجه الخصوص، قد يشمل ذلك العمل الصوتي. بحكم طبيعته، يكون السلوك الداخلي لنواة الأمان غامضًا من الطبقات ذات المستوى الأعلى، وبالتالي فإن أي حالات شاذة في الأداء تسببها نواة الأمان تكون ضارة بشكل خاص. على سبيل المثال، لا تظهر عمليات kernel الأمان عادةً في تتبعات تبديل السياق. نحن نسمي هذا "الوقت المظلم" - الوقت الذي ينقضي ولا يمكن ملاحظته. يجب أن يتم تصميم نواة الأمان بحيث تكون مقبولة لتوقف العمل في أسوأ الحالات أثناء نشاط الصوت.