لماذا ينقطع الصوت رغم انخفاض استخدام CPU؟ — قراءة من زاوية المخزن المؤقّت والموعد النهائي

تستمع إلى الموسيقى، فتُسمَع بين حين وآخر «طقّ» وينقطع الصوت. في «إدارة المهام» يقف استخدام CPU عند نحو 10٪، ومع ذلك فالصوت وحده غير مستقرّ. فلماذا ينقطع الصوت حتّى حين يكون لدى CPU متّسع؟

حتّى مع انخفاض استخدام CPU، قد ينقطع الصوت إذا لم تلحق تعبئة بيانات الصوت التالية بموعدها النهائي. والسبب أنّه يجب تسليم البيانات التالية بينما يُشغَّل الصوت المتبقّي في المخزن المؤقّت. وتأخّر التعبئة بسبب انتظار البيانات أو الأقفال، أو بسبب DPC/ISR وما شابهها على المعالج المنطقي المطلوب، يحدث دون أن يُستهلَك CPU بأكمله. Exclusive-Mode Streams، CPU Analysis

لكنّ «الطقّة» التي سمعتها وحدها لا تكفي للجزم بأنّها underrun، فأعراض مشابهة قد تنشأ أيضاً عن مصدر الصوت أو التطبيق أو المؤثّرات الصوتية أو جهاز الإخراج وغيرها. ابدأ بالمقارنة على مصدر الصوت نفسه: غيّر شرطاً واحداً في كلّ مرّة ثمّ أعِده إلى حاله، وإن لم يكفِ ذلك لتضييق النطاق فسجّل ما يحدث قبل الانقطاع وبعده. Fix distorted or crackling audio in Windows

تتناول هذه المقالة ذلك السؤال وما يليه من أسئلة: «هل يكفي تكبير المخزن المؤقّت؟» و«ما الذي نقارنه وما الذي نسجّله لتضييق نطاق السبب؟». ولا تحدّد سبب عطل بعينه انطلاقاً من استخدام CPU أو الصوت المسموع وحدهما.

يتركّز النطاق أساساً على إخراج الصوت في Windows 11. نقارن بين مخارج مدمجة وسلكية وUSB وBluetooth وغيرها، وفي برامج إنتاج الموسيقى (DAW) نتناول أيضاً المقارنة حين يوفّر التطبيق أو برنامج التشغيل إعداداً للمخزن المؤقّت. ولا تغطّي المقالة تصميم منظومة التسجيل الصوتي بأكملها، ولا تشخيص الاتصال اللاسلكي لكلّ جهاز.

نعتمد في الشرح الوضع المشترك (shared mode) مثالاً أساسياً. أمّا المسار الفعلي وحجم المخزن المؤقّت ودورة المعالجة فتختلف باختلاف التطبيق وواجهة API وبرنامج التشغيل والجهاز، ولا توجد شاشة إعدادات للمخزن المؤقّت مشتركة بين جميع التطبيقات. Low Latency Audio

قيم استخدام CPU، والـ 10 ميلي ثانية المتبقّية، وأوقات التعبئة وما شابهها في هذه المقالة افتراضات لأغراض الشرح، وليست تقريراً عن إعادة إنتاج أو تحسّن قيس فعلياً على حاسوب بعينه. أمّا العمليات في الجزء الثاني فإجراءات تحقّق تنفّذها في بيئتك.

يمكن قراءة الآلية بالترتيب بدءاً من القسم التالي «المخزن المؤقّت لتشغيل الصوت». أمّا عمليات التحقيق في انقطاع الصوت فتجدها في «مقارنة شروط إعادة الإنتاج» و«تسجيل انقطاع الصوت باستخدام WPR».

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 5، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

المخزن المؤقّت لتشغيل الصوت

حفظ ملفّ موسيقى وحده لا يُصدِر صوتاً من مكبّرات الصوت. يُعِدّ التطبيق بيانات الصوت، فتصل إلى جهاز الإخراج عبر Windows وبرنامج التشغيل. والمخزن المؤقّت لتشغيل الصوت منطقة تحتفظ مؤقّتاً بالبيانات التي ستُشغَّل بعد قليل. وبينما يشغّل الجهاز البيانات الحالية، يُعِدّ الطرف المزوِّد البيانات التالية ويعبّئ بها المخزن المؤقّت. Rendering a Stream

flowchart TB
    accTitle: تخزين قليل من الصوت مسبقاً ثمّ تشغيله
    accDescr: تدفّق تُعبَّأ فيه بيانات الصوت المُعَدّة في المخزن المؤقّت، وتُعَدّ البيانات التالية بينما يتقدّم التشغيل في جانب الجهاز.
    A["إعداد الصوت التالي"] --> B["التعبئة في المخزن المؤقّت"]
    B --> C["تشغيل الصوت المخزَّن"]
    C -.->|"قبل أن ينفد"| A

الشكل 1: لكي يستمرّ التشغيل، يجب أن تواكب التعبئة الطرف الذي يستهلك الصوت.

الشكل 1 مخطّط مفاهيمي يبيّن العلاقة بين التعبئة والاستهلاك فقط، ولا يعامل المخازن المؤقّتة المتعدّدة في مسار الصوت الفعلي على أنّها منطقة فيزيائية واحدة. Low Latency Audio

دور المخزن المؤقّت امتصاص فروق الوقت القصيرة بين الطرف الذي يُعِدّ الصوت والطرف الذي يستخدمه، ليبقى التشغيل متّصلاً. لكنّ سعة المخزن المؤقّت شيء، وكمّية البيانات غير المشغَّلة الموجودة فيه الآن شيء آخر. فعبارة «سعته 10 ميلي ثانية» لا تعني أنّه يبقى فيه دائماً ما يعادل 10 ميلي ثانية. Rendering a Stream

نسمّي هنا القيد الزمني الذي يفرض تسليم البيانات التالية اللازمة قبل نفاد البيانات قيد التشغيل «الموعد النهائي للتعبئة». فمعالجة الصوت تحتاج إلى أن تكون البيانات «جاهزة قبل لحظة إصدارها»، ولا يكفي أن «يكتمل الحساب في النهاية». والحالة التي لا يصل فيها الإمداد في الوقت فتنفد البيانات المراد تشغيلها تُسمّى underrun، وتؤدّي إلى انقطاع الصوت أو سماع طقّات. وحتّى إن وصلت البيانات متأخّرة، فلا يمكن لاحقاً ملء انقطاع سُمِع بالفعل. Exclusive-Mode Streams

مسار بيانات الصوت

في الوضع المشترك المعتاد، يستقبل محرّك الصوت (audio engine) في Windows البيانات التي أعدّها التطبيق الذي يشغّل الصوت، فيمزج عدّة أصوات ويطبّق المؤثّرات، ثمّ يمرّرها إلى برنامج التشغيل وجهاز الإخراج. يشارك التطبيق الذي يشغّل الصوت في قراءة مصدر الصوت وفي الإمداد إلى وجهة الإخراج معاً، بينما ينقل برنامج التشغيل وجهاز الإخراج البيانات إلى جانب الجهاز ويشغّلانها. Low Latency Audio

flowchart TB
    accTitle: مسار بيانات الصوت في الوضع المشترك
    accDescr: يعالج محرّك الصوت البيانات التي أعدّها التطبيق بالمزج والمؤثّرات ويمرّرها إلى برنامج التشغيل، ثمّ يشغّلها جهاز الإخراج.
    A["التطبيق: يُعِدّ البيانات"] --> E["محرّك الصوت: مزج ومؤثّرات"]
    E --> D["برنامج التشغيل: ينقل إلى الجهاز"]
    D --> O["جهاز الإخراج: تشغيل"]

الشكل 2: مثال على الوضع المشترك. تختلف المعالجة والمخازن المؤقّتة الوسيطة باختلاف واجهة API والجهاز.

قد توجد معالجة ومخازن مؤقّتة في جانب الجهاز أيضاً، فلا يحدّد المخزن المؤقّت في جانب التطبيق وحده التأخير الكلّي. ويفترض هذا الشرح مسار الوضع المشترك، ولا يعني أنّ كلّ واجهات API تمرّ بالمعالجة نفسها. Low Latency Audio

التعبئة حين يتبقّى 10 ميلي ثانية

لنفترض أنّه بقي الآن في المخزن المؤقّت ما يعادل 10 ميلي ثانية من البيانات غير المشغَّلة. إن جاءت التعبئة التالية بعد 8 ميلي ثانية، فإنّها تصل والبيانات لم تنفد بعد فيتّصل التشغيل. أمّا إن تعذّرت التعبئة حتّى 12 ميلي ثانية، ففي هذا المثال المبسّط تنفد البيانات عند 10 ميلي ثانية.

flowchart TB
    accTitle: مع المتبقّي نفسه البالغ 10 ميلي ثانية تختلف النتيجة بحسب توقيت التعبئة
    accDescr: يبيّن، كافتراض لأغراض الشرح، أنّه مع بقاء 10 ميلي ثانية من بيانات التشغيل تلحق التعبئة التي تأتي بعد 8 ميلي ثانية، بينما تأتي التعبئة بعد 12 ميلي ثانية بعد نفاد البيانات.
    A["يتبقّى 10 ميلي ثانية"] --> B{"التعبئة التالية"}
    B -->|"بعد 8 ميلي ثانية"| C["يتّصل التشغيل"]
    B -->|"بعد 12 ميلي ثانية"| D["تنفد عند 10 ميلي ثانية"]

الشكل 3: مثال بتوقيتات مبسّطة. المهمّ ليس نجاح التعبئة فحسب، بل توقيتها أيضاً.

استخدام CPU وتأخّر التعبئة

يبيّن استخدام CPU مدى انشغاله خلال فترة زمنية معيّنة، وهذا مقياس مختلف عن سؤال: هل تمكّنت معالجة الصوت من التنفيذ في اللحظة التي احتاجت إليها؟ حتّى لو كان لدى CPU متّسع في معظم الثانية، فإنّ وجود فترة واحدة تتعذّر فيها التعبئة لمدّة 12 ميلي ثانية قد يجعل هذا التأخّر الوحيد يقطع الصوت. ولا يستطيع فائض قدرة المعالجة الذي يبقى بعد ذلك استعادة لحظة تشغيل فاتت. CPU Analysis

flowchart TB
    accTitle: متّسع في المتوسّط مقابل تأخّر تعبئة واحد
    accDescr: حتّى لو كان لدى CPU متّسع في معظم الثانية، فإنّ فترة واحدة تتعذّر فيها التعبئة لمدّة 12 ميلي ثانية قد تقطع الصوت بسبب هذا التأخّر الوحيد.
    A["لدى CPU متّسع معظم الثانية"] --> B["تتعذّر التعبئة مرّة لمدّة 12 ميلي ثانية"]
    B --> C["تلك المرّة تقطع الصوت"]

الشكل 4: حتّى مع متّسع في المتوسّط، لا يمكن استعادة لحظة تشغيل فاتت.

ليس زمن الحساب وحده ما يقتطع من الوقت المتاح حتّى الموعد النهائي، بل يشمل ذلك أيضاً الانتظار حتّى تبدأ المعالجة، والانتظار حتّى تصل البيانات اللازمة. لذا يتغيّر سؤال التحقيق أيضاً: لا يقتصر على «كم كانت نسبة CPU؟»، بل يصبح «في لحظة انقطاع الصوت، ماذا كان الصوت التالي ينتظر؟».

انتظار البيانات والأقفال

لنفترض أنّ المعالجة التي تُعِدّ بيانات الصوت تنتظر اكتمال قراءة ملفّ. والأمر نفسه إذا كانت تنتظر قفلاً تحتفظ به معالجة أخرى داخل التطبيق. المعالجة المنتظِرة نفسها لا تستخدم CPU كثيراً، لكنّ التشغيل يستمرّ في جانب الجهاز ويتناقص الصوت المتبقّي. Results for the Streaming Media Performance Assessment، CPU Analysis

flowchart TB
    accTitle: التشغيل يتقدّم حتّى أثناء انتظار لا يستخدم CPU
    accDescr: بينما تنتظر معالجة الصوت البيانات أو قفلاً فهي لا تستخدم CPU، لكنّ التشغيل يتقدّم ويتناقص المتبقّي، وإذا تأخّرت التعبئة فقد ينفد المخزن المؤقّت.
    A["معالجة الصوت تنتظر البيانات"] --> B["تلك المعالجة لا تستخدم CPU"]
    B --> C["التشغيل يستمرّ في الأثناء"]
    C --> D["تأخّر التعبئة يعني نفاد المخزون"]

الشكل 5: عدم استخدام CPU شيء، وانتهاء العمل المطلوب شيء آخر.

DPC وISR وخيط الصوت

ISR هي المعالجة التي تستجيب للمقاطعة (interrupt) الواردة من جهاز. وDPC آلية تؤجّل بقية العمل إلى وقت لاحق لتقصير معالجة المقاطعة. يُنفَّذ DPC العادي قبل الخيوط العادية على المعالج المنطقي نفسه، وطوال تنفيذ DPC أو ISR العاديّين لا يستطيع ذلك المعالج المنطقي تنفيذ الخيوط العادية. Introduction to DPCs، CPU Analysis

حتّى إن كان لدى CPU متّسع إجمالاً، فإنّ طول هذه العمليات أو تكرارها على CPU الذي تحتاجه معالجة الصوت قد يؤخّر الإمداد. وتذكر مواد Microsoft لتحليل أداء الصوت والفيديو أنّ DPC/ISR الطويلة الصادرة عن برامج تشغيل الشبكة والتخزين والرسوميات وغيرها هي أيضاً من الأسباب المحتملة لانقطاع الصوت. فلا يكفي دائماً فحص الجهاز الذي يُصدِر الصوت وحده. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: حين تؤخّر الاستجابة للأجهزة تنفيذ الصوت
    accDescr: إذا طال DPC أو ISR العاديّان على CPU الذي تحتاجه معالجة الصوت، يتأخّر تنفيذ الخيط، وقد يؤثّر ذلك في الموعد النهائي للتعبئة.
    A["DPC وISR على CPU نفسه"] -->|"إذا طالت"| B["تنفيذ الصوت ينتظر"]
    B --> C["تتأخّر تعبئة الصوت التالي"]
    C --> D["نفاد المتبقّي يقطع الصوت"]

الشكل 6: قد تؤثّر معالجة لا تخصّ الجهاز الذي يُصدِر الصوت تأثيراً غير مباشر في تعبئة الصوت.

لا يمكن رسم حدّ مشترك من قبيل «إذا كان DPC أقلّ من كذا ميكروثانية فلن ينقطع الصوت على أيّ حاسوب». فقيم التحذير في مواد تقييم الأداء قيمٌ ضمن شروط ذلك التقييم، ولا نتّخذها معياراً للأمان بمعزل عن الموعد النهائي الفعلي للتعبئة وعن متّسع المخزن المؤقّت. Results for the Streaming Media Performance Assessment

حجم المخزن المؤقّت وتأخير التشغيل

إذا زِدتَ الصوت المخزَّن مسبقاً في الشروط نفسها، سهُل امتصاص تأخّرات التعبئة المؤقّتة، لكنّ الصوت الجديد ينتظر خلف الصوت المخزَّن بالفعل. فالانتظار المقبول عند الاستماع إلى الموسيقى فقط قد يصبح مزعجاً عند العزف على لوحة مفاتيح موسيقية، أو عند معالجة صوت الميكروفون والاستماع إليه بنفسك، إذ يُلاحَظ الفارق بين الإجراء والصوت. Exclusive-Mode Streams، Low Latency Audio

flowchart TB
    accTitle: متّسع المخزن المؤقّت مقابل تأخّر الاستجابة
    accDescr: زيادة الصوت المخزَّن مسبقاً تسهّل امتصاص تأخّرات التعبئة المؤقّتة، لكنّها تزيد أيضاً زمن الانتظار حتّى يُشغَّل الصوت الجديد.
    A["زيادة الصوت المخزَّن مسبقاً"] --> B["أسهل لامتصاص تأخّر التعبئة"]
    B -->|"في المقابل"| C["الصوت الجديد ينتظر خلفه"]
    C --> D["يتأخّر الصوت عن الإجراء"]

الشكل 7: تكبير المخزن المؤقّت ضبطٌ يصنع متّسعاً على حساب سرعة الاستجابة.

ليس الأمر «كلّما صغر كان أفضل أداءً» ولا «كلّما كبر كان هو الصواب». احتفظ بسرعة الاستجابة اللازمة، مع ترك متّسع يمنع الانقطاع.

تكبير المخزن المؤقّت يصنع متّسعاً في مواجهة تأخّرات الإمداد المؤقّتة. أمّا إذا كان الإمداد نفسه في المتوسّط لا يواكب الاستهلاك، فإنّ تكبير مخزن مؤقّت محدود السعة لا يفعل سوى إطالة الوقت حتّى ينفد، ولا يعالج انقطاع اتصال الجهاز أيضاً. وليس هذا توصيةً بأنّ استخدام الوضع الحصري (exclusive mode) يحلّ كلّ شيء. Exclusive-Mode Streams

صوت بطول 480 إطاراً عند 48kHz

إطار PCM وحدة تجمع عيّنات جميع القنوات التي تُشغَّل في اللحظة نفسها. فكون الصوت ستيريو لا يعني مضاعفة عدد الإطارات لحساب الزمن. يُحسَب طول الصوت الذي يمثّله عدد من الإطارات بالصيغة «عدد الإطارات ÷ معدّل أخذ العيّنات»: عند 48kHz تساوي 480 إطاراً 480 ÷ 48000 ثانية، أي 10 ميلي ثانية. وإذا زِدتَ عدد الإطارات مع البقاء على 48kHz، طال أيضاً زمن الصوت الذي يمكن تخزينه. Rendering a Stream

هذا الزمن غير التأخير الكلّي من لحظة الضغط على المفتاح حتّى سماع الصوت، لأنّ هناك أيضاً أزمنة التطبيق وبرنامج التشغيل والجهاز والمخازن المؤقّتة والمعالجات الأخرى. وكذلك تُقرأ قيم إعدادات DAW بعد التحقّق من وحدتها ومن المخزن المؤقّت الذي تخصّه. Low Latency Audio

flowchart TB
    accTitle: الزمن المحسوب من عدد الإطارات مقابل التأخير الكلّي
    accDescr: الـ 10 ميلي ثانية الناتجة عن قسمة 480 إطاراً على 48000 هي الزمن الذي يمثّله المخزن المؤقّت، وبإضافة معالجة التطبيق وبرنامج التشغيل والجهاز وغيرها نحصل على التأخير الكلّي من المفتاح إلى الصوت.
    A["480 ÷ 48000"] --> B["10 ميلي ثانية يمثّلها المخزن المؤقّت"]
    B -->|"تُضاف معالجات أخرى"| C["التأخير الكلّي من المفتاح إلى الصوت"]

الشكل 8: الزمن المحسوب من عدد الإطارات جزء من التأخير الكلّي.

مقارنة شروط إعادة الإنتاج

ابدأ بتضييق التركيبة التي تتكرّر فيها المشكلة، ولا تنتقل إلى التسجيل المفصّل إلا عند الحاجة. ما يلي إجراء للتحقّق من السبب، وليس قائمة حلول تُطبَّق فيها كلّ تغييرات الإعدادات دفعة واحدة.

احفظ عملك، وأنهِ الاجتماعات أو التسجيلات الفعلية، ثمّ جرّب بمستوى صوت لا يُجهد أذنيك. دوّن وجهة الإخراج الأصلية وحالة تحسينات الصوت وقيم المخزن المؤقّت وما شابهها، لتتمكّن من الرجوع إليها. تجاوز البنود التي لا يتوفّر لها إعداد، ولا تعدّل السجلّ (Registry) أو ما شابهه لإظهار بند إعداد.

1. حدّد مقطعاً صوتياً قصيراً ثابتاً وزمن مراقبة ثابتاً، وتحقّق من تكرّر المشكلة في الشروط الأصلية.

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

2. اختر مقارنة واحدة من الجدول التالي، وغيّر ذلك الشرط وحده ثمّ شغّل الصوت.

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

3. عند مقارنة تحسينات الصوت، أوقف الإعداد مؤقّتاً على الإخراج المعني.

   في Windows اختر الإخراج المعني من «الإعدادات» ثمّ «النظام» ثمّ «الصوت»، وفي البيئات التي يتوفّر فيها ذلك أوقف «تحسينات الصوت». إن اختلفت الواجهة أو لم يظهر البند، فراجع الإرشادات الخاصّة بذلك الإصدار والجهاز. Fix distorted or crackling audio in Windows

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

   ضع نتائج «الشروط الأصلية» و«تغيير شرط واحد» و«بعد الإرجاع إلى الأصل» جنباً إلى جنب. أعِد أيّ تغيير لم يُحدِث أثراً إلى حاله قبل الانتقال إلى مقارنة أخرى، فإذا واصلت تغيير تركيبات الإعدادات لن تعرف ما الذي أفاد.

5. إن أردت تجربة تغيير برنامج التشغيل، فافعل ذلك بعد التحقّق من مصدر التوزيع الرسمي ومن طريقة الاستعادة.

   استخدم Windows Update أو التوزيع الرسمي من الشركة المصنّعة للجهاز، وسجّل الإصدار والإعدادات قبل التغيير وبعده. تحقّق مسبقاً من إمكانية الرجوع إلى ما كان عليه، وفي الحواسيب المُدارة تشاوَر مع المسؤول. لا تعدّ المشكلة محلولة لمجرّد نجاح التشغيل مرّة واحدة بعد التحديث مباشرة، بل تحقّق في شروط إعادة الإنتاج نفسها. Fix distorted or crackling audio in Windows

النتيجة المطلوبة سجلٌّ يربط العَرَض بالشروط، مثل «تتكرّر المشكلة في هذا التطبيق عند استخدام هذا الإخراج». وحتّى إن وجدت إعداداً يحسّن الوضع، فافصل ذلك عن تحديد السبب.

flowchart TB
    accTitle: مقارنة تغيّر شرطاً واحداً ثمّ تعيده
    accDescr: تحقّق من تكرّر المشكلة بمصدر الصوت نفسه، وغيّر شرطاً واحداً كالتطبيق أو الإخراج، وسجّل أيضاً النتيجة بعد الإرجاع إلى الأصل.
    A["التشغيل بالتركيبة الأصلية"] --> B["تغيير شرط واحد والتشغيل"]
    B --> C["الإرجاع إلى الأصل والتشغيل"]
    C --> D["تسجيل الشروط ووقت الانقطاع"]

الشكل 9: تحقّق من أنّ الشرط والعَرَض يتطابقان مراراً، لا من أنّ الوضع تحسّن مرّة واحدة.

إعادة الإنتاج قبل تغيير الشرط وبعده

«تمكّنّا من كبح العَرَض» و«تمكّنّا من تضييق الشروط» و«حدّدنا السبب الجذري» مراحل مختلفة. سجّل الاستنتاج بما يتناسب مع ما أمكن ملاحظته فعلاً.

flowchart TB
    accTitle: ثلاث نتائج تدلّ على ارتباط بالشرط
    accDescr: إذا تكرّرت المشكلة في الشروط الأصلية، وتحسّنت عند تغيير شرط واحد، وعادت عند الإرجاع، فتلك قرينة على ارتباط بذلك الشرط، لكنّها منفصلة عن تحديد السبب.
    A["تتكرّر في الشروط الأصلية"] --> B["تتحسّن بتغيير شرط واحد"]
    B --> C["تعود عند الإرجاع"]
    C --> D["قرينة على ارتباط بالشرط"]

الشكل 10: حتّى إذا اجتمعت النتائج الثلاث، فما تعرفه لا يتجاوز قرينة على الارتباط.

انخفاض استخدام CPU ليس دليلاً على أنّ الموعد النهائي للصوت قد احتُرم. وفي الوقت نفسه، لا يكفي وقوع انقطاع للقول إنّ تأخّر التعبئة كان السبب الجذري. قارن مصدر الصوت ومعالجة التطبيق والمؤثّرات ومسار الإخراج وغيرها، واحكم في حدود ما لاحظته. Fix distorted or crackling audio in Windows

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

تسجيل انقطاع الصوت باستخدام WPR

تُنفَّذ هذه الخطوة حين لا تكفي مقارنة الشروط وحدها لتضييق النطاق، أو عند فحص المعالجة في جانب برنامج التشغيل. WPR أداة للتسجيل، وWPA أداة لتحليل المحور الزمني المحفوظ. جهّز Windows Performance Toolkit والصلاحيات اللازمة للتسجيل ومكان حفظ ملفّ ETL. وإذا أردت تثبيت الأدوات والتسجيل على حاسوب مُدار، فاطلب ذلك من المسؤول. وتحقّق من أسماء العرض وملفّات التعريف المتاحة في الإصدار المثبّت. Windows Performance Recorder

قد يتضمّن ملفّ ETL أسماء العمليات (process) ومسارات الملفّات وغيرها. قبل التسجيل راجع قواعد مؤسّستك ومن يجوز مشاركته معه، ولا ترفقه كما هو في مكان عامّ. وإذا كانت جلسة تسجيل أخرى قيد التشغيل، فلا توقفها من تلقاء نفسك، بل راجع المسؤول عنها. WPR How-to Topics

1. افتح «More Options» في WPR، واختر ملفّ تعريف التسجيل المناسب للغرض.

   من ملفّات التعريف القياسية «Audio glitches» و«CPU usage». اختر إعداداً يتيح فحص انقطاعات الصوت ونشاط CPU. تحقّق من ملفّات التعريف المتاحة وأسماء العرض وما يُجمَع في الإصدار المثبّت، ولا تضبط تسجيلاً طويلاً لكلّ الأنواع. Built-in Recording Profiles

2. ابدأ التسجيل قبل إعادة إنتاج انقطاع الصوت.

   إذا ظهر طلب تأكيد لإيقاف تسجيل قائم، فلا تتابع، بل ألغِ البدء وراجع المسؤول. اجعل الشروط مطابقة لحالة عدم التسجيل، وأبقِ في الحسبان احتمال أن يغيّر حِملُ التسجيل نفسه العَرَض. WPR How-to Topics

3. شغّل الصوت في الشروط التي وجدتها في المقارنة، ودوّن وقت الانقطاع والعملية الجارية.

   ضمّن أيضاً فترة قصيرة سليمة قبل العَرَض وبعده. وفي التسجيل الذي لم تتكرّر فيه المشكلة اذكر ذلك صراحة، ولا تعامله كتسجيل التقط السبب.

4. بعد إعادة الإنتاج أنهِ التسجيل بـ «Save» واحفظ ملفّ ETL.

   «Cancel» لا يحفظ شيئاً. دوّن مكان الحفظ وشروط إعادة الإنتاج ووجود التسجيل من عدمه، وهل ظهر تحذير بفقدان أحداث. وفي تسجيل فيه أحداث مفقودة، لا تحكم بأنّ الفترات غير الظاهرة كانت سليمة. WPR How-to Topics

حين يتوفّر ملفّ ETL وملاحظات عن وقت الانقطاع والعملية الجارية والشروط، تكون مستعدّاً للمطابقة في WPA. وحفظ التسجيل وحده لا يضمن أنّ الأحداث اللازمة قد جُمعت. تحقّق من المحتوى في القسم التالي «التنفيذ والانتظار حول لحظة الانقطاع».

flowchart TB
    accTitle: أخذ تسجيل قصير يتضمّن الانقطاع
    accDescr: ابدأ التسجيل في WPR، وأعِد إنتاج العَرَض ودوّن الوقت، ثمّ أوقف التسجيل واحفظه وافحصه في WPA.
    A["بدء التسجيل في WPR"] --> B["إعادة إنتاج الانقطاع بالشروط نفسها"]
    B --> C["تدوين الوقت والعملية والحفظ"]
    C --> D["تكبير الفترة المحيطة في WPA"]

الشكل 11: لا يكفي النظر إلى استخدام CPU بعد زوال العَرَض، بل يلزم تسجيل الفترة التي وقع فيها.

التنفيذ والانتظار حول لحظة الانقطاع

جهّز ملفّ ETL المحفوظ وملاحظات وقت إعادة الإنتاج. ما يلي نقطة انطلاق للتحقيق في WPA. وإذا احتجت إلى تحليل مفصّل يشمل stacks وsymbols، فاطلبه من المسؤول أو المطوّرين مع الانتباه إلى طريقة التعامل مع التسجيل.

1. افتح ملفّ ETL في WPA، وكبّر الفترة المحيطة بالانقطاع استناداً إلى أحداث الصوت المجمَّعة ووقت إعادة الإنتاج.

   أبقِ فترة خالية من العَرَض للمقارنة. لا تنظر إلى ترتيب القيم القصوى وحده، بل قارن على النطاق الزمني نفسه.

2. افحص «DPC/ISR» و«CPU Usage (Precise)» على النطاق نفسه.

   إن لم تتوفّر البيانات اللازمة، فتحقّق من أنّ ملفّ التعريف يجمعها وعُد إلى التسجيل في WPR. غياب البيانات شيء، وعدم وجود مشكلة شيء آخر. CPU Analysis، Built-in Recording Profiles

3. ميّز ما إذا كان الخيط المرتبط بالصوت جاهزاً للتنفيذ لكنّه ينتظر دوره، أم كان ينتظر بيانات أو ما شابهها.

   في الحالة الأولى، طابِق لترى هل كان DPC/ISR أو ما شابهه يعمل طويلاً على المعالج المنطقي المعني. وفي الحالة الثانية، تتبّع ما الذي أنهى الانتظار عبر الأحداث وstacks المجمَّعة. ولأنّ الخيط قيد التنفيذ قد تقطعه مقاطعة، فلا تقتصر على زمن Ready، بل ضع فوقه فترات DPC/ISR أيضاً. CPU Analysis

4. سجّل معاً التطابق الزمني مع الانقطاع، وCPU المعني، ونتائج تغيير الشروط.

   لا تحدّد جهازاً أو برنامج تشغيل بعينه سبباً لمجرّد اسم الوحدة (module) في DPC/ISR طويل. فقد تكون تنظر إلى قيمة كبيرة من وقت آخر، أو إلى جزء مشترك تمرّ عبره عدّة أجهزة.

flowchart TB
    accTitle: فحص نوع الانتظار في فترة الانقطاع
    accDescr: كبّر الفترة المحيطة بالانقطاع وانظر إلى حالة خيط الصوت. إن كان جاهزاً ينتظر دوره فطابِقه مع DPC وISR على CPU نفسه، وإن كان ينتظر بيانات أو نحوها فتتبّع المعالجة التي أنهت الانتظار.
    A["تكبير الفترة المحيطة بالانقطاع"] --> B{"حالة الخيط"}
    B -->|"ينتظر دوره"| C["DPC وISR"]
    B -->|"ينتظر البيانات"| D["ما أنهى الانتظار"]

الشكل 12: لا تلتقط القيم القصوى وحدها، بل اقرأها مقرونةً بالفترة التي احتاجت فيها معالجة الصوت إلى التنفيذ.

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

التحميل المسبق في تطبيقات الصوت

إذا كنت تطوّر تطبيق صوت بنفسك، فصمّمه بحيث تلحق المعالجة التي تملأ المخزن المؤقّت التالي بالموعد النهائي في كلّ مرّة. وفي WASAPI طريقة لتلقّي حدث (event) يُعلمك بالتوقيت الذي يمكن فيه معالجة المخزن المؤقّت. Exclusive-Mode Streams

MMCSS آلية توزّع موارد CPU على خيوط معالجة الوسائط المتعدّدة ذات القيود الزمنية. وليست لديها وظيفة لتجهيز البيانات من القرص مسبقاً أو لإزالة انتظار الأقفال. وحتّى عند الاستفادة من التوزيع الذي يقدّمه MMCSS، يظلّ التصميم الذي يجهّز البيانات ويقلّل الانتظار مطلوباً على حدة. Multimedia Class Scheduler Service

flowchart TB
    accTitle: النطاق الذي يتولّاه MMCSS
    accDescr: يوزّع MMCSS موارد CPU على خيوط المعالجة ذات القيود الزمنية، أمّا تجهيز البيانات وتقليل انتظار الأقفال فيتمّان بتصميم منفصل.
    M["MMCSS: يوزّع موارد CPU"] -.->|"مطلوب على حدة"| D["تجهيز البيانات وتقليل الانتظار"]

الشكل 13: توزيع موارد CPU، والتصميم الذي يوصل البيانات في وقتها، عملان منفصلان.

مبدأ التصميم هو الفصل بين المعالجة التي تقرأ من الملفّات أو الشبكة، والمعالجة التي تسلّم الصوت. نفّذ مسبقاً التجهيزات التي يصعب توقّع زمنها، واستخدم للتسليم مخزناً مؤقّتاً محجوزاً مسبقاً. واجعل جانب الصوت في غنى عن انتظار ردّ واجهة المستخدم، أو الأقفال الطويلة، أو كتابة السجلات (log) بشكل متزامن.

flowchart TB
    accTitle: الفصل بين التجهيز غير المتوقّع الزمن وإمداد الصوت
    accDescr: تصميم تُنفَّذ فيه القراءة ونحوها في معالجة مسبقة، وتُسلَّم البيانات المجهّزة إلى معالجة الصوت عبر مخزن مؤقّت، لتقليل الانتظار الطويل قبيل الموعد النهائي.
    A["معالجة مسبقة تجهّز البيانات"] --> B["منطقة تسليم محجوزة مسبقاً"]
    B --> C["معالجة الصوت تسلّم القدر اللازم"]
    C --> D["الإمداد إلى وجهة إخراج الصوت"]

الشكل 14: أخرِج العمل المستغرِق للوقت من اللحظة التي تسبق تسليم الصوت مباشرة.

إذا توقّف جانب التجهيز طويلاً، فسينفد المخزون حتّى مع هذا الفصل. سجّل، بطريقة لا تعيق معالجة الصوت، ليس متوسّط زمن المعالجة فحسب، بل أيضاً المرّات التي ظهرت فيها معالجة أو انتظار طويل، وعدد المرّات التي تعذّر فيها الإمداد. وتحقّق من حجم المخزن المؤقّت والدورة المختارَين فعلياً عبر واجهة API أو برنامج التشغيل، ولا تفترض أنّ القيمة المحدّدة اعتُمدت كما هي. Rendering a Stream، Low Latency Audio

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

أثر أولويّة الوقت الحقيقي

لا يُوصى بشكل عامّ بأن يرفع المستخدم مشغّل الوسائط بأكمله إلى أولويّة «الوقت الحقيقي». ففي ذلك خطر إعاقة معالجات مهمّة أخرى، ورفع أولويّة الخيط العادي لا يعني القدرة على إزالة انتظار DPC/ISR أو انتظار البيانات والأقفال. وفي التطوير تُستخدَم آليات مثل MMCSS، وتصميم لا يُدخِل الانتظار الطويل إلى إمداد الصوت. Scheduling Priorities، CPU Analysis

flowchart TB
    accTitle: الانتظار الذي يبقى حتّى بعد التحويل إلى أولويّة الوقت الحقيقي
    accDescr: حتّى لو رُفع مشغّل الوسائط إلى أولويّة الوقت الحقيقي، فإنّ الخيط العادي لا يسبق DPC وISR على CPU نفسه، ويبقى انتظار البيانات والأقفال، وهناك أيضاً خطر إعاقة معالجات مهمّة أخرى.
    A["رفع المشغّل إلى أولويّة الوقت الحقيقي"] --> B["لا يسبق DPC وISR"]
    B --> C["يبقى انتظار البيانات والأقفال"]
    C --> D["خطر إعاقة معالجات أخرى"]

الشكل 15: حتّى برفع الأولويّة، يبقى الانتظار الذي يؤخّر تعبئة الصوت.

مقالات ذات صلة

• إعداد Processor scheduling في Windows وخدمات الخلفية
• عزل استخدام القرص عند 100٪ في Windows بأمان
• لماذا يبطؤ RDP رغم سرعة الاتصال؟

المراجع

• Microsoft Learn, Rendering a Stream. الإمداد إلى مخزن التشغيل المؤقّت، والكمّية المتبقّية فيه، والحجم الفعلي للمخزن المؤقّت، ومعنى إطار PCM.
• Microsoft Learn, Exclusive-Mode Streams. توقيت إمداد المخزن المؤقّت وتشوّهات الصوت (glitches)، والموازنة مع التأخير، والإمداد المدفوع بالأحداث. وليس في ذلك توصية عامّة بالوضع الحصري نفسه.
• Microsoft Learn, Low Latency Audio. مسار الصوت في Windows، والمخازن المؤقّتة والأجهزة ومعالجة المؤثّرات وعلاقتها بالتأخير، ومقايضات التأخير المنخفض.
• Microsoft Learn, CPU Analysis. المعالج المنطقي، وحالتا Ready/Waiting للخيوط، والعلاقة بين DPC/ISR وتنفيذ الخيوط، وتحليل CPU في WPA.
• Microsoft Learn, Introduction to DPCs. الآلية التي تقصّر معالجة المقاطعة وتؤجّل بقية العمل إلى DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPC/ISR الطويلة والمتكرّرة، ونقص إمداد البيانات وتشوّهات الصوت. ولا نعمّم قيم التحذير في التقييم لتصبح معياراً للأمان على جميع الأجهزة.
• Microsoft Support, Fix distorted or crackling audio in Windows. فحص تحسينات الصوت والصيغة وبرامج التشغيل وغيرها.
• Microsoft Learn, Windows Performance Recorder. تسجيل ETW والتحليل باستخدام WPA، واستخدام Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options في WPR، وملفّات التعريف القياسية مثل Audio glitches وCPU usage.
• Microsoft Learn, WPR How-to Topics. بدء التسجيل والحفظ بـ Save، والتعارض مع الجلسات القائمة، والتنبّه إلى المعلومات الشخصية وفقدان الأحداث.
• Microsoft Learn, Multimedia Class Scheduler Service. توزيع موارد CPU على معالجة الوسائط المتعدّدة ذات القيود الزمنية.
• Microsoft Learn, Scheduling Priorities. أولويّات العمليات والخيوط، وتنبيهات بشأن أولويّة الوقت الحقيقي.

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

مواضيع ذات صلة

صفحات مواضيع قريبة من موضوع هذه المقالة. وانطلاقًا من المقالة يمكنكم الانتقال إلى الخدمات ذات الصلة وإلى مقالات أخرى.

الخدمات المرتبطة بهذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة نتلقّاها عند الاستشارة حول موضوع هذه المقالة.

لماذا ينقطع الصوت بينما لا يتجاوز استخدام CPU نحو 10٪؟

للصوت موعد نهائي: يجب تعبئة البيانات التالية قبل أن تنفد البيانات التي تُشغَّل حالياً. وحتّى إذا كان استخدام CPU الإجمالي منخفضاً، فقد لا تصل التعبئة في وقتها إذا لم تتمكّن معالجة الصوت من التنفيذ في تلك اللحظة، أو كانت تنتظر بيانات تحتاجها. ليس كلّ انقطاع ناتجاً عن هذا السبب، لذا تلزم أيضاً مقارنات تُغيِّر فيها جهاز الإخراج أو التطبيق.

هل يُصلح تكبيرُ المخزن المؤقّت للصوت انقطاعَ الصوت؟

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

كم ميلي ثانية من الصوت تمثّل 480 إطاراً عند 48kHz؟

480÷48000 ثانية، أي 10 ميلي ثانية. الإطار الواحد في PCM وحدة تجمع عيّنات جميع القنوات في اللحظة نفسها. هذه القيمة هي طول الصوت الذي يمثّله هذا العدد من الإطارات، وليست التأخير الكلّي الذي يشمل الجهاز والتطبيق.

هل برنامج التشغيل الذي تطول أزمنة تنفيذ DPC أو ISR فيه هو سبب انقطاع الصوت؟

قد يكون مرشّحاً، لكنّ ترتيب أزمنة التنفيذ وحده لا يكفي للحسم. طابِق الفترة التي وقع فيها الانقطاع مع انتظار خيط الصوت ومع تنفيذ DPC/ISR على CPU نفسه. لا تجزم من اسم الوحدة (module) وحده بوجود عطل في جهاز أو برنامج تشغيل بعينه، وتحقّق أيضاً من نتائج تغيير شروط إعادة الإنتاج.

هل يتحسّن الوضع إذا رفعتُ مشغّل الوسائط إلى أولويّة الوقت الحقيقي؟

لا يُوصى بذلك بشكل عامّ. رفع أولويّة خيط عادي لا يجعله يسبق DPC وISR العاديّين على CPU نفسه، ولا يزيل انتظار البيانات أو الأقفال. يستخدم المطوّرون آليات مثل MMCSS وتصميماً لا يُدخِل الانتظار، ويقارن المستخدمون أوّلاً شروط إعادة الإنتاج ومسار الإخراج.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

ممثل شركة كومورا سوفت ذ.م.م.

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