למה האודיו נקטע כשניצולת ה-CPU נמוכה? — הסבר דרך buffer ו-deadline

אתם מקשיבים למוזיקה, ומדי פעם נשמע “פופ” והצליל נקטע. ב-Task Manager ניצולת ה-CPU עומדת בסביבות 10%, ורק האודיו לא יציב. אז למה האודיו נקטע כשיש ל-CPU מרווח?

גם כשניצולת ה-CPU נמוכה, האודיו עלול להיקטע אם המילוי של נתוני האודיו הבאים לא עומד ב-deadline. הסיבה היא שצריך להעביר את הנתונים הבאים בזמן שהאודיו שנשאר ב-buffer עדיין מתנגן. עיכובים במילוי בגלל המתנה לנתונים או ל-locks, או בגלל DPC/ISR וגורמים דומים על ה-logical CPU הדרוש, קורים גם בלי שה-CPU כולו מנוצל עד הסוף. Exclusive-Mode Streams, CPU Analysis

עם זאת, ה”פופ” ששמעתם לבדו לא מספיק כדי לקבוע שמדובר ב-underrun. סימפטומים דומים יכולים לנבוע גם ממקור האודיו, מהאפליקציה, מאפקטים של אודיו, מהתקן הפלט ועוד. קודם משווים עם אותו מקור אודיו: משנים תנאי אחד בכל פעם ומחזירים אותו למצב המקורי. אם גם כך לא מצליחים לצמצם, מקליטים את מה שקורה לפני הקטיעה ואחריה. Fix distorted or crackling audio in Windows

המאמר עוסק בשאלה הזו ובשאלות שבאות אחריה: “האם מספיק להגדיל את ה-buffer?” ו”מה להשוות ומה להקליט כדי לצמצם את הסיבה?”. הוא לא קובע את הסיבה לתקלה ספציפית על סמך ניצולת ה-CPU או הצליל שנשמע בלבד.

המאמר מתמקד בעיקר בפלט אודיו ב-Windows 11. משווים בין פלטים מובנים, חוטיים, USB, Bluetooth ועוד, ובתוכנות להפקת מוזיקה (DAW) מכוסות גם השוואות במקרים שבהם האפליקציה או הדרייבר מספקים הגדרת buffer. המאמר לא מכסה את התכנון של כל שרשרת ההקלטה, וגם לא אבחון של התקשורת האלחוטית של כל התקן.

ההסבר משתמש ב-shared mode כדוגמה הבסיסית. הנתיב בפועל, גודל ה-buffer ומחזור העיבוד משתנים לפי האפליקציה, ה-API, הדרייבר וההתקן, ואין מסך הגדרות buffer שמשותף לכל האפליקציות. Low Latency Audio

ניצולת ה-CPU, ה-10 מילישניות שנותרו, זמני המילוי ושאר הערכים שמופיעים כאן הם הנחות לצורך ההסבר. זה לא דיווח על שחזור או שיפור שנמדדו בפועל על מחשב מסוים. הפעולות בחלק השני הן תהליכי בדיקה שמבצעים בסביבה שלכם.

את המנגנון אפשר לקרוא לפי הסדר, החל מהפרק הבא, “ה-buffer של ניגון האודיו”. הפעולות לחקירת קטיעות נמצאות בפרקים “השוואת תנאי השחזור” ו”הקלטת הקטיעה עם WPR”.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 5, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

ה-buffer של ניגון האודיו

רק לשמור קובץ מוזיקה לא גורם לרמקולים להשמיע צליל. האפליקציה מכינה את נתוני האודיו, והם מגיעים להתקן הפלט דרך Windows והדרייבר. ה-buffer של ניגון האודיו הוא אזור שמחזיק זמנית את הנתונים שעומדים להתנגן. בזמן שההתקן מנגן את הנתונים הנוכחיים, הצד שמספק את הנתונים מכין את הנתונים הבאים וממלא בהם את ה-buffer. Rendering a Stream

flowchart TB
    accTitle: צוברים מעט אודיו מראש ואז מנגנים
    accDescr: נתוני האודיו שהוכנו נכנסים ל-buffer, ובזמן שהניגון בצד ההתקן מתקדם מכינים את הנתונים הבאים.
    A["מכינים את הצליל הבא"] --> B["ממלאים את ה-buffer"]
    B --> C["מנגנים את מה שנצבר"]
    C -.->|"לפני שנגמר"| A

איור 1: כדי שהניגון יימשך, המילוי צריך לעמוד בקצב של הצד שצורך את האודיו.

איור 1 הוא תרשים עקרוני שמראה רק את היחס בין מילוי לצריכה. הוא לא מתאר את ה-buffers הרבים שבנתיב האודיו האמיתי כאזור פיזי אחד. Low Latency Audio

התפקיד של ה-buffer הוא לספוג פערי זמן קצרים בין הצד שמכין את האודיו לצד שמשתמש בו, כך שהניגון יהיה רציף. אבל הקיבולת של ה-buffer וכמות הנתונים שנמצאים בו כרגע ועוד לא התנגנו הם שני דברים שונים. “יש קיבולת של 10 מילישניות” לא אומר שתמיד נשארו בו 10 מילישניות של אודיו. Rendering a Stream

במאמר הזה, אילוץ הזמן שלפיו צריך להעביר את הנתונים הבאים לפני שהנתונים שמתנגנים נגמרים נקרא “ה-deadline של המילוי”. בעיבוד אודיו צריך ש”הנתונים יהיו מוכנים עד הרגע שבו הם צריכים להישמע”. “בסוף החישוב הסתיים” לא מספיק. מצב שבו האספקה לא מגיעה בזמן והנתונים לניגון נגמרים נקרא underrun, והוא מוביל לקטיעות ולקליקים. גם אם הנתונים מגיעים באיחור, אי אפשר למלא בדיעבד קטיעה שכבר נשמעה. Exclusive-Mode Streams

הנתיב של נתוני האודיו

ב-shared mode הרגיל, ה-audio engine של Windows מקבל את הנתונים שאפליקציית הניגון הכינה, מערבב כמה צלילים ומחיל אפקטים, ואז מעביר אותם לדרייבר ולהתקן הפלט. אפליקציית הניגון אחראית גם לקריאת מקור האודיו וגם לאספקה ליעד הפלט, והדרייבר והתקן הפלט מעבירים את הנתונים לצד ההתקן ומנגנים אותם. Low Latency Audio

flowchart TB
    accTitle: הנתיב של נתוני האודיו ב-shared mode
    accDescr: ה-audio engine מערבב את הנתונים שאפליקציית הניגון הכינה ומחיל עליהם אפקטים, מעביר אותם לדרייבר, והתקן הפלט מנגן אותם.
    A["אפליקציית ניגון: מכינה נתונים"] --> E["Audio engine: מיקס ואפקטים"]
    E --> D["דרייבר: מעביר להתקן"]
    D --> O["התקן פלט: ניגון"]

איור 2: דוגמה ל-shared mode. העיבוד וה-buffers שבדרך משתנים לפי ה-API וההתקן.

לפעמים יש עיבוד ו-buffers גם בצד ההתקן, כך שה-buffer בצד האפליקציה לבדו לא קובע את ההשהיה הכוללת. ההסבר הזה מניח את הנתיב של shared mode, ואין הכוונה שכל ה-APIs עוברים את אותו עיבוד. Low Latency Audio

מילוי כשנותרו 10 מילישניות

נניח שכרגע נשארו ב-buffer עוד 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 לאורך פרק זמן מסוים. זה מדד אחר מהשאלה אם עיבוד האודיו הצליח לרוץ ברגע שבו היה צריך. גם אם ל-CPU יש מרווח ברוב השנייה, מספיק קטע אחד של 12 מילישניות שבו אי אפשר למלא, והעיכוב הבודד הזה עלול לקטוע את האודיו. כוח העיבוד הפנוי שנשאר אחר כך לא יכול להחזיר זמן ניגון שכבר עבר. CPU Analysis

flowchart TB
    accTitle: מרווח ממוצע מול עיכוב מילוי בודד
    accDescr: גם אם ל-CPU יש מרווח ברוב השנייה, קטע אחד של 12 מילישניות שבו אי אפשר למלא עלול לקטוע את האודיו בגלל העיכוב הבודד הזה.
    A["ל-CPU יש מרווח ברוב השנייה"] --> B["פעם אחת אין מילוי במשך 12 מילישניות"]
    B --> C["הפעם הזו קוטעת את האודיו"]

איור 4: גם עם מרווח ממוצע, אי אפשר להחזיר זמן ניגון שכבר עבר.

לא רק זמן החישוב מצמצם את המרווח עד ה-deadline. גם ההמתנה עד שהעיבוד מתחיל וההמתנה עד שהנתונים הדרושים מגיעים מצמצמות אותו. לכן גם שאלת החקירה משתנה: לא רק “כמה אחוזי CPU היו”, אלא “ברגע שהאודיו נקטע, על מה חיכה הצליל הבא?”.

המתנה לנתונים ול-locks

נניח שהעיבוד שמכין את נתוני האודיו מחכה לסיום קריאה מקובץ. אותו דבר קורה כשהוא מחכה ל-lock שמחזיק עיבוד אחר באפליקציה. העיבוד שמחכה כמעט לא משתמש ב-CPU, אבל בצד ההתקן הניגון ממשיך והאודיו שנשאר הולך ומתמעט. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: הניגון מתקדם גם בזמן המתנה שלא משתמשת ב-CPU
    accDescr: בזמן שעיבוד האודיו מחכה לנתונים או ל-lock הוא לא משתמש ב-CPU, אבל הניגון מתקדם והאודיו שנשאר מתמעט, ואם המילוי מתעכב ה-buffer עלול להתרוקן.
    A["עיבוד האודיו מחכה לנתונים"] --> B["העיבוד לא משתמש ב-CPU"]
    B --> C["בינתיים הניגון ממשיך"]
    C --> D["מילוי מאוחר מרוקן את ה-buffer"]

איור 5: זה שלא משתמשים ב-CPU לא אומר שהעבודה הדרושה הסתיימה.

DPC, ISR וה-thread של האודיו

ISR הוא הקוד שמטפל ב-interrupt שמגיע מהתקן. DPC הוא מנגנון שדוחה את שארית העבודה לשלב מאוחר יותר, כדי שהטיפול ב-interrupt יהיה קצר. DPC רגיל רץ לפני threads רגילים על אותו logical CPU, וכל עוד DPC או ISR רגילים רצים, ה-logical CPU הזה לא יכול להריץ threads רגילים. Introduction to DPCs, CPU Analysis

גם כשיש מרווח ב-CPU בסך הכול, אם אלה נמשכים זמן רב או קורים לעתים קרובות על ה-CPU שעיבוד האודיו צריך, האספקה עלולה להתעכב. בחומר של Microsoft על ניתוח ביצועי אודיו ווידאו, גם DPC/ISR ארוכים של דרייברים של רשת, אחסון, גרפיקה ועוד מופיעים כגורמים אפשריים לקטיעות. לא תמיד מספיק לבדוק רק את ההתקן שמשמיע את הצליל. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: כשהטיפול בהתקנים מעכב את הריצה של האודיו
    accDescr: כש-DPC או ISR רגילים נמשכים זמן רב על ה-CPU שעיבוד האודיו צריך, ריצת ה-thread מתעכבת, וזה עלול להשפיע על ה-deadline של המילוי.
    A["DPC ו-ISR על אותו CPU"] -->|"כשהם נמשכים"| B["האודיו ממתין לריצה"]
    B --> C["מילוי הצליל הבא מתעכב"]
    C --> D["כשהנתונים נגמרים, קטיעה"]

איור 6: לפעמים עיבוד שלא קשור להתקן שמשמיע את הצליל משפיע בעקיפין על מילוי האודיו.

אי אפשר לקבוע סף כללי בסגנון “אם DPC קצר ממספר מסוים של מיקרו-שניות, לא יהיו קטיעות באף מחשב”. ערכי האזהרה בחומר על הערכת הביצועים תקפים לתנאי ההערכה שלו, ולא משתמשים בהם כסף בטיחות במנותק מה-deadline האמיתי של המילוי ומהמרווח של ה-buffer. Results for the Streaming Media Performance Assessment

גודל ה-buffer וההשהיה בניגון

אם בתנאים זהים מחזיקים יותר אודיו מראש, קל יותר לספוג עיכובי מילוי זמניים, אבל צליל חדש שנוצר מחכה מאחורי האודיו שכבר נצבר. המתנה שמקובלת כשרק מקשיבים למוזיקה יכולה להפריע כשמנגנים בקלידים, או כשמעבדים את הקול מהמיקרופון ומאזינים לו בעצמכם: הפער בין הפעולה לצליל מורגש. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: מרווח ב-buffer מול תגובה איטית יותר
    accDescr: כשמחזיקים יותר אודיו מראש קל יותר לספוג עיכובי מילוי זמניים, אבל גם זמן ההמתנה עד שצליל חדש מתנגן גדל.
    A["מחזיקים יותר אודיו מראש"] --> B["קל יותר לספוג עיכובי מילוי"]
    B -->|"במחיר של"| C["צליל חדש מחכה מאחור"]
    C --> D["הצליל מגיע באיחור אחרי הפעולה"]

איור 7: הגדלת ה-buffer היא כוונון שקונה מרווח במחיר של מהירות התגובה.

זה לא “כמה שיותר קטן, יותר טוב” וגם לא “כמה שיותר גדול, יותר נכון”. שומרים על מהירות התגובה הנדרשת, ובמקביל משאירים מספיק מרווח כדי שהאודיו לא ייקטע.

הגדלת ה-buffer יוצרת מרווח מול עיכובי אספקה זמניים. אם האספקה עצמה, בממוצע, לא עומדת בקצב הצריכה, הגדלה של buffer סופי רק דוחה את הרגע שבו הוא מתרוקן, והיא גם לא פותרת ניתוקים של ההתקן. זו גם לא המלצה ש-exclusive mode יפתור הכול. Exclusive-Mode Streams

אודיו של 480 frames ב-48kHz

frame של PCM הוא יחידה שמאגדת את ה-samples של כל הערוצים שמתנגנים באותה נקודת זמן. בסטריאו לא מכפילים את מספר ה-frames פי 2 כדי לחשב זמן. את אורך האודיו שמספר frames מייצג מחשבים כ”מספר frames ÷ sample rate”: ב-48kHz, 480 frames הם 480 ÷ 48000 שניות, כלומר 10 מילישניות. אם מגדילים את מספר ה-frames ונשארים ב-48kHz, גם משך האודיו שאפשר להחזיק גדל. Rendering a Stream

הזמן הזה שונה מההשהיה הכוללת מרגע הלחיצה על קליד ועד שהצליל נשמע, כי מצטרפים אליו גם הזמנים של האפליקציה, הדרייבר, ההתקן, buffers אחרים ועיבוד נוסף. גם את הערכים בהגדרות של DAW קוראים אחרי שבודקים את היחידה ואיזה buffer הם מתארים. Low Latency Audio

flowchart TB
    accTitle: הזמן שמחושב ממספר ה-frames מול ההשהיה הכוללת
    accDescr: 10 המילישניות שמתקבלות מחלוקת 480 frames ב-48000 הן הזמן שה-buffer מייצג, וכשמוסיפים את העיבוד של האפליקציה, הדרייבר, ההתקן ועוד מקבלים את ההשהיה הכוללת מהקליד ועד הצליל.
    A["480 ÷ 48000"] --> B["10 מילישניות שה-buffer מייצג"]
    B -->|"מצטרף עיבוד נוסף"| C["השהיה כוללת מקליד לצליל"]

איור 8: הזמן שמחושב ממספר ה-frames הוא חלק מההשהיה הכוללת.

השוואת תנאי השחזור

קודם מצמצמים את השילוב שבו הבעיה משתחזרת, ועוברים להקלטה מפורטת רק כשצריך. מה שמופיע כאן הוא תהליך לבירור הסיבה, ולא רשימת תיקונים שבה מחילים את כל שינויי ההגדרות בבת אחת.

שמרו את העבודה וסיימו פגישות או הקלטות חיות, ורק אז נסו, בעוצמה שלא מכבידה על האוזניים. רשמו את יעד הפלט המקורי, את מצב ה-audio enhancements, את ערכי ה-buffer וכן הלאה, כדי שתוכלו לחזור למצב המקורי. דלגו על פריטים שאין להם הגדרה, ואל תשנו את ה-Registry או הגדרות דומות רק כדי שפריט הגדרה יופיע.

1. בוחרים קטע אודיו קצר קבוע וזמן תצפית קבוע, ומוודאים שהבעיה משתחזרת בתנאים המקוריים.

   רושמים את גרסת Windows, את שם האפליקציה והגרסה שלה, את התקן הפלט, את סוג החיבור ואת גרסת הדרייבר. מתעדים גם את השעה, הפעולה ומספר הפעמים שבהן התרחשה קטיעה. אם הבעיה לא משתחזרת בתנאים המקוריים, לא מסיקים שהמצב השתפר, אלא חוזרים לברר באילו תנאים היא משתחזרת.

2. בוחרים השוואה אחת מהטבלה הבאה, משנים רק את התנאי הזה ומנגנים.

   התנאי להשוואה	מה בודקים
   מקור אודיו ששמור מקומית מול ניגון דרך הרשת	האם זה קורה רק בניגון דרך הרשת. אם הפורמט או נתיב העיבוד שונים גם כשהתוכן זהה, רושמים גם את זה.
   אותו מקור אודיו באפליקציה אחרת	האם הבעיה מרוכזת באפליקציה מסוימת.
   פלט Bluetooth וכדומה מול פלט מובנה או חוטי	האם הבעיה מרוכזת בנתיב פלט מסוים.
   audio enhancements מופעלים מול מושבתים	האם השילוב עם עיבוד האפקטים משנה משהו.
   ה-buffer הנוכחי ב-DAW וכדומה מול ערך גדול יותר בדרגה אחת	האם יותר מרווח מראש משנה משהו. והאם גם ההשהיה בין הפעולה לצליל עדיין מקובלת.

3. כשמשווים audio enhancements, מכבים את ההגדרה באופן זמני בפלט הרלוונטי.

   ב-Windows בוחרים את הפלט ב-Settings > System > Sound, ובסביבות שבהן זה זמין מכבים את “Audio enhancements”. אם התצוגה שונה או שהפריט לא מופיע, בדקו את ההנחיות לגרסה ולהתקן שלכם. 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: מה שבודקים הוא שהתנאי והסימפטום מתאימים זה לזה שוב ושוב, ולא שהמצב השתפר פעם אחת.

שחזור לפני שינוי התנאי ואחריו

“הצלחנו לרסן את הסימפטום”, “הצלחנו לצמצם את התנאים” ו”זיהינו את ה-root cause” הם שלבים שונים. רושמים מסקנה שמתאימה למה שבאמת נצפה.

flowchart TB
    accTitle: שלוש תוצאות שמצביעות על קשר לתנאי
    accDescr: אם הבעיה משתחזרת בתנאים המקוריים, משתפרת כשמשנים תנאי אחד ומשתחזרת שוב כשמחזירים אותו, זה רמז לקשר עם התנאי, אבל עדיין לא קביעה של הסיבה.
    A["משתחזר בתנאים המקוריים"] --> B["משתפר כשמשנים תנאי אחד"]
    B --> C["משתחזר כשמחזירים"]
    C --> D["רמז לקשר עם התנאי"]

איור 10: גם כשכל השלוש מתקיימות, מה שיש לכם הוא רמז לקשר, לא יותר.

ניצולת CPU נמוכה היא לא הוכחה שה-deadline של האודיו נשמר. מצד שני, עצם העובדה שהייתה קטיעה לא מוכיחה שעיכוב במילוי היה ה-root cause. משווים את מקור האודיו, העיבוד באפליקציה, האפקטים, נתיב הפלט ועוד, ומסיקים רק בגבולות מה שנצפה. Fix distorted or crackling audio in Windows

כשמאמצים workaround זמני, מתעדים את ההגדרה המקורית, מה שונה, את זמן התצפית, אם הבעיה חזרה, ואיזו השהיה מקובלת. אם ה-root cause עדיין לא ידוע, רושמים גם את זה.

הקלטת הקטיעה עם WPR

את השלב הזה מבצעים כשהשוואת התנאים לבדה לא מספיקה כדי לצמצם, או כשרוצים לחקור את העיבוד בצד הדרייבר. WPR הוא כלי להקלטה, ו-WPA הוא כלי לניתוח ציר הזמן שנשמר. מכינים את Windows Performance Toolkit, את ההרשאות הדרושות להקלטה ומקום לשמירת קובץ ה-ETL. כדי להתקין את הכלים ולהקליט במחשב מנוהל, פנו למנהל המערכת. את שמות התצוגה ואת ה-profiles הזמינים בודקים בגרסה שהותקנה. Windows Performance Recorder

קובץ ETL עשוי לכלול שמות process, נתיבי קבצים ומידע נוסף. לפני ההקלטה בדקו את הכללים בארגון ועם מי מותר לשתף, ואל תצרפו את הקובץ כמו שהוא למקום ציבורי. אם רץ session הקלטה אחר, אל תעצרו אותו על דעת עצמכם, אלא בדקו קודם עם האחראי. WPR How-to Topics

1. ב-WPR פותחים את “More Options” ובוחרים profile הקלטה שמתאים למטרה.

   בין ה-profiles המובנים יש “Audio glitches” ו-“CPU usage”. בוחרים הגדרה שמאפשרת לבדוק גם את אי-הרציפות באודיו וגם את הפעילות של ה-CPU. את ה-profiles הזמינים, את שמות התצוגה ואת מה שנאסף בודקים בגרסה שהותקנה, ולא מגדירים הקלטה ארוכה של כל הסוגים. 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["zoom ב-WPA לקטע סביב הקטיעה"]

איור 11: לא מספיק להסתכל על ניצולת ה-CPU אחרי שהסימפטום חלף. צריך הקלטה של הקטע שבו הוא התרחש.

ריצה והמתנה סביב הקטיעה

מכינים את קובץ ה-ETL שנשמר ואת ההערות על שעת השחזור. מה שמופיע כאן הוא נקודת פתיחה לחקירה ב-WPA. אם צריך ניתוח מפורט יותר, כולל stacks ו-symbols, מעבירים אותו למנהל המערכת או למפתחים, ומקפידים על אופן הטיפול בהקלטה.

1. פותחים את ה-ETL ב-WPA, ועל סמך אירועי האודיו שנאספו ושעת השחזור עושים zoom לקטע שלפני הקטיעה ואחריה.

   משאירים גם קטע בלי סימפטום לצורך השוואה. לא מסתכלים רק על דירוג הערכים המקסימליים, אלא משווים על אותו טווח זמן.

2. באותו טווח בודקים את “DPC/ISR” ואת “CPU Usage (Precise)”.

   אם הנתונים הדרושים חסרים, בודקים אם ה-profile אוסף אותם וחוזרים להקלטה ב-WPR. זה שאין נתונים לא אומר שלא הייתה בעיה. CPU Analysis, Built-in Recording Profiles

3. מבחינים אם ה-thread שקשור לאודיו היה מוכן לריצה אבל חיכה לתורו, או שחיכה לנתונים או למשהו אחר.

   במקרה הראשון, מצליבים כדי לבדוק אם DPC/ISR או עיבוד דומה רצו זמן רב על ה-logical CPU הרלוונטי. במקרה השני, עוקבים בעזרת האירועים וה-stacks שנאספו אחרי מה ששחרר את ההמתנה. כיוון ש-thread שרץ עלול להיעצר בגלל interrupt, לא מסתפקים בזמן ה-Ready, אלא מניחים עליו גם את קטעי ה-DPC/ISR. CPU Analysis

4. מתעדים יחד את ההתאמה בזמן לקטיעה, את ה-CPU הרלוונטי ואת התוצאות של שינוי התנאים.

   לא קובעים שהתקן או דרייבר מסוים הוא הסיבה רק לפי שם ה-module של DPC/ISR ארוך. ייתכן שאתם מסתכלים על ערך גבוה מזמן אחר, או על רכיב משותף שכמה התקנים עוברים דרכו.

flowchart TB
    accTitle: בודקים את סוג ההמתנה בקטע של הקטיעה
    accDescr: עושים zoom לקטע שלפני הקטיעה ואחריה ובודקים את מצב ה-thread של האודיו. אם הוא היה מוכן לריצה וחיכה לתורו מצליבים עם DPC ו-ISR על אותו CPU, ואם הוא חיכה לנתונים או למשהו דומה עוקבים אחרי מה ששחרר את ההמתנה.
    A["zoom לקטע סביב הקטיעה"] --> B{"מצב ה-thread"}
    B -->|"חיכה לתור"| C["DPC ו-ISR"]
    B -->|"חיכה לנתונים"| D["מה ששחרר את ההמתנה"]

איור 12: לא מסתפקים בערכים המקסימליים. קוראים אותם על רקע הקטע שבו עיבוד האודיו היה צריך לרוץ.

אם לא הצלחתם לזהות את הסיבה, מעבירים את החקירה הלאה כשהיא מסומנת כלא פתורה. מצרפים את הגרסאות של מערכת ההפעלה, האפליקציה, ההתקן והדרייבר, את שלבי השחזור, את התוצאות לפני השינוי ואחריו, את שעת ההתרחשות, את ה-profile שבו נאסף המידע, ואם הייתה אזהרה על אירועים שאבדו. את ה-ETL משתפים לפי הכללים בארגון, ורק עם מי שאחראי על החקירה.

טעינה מראש באפליקציות אודיו

אם אתם מפתחים אפליקציית אודיו בעצמכם, תכננו אותה כך שהעיבוד שממלא את ה-buffer הבא יעמוד ב-deadline בכל פעם. ב-WASAPI יש דרך לקבל event שמסמן מתי אפשר לעבד את ה-buffer. Exclusive-Mode Streams

MMCSS הוא מנגנון שמקצה משאבי CPU ל-threads של עיבוד מולטימדיה עם אילוצי זמן. אין בו יכולת להכין נתונים מהדיסק מראש או לבטל המתנות ל-locks. גם כשמשתמשים בהקצאה של MMCSS, עדיין צריך בנפרד תכנון שמכין את הנתונים ומצמצם המתנות. Multimedia Class Scheduler Service

flowchart TB
    accTitle: על מה MMCSS אחראי
    accDescr: MMCSS מקצה משאבי CPU ל-threads של עיבוד עם אילוצי זמן, אבל הכנת הנתונים וצמצום ההמתנות ל-locks נעשים בתכנון נפרד.
    M["MMCSS: מקצה משאבי CPU"] -.->|"נדרש בנפרד"| D["הכנת נתונים וצמצום המתנות"]

איור 13: הקצאת משאבי CPU ותכנון שמביא את הנתונים בזמן הן שתי משימות נפרדות.

עקרון התכנון הוא להפריד בין העיבוד שקורא מקבצים או מהרשת לבין העיבוד שמעביר את האודיו. הכנות שקשה לצפות כמה זמן ייקחו מבצעים מראש, ולהעברה משתמשים ב-buffer שהוקצה מראש. בצד האודיו בונים את הקוד כך שלא יצטרך לחכות לתשובה מה-UI, ל-locks ארוכים או לכתיבת לוג סינכרונית.

flowchart TB
    accTitle: מפרידים בין הכנות שזמנן לא צפוי לבין אספקת האודיו
    accDescr: תכנון שבו קריאה ופעולות דומות נעשות בעיבוד מקדים, והנתונים שהוכנו מועברים לעיבוד האודיו דרך buffer, כדי לצמצם המתנות ארוכות ממש לפני ה-deadline.
    A["עיבוד מקדים מכין נתונים"] --> B["אזור העברה שהוקצה מראש"]
    B --> C["עיבוד האודיו מעביר את הכמות הדרושה"]
    C --> D["אספקה ליעד הפלט של האודיו"]

איור 14: מוציאים עבודה שלוקחת זמן מהרגע שלפני העברת האודיו.

אם צד ההכנה נעצר לזמן ארוך, ה-buffer יתרוקן גם עם ההפרדה הזו. מתעדים לא רק את זמן העיבוד הממוצע, אלא גם את הפעמים שבהן היה עיבוד או המתנה ארוכים ואת מספר הפעמים שבהן לא הייתה אספקה, בדרך שלא מפריעה לעיבוד האודיו. את גודל ה-buffer ואת המחזור שנבחרו בפועל בודקים דרך ה-API או הדרייבר, ולא מניחים שהערך שביקשתם נקבע כמו שהוא. Rendering a Stream, Low Latency Audio

הדוגמאות המספריות ודוגמאות התכנון נועדו להסבר בלבד. הן לא ערכי הגדרה מומלצים להתקן מסוים, ולא הבטחה שלא יהיו קטיעות בכל סביבה.

ההשפעה של עדיפות Realtime

לא ממליצים באופן גורף שמשתמשים יעבירו את כל הנגן לעדיפות “Realtime”. יש סיכון שזה יפריע לעיבוד חשוב אחר, והעלאת העדיפות של thread רגיל לא פותרת המתנות שנגרמות מ-DPC/ISR או מהמתנה לנתונים ול-locks. בפיתוח משתמשים במנגנונים כמו MMCSS ובתכנון שלא מכניס המתנות ארוכות לאספקת האודיו. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: ההמתנות שנשארות גם בעדיפות Realtime
    accDescr: גם כשמעבירים את הנגן לעדיפות Realtime, thread רגיל לא יכול לעקוף DPC ו-ISR על אותו CPU, ההמתנות לנתונים ול-locks נשארות, ויש גם סיכון להפריע לעיבוד חשוב אחר.
    A["מעבירים את הנגן לעדיפות Realtime"] --> B["אי אפשר לעקוף DPC ו-ISR"]
    B --> C["גם המתנות לנתונים ול-locks נשארות"]
    C --> D["סיכון להפריע לעיבוד אחר"]

איור 15: גם אחרי העלאת העדיפות, ההמתנות שמעכבות את מילוי האודיו נשארות.

מאמרים קשורים

• Processor scheduling ב-Windows והגדרת Background services
• בידוד בטוח של דיסק ב-100% ב-Windows
• למה RDP איטי כשהחיבור מהיר?

מקורות

• Microsoft Learn, Rendering a Stream. אספקה ל-buffer הניגון, הכמות שנותרה בו, גודל ה-buffer בפועל, וההגדרה של frame ב-PCM.
• Microsoft Learn, Exclusive-Mode Streams. תזמון האספקה ל-buffer ו-glitches באודיו, האיזון מול ההשהיה, ואספקה מבוססת events. אין כאן המלצה גורפת על exclusive mode עצמו.
• Microsoft Learn, Low Latency Audio. נתיב האודיו ב-Windows, ה-buffers, ההתקנים ועיבוד האפקטים וההשפעה שלהם על ההשהיה, וה-trade-offs של low latency.
• Microsoft Learn, CPU Analysis. logical CPUs, המצבים Ready/Waiting של threads, הקשר בין DPC/ISR לריצת threads, וניתוח CPU ב-WPA.
• Microsoft Learn, Introduction to DPCs. המנגנון שמקצר את הטיפול ב-interrupt ודוחה את שארית העבודה ל-DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPC/ISR ארוכים ותכופים, אספקת נתונים לא מספקת ו-glitches באודיו. את ערכי האזהרה של ההערכה לא מכלילים לסף בטיחות לכל ההתקנים.
• Microsoft Support, Fix distorted or crackling audio in Windows. בדיקה של audio enhancements, של הפורמט, של הדרייברים ועוד.
• Microsoft Learn, Windows Performance Recorder. הקלטת ETW, ניתוח עם WPA ושימוש ב-Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options ב-WPR, וה-profiles המובנים כמו Audio glitches ו-CPU usage.
• Microsoft Learn, WPR How-to Topics. התחלת הקלטה ושמירה עם Save, התנגשות עם sessions קיימים, ותשומת לב למידע אישי ולאירועים שאבדו.
• Microsoft Learn, Multimedia Class Scheduler Service. הקצאת משאבי CPU לעיבוד מולטימדיה עם אילוצי זמן.
• Microsoft Learn, Scheduling Priorities. העדיפויות של processes ו-threads, ואזהרות לגבי עדיפות Realtime.

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

אלה דפי נושא הקרובים לנושא הזה. מהמאמר אפשר להמשיך לשירותים קשורים ולמאמרים אחרים.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בהתייעצויות בנושא המאמר.

למה האודיו נקטע כשניצולת ה-CPU היא רק בסביבות 10%?

לאודיו יש deadline: צריך למלא את הנתונים הבאים לפני שהנתונים שמתנגנים עכשיו נגמרים. גם כשהניצולת הכוללת של ה-CPU נמוכה, המילוי עלול לא להגיע בזמן אם עיבוד האודיו לא הצליח לרוץ באותו רגע, או שחיכה לנתונים שהוא צריך. לא כל קטיעה נובעת מהסיבה הזו, ולכן צריך גם השוואות שבהן מחליפים את התקן הפלט או את האפליקציה.

האם buffer אודיו גדול יותר יפתור את הקטיעות?

כשהמילוי מתעכב באופן זמני, buffer גדול יותר יכול לפעמים לספוג את העיכוב. אבל גם זמן ההמתנה עד שהאודיו שנצבר מתנגן גדל. זו לא הגדרה שפותרת גם מחסור מתמשך בכוח עיבוד או ניתוק של ההתקן. באפליקציות ובדרייברים שמאפשרים לשנות את הערך, רושמים את הערך המקורי ומשווים שלב אחד בכל פעם.

כמה מילישניות של אודיו הם 480 frames ב-48kHz?

480÷48000 שניות, כלומר 10 מילישניות. frame אחד של PCM הוא היחידה שמאגדת את ה-samples של כל הערוצים באותה נקודת זמן. הערך הזה הוא אורך האודיו שמספר ה-frames הזה מייצג, ולא ההשהיה הכוללת, שכוללת גם את ההתקן ואת האפליקציה.

האם דרייבר עם זמני ריצה ארוכים של DPC או ISR הוא האשם בקטיעות?

הוא יכול להיות חשוד, אבל דירוג לפי זמן ריצה לבדו לא מספיק כדי לקבוע. מצליבים את קטע הזמן שבו התרחשה הקטיעה עם ההמתנות של ה-thread של האודיו ועם הריצה של DPC/ISR על אותו CPU. לא קובעים לפי שם ה-module בלבד שיש תקלה בהתקן או בדרייבר מסוים, ובודקים גם את התוצאות של שינוי תנאי השחזור.

האם העברת הנגן לעדיפות Realtime תשפר את המצב?

לא ממליצים על זה באופן גורף. העלאת העדיפות של thread רגיל לא מאפשרת לו לעקוף DPC-ים ו-ISR-ים רגילים על אותו CPU, וגם לא מעלימה המתנות לנתונים או ל-locks. מפתחים משתמשים במנגנונים כמו MMCSS ובתכנון שלא מכניס המתנות, ומשתמשים משווים קודם את תנאי השחזור ואת נתיב הפלט.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

נציג KomuraSoft LLC

מתמקד בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, וחזק במיוחד בפרויקטים שבהם נותרו נכסים קיימים ובחקירת תקלות שגורמן קשה לזיהוי.