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

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

בא לכם לשאול: “עם כל כך הרבה מרווח, להשמיע אודיו זה יותר מדי לבקש?”

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

מתחילים מסצנה של ניגון מוזיקה ב-PC. פרקים 1 עד 4 מסיימים את הדיון במנגנון, ומפרק 5 ואילך מרוכזות שיטות החקירה. ההנחה היא פלט אודיו ב-Windows 11, והמספרים הם הנחות לצורך ההסבר.

1. האודיו מתנגן בזמן שקטע קטן מההמשך מוחזק מראש

קובץ מוזיקה שנשמר ב-PC לא מנגן ברמקולים רק מעצם זה שהוא נמצא שם. אפליקציית הניגון מכינה את נתוני האודיו ומעבירה אותם, דרך Windows והדרייבר, אל ההתקן שמייצר את הצליל. במצב shared mode הרגיל, מנוע האודיו של Windows ממזג כמה streams ומחיל effects בדרך.²

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

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

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

נניח שב-buffer נשארו כרגע 10 מילישניות של אודיו. אם המילוי מחדש הבא מגיע בעוד 8 מילישניות, הוא מתחבר כל עוד נשאר משהו. אבל אם עד 12 מילישניות לא מגיע דבר, המלאי נגמר בסימן של 10 מילישניות.

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

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

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

ניגון אודיו הוא עיבוד שבו “בסוף זה חושב” אינו מספיק; מה שנדרש הוא “זה היה מוכן עד הרגע שבו היה צריך להישמע”.

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

2. למה המילוי מחדש מאחר גם כשה-CPU לא עסוק

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

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

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

לא חישוב איטי, אלא המתנה להזדמנות לרוץ

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

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

איור 3: “לא לנצל את ה-CPU” אינו אותו דבר כמו “העבודה הנדרשת הסתיימה”.

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

יש מקרה שני, שבו התור לא מגיע בצד של Windows.

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

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

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

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

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

3. אז למה לא פשוט לצבור הרבה אודיו מראש?

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

באותם תנאים, החזקה של יותר אודיו מראש מקלה לעבור איחורי מילוי קצרים. אבל עכשיו אודיו שנוצר עכשיו ממתין מאחורי האודיו שכבר מוחזק מראש.¹²

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

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

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

גם הגדרות ה-buffer שמופיעות בתוכנות להפקת מוזיקה כ-“128”, “256” ו-“512” קשורות לזמן הזה. ב-PCM, היחידה שמאגדת את ה-samples של כל הערוצים באותו רגע נקראת frame. ב-48kHz, 480 frames הם 480 חלקי 48000 שניות, כלומר 10 מילישניות של אודיו. באותו sample rate, ככל שמספר ה-frames גדול יותר, כך קטע האודיו שהם מחזיקים ארוך יותר.³

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

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

4. מה שאודיו צריך זה לעמוד ב-deadline, לא מהירות ממוצעת

חוזרים לשאלה הראשונה.

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

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

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

5. חקירה: קודם כל, לברר באיזה שילוב יש קטיעות

“פופ” ששמעתם אינו מוכיח בעצמו את ה-underrun שתואר עד כאן. גם המקור עצמו, העיבוד של האפליקציה, אפקטי האודיו, התקן הפלט ובעיות אחרות יוצרים סימפטום דומה. גם בחומרי הטיפול של Microsoft מופיעים audio enhancements, ה-format והדרייברים בין הדברים שצריך לבדוק.⁷

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

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

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

איור 6: במקום שיפור חד-פעמי, מאמתים שהתנאי והסימפטום תואמים זה לזה שוב ושוב.

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

כדי להשוות audio enhancements, בוחרים ב-Windows את ה-output הרצוי תחת Settings > System > Sound, ובסביבות שבהן זה זמין מכבים את Audio enhancements ומנסים שוב. רושמים את ההגדרה המקורית, ואם אין הבדל מחזירים אותה. את הדרייברים לוקחים מ-Windows Update או מהפצה רשמית של יצרן ההתקן, ורושמים את הגרסאות לפני ואחרי השינוי.⁷

6. חקירה: לתעד את הרגע שבו נקטע ולהתמקד בו

כשהשוואת התנאים לא מצמצמת את הבעיה, או כשחושדים בעיבוד בצד הדרייבר, מצלמים את מה שקורה בפרק זמן קצר. Windows Performance Recorder (WPR) מבצע את הצילום, ו-Windows Performance Analyzer (WPA) הוא הכלי לבחינת ציר הזמן שנוקלט בפירוט.⁸

להתחיל לצלם לפני השחזור

במחשב שבו מותקן Windows Performance Toolkit, פותחים את More Options בחלון של WPR. בין ה-profiles המובנים יש Audio glitches ו-CPU usage. בוחרים צילום שמאפשר לבחון את אי-הרציפות באודיו יחד עם פעילות ה-CPU, כשה-Audio glitches במרכז. את ה-profiles הזמינים ואת שמות התצוגה שלהם בודקים בגרסה שמותקנת אצלכם.⁹

מתחילים את הצילום, ואז מנגנים אודיו בתנאים שמצאתם קודם. רושמים את הזמנים שבהם נקטע ואת מה שעשיתם, ואחרי השחזור מסיימים את הצילום עם Save כדי לכתוב את קובץ ה-ETL. Cancel לא שומר אותו. שילוב של קטע נקי קצר נותן בסיס להשוואה. אם מופיעה הודעה שמבקשת לעצור צילום קיים, מבטלים את ההתחלה ובודקים עם האחראי, כדי לא לקטוע חקירה אחרת.¹⁰

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

איור 7: שומרים את הקטע שבו הופיע הסימפטום, לא את השימוש ב-CPU אחרי שהוא נגמר.

קובץ ETL יכול להכיל שמות processes ונתיבי קבצים וכדומה, ולכן פועלים לפי כללי הארגון ומשתפים אותו רק עם מי שצריך. צילום עשוי לדרוש הרשאות או כלים נוספים; ב-PC של החברה מבקשים ממנהל מערכת. מפני שעומס הצילום עצמו יכול לשנות את הסימפטום, רושמים אם צילום היה פעיל. עדיף צילום קצר שמתאים למטרה על פני צילום ארוך עם כל ה-providers. בצילום שמדווח על אירועים שאבדו, לא מסיקים שהקטעים שלא רואים בריאים.¹⁰

מה קרה באותו זמן, ולא דירוג של מספרים גדולים

ב-WPA מתמקדים בקטע שלפני ואחרי הקטיעה, לפי אירועי האודיו שנקלטו ולפי הזמנים שרשמתם. באותו טווח זמן בודקים את DPC/ISR ואת CPU Usage (Precise), שמראה הרצה והמתנה של threads. אם הנתונים האלה חסרים, בודקים אם ה-profile אוסף את האירועים הנדרשים ומצלמים שוב. היעדר רשומות אינו אותו דבר כמו היעדר בעיה.⁴⁹

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

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

איור 8: לא לשלוף רק את ערכי השיא, אלא לקרוא אותם בהצמדה לקטע שבו עיבוד האודיו היה נדרש.

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

בנוסף, אי אפשר לקבוע סף אחיד כמו “DPC מתחת לכמה מיקרושניות לא גורם לקטיעות בשום PC”. ערכי האזהרה שבמסמכים מותנים באותה הערכה. לא משתמשים בהם כקריטריון עובר/נכשל מנותק מה-deadline האמיתי של המילוי מחדש ומהמרווח ב-buffer.⁵

7. למפתחים: לא להכניס המתנות ארוכות לקוד שמוסר את האודיו

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

ב-WASAPI יש דרך לקבל כאירוע את העיתוי שבו אפשר לעבד buffer. שימוש ב-MMCSS, בתורו, מקל לתת זמן CPU ל-threads של עיבוד מולטימדיה עם מגבלת זמן. אבל אלה אינם קסם שמסלק המתנות. גם MMCSS לא יכין עבורכם מראש את נתוני האודיו מהדיסק.¹¹¹

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

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

איור 9: המטרה אינה לבטל עבודה איטית, אלא להוציא אותה מהרגע שלפני מסירת האודיו.

גם עם ההפרדה הזאת, המלאי נגמר אם צד ההכנה נתקע זמן ארוך. מעבר לזמן העיבוד הממוצע, רושמים — בדרך שלא מפריעה לעיבוד האודיו — את הפעמים שבהן עיבוד או המתנה נמשכו זמן ארוך, ואת מספר הפעמים שהאספקה נכשלה. את גודל ה-buffer וה-period שנבחרו בפועל בודקים דרך ה-API או הדרייבר, ולא מניחים ש”הערך שהגדרתי אומץ כמו שהוא”.³²

נמנעים גם מלהמליץ למשתמשים להגדיר את כל ה-player לעדיפות realtime. יש בכך סיכון להפריע לעבודה חשובה אחרת, והעלאת העדיפות של thread רגיל לא פותרת DPC-ים, ISR-ים או המתנות על נתונים.¹²⁴

8. סיכום: שימוש נמוך ב-CPU אינו הוכחה שה-deadline של האודיו נשמר

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

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

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

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

מקורות

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

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

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

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

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

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

שאלות נפוצות

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

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

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

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

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

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

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

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

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

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

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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