תורמים להשהיית אודיו

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

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

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

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

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

מניסיוננו, הגורמים הנפוצים ביותר לחריגים וחריגים כוללים:

• Linux CFS (מתזמן הוגן לחלוטין)
• שרשורים בעדיפות גבוהה עם תזמון SCHED_FIFO
• היפוך עדיפות
• חביון תזמון ארוך
• מטפלי פסיקות ארוכות טווח
• זמן השבתת הפסקה ארוך
• ניהול צריכת חשמל
• גרעיני אבטחה

תזמון CFS ו-SCHED_FIFO של Linux

Linux CFS נועד להיות הוגן לעומסי עבודה מתחרים החולקים משאב CPU משותף. ההגינות הזו מיוצגת על ידי פרמטר נחמד לכל חוט. הערך הנחמד נע בין -19 (הכי פחות נחמד, או מוקצה הכי הרבה זמן CPU) ל-20 (הכי נחמד, או לפחות זמן CPU שהוקצה). באופן כללי, כל השרשורים עם ערך נחמד נתון מקבלים זמן מעבד שווה בערך, והשרשורים עם ערך נחמד מספרית נמוך יותר צריכים לצפות לקבל יותר זמן מעבד. עם זאת, CFS הוא "הוגן" רק על פני תקופות ארוכות יחסית של תצפית. במהלך חלונות תצפית קצרי טווח, CFS עשוי להקצות את משאב ה-CPU בדרכים בלתי צפויות. לדוגמה, זה עשוי להרחיק את ה-CPU מחוט עם נוחות מספרית נמוכה אל חוט עם יופי גבוה מספרית. במקרה של אודיו, זה יכול לגרום לאי-דריסה או לחריגה.

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

היפוך עדיפות

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

תזמון זמן אחזור

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

מפריע

בעיצובים רבים, CPU 0 משרת את כל ההפרעות החיצוניות. כך שמטפל בפסיקות ארוכות טווח עשוי לעכב פסיקות אחרות, בפרט פסיקות להשלמת גישה לזיכרון ישיר לשמע (DMA). תכנן מטפלי פסיקה לסיים במהירות ולדחות עבודה ממושכת לשרשור (רצוי שרשור CFS או שרשור SCHED_FIFO בעדיפות 1).

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

כוח, ביצועים וניהול תרמי

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

• קנה מידה מתח דינמי
• קנה מידה דינמי של תדרים
• מאפשר ליבה דינמית
• החלפת אשכולות
• שער כוח
• hotplug (החלפה חמה)
• מצבי שינה שונים (עצירה, עצירה, סרק, השהייה וכו')
• תהליך הגירה
• זיקה למעבד

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

גרעיני אבטחה

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