גורמים שמשפיעים על זמן האחזור של האודיו

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

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

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

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

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

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

מהניסיון שלנו, הסיבות הנפוצות ביותר לחריגות של זמן ריצה קצר או ארוך מדי הן:

• Linux CFS‏ (Completely Fair Scheduler)
• שרשור בעדיפות גבוהה עם תזמון SCHED_FIFO
• היפוך עדיפות
• זמן אחזור ארוך לתזמון
• טיפולי השהיה ממושכים
• long interrupt disable time
• ניהול צריכת החשמל
• ליבות אבטחה

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

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

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

תזמון מונוטוני של קצב שליחת בקשות

למידע נוסף על התיאוריה של הקצאת תעדוף קבוע, תוכלו לקרוא את המאמר Rate-monotonic scheduling (RMS) ב-Wikipedia. חשוב לזכור שעדיפות קבועה צריכה להיות מוקצית אך ורק על סמך פרק הזמן, וצריך להקצות עדיפות גבוהה יותר לשרשור עם פרק זמן קצר יותר, ולא על סמך 'חשיבות' משוערת. אפשר ליצור מודל של חוטים לא תקופתיים כחוטים תקופתיים, באמצעות תדירות הביצוע המקסימלית והחישוב המקסימלי לכל ביצוע. אם לא ניתן ליצור מודל של חוט לא תקופתי כחוט תקופתי (לדוגמה, הוא יכול לפעול בתדירות בלתי מוגבלת או בזמן חישוב בלתי מוגבל לכל הפעלה), אין להקצות לו עדיפות קבועה כי זה לא תואם לתזמון של חוטים תקופתיים אמיתיים.

היפוך עדיפות

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

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

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

הפסקות

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

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

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

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

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

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

ליבות אבטחה

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