ผู้มีส่วนทำให้เกิดความล่าช้าของเสียง

หน้านี้มุ่งเน้นไปที่ผู้มีส่วนร่วมในเวลาแฝงของเอาท์พุต แต่มีการสนทนาที่คล้ายกันกับเวลาแฝงของอินพุต

สมมติว่าวงจรแอนะล็อกไม่ได้มีส่วนช่วยอย่างมีนัยสำคัญ ดังนั้นปัจจัยหลักในระดับพื้นผิวต่อความหน่วงของเสียงมีดังนี้:

• แอปพลิเคชัน
• จำนวนบัฟเฟอร์ทั้งหมดในไปป์ไลน์
• ขนาดของแต่ละบัฟเฟอร์ในเฟรม
• เวลาแฝงเพิ่มเติมหลังจากโปรเซสเซอร์แอป เช่น จาก DSP

แม้ว่ารายชื่อผู้ร่วมให้ข้อมูลข้างต้นจะมีความถูกต้องแม่นยำ แต่ก็ทำให้เข้าใจผิดเช่นกัน เหตุผลก็คือจำนวนบัฟเฟอร์และขนาดบัฟเฟอร์มี ผลกระทบ มากกว่า สาเหตุ สิ่งที่มักจะเกิดขึ้นคือมีการใช้และทดสอบรูปแบบบัฟเฟอร์ที่กำหนด แต่ในระหว่างการทดสอบ เสียงที่ดังเกินหรือดังเกินไปจะได้ยินเป็น "คลิก" หรือ "ป๊อป" เพื่อเป็นการชดเชย ผู้ออกแบบระบบจึงเพิ่มขนาดบัฟเฟอร์หรือจำนวนบัฟเฟอร์ สิ่งนี้ให้ผลลัพธ์ที่ต้องการในการกำจัดอันเดอร์รันหรือโอเวอร์รัน แต่ก็มีผลข้างเคียงที่ไม่พึงประสงค์จากการเพิ่มเวลาแฝงด้วย สำหรับข้อมูลเพิ่มเติมเกี่ยวกับขนาดบัฟเฟอร์ โปรดดูวิดีโอ เวลาแฝงของเสียง: ขนาดบัฟเฟอร์

แนวทางที่ดีกว่าคือการทำความเข้าใจสาเหตุของการ underrun และ overrun แล้วจึงแก้ไขสาเหตุเหล่านั้น วิธีนี้จะกำจัดสิ่งแปลกปลอมที่ได้ยินและอาจอนุญาตให้มีบัฟเฟอร์น้อยลงหรือน้อยลง ดังนั้นจึงลดเวลาแฝง

จากประสบการณ์ของเรา สาเหตุที่พบบ่อยที่สุดของการวิ่งเกินและการวิ่งเกิน ได้แก่:

• Linux CFS (ตัวกำหนดเวลาที่ยุติธรรมอย่างสมบูรณ์)
• เธรดที่มีลำดับความสำคัญสูงพร้อมการกำหนดเวลา SCHED_FIFO
• การผกผันลำดับความสำคัญ
• เวลาแฝงของการกำหนดเวลาที่ยาวนาน
• ตัวจัดการการขัดจังหวะที่ทำงานยาวนาน
• เวลาปิดการใช้งานขัดจังหวะนาน
• การจัดการพลังงาน
• เคอร์เนลความปลอดภัย

การกำหนดเวลา Linux CFS และ SCHED_FIFO

Linux CFS ได้รับการออกแบบมาให้ยุติธรรมกับปริมาณงานที่แข่งขันกันซึ่งใช้ทรัพยากร CPU ร่วมกัน ความเป็นธรรมนี้แสดงโดยพารามิเตอร์ nice ต่อเธรด ค่าที่ดีมีตั้งแต่ -19 (ดีน้อยที่สุด หรือจัดสรรเวลา CPU ส่วนใหญ่) ถึง 20 (ดีที่สุด หรือจัดสรรเวลา CPU น้อยที่สุด) โดยทั่วไป เธรดทั้งหมดที่มีค่า nice ที่กำหนดจะได้รับเวลา CPU เท่ากันโดยประมาณ และเธรดที่มีค่า nice ต่ำกว่าควรคาดหวังว่าจะได้รับเวลา 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 สำหรับเธรดที่รับประกันว่าจะเสร็จสิ้นภายในระยะเวลาที่กำหนด ดำเนินการด้วยช่วงเวลาที่สั้นกว่าระยะเวลาของเธรดเสียง และเป็นที่ทราบกันว่าไม่รบกวนการกำหนดเวลา ของเธรดเสียง

การกำหนดเวลาแบบอัตราเดียว

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับทฤษฎีการกำหนดลำดับความสำคัญคงที่ ดูบทความ Wikipedia Rate-monotonic scheduling (RMS) ประเด็นสำคัญคือลำดับความสำคัญคงที่ควรได้รับการจัดสรรอย่างเคร่งครัดตามระยะเวลา โดยมีลำดับความสำคัญที่สูงกว่าที่กำหนดให้กับเธรดที่มีระยะเวลาสั้นกว่า ไม่ใช่ขึ้นอยู่กับการรับรู้ "ความสำคัญ" เธรดที่ไม่ใช่เป็นระยะอาจถูกสร้างแบบจำลองเป็นเธรดเป็นระยะ โดยใช้ความถี่สูงสุดของการดำเนินการและการคำนวณสูงสุดต่อการดำเนินการ หากไม่สามารถจำลองเธรดที่ไม่ใช่ตามระยะเวลาเป็นเธรดตามระยะเวลาได้ (เช่น สามารถดำเนินการด้วยความถี่ที่ไม่มีขอบเขตหรือการคำนวณที่ไม่มีขอบเขตต่อการดำเนินการ) ก็ไม่ควรกำหนดลำดับความสำคัญคงที่ เนื่องจากจะไม่เข้ากันกับการกำหนดเวลาของเธรดตามระยะเวลาจริง .

การกลับลำดับความสำคัญ

การผกผันลำดับความสำคัญ เป็นโหมดความล้มเหลวแบบคลาสสิกของระบบเรียลไทม์ โดยที่งานที่มีลำดับความสำคัญสูงกว่าจะถูกบล็อกเป็นเวลาที่ไม่มีขอบเขตเพื่อรอให้งานที่มีลำดับความสำคัญต่ำกว่าปล่อยทรัพยากร เช่น (สถานะที่ใช้ร่วมกันที่ได้รับการป้องกันโดย) mutex ดูบทความ " การหลีกเลี่ยงการผกผันลำดับความสำคัญ " เพื่อดูเทคนิคในการบรรเทาปัญหา

กำหนดเวลาแฝง

เวลาแฝงในการจัดกำหนดการคือเวลาระหว่างเวลาที่เธรดพร้อมที่จะรันและเมื่อการสลับบริบทที่เป็นผลลัพธ์เสร็จสมบูรณ์ เพื่อให้เธรดทำงานบน CPU จริง ยิ่งเวลาแฝงสั้นลงก็ยิ่งดี และอะไรก็ตามที่เกินสองมิลลิวินาทีจะทำให้เกิดปัญหากับเสียง เวลาแฝงของการกำหนดตารางเวลาที่ยาวนานมักจะเกิดขึ้นในระหว่างการเปลี่ยนโหมด เช่น การเปิดหรือปิด CPU การสลับระหว่างเคอร์เนลการรักษาความปลอดภัยและเคอร์เนลปกติ การสลับจากโหมดพลังงานเต็มเป็นโหมดพลังงานต่ำ หรือการปรับความถี่สัญญาณนาฬิกาของ CPU และแรงดันไฟฟ้า .

ขัดจังหวะ

ในการออกแบบหลายๆ แบบ CPU 0 ให้บริการการขัดจังหวะภายนอกทั้งหมด ดังนั้นตัวจัดการการขัดจังหวะที่ทำงานเป็นเวลานานอาจชะลอการขัดจังหวะอื่นๆ โดยเฉพาะอย่างยิ่งการขัดจังหวะการเข้าถึงหน่วยความจำโดยตรงของเสียง (DMA) ออกแบบตัวจัดการการขัดจังหวะเพื่อให้เสร็จสิ้นอย่างรวดเร็วและเลื่อนการทำงานที่มีความยาวไปยังเธรด (ควรเป็นเธรด CFS หรือเธรด SCHED_FIFO ที่มีลำดับความสำคัญ 1)

ในทำนองเดียวกัน การปิดใช้งานการขัดจังหวะบน CPU 0 เป็นเวลานานจะมีผลเช่นเดียวกันกับการชะลอการให้บริการการขัดจังหวะทางเสียง โดยทั่วไปเวลาปิดการใช้งานการขัดจังหวะที่นานจะเกิดขึ้นในขณะที่รอ การล็อคการหมุน ของเคอร์เนล ตรวจสอบตัวล็อคการหมุนเหล่านี้เพื่อให้แน่ใจว่ามีขอบเขตอยู่

การจัดการพลังงาน ประสิทธิภาพ และระบายความร้อน

การจัดการพลังงาน เป็นคำกว้างๆ ที่ครอบคลุมถึงความพยายามในการตรวจสอบและลดการใช้พลังงานไปพร้อมๆ กับการเพิ่มประสิทธิภาพการทำงาน การจัดการระบายความร้อน และ การระบายความร้อนของคอมพิวเตอร์ มีความคล้ายคลึงกัน แต่พยายามวัดและควบคุมความร้อนเพื่อหลีกเลี่ยงความเสียหายเนื่องจากความร้อนส่วนเกิน ในเคอร์เนล Linux CPU Governor มีหน้าที่รับผิดชอบนโยบายระดับต่ำ ในขณะที่โหมดผู้ใช้จะกำหนดค่านโยบายระดับสูง เทคนิคที่ใช้ได้แก่:

• สเกลแรงดันไฟฟ้าแบบไดนามิก
• การปรับความถี่แบบไดนามิก
• การเปิดใช้งานคอร์แบบไดนามิก
• การสลับคลัสเตอร์
• ประตูพลังงาน
• ฮอตปลั๊ก (ฮอตสวอป)
• โหมดสลีปต่างๆ (หยุด, หยุด, ไม่ได้ใช้งาน, หยุดชั่วคราว ฯลฯ)
• กระบวนการโยกย้าย
• ความสัมพันธ์ของโปรเซสเซอร์

การดำเนินการจัดการบางอย่างอาจส่งผลให้เกิด "การหยุดทำงาน" หรือช่วงเวลาที่ไม่มีงานที่เป็นประโยชน์ใดที่ดำเนินการโดยตัวประมวลผลแอปพลิเคชัน การหยุดทำงานเหล่านี้อาจรบกวนเสียง ดังนั้นการจัดการดังกล่าวควรได้รับการออกแบบสำหรับการหยุดการทำงานในกรณีที่เลวร้ายที่สุดที่ยอมรับได้ในขณะที่เสียงทำงานอยู่ แน่นอนว่า เมื่อความร้อนใกล้เข้ามา การหลีกเลี่ยงความเสียหายถาวรมีความสำคัญมากกว่าเสียง!

เคอร์เนลความปลอดภัย

เคอร์เนลความปลอดภัย สำหรับ การจัดการสิทธิ์ดิจิทัล (DRM) อาจทำงานบนแกนประมวลผลแอปพลิเคชันเดียวกันกับที่ใช้สำหรับเคอร์เนลระบบปฏิบัติการหลักและรหัสแอปพลิเคชัน เมื่อใดก็ตามที่การดำเนินการเคอร์เนลการรักษาความปลอดภัยแอ็คทีฟบนคอร์ ถือเป็นการหยุดทำงานปกติที่ปกติจะทำงานบนคอร์นั้นอย่างมีประสิทธิภาพ โดยเฉพาะอาจรวมถึงงานด้านเสียงด้วย โดยธรรมชาติแล้ว พฤติกรรมภายในของเคอร์เนลการรักษาความปลอดภัยนั้นไม่สามารถเข้าใจได้จากเลเยอร์ระดับที่สูงกว่า ดังนั้น ความผิดปกติของประสิทธิภาพใดๆ ที่เกิดจากเคอร์เนลการรักษาความปลอดภัยจึงเป็นอันตรายอย่างยิ่ง ตัวอย่างเช่น การดำเนินการเคอร์เนลความปลอดภัยมักไม่ปรากฏในการติดตามการสลับบริบท เราเรียกสิ่งนี้ว่า "ยุคมืด" ซึ่งเป็นเวลาที่ผ่านไปแล้วแต่ไม่อาจสังเกตได้ เคอร์เนลด้านความปลอดภัยควรได้รับการออกแบบสำหรับการหยุดทำงานในกรณีที่เลวร้ายที่สุดที่ยอมรับได้ในขณะที่เสียงทำงานอยู่