ปัจจัยที่ทำให้เกิดเวลาในการตอบสนองของเสียง

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

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

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

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

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

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

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

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

การจัดตารางเวลา CFS และ SCHED_FIFO ของ Linux

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

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

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

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

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

เวลาในการตอบสนองของการกำหนดเวลา

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

ขัดจังหวะ

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

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

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

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

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

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

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

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