ทำไมเสียงขาดทั้งที่การใช้ CPU ต่ำ ── มองผ่านบัฟเฟอร์และเส้นตาย

ระหว่างฟังเพลง บางครั้งเสียงก็ขาดไปดัง “ปุ๊” ใน Task Manager การใช้ CPU อยู่ที่ราว 10% แต่มีเพียงเสียงที่ไม่เสถียร ในสถานการณ์แบบนี้ ทำไมเสียงจึงขาดได้ทั้งที่ CPU ยังมีกำลังเหลือ

แม้การใช้ CPU จะต่ำ หากการเติมข้อมูลเสียงชุดถัดไปไม่ทันเส้นตาย เสียงก็ขาดได้ เพราะต้องส่งข้อมูลชุดถัดไปในระหว่างที่เสียงซึ่งเหลืออยู่ในบัฟเฟอร์กำลังถูกเล่น การเติมข้อมูลล่าช้าเพราะการรอข้อมูลหรือล็อก หรือเพราะ DPC/ISR บน CPU เชิงตรรกะที่จำเป็น เกิดขึ้นได้แม้จะไม่ได้ใช้ CPU ทั้งหมดจนเต็ม Exclusive-Mode Streams, CPU Analysis

อย่างไรก็ตาม จากเสียง “ปุ๊” ที่ได้ยินเพียงอย่างเดียว ยังสรุปไม่ได้ว่าเป็นอันเดอร์รัน อาการคล้ายกันเกิดได้จากแหล่งเสียง แอป เอฟเฟกต์เสียง อุปกรณ์เอาต์พุต และอื่น ๆ ให้เริ่มจากการเปรียบเทียบด้วยแหล่งเสียงเดิม โดยเปลี่ยนเงื่อนไขทีละอย่างแล้วเปลี่ยนกลับ หากยังจำกัดวงไม่ได้ จึงบันทึกช่วงก่อนและหลังเสียงขาด Fix distorted or crackling audio in Windows

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

ขอบเขตหลักคือเอาต์พุตเสียงบน Windows 11 โดยเปรียบเทียบเอาต์พุตแบบในตัว แบบมีสาย USB Bluetooth และอื่น ๆ สำหรับซอฟต์แวร์ทำเพลง (DAW) จะครอบคลุมการเปรียบเทียบในกรณีที่แอปหรือไดรเวอร์มีการตั้งค่าบัฟเฟอร์ให้ด้วย บทความนี้ไม่ได้ครอบคลุมการออกแบบระบบบันทึกเสียงทั้งหมด หรือการวินิจฉัยการสื่อสารไร้สายของอุปกรณ์แต่ละตัว

คำอธิบายใช้ shared mode เป็นตัวอย่างพื้นฐาน เส้นทาง ขนาดบัฟเฟอร์ และรอบการประมวลผลจริงแตกต่างกันไปตามแอป API ไดรเวอร์ และอุปกรณ์ และไม่มีหน้าจอตั้งค่าบัฟเฟอร์ที่ใช้ร่วมกันได้ในทุกแอป Low Latency Audio

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

กลไกอ่านเรียงได้ตั้งแต่หัวข้อถัดไป “บัฟเฟอร์การเล่นเสียง” ส่วนขั้นตอนการสอบสวนเสียงขาดอยู่ใน “เปรียบเทียบเงื่อนไขที่ทำให้เกิดซ้ำ” และ “บันทึกเสียงขาดด้วย WPR”

ในแผนภาพ เส้นทึบหมายถึงความสัมพันธ์ที่ถือเสมอ และเส้นประหมายถึงความสัมพันธ์ที่มีเงื่อนไข (เงื่อนไขอยู่ในการอธิบายของแต่ละความสัมพันธ์ในหน้าละเอียด) รายการความสัมพันธ์ทั้งหมด (รวม 5 รายการ พร้อมหลักฐานและระดับความเชื่อมั่น) และนิยามของแนวคิดหลักรวบรวมไว้ที่ หน้าละเอียดของแผนที่ความรู้ (เป็นภาษาญี่ปุ่น) ข้อมูล: JSON-LD / Turtle

บัฟเฟอร์การเล่นเสียง

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

flowchart TB
    accTitle: เก็บเสียงล่วงหน้าเล็กน้อยก่อนเล่น
    accDescr: ลำดับการเติมข้อมูลเสียงที่เตรียมไว้ลงบัฟเฟอร์ และเตรียมข้อมูลชุดถัดไประหว่างที่การเล่นฝั่งอุปกรณ์ดำเนินไป
    A["เตรียมเสียงถัดไป"] --> B["เติมลงบัฟเฟอร์"]
    B --> C["เล่นเสียงที่สะสมไว้"]
    C -.->|"ก่อนใช้หมด"| A

ภาพ 1: การเล่นจะต่อเนื่องได้ การเติมข้อมูลต้องตามฝั่งที่ใช้เสียงให้ทัน

ภาพ 1 เป็นแผนภาพแนวคิดที่แสดงเพียงความสัมพันธ์ระหว่างการเติมกับการใช้ ไม่ได้หมายความว่าบัฟเฟอร์หลายตัวในเส้นทางเสียงจริงเป็นพื้นที่ทางกายภาพเดียวกัน Low Latency Audio

หน้าที่ของบัฟเฟอร์คือดูดซับความคลาดเคลื่อนของเวลาช่วงสั้น ๆ ระหว่างฝั่งที่เตรียมเสียงกับฝั่งที่ใช้เสียง เพื่อให้การเล่นต่อเนื่อง แต่ความจุของบัฟเฟอร์กับปริมาณข้อมูลที่ยังไม่ได้เล่นซึ่งอยู่ในบัฟเฟอร์ขณะนั้นเป็นคนละเรื่องกัน “มีความจุ 10 มิลลิวินาที” ไม่ได้แปลว่าจะเหลือข้อมูล 10 มิลลิวินาทีอยู่เสมอ Rendering a Stream

ในบทความนี้ ข้อจำกัดด้านเวลาที่ต้องส่งข้อมูลชุดถัดไปที่จำเป็นให้ถึงก่อนข้อมูลที่กำลังเล่นจะหมด จะเรียกว่าเส้นตายของการเติมข้อมูล งานประมวลผลเสียงต้องการ “เตรียมเสร็จภายในเวลาที่ต้องส่งเสียงออก” แค่ “ในที่สุดก็คำนวณเสร็จ” ยังไม่พอ สภาวะที่ส่งข้อมูลไม่ทันจนข้อมูลที่จะเล่นหมดลงคืออันเดอร์รัน ซึ่งนำไปสู่เสียงขาดหรือเสียงคลิก แม้ข้อมูลจะมาถึงทีหลัง ก็ย้อนกลับไปเติมช่วงที่ขาดซึ่งได้ยินไปแล้วไม่ได้ Exclusive-Mode Streams

เส้นทางของข้อมูลเสียง

ใน shared mode ทั่วไป audio engine ของ Windows จะรับข้อมูลที่แอปเล่นเสียงเตรียมไว้ ผสมเสียงหลายแหล่งหรือใส่เอฟเฟกต์ แล้วส่งต่อไปยังไดรเวอร์และอุปกรณ์เอาต์พุต แอปเล่นเสียงเกี่ยวข้องทั้งการอ่านแหล่งเสียงและการส่งข้อมูลไปยังปลายทางเอาต์พุต ส่วนไดรเวอร์และอุปกรณ์เอาต์พุตจะขนข้อมูลไปยังฝั่งอุปกรณ์แล้วเล่น Low Latency Audio

flowchart TB
    accTitle: เส้นทางที่ข้อมูลเสียงผ่านใน shared mode
    accDescr: audio engine รับข้อมูลที่แอปเล่นเสียงเตรียมไว้ ผสมและใส่เอฟเฟกต์ แล้วส่งให้ไดรเวอร์ จากนั้นอุปกรณ์เอาต์พุตจึงเล่น
    A["แอปเล่นเสียง: เตรียมข้อมูล"] --> E["audio engine: ผสม/เอฟเฟกต์"]
    E --> D["ไดรเวอร์: ส่งไปอุปกรณ์"]
    D --> O["อุปกรณ์เอาต์พุต: เล่น"]

ภาพ 2: ตัวอย่างของ shared mode การประมวลผลและบัฟเฟอร์ระหว่างทางเปลี่ยนไปตาม API และอุปกรณ์

บางครั้งฝั่งอุปกรณ์ก็มีการประมวลผลหรือบัฟเฟอร์ของตัวเอง ความหน่วงทั้งหมดจึงไม่ได้ถูกกำหนดด้วยบัฟเฟอร์ฝั่งแอปเพียงอย่างเดียว คำอธิบายนี้ตั้งอยู่บนเส้นทางของ shared mode และไม่ได้หมายความว่าทุก API ผ่านการประมวลผลแบบเดียวกัน Low Latency Audio

การเติมข้อมูลเมื่อเหลือ 10 มิลลิวินาที

สมมติว่าขณะนี้ในบัฟเฟอร์ยังมีข้อมูลที่ยังไม่ได้เล่นเหลืออยู่ 10 มิลลิวินาที ถ้าการเติมครั้งถัดไปเกิดขึ้นหลัง 8 มิลลิวินาที เสียงจะต่อเนื่องได้ขณะที่ยังมีข้อมูลเหลือ แต่ถ้าเติมไม่ได้จนถึง 12 มิลลิวินาที ในตัวอย่างแบบง่ายนี้ข้อมูลจะหมดที่จุด 10 มิลลิวินาที

flowchart TB
    accTitle: เหลือ 10 มิลลิวินาทีเท่ากัน แต่ผลต่างกันตามเวลาที่เติม
    accDescr: ภายใต้สมมติฐานเพื่อการอธิบายว่าเหลือข้อมูลที่จะเล่น 10 มิลลิวินาที หากเติมหลัง 8 มิลลิวินาทีจะทัน แต่หากเติมหลัง 12 มิลลิวินาทีจะเป็นหลังจากข้อมูลหมดแล้ว
    A["เหลือ 10 มิลลิวินาที"] --> B{"การเติมครั้งถัดไป"}
    B -->|"หลัง 8 มิลลิวินาที"| C["ต่อเนื่อง"]
    B -->|"หลัง 12 มิลลิวินาที"| D["หมดที่ 10 มิลลิวินาที"]

ภาพ 3: ตัวอย่างที่ทำให้เรื่องเวลาเรียบง่ายขึ้น สิ่งสำคัญไม่ใช่แค่เติมได้หรือไม่ แต่คือเติมได้เมื่อใด

การใช้ CPU กับการเติมข้อมูลที่ล่าช้า

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

flowchart TB
    accTitle: ความว่างโดยเฉลี่ยกับการเติมที่ล่าช้าเพียงครั้งเดียว
    accDescr: แม้ CPU จะว่างเกือบตลอด 1 วินาที หากมีช่วงที่เติมข้อมูลไม่ได้นาน 12 มิลลิวินาทีเพียงครั้งเดียว ความล่าช้าครั้งนั้นก็ทำให้เสียงขาดได้
    A["CPU ว่างเกือบตลอด 1 วินาที"] --> B["เติมไม่ได้ 12 มิลลิวินาทีครั้งเดียว"]
    B --> C["เสียงขาดจากครั้งนั้น"]

ภาพ 4: แม้จะว่างโดยเฉลี่ย ก็เรียกเวลาการเล่นที่ผ่านไปแล้วคืนไม่ได้

สิ่งที่กินเวลาก่อนถึงเส้นตายไม่ได้มีแค่เวลาคำนวณ ยังรวมถึงการรอจนกว่างานจะเริ่ม และการรอจนกว่าข้อมูลที่จำเป็นจะมาถึง ดังนั้นคำถามในการสอบสวนจึงต้องเปลี่ยนจากแค่ “CPU กี่เปอร์เซ็นต์” เป็น “ในขณะที่เสียงขาด เสียงชุดถัดไปกำลังรออะไรอยู่”

การรอข้อมูลและล็อก

สมมติว่างานที่เตรียมข้อมูลเสียงกำลังรอให้การอ่านไฟล์เสร็จ กรณีที่รอล็อกซึ่งงานอื่นในแอปถืออยู่ก็เช่นเดียวกัน งานที่กำลังรอแทบไม่ได้ใช้ CPU แต่ฝั่งอุปกรณ์ยังเล่นต่อไป และเสียงที่เหลือก็ลดลงเรื่อย ๆ Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: การเล่นยังเดินต่อแม้ในเวลารอที่ไม่ใช้ CPU
    accDescr: ระหว่างที่งานเสียงรอข้อมูลหรือล็อก งานนั้นไม่ใช้ CPU แต่การเล่นยังดำเนินไปและข้อมูลที่เหลือลดลง หากเติมล่าช้าบัฟเฟอร์อาจหมดได้
    A["งานเสียงรอข้อมูล"] --> B["งานนั้นไม่ใช้ CPU"]
    B --> C["ระหว่างนั้นการเล่นยังเดินต่อ"]
    C --> D["เติมช้าก็สต็อกหมด"]

ภาพ 5: การไม่ได้ใช้ CPU กับการที่งานที่จำเป็นทำเสร็จแล้วเป็นคนละเรื่องกัน

DPC/ISR กับเธรดเสียง

ISR คืองานที่ตอบสนองต่ออินเทอร์รัปต์จากอุปกรณ์ DPC คือกลไกที่เลื่อนงานส่วนที่เหลือออกไปทำภายหลัง เพื่อให้การจัดการอินเทอร์รัปต์สั้นลง DPC ปกติจะรันก่อนเธรดปกติบน CPU เชิงตรรกะเดียวกัน และระหว่างที่ DPC หรือ ISR ปกติกำลังทำงาน CPU เชิงตรรกะนั้นจะรันเธรดปกติไม่ได้ Introduction to DPCs, CPU Analysis

แม้ CPU โดยรวมจะยังเหลือ หากสิ่งเหล่านี้ยืดเยื้อหรือเกิดถี่บน CPU ที่งานเสียงต้องใช้ การส่งข้อมูลก็อาจล่าช้าได้ เอกสารวิเคราะห์ประสิทธิภาพเสียงและวิดีโอของ Microsoft ยกให้ DPC/ISR ที่ยาวจากไดรเวอร์เครือข่าย สตอเรจ กราฟิก และอื่น ๆ เป็นหนึ่งในสาเหตุที่เป็นไปได้ของเสียงขาดด้วย ไม่แน่เสมอไปว่าตรวจแค่อุปกรณ์ที่ส่งเสียงออกก็พอ Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: เมื่อการตอบสนองต่ออุปกรณ์ทำให้งานเสียงรันช้าลง
    accDescr: หาก DPC หรือ ISR ปกติยืดเยื้อบน CPU ที่งานเสียงต้องใช้ การรันเธรดจะล่าช้าและอาจกระทบเส้นตายของการเติมข้อมูล
    A["DPC/ISR บน CPU เดียวกัน"] -->|"เมื่อยืดเยื้อ"| B["งานเสียงต้องรอ"]
    B --> C["เติมเสียงถัดไปล่าช้า"]
    C --> D["ข้อมูลหมดก็เสียงขาด"]

ภาพ 6: บางครั้งงานอื่นที่ไม่ใช่ของอุปกรณ์ส่งเสียง ก็ส่งผลทางอ้อมต่อการเติมข้อมูลเสียง

ไม่มีเส้นแบ่งร่วมแบบ “ถ้า DPC ไม่เกินกี่ไมโครวินาที เสียงจะไม่ขาดบนพีซีทุกเครื่อง” ค่าเตือนในเอกสารประเมินประสิทธิภาพเป็นค่าภายใต้เงื่อนไขการประเมินนั้น จึงไม่นำค่านั้นมาใช้เป็นเกณฑ์ความปลอดภัยโดยแยกออกจากกำหนดเวลาเติมข้อมูลจริงหรือความเผื่อของบัฟเฟอร์ Results for the Streaming Media Performance Assessment

ขนาดบัฟเฟอร์กับความหน่วงในการเล่น

ภายใต้เงื่อนไขเดียวกัน ถ้าเพิ่มเสียงที่สะสมไว้ล่วงหน้า ก็จะดูดซับการเติมที่ล่าช้าชั่วคราวได้ง่ายขึ้น แต่ในอีกด้านหนึ่ง เสียงที่เพิ่งสร้างใหม่ต้องรอต่อท้ายเสียงที่สะสมอยู่แล้ว การรอที่ยอมรับได้เมื่อแค่ฟังเพลง จะกลายเป็นความคลาดเคลื่อนระหว่างการกระทำกับเสียงที่รู้สึกได้ชัด เมื่อเล่นคีย์บอร์ดดนตรี หรือเมื่อประมวลผลเสียงพูดจากไมโครโฟนแล้วฟังเสียงตัวเอง Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: ความเผื่อของบัฟเฟอร์กับการตอบสนองที่ช้าลง
    accDescr: การเพิ่มเสียงที่สะสมไว้ล่วงหน้าช่วยดูดซับการเติมที่ล่าช้าชั่วคราวได้ง่ายขึ้น แต่เวลารอจนเสียงใหม่ถูกเล่นก็เพิ่มขึ้นด้วย
    A["เพิ่มเสียงที่สะสมล่วงหน้า"] --> B["ดูดซับการเติมล่าช้าได้ง่าย"]
    B -->|"แลกกับ"| C["เสียงใหม่รอต่อท้าย"]
    C --> D["จากการกดถึงเสียงช้าลง"]

ภาพ 7: การเพิ่มบัฟเฟอร์คือการปรับเพื่อสร้างความเผื่อโดยแลกกับความเร็วในการตอบสนอง

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

การปรับเพิ่มบัฟเฟอร์คือการสร้างความเผื่อต่อการส่งข้อมูลที่ล่าช้าชั่วคราว หากการส่งข้อมูลโดยเฉลี่ยตามการใช้ไม่ทันอยู่แล้ว การเพิ่มบัฟเฟอร์ที่มีขนาดจำกัดก็เพียงยืดเวลาจนกว่าจะหมด และไม่ได้แก้ปัญหาอุปกรณ์หลุดการเชื่อมต่อด้วย นี่ก็ไม่ใช่คำแนะนำว่าใช้ exclusive mode แล้วทุกอย่างจะแก้ได้ Exclusive-Mode Streams

เสียง 480 เฟรมที่ 48kHz

เฟรมของ PCM คือหน่วยที่รวมแซมเปิลของทุกช่องสัญญาณที่เล่น ณ เวลาเดียวกัน การเป็นสเตอริโอจึงไม่ได้หมายความว่าต้องคูณจำนวนเฟรมด้วย 2 เพื่อคำนวณเวลา ความยาวของเสียงที่จำนวนเฟรมแทนหาได้จาก “จำนวนเฟรม ÷ sample rate” ที่ 48kHz 480 เฟรมคือ 480 ÷ 48000 วินาที หรือ 10 มิลลิวินาที หากคง 48kHz ไว้แล้วเพิ่มจำนวนเฟรม เวลาของเสียงที่สะสมได้ก็ยาวขึ้น Rendering a Stream

เวลานี้เป็นคนละเรื่องกับความหน่วงรวมตั้งแต่กดคีย์จนได้ยินเสียง เพราะยังมีเวลาของแอป ไดรเวอร์ อุปกรณ์ บัฟเฟอร์อื่น และการประมวลผลอื่นอีก ค่าที่ตั้งใน DAW ก็ต้องตรวจหน่วยและบัฟเฟอร์ที่ค่านั้นหมายถึงก่อนอ่านเช่นกัน Low Latency Audio

flowchart TB
    accTitle: เวลาที่คำนวณจากจำนวนเฟรมกับความหน่วงรวม
    accDescr: 10 มิลลิวินาทีที่ได้จากการหาร 480 เฟรมด้วย 48000 คือเวลาที่บัฟเฟอร์แทน เมื่อรวมการประมวลผลของแอป ไดรเวอร์ อุปกรณ์ และอื่น ๆ เข้าไปจึงเป็นความหน่วงรวมจากคีย์ถึงเสียง
    A["480 ÷ 48000"] --> B["10 มิลลิวินาทีที่บัฟเฟอร์แทน"]
    B -->|"บวกการประมวลผลอื่น"| C["ความหน่วงรวมจากคีย์ถึงเสียง"]

ภาพ 8: เวลาที่คำนวณจากจำนวนเฟรมเป็นเพียงส่วนหนึ่งของความหน่วงรวม

เปรียบเทียบเงื่อนไขที่ทำให้เกิดซ้ำ

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

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

1. กำหนดแหล่งเสียงสั้น ๆ ชุดเดิมและระยะเวลาสังเกต แล้วยืนยันการเกิดซ้ำในเงื่อนไขเดิม

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

2. เลือกการเปรียบเทียบหนึ่งรายการจากตารางต่อไปนี้ แล้วเปลี่ยนเฉพาะเงื่อนไขนั้นและเล่นเสียง

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

3. หากเปรียบเทียบการปรับปรุงเสียง ให้ปิดการตั้งค่านี้ชั่วคราวบนเอาต์พุตเป้าหมาย

   ใน Windows ไปที่ “การตั้งค่า” → “ระบบ” → “เสียง” เลือกเอาต์พุตเป้าหมาย แล้วปิด “การปรับปรุงเสียง” ในสภาพแวดล้อมที่มีตัวเลือกนี้ หากหน้าจอหรือรายการที่มีอยู่ต่างไป โปรดดูคำแนะนำสำหรับรุ่นและอุปกรณ์นั้น Fix distorted or crackling audio in Windows

4. เปลี่ยนการตั้งค่าที่แก้ไขกลับเป็นค่าเดิม แล้วลองอีกครั้งด้วยแหล่งเสียงและระยะเวลาสังเกตเดิม

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

5. หากจะลองเปลี่ยนไดรเวอร์ ให้ตรวจสอบช่องทางแจกจ่ายอย่างเป็นทางการและวิธีกู้คืนก่อนลงมือ

   ใช้ Windows Update หรือช่องทางแจกจ่ายอย่างเป็นทางการของผู้ผลิตอุปกรณ์ และบันทึกรุ่นและการตั้งค่าก่อนและหลังเปลี่ยน ตรวจสอบล่วงหน้าว่าย้อนกลับได้หรือไม่ และสำหรับพีซีที่องค์กรดูแล ให้ปรึกษาผู้ดูแลระบบ อย่าถือว่าแก้ได้แล้วเพียงเพราะเล่นได้หนึ่งครั้งหลังอัปเดต ให้ยืนยันด้วยเงื่อนไขการเกิดซ้ำเดิม Fix distorted or crackling audio in Windows

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

flowchart TB
    accTitle: เปรียบเทียบโดยเปลี่ยนเงื่อนไขหนึ่งอย่างแล้วเปลี่ยนกลับ
    accDescr: ยืนยันการเกิดซ้ำด้วยแหล่งเสียงเดิม เปลี่ยนเงื่อนไขหนึ่งอย่าง เช่น แอปหรือเอาต์พุต แล้วบันทึกผลเมื่อเปลี่ยนกลับด้วย
    A["เล่นด้วยชุดเงื่อนไขเดิม"] --> B["เปลี่ยนหนึ่งเงื่อนไขแล้วเล่น"]
    B --> C["เปลี่ยนกลับแล้วเล่น"]
    C --> D["จดเงื่อนไขและเวลาที่ขาด"]

ภาพ 9: ตรวจว่าเงื่อนไขกับอาการสอดคล้องกันซ้ำ ๆ มากกว่าการที่ดีขึ้นเพียงครั้งเดียว

การเกิดซ้ำก่อนและหลังเปลี่ยนเงื่อนไข

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

flowchart TB
    accTitle: ผลสามอย่างที่บ่งชี้ความเกี่ยวข้องกับเงื่อนไข
    accDescr: หากเกิดซ้ำในเงื่อนไขเดิม ดีขึ้นเมื่อเปลี่ยนเงื่อนไขหนึ่งอย่าง และเกิดซ้ำเมื่อเปลี่ยนกลับ ก็เป็นเบาะแสที่บ่งชี้ความเกี่ยวข้องกับเงื่อนไขนั้น แต่ต้องแยกจากการระบุสาเหตุให้แน่ชัด
    A["เกิดซ้ำในเงื่อนไขเดิม"] --> B["เปลี่ยนหนึ่งอย่างแล้วดีขึ้น"]
    B --> C["เปลี่ยนกลับแล้วเกิดซ้ำ"]
    C --> D["เบาะแสความเกี่ยวข้องกับเงื่อนไข"]

ภาพ 10: แม้ครบทั้งสามอย่าง สิ่งที่รู้ได้ก็เป็นเพียงเบาะแสของความเกี่ยวข้อง

การใช้ CPU ที่ต่ำไม่ใช่หลักฐานว่าเส้นตายของเสียงถูกรักษาไว้ ในขณะเดียวกัน การที่เสียงขาดเพียงอย่างเดียวก็ยังบอกไม่ได้ว่าการเติมล่าช้าคือสาเหตุที่แท้จริง ให้เปรียบเทียบแหล่งเสียง การประมวลผลของแอป เอฟเฟกต์ เส้นทางเอาต์พุต และอื่น ๆ แล้วตัดสินภายในขอบเขตที่สังเกตได้ Fix distorted or crackling audio in Windows

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

บันทึกเสียงขาดด้วย WPR

ทำขั้นตอนนี้เมื่อการเปรียบเทียบเงื่อนไขเพียงอย่างเดียวจำกัดวงไม่ได้ หรือเมื่อต้องการตรวจงานฝั่งไดรเวอร์ WPR เป็นเครื่องมือสำหรับบันทึก ส่วน WPA ใช้วิเคราะห์ไทม์ไลน์ที่บันทึกไว้ เตรียม Windows Performance Toolkit สิทธิ์ที่จำเป็นต่อการบันทึก และตำแหน่งเก็บไฟล์ ETL หากจะติดตั้งเครื่องมือและบันทึกบนพีซีที่องค์กรดูแล โปรดขอให้ผู้ดูแลระบบดำเนินการ ชื่อที่แสดงและโปรไฟล์ที่ใช้ได้ให้ตรวจสอบในรุ่นที่ติดตั้ง Windows Performance Recorder

ไฟล์ ETL อาจมีชื่อโปรเซส พาธไฟล์ และข้อมูลอื่น ๆ ก่อนบันทึก ให้ตรวจกฎขององค์กรและผู้ที่จะแชร์ไฟล์ให้ และอย่าแนบไฟล์ไว้ในพื้นที่สาธารณะทั้งอย่างนั้น หากมีเซสชันบันทึกอื่นทำงานอยู่ อย่าหยุดเองโดยพลการ ให้สอบถามผู้รับผิดชอบก่อน WPR How-to Topics

1. เปิด “More Options” ของ WPR แล้วเลือกโปรไฟล์การบันทึกที่ตรงกับวัตถุประสงค์

   โปรไฟล์มาตรฐานมี “Audio glitches” และ “CPU usage” ให้เลือกการตั้งค่าที่ตรวจความไม่ต่อเนื่องของเสียงและการทำงานของ CPU ได้ ตรวจโปรไฟล์ ชื่อที่แสดง และเนื้อหาที่เก็บได้ในรุ่นที่ติดตั้ง และไม่ตั้งค่าให้บันทึกทุกประเภทเป็นเวลานาน Built-in Recording Profiles

2. เริ่มบันทึกก่อนทำให้เสียงขาดเกิดซ้ำ

   หากมีข้อความยืนยันว่าจะหยุดการบันทึกที่มีอยู่ อย่าดำเนินการต่อ ให้ยกเลิกการเริ่มบันทึกแล้วสอบถามผู้รับผิดชอบ จัดเงื่อนไขให้ตรงกับตอนที่ไม่ได้บันทึก และเผื่อความเป็นไปได้ว่าภาระของการบันทึกเองอาจทำให้อาการเปลี่ยนไป WPR How-to Topics

3. เล่นด้วยเงื่อนไขที่พบจากการเปรียบเทียบ แล้วจดเวลาที่เสียงขาดและการกระทำไว้

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

4. หลังอาการเกิดซ้ำ ให้จบการบันทึกด้วย “Save” แล้วบันทึกไฟล์ ETL

   หากใช้ “Cancel” จะไม่มีการบันทึกไฟล์ จดตำแหน่งที่เก็บ เงื่อนไขการเกิดซ้ำ ว่ามีการบันทึกหรือไม่ และมีคำเตือนอีเวนต์ตกหล่นหรือไม่ ในบันทึกที่มีอีเวนต์ตกหล่น จะไม่ตัดสินว่าช่วงที่มองไม่เห็นเป็นปกติ WPR How-to Topics

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

flowchart TB
    accTitle: บันทึกสั้น ๆ ที่ครอบคลุมช่วงเสียงขาด
    accDescr: เริ่มบันทึกด้วย WPR ทำให้อาการเกิดซ้ำและจดเวลา หยุดและบันทึกไฟล์ แล้วตรวจบันทึกนั้นด้วย WPA
    A["เริ่มบันทึกด้วย WPR"] --> B["ทำให้เสียงขาดซ้ำในเงื่อนไขเดิม"]
    B --> C["จดเวลาและการกระทำแล้วบันทึก"]
    C --> D["ขยายช่วงก่อนหลังใน WPA"]

ภาพ 11: การดูการใช้ CPU หลังอาการจบไปแล้วไม่เพียงพอ ต้องมีบันทึกของช่วงที่อาการเกิดขึ้น

การทำงานและการรอช่วงก่อนและหลังเสียงขาด

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

1. เปิด ETL ใน WPA แล้วขยายช่วงก่อนและหลังเสียงขาด โดยอิงอีเวนต์เสียงที่เก็บได้และเวลาที่อาการเกิดซ้ำ

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

2. ตรวจ “DPC/ISR” และ “CPU Usage (Precise)” ในช่วงเดียวกัน

   หากไม่มีข้อมูลที่จำเป็น ให้ตรวจว่าเป็นโปรไฟล์ที่เก็บข้อมูลนั้นได้หรือไม่ แล้วกลับไปบันทึกด้วย WPR การไม่มีบันทึกกับการไม่มีปัญหาเป็นคนละเรื่องกัน CPU Analysis, Built-in Recording Profiles

3. แยกให้ออกว่าเธรดที่เกี่ยวกับเสียงพร้อมรันแต่ต้องรอคิว หรือกำลังรอข้อมูลหรือสิ่งอื่นอยู่

   หากเป็นกรณีแรก ให้ตรวจเทียบว่ามี DPC/ISR หรืออื่น ๆ ทำงานนานบน CPU เชิงตรรกะที่เกี่ยวข้องหรือไม่ หากเป็นกรณีหลัง ให้ติดตามจากอีเวนต์หรือสแตกที่เก็บได้ว่าอะไรปลดการรอนั้น เธรดที่กำลังรันอยู่ก็อาจถูกอินเทอร์รัปต์ขัดจังหวะได้ จึงไม่จำกัดอยู่แค่เวลา Ready แต่ซ้อนช่วง DPC/ISR ดูด้วย CPU Analysis

4. บันทึกความสอดคล้องของเวลากับเสียงขาด CPU ที่เกี่ยวข้อง และผลจากการเปลี่ยนเงื่อนไขไว้ด้วยกัน

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

flowchart TB
    accTitle: ตรวจลักษณะการรอในช่วงเสียงขาด
    accDescr: ขยายช่วงก่อนและหลังเสียงขาดเพื่อดูสถานะของเธรดเสียง หากพร้อมรันแต่รอคิว ให้เทียบกับ DPC หรือ ISR บน CPU เดียวกัน หากรอข้อมูลหรือสิ่งอื่น ให้ติดตามงานที่ปลดการรอ
    A["ขยายช่วงก่อนหลังเสียงขาด"] --> B{"สถานะเธรด"}
    B -->|"รอคิว"| C["DPC/ISR"]
    B -->|"รอข้อมูล"| D["งานที่ปลดการรอ"]

ภาพ 12: อย่าหยิบแค่ค่าสูงสุด ให้อ่านซ้อนกับช่วงที่งานเสียงจำเป็นต้องทำงาน

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

การโหลดล่วงหน้าในแอปเสียง

หากสร้างแอปเสียงเอง ให้ออกแบบให้งานที่เติมบัฟเฟอร์ชุดถัดไปทันกำหนดเวลาทุกครั้ง WASAPI มีวิธีรับจังหวะที่ประมวลผลบัฟเฟอร์ได้ในรูปอีเวนต์ Exclusive-Mode Streams

MMCSS เป็นกลไกที่จัดสรรทรัพยากร CPU ให้เธรดของงานมัลติมีเดียที่มีข้อจำกัดด้านเวลา ไม่มีฟังก์ชันเตรียมข้อมูลจากดิสก์ไว้ล่วงหน้าหรือกำจัดการรอล็อก แม้จะใช้การจัดสรรของ MMCSS ก็ยังต้องมีการออกแบบที่เตรียมข้อมูลและลดการรอแยกต่างหาก Multimedia Class Scheduler Service

flowchart TB
    accTitle: ขอบเขตที่ MMCSS รับผิดชอบ
    accDescr: MMCSS จัดสรรทรัพยากร CPU ให้เธรดของงานที่มีข้อจำกัดด้านเวลา แต่การเตรียมข้อมูลและการลดการรอล็อกต้องทำด้วยการออกแบบอีกส่วนหนึ่ง
    M["MMCSS: จัดสรรทรัพยากร CPU"] -.->|"ต้องมีแยกต่างหาก"| D["เตรียมข้อมูลและลดการรอ"]

ภาพ 13: การจัดสรรทรัพยากร CPU กับการออกแบบให้ข้อมูลมาทันเป็นงานคนละส่วนกัน

แนวทางการออกแบบคือแยกงานที่อ่านจากไฟล์หรือเครือข่ายออกจากงานที่ส่งเสียง งานเตรียมที่คาดเวลาได้ยากให้ทำล่วงหน้า และใช้บัฟเฟอร์ที่จองไว้ล่วงหน้าในการส่งต่อข้อมูล ฝั่งเสียงควรอยู่ในรูปที่ไม่ต้องรอการตอบกลับของ UI ล็อกที่ยาว หรือการเขียน log แบบซิงโครนัส

flowchart TB
    accTitle: แยกงานเตรียมที่คาดเวลาได้ยากออกจากการส่งเสียง
    accDescr: การออกแบบที่ทำงานอย่างการอ่านไฟล์ในงานล่วงหน้า แล้วส่งข้อมูลที่เตรียมไว้ผ่านบัฟเฟอร์ไปยังงานเสียง เพื่อลดการรอนาน ๆ ก่อนถึงเส้นตาย
    A["เตรียมข้อมูลในงานล่วงหน้า"] --> B["พื้นที่ส่งต่อที่จองไว้ก่อน"]
    B --> C["งานเสียงส่งตามที่ต้องการ"]
    C --> D["ส่งไปยังปลายทางเสียง"]

ภาพ 14: ย้ายงานที่ใช้เวลานานออกจากช่วงก่อนส่งต่อเสียง

หากฝั่งเตรียมข้อมูลหยุดนาน แม้จะแยกแบบนี้แล้วสต็อกก็ยังหมดได้ ให้บันทึกไม่ใช่แค่เวลาประมวลผลเฉลี่ย แต่รวมถึงรอบที่เกิดงานหรือการรอที่ยาว และจำนวนครั้งที่ส่งข้อมูลไม่ทันด้วย โดยใช้วิธีที่ไม่รบกวนงานเสียง ตรวจขนาดบัฟเฟอร์และรอบที่ถูกเลือกจริงจาก API หรือไดรเวอร์ และไม่สันนิษฐานว่าค่าที่ระบุถูกนำไปใช้ตามนั้น Rendering a Stream, Low Latency Audio

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

ผลของลำดับความสำคัญแบบเรียลไทม์

เราไม่แนะนำโดยทั่วไปให้ผู้ใช้เปลี่ยนเพลเยอร์ทั้งโปรแกรมเป็นลำดับความสำคัญ “เรียลไทม์” เพราะเสี่ยงที่จะขัดขวางงานสำคัญอื่น และการเพิ่มลำดับความสำคัญของเธรดปกติก็ไม่ได้ทำให้ DPC/ISR หรือการรอข้อมูลและล็อกหมดไป ในการพัฒนา ให้ใช้กลไกอย่าง MMCSS และการออกแบบที่ไม่นำการรอนาน ๆ เข้ามาในการส่งข้อมูลเสียง Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: การรอที่ยังเหลืออยู่แม้เปลี่ยนเป็นลำดับความสำคัญแบบเรียลไทม์
    accDescr: แม้ตั้งเพลเยอร์เป็นลำดับความสำคัญแบบเรียลไทม์ เธรดปกติก็แซง DPC หรือ ISR บน CPU เดียวกันไม่ได้ การรอข้อมูลและล็อกยังคงอยู่ และยังเสี่ยงขัดขวางงานสำคัญอื่น
    A["ตั้งเพลเยอร์เป็นเรียลไทม์"] --> B["แซง DPC/ISR ไม่ได้"]
    B --> C["การรอข้อมูลและล็อกยังอยู่"]
    C --> D["เสี่ยงขัดขวางงานอื่น"]

ภาพ 15: แม้เพิ่มลำดับความสำคัญ การรอที่ทำให้การเติมข้อมูลเสียงล่าช้าก็ยังคงอยู่

บทความที่เกี่ยวข้อง

• “Processor scheduling” ของ Windows และการตั้งค่าบริการเบื้องหลัง
• แยกแยะปัญหาดิสก์ 100% บน Windows อย่างปลอดภัย
• ทำไม RDP ถึงหน่วงทั้งที่อินเทอร์เน็ตเร็ว

เอกสารอ้างอิง

• Microsoft Learn, Rendering a Stream. การส่งข้อมูลเข้าบัฟเฟอร์การเล่น ปริมาณคงเหลือ ขนาดบัฟเฟอร์จริง และนิยามของเฟรม PCM
• Microsoft Learn, Exclusive-Mode Streams. เวลาส่งข้อมูลเข้าบัฟเฟอร์กับเสียงกระตุก (glitch) การปรับสมดุลกับความหน่วง และการส่งข้อมูลแบบขับเคลื่อนด้วยอีเวนต์ ทั้งนี้ไม่ได้เป็นการแนะนำ exclusive mode โดยทั่วไป
• Microsoft Learn, Low Latency Audio. เส้นทางเสียงของ Windows บัฟเฟอร์ อุปกรณ์ และการประมวลผลเอฟเฟกต์กับความหน่วง และข้อแลกเปลี่ยนของความหน่วงต่ำ
• Microsoft Learn, CPU Analysis. CPU เชิงตรรกะ สถานะ Ready/Waiting ของเธรด ความสัมพันธ์ระหว่าง DPC/ISR กับการรันเธรด และการวิเคราะห์ CPU ใน WPA
• Microsoft Learn, Introduction to DPCs. กลไกที่ทำให้การจัดการอินเทอร์รัปต์สั้นลงและส่งงานที่เหลือไปให้ DPC
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPC/ISR ที่ยาวหรือเกิดถี่ การส่งข้อมูลไม่พอ และเสียงกระตุก ไม่นำค่าเตือนของการประเมินไปใช้เป็นเกณฑ์ความปลอดภัยของอุปกรณ์ทุกตัว
• Microsoft Support, Fix distorted or crackling audio in Windows. การตรวจสอบการปรับปรุงเสียง รูปแบบเสียง ไดรเวอร์ และอื่น ๆ
• Microsoft Learn, Windows Performance Recorder. การบันทึก ETW การวิเคราะห์ด้วย WPA และการใช้ Windows Performance Toolkit
• Microsoft Learn, Built-in Recording Profiles. More Options ของ WPR และโปรไฟล์มาตรฐานอย่าง Audio glitches และ CPU usage
• Microsoft Learn, WPR How-to Topics. การเริ่มบันทึกและการบันทึกไฟล์ด้วย Save การชนกับเซสชันที่มีอยู่ และข้อควรระวังเรื่องข้อมูลส่วนบุคคลและอีเวนต์ตกหล่น
• Microsoft Learn, Multimedia Class Scheduler Service. การจัดสรรทรัพยากร CPU ให้งานมัลติมีเดียที่มีข้อจำกัดด้านเวลา
• Microsoft Learn, Scheduling Priorities. ลำดับความสำคัญของโปรเซสและเธรด และข้อควรระวังเกี่ยวกับลำดับความสำคัญแบบเรียลไทม์

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

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

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เชื่อมโยงกับหน้าบริการต่อไปนี้ โปรดเริ่มดูจากหน้าที่ใกล้เคียงที่สุด

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

ทำไมเสียงขาดทั้งที่การใช้ CPU อยู่แค่ราว 10%

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

ถ้าขยายบัฟเฟอร์เสียงให้ใหญ่ขึ้น เสียงขาดจะหายไหม

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

480 เฟรมที่ 48kHz คือเสียงยาวกี่มิลลิวินาที

480÷48000 วินาที จึงเท่ากับ 10 มิลลิวินาที เฟรม PCM หนึ่งเฟรมคือหน่วยที่รวมแซมเปิลของทุกช่องสัญญาณ ณ เวลาเดียวกัน ค่านี้คือความยาวของเสียงที่จำนวนเฟรมนั้นแทน ไม่ใช่ความหน่วงรวมที่รวมอุปกรณ์และแอปไว้ด้วย

ไดรเวอร์ที่ DPC หรือ ISR ใช้เวลารันนานคือตัวการของเสียงขาดใช่หรือไม่

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

ตั้งเพลเยอร์เป็นลำดับความสำคัญแบบเรียลไทม์แล้วจะดีขึ้นไหม

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

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะงานที่มีระบบเดิมอยู่ และการตรวจสอบความขัดข้องที่มองเห็นสาเหตุได้ยาก