Vì sao mức sử dụng CPU thấp mà âm thanh vẫn bị ngắt? — Nhìn từ bộ đệm và hạn chót nạp dữ liệu

Đang nghe nhạc thì thỉnh thoảng âm thanh bị ngắt một tiếng “tách”. Task Manager cho thấy mức sử dụng CPU chỉ khoảng 10%, vậy mà riêng âm thanh lại không ổn định. Trong trường hợp như vậy, vì sao CPU vẫn còn dư mà âm thanh lại bị ngắt?

Dù mức sử dụng CPU thấp, nếu việc nạp dữ liệu âm thanh tiếp theo không kịp hạn chót thì âm thanh vẫn có thể bị ngắt. Lý do là dữ liệu tiếp theo phải được chuyển tới trong lúc phần âm thanh còn lại trong bộ đệm đang được phát. Việc nạp bị trễ do chờ dữ liệu hoặc chờ lock, do DPC/ISR trên CPU logic cần dùng, v.v. có thể xảy ra ngay cả khi toàn bộ CPU chưa bị dùng hết. Exclusive-Mode Streams, CPU Analysis

Tuy nhiên, chỉ dựa vào tiếng “tách” nghe được thì chưa thể khẳng định đó là underrun. Nguồn âm thanh, ứng dụng, hiệu ứng âm thanh, thiết bị đầu ra, v.v. cũng có thể gây ra triệu chứng tương tự. Trước hết, hãy dùng cùng một nguồn âm thanh, thay đổi từng điều kiện một rồi khôi phục lại để so sánh; nếu vẫn không khoanh vùng được thì ghi lại khoảng thời gian trước và sau lúc ngắt tiếng. Fix distorted or crackling audio in Windows

Bài viết này đề cập tới câu hỏi đó và những câu hỏi tiếp theo: “Có nên tăng kích thước bộ đệm không?” và “Cần so sánh gì, ghi lại gì để khoanh vùng được nguyên nhân?”. Bài viết không xác định nguyên nhân của từng sự cố cụ thể chỉ từ mức sử dụng CPU hay âm thanh nghe được.

Đối tượng chủ yếu là đầu ra âm thanh trên Windows 11. Bài viết lấy các đầu ra tích hợp, có dây, USB, Bluetooth, v.v. làm đối tượng so sánh; với phần mềm sản xuất âm nhạc (DAW), bài viết cũng đề cập tới việc so sánh khi ứng dụng hoặc driver cung cấp thiết lập bộ đệm. Bài viết không bao quát việc thiết kế toàn bộ hệ thống thu âm hay việc chẩn đoán truyền thông không dây của từng thiết bị.

Phần giải thích lấy chế độ dùng chung làm ví dụ cơ bản. Đường đi thực tế, lượng bộ đệm và chu kỳ xử lý khác nhau tùy ứng dụng, API, driver và thiết bị, và cũng không có màn hình thiết lập bộ đệm chung cho mọi ứng dụng. Low Latency Audio

Mức sử dụng CPU, lượng còn lại 10 mili giây, thời điểm nạp, v.v. nêu ở đây là giả định để minh họa. Đây không phải báo cáo đo thực tế việc tái hiện hay cải thiện trên một PC cụ thể. Các thao tác ở phần sau là quy trình kiểm tra mà bạn đọc thực hiện trong môi trường của mình.

Cơ chế có thể đọc lần lượt từ mục “Bộ đệm phát âm thanh” ngay sau đây. Các thao tác điều tra ngắt tiếng nằm ở mục “So sánh điều kiện tái hiện” và “Ghi lại ngắt tiếng bằng WPR”.

Trong sơ đồ, đường liền nét biểu thị quan hệ luôn đúng và đường nét đứt biểu thị quan hệ có điều kiện (điều kiện nằm trong phần giải thích từng quan hệ trên trang chi tiết). Danh sách đầy đủ các quan hệ (tổng 5, kèm bằng chứng và mức chắc chắn) cùng định nghĩa các khái niệm chính được tập hợp tại trang chi tiết bản đồ tri thức (bằng tiếng Nhật). Dữ liệu: JSON-LD / Turtle

Bộ đệm phát âm thanh

Chỉ lưu tệp nhạc thôi thì loa không phát ra tiếng. Ứng dụng chuẩn bị dữ liệu âm thanh và chuyển tới thiết bị đầu ra thông qua Windows và driver. Bộ đệm phát âm thanh là vùng tạm thời chứa dữ liệu sắp được phát. Trong lúc thiết bị đang phát dữ liệu hiện tại, phía cung cấp chuẩn bị dữ liệu tiếp theo và nạp vào. Rendering a Stream

flowchart TB
    accTitle: Tích trữ trước một chút âm thanh rồi mới phát
    accDescr: Luồng nạp dữ liệu âm thanh đã chuẩn bị vào bộ đệm và chuẩn bị dữ liệu tiếp theo trong lúc phía thiết bị tiếp tục phát.
    A["Chuẩn bị âm thanh tiếp theo"] --> B["Nạp vào bộ đệm"]
    B --> C["Phát âm thanh đã tích trữ"]
    C -.->|"Trước khi dùng hết"| A

Hình 1: Để tiếp tục phát, việc nạp phải theo kịp phía sử dụng âm thanh.

Hình 1 là sơ đồ khái niệm chỉ thể hiện quan hệ giữa nạp và tiêu thụ. Sơ đồ này không coi nhiều bộ đệm trên đường đi âm thanh thực tế là một vùng vật lý duy nhất. Low Latency Audio

Vai trò của bộ đệm là hấp thụ độ lệch thời gian ngắn giữa phía chuẩn bị âm thanh và phía sử dụng âm thanh, để việc phát được liên tục. Tuy nhiên, dung lượng bộ đệm và lượng dữ liệu chưa phát đang nằm trong đó là hai chuyện khác nhau. “Có dung lượng 10 mili giây” không có nghĩa là lúc nào cũng còn đủ 10 mili giây dữ liệu. Rendering a Stream

Ở đây, ràng buộc về thời gian phải đưa tới dữ liệu tiếp theo cần thiết trước khi dữ liệu đang phát bị dùng hết được gọi là hạn chót nạp dữ liệu. Xử lý âm thanh là loại xử lý đòi hỏi “đã chuẩn bị xong trước thời điểm phát”. Chỉ “cuối cùng cũng tính xong” là chưa đủ. Trạng thái nguồn cấp không kịp khiến dữ liệu để phát bị cạn là underrun, dẫn tới ngắt tiếng hoặc tiếng click. Dù dữ liệu có tới muộn, cũng không thể lấp lại về sau khoảng ngắt đã nghe thấy. Exclusive-Mode Streams

Đường đi của dữ liệu âm thanh

Ở chế độ dùng chung thông thường, audio engine của Windows nhận dữ liệu do ứng dụng phát chuẩn bị, trộn nhiều âm thanh hoặc áp dụng hiệu ứng, rồi chuyển cho driver và thiết bị đầu ra. Ứng dụng phát tham gia cả việc đọc nguồn âm thanh lẫn việc cung cấp dữ liệu cho đích đầu ra; driver và thiết bị đầu ra vận chuyển dữ liệu sang phía thiết bị và phát. Low Latency Audio

flowchart TB
    accTitle: Đường đi của dữ liệu âm thanh ở chế độ dùng chung
    accDescr: Audio engine trộn và xử lý hiệu ứng cho dữ liệu do ứng dụng phát chuẩn bị rồi chuyển cho driver, và thiết bị đầu ra phát.
    A["Ứng dụng phát: chuẩn bị dữ liệu"] --> E["Audio engine: trộn, hiệu ứng"]
    E --> D["Driver: chuyển tới thiết bị"]
    D --> O["Thiết bị đầu ra: phát"]

Hình 2: Ví dụ ở chế độ dùng chung. Các bước xử lý và bộ đệm ở giữa thay đổi tùy API và thiết bị.

Phía thiết bị cũng có thể có xử lý và bộ đệm riêng, nên độ trễ tổng thể không chỉ do bộ đệm phía ứng dụng quyết định. Phần giải thích này giả định đường đi của chế độ dùng chung, không có nghĩa là mọi API đều đi qua cùng các bước xử lý. Low Latency Audio

Nạp khi còn 10 mili giây

Giả sử hiện trong bộ đệm còn 10 mili giây dữ liệu chưa phát. Nếu lần nạp tiếp theo diễn ra sau 8 mili giây thì âm thanh được nối tiếp khi vẫn còn dữ liệu, nhưng nếu tới 12 mili giây sau mới nạp được thì trong ví dụ đơn giản hóa này, dữ liệu sẽ cạn ở mốc 10 mili giây.

flowchart TB
    accTitle: Cùng còn 10 mili giây, kết quả khác nhau tùy thời điểm nạp
    accDescr: Với giả định minh họa là còn 10 mili giây dữ liệu phát, sơ đồ cho thấy nạp sau 8 mili giây thì kịp, còn nạp sau 12 mili giây thì dữ liệu đã bị dùng hết.
    A["Còn 10 mili giây"] --> B{"Lần nạp tiếp theo"}
    B -->|"Sau 8 mili giây"| C["Nối tiếp được"]
    B -->|"Sau 12 mili giây"| D["Cạn ở mốc 10 mili giây"]

Hình 3: Ví dụ đã đơn giản hóa thời gian. Điều quan trọng không chỉ là có nạp được hay không mà còn là nạp được vào lúc nào.

Mức sử dụng CPU và việc nạp bị trễ

Mức sử dụng CPU cho biết mức độ bận trong một khoảng thời gian nhất định. Nó nhìn vào một thứ khác với việc xử lý âm thanh có được thực thi đúng vào lúc cần hay không. Dù CPU còn dư trong phần lớn của một giây, chỉ cần có một khoảng 12 mili giây không nạp được thì chỉ một lần trễ đó cũng có thể làm âm thanh bị ngắt. Năng lực xử lý còn dư về sau không thể lấy lại thời điểm phát đã trôi qua. CPU Analysis

flowchart TB
    accTitle: Dư địa trung bình và một lần nạp trễ
    accDescr: Dù CPU còn dư trong phần lớn của một giây, chỉ cần có một khoảng 12 mili giây không nạp được thì một lần trễ đó cũng có thể làm âm thanh bị ngắt.
    A["CPU dư trong phần lớn 1 giây"] --> B["Một lần 12 mili giây không nạp được"]
    B --> C["Một lần đó làm ngắt tiếng"]

Hình 4: Dù trung bình vẫn còn dư, thời điểm phát đã qua không thể lấy lại.

Thứ làm hao hụt thời gian còn lại trước hạn chót không chỉ có thời gian tính toán. Nó còn gồm thời gian chờ cho tới khi bắt đầu xử lý và thời gian chờ cho tới khi dữ liệu cần thiết tới nơi. Vì vậy, câu hỏi điều tra cũng chuyển từ chỉ “CPU dùng bao nhiêu %” sang “ngay lúc âm thanh bị ngắt, phần âm thanh tiếp theo đang chờ điều gì”.

Chờ dữ liệu và lock

Giả sử phần xử lý chuẩn bị dữ liệu âm thanh đang chờ việc đọc tệp hoàn tất. Trường hợp chờ lock mà một phần xử lý khác trong ứng dụng đang giữ cũng vậy. Bản thân phần xử lý đang chờ hầu như không dùng CPU, nhưng phía thiết bị vẫn tiếp tục phát và phần âm thanh còn lại cứ giảm dần. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Việc phát vẫn tiếp diễn cả trong lúc chờ không dùng CPU
    accDescr: Trong lúc xử lý âm thanh chờ dữ liệu hoặc lock, phần xử lý đó không dùng CPU, nhưng việc phát vẫn tiếp tục làm phần còn lại giảm đi, và nếu nạp trễ thì bộ đệm có thể cạn.
    A["Xử lý âm thanh chờ dữ liệu"] --> B["Phần xử lý đó không dùng CPU"]
    B --> C["Trong lúc đó vẫn đang phát"]
    C --> D["Nạp trễ thì cạn dự trữ"]

Hình 5: Không dùng CPU và đã làm xong việc cần làm là hai chuyện khác nhau.

DPC, ISR và thread âm thanh

ISR là phần xử lý đáp ứng ngắt từ thiết bị. DPC là cơ chế dời phần việc còn lại về sau để rút ngắn phần xử lý ngắt. DPC thông thường được thực thi trước các thread thông thường trên cùng CPU logic, và trong lúc DPC thông thường hoặc ISR đang chạy, CPU logic đó không thể thực thi các thread thông thường. Introduction to DPCs, CPU Analysis

Dù toàn bộ CPU còn dư, nếu các xử lý này kéo dài hoặc xảy ra dày đặc trên CPU mà xử lý âm thanh cần dùng thì việc cung cấp dữ liệu có thể bị trễ. Tài liệu phân tích hiệu năng âm thanh và video của Microsoft cũng nêu DPC/ISR kéo dài do driver mạng, lưu trữ, đồ họa, v.v. là những nguyên nhân có thể gây ngắt tiếng. Không phải lúc nào chỉ kiểm tra thiết bị phát ra âm thanh là đủ. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Khi việc đáp ứng thiết bị làm chậm việc thực thi âm thanh
    accDescr: Nếu DPC thông thường hoặc ISR kéo dài trên CPU mà xử lý âm thanh cần dùng, việc thực thi thread bị chậm và có thể ảnh hưởng tới hạn chót nạp dữ liệu.
    A["DPC, ISR trên cùng CPU"] -->|"Nếu kéo dài"| B["Thực thi âm thanh phải chờ"]
    B --> C["Nạp âm thanh tiếp theo bị trễ"]
    C --> D["Hết phần còn lại thì ngắt tiếng"]

Hình 6: Xử lý dành cho các thiết bị khác ngoài thiết bị phát âm thanh cũng có thể gián tiếp ảnh hưởng tới việc nạp âm thanh.

Không thể vạch ra một ngưỡng chung kiểu “DPC dưới bao nhiêu micro giây thì mọi PC đều không bị ngắt tiếng”. Giá trị cảnh báo trong tài liệu đánh giá hiệu năng là giá trị trong điều kiện đánh giá đó; không tách nó khỏi thời hạn nạp và dư địa bộ đệm thực tế để dùng làm tiêu chuẩn an toàn. Results for the Streaming Media Performance Assessment

Lượng bộ đệm và độ trễ phát

Trong cùng điều kiện, nếu tăng lượng âm thanh tích trữ trước thì dễ hấp thụ các lần nạp trễ tạm thời hơn, nhưng âm thanh mới tạo ra sẽ phải chờ phía sau phần âm thanh đã tích trữ. Mức chờ có thể chấp nhận được khi chỉ nghe nhạc, nhưng khi chơi phím đàn hoặc khi xử lý giọng nói từ micro rồi tự nghe lại thì độ lệch giữa thao tác và âm thanh sẽ trở nên đáng chú ý. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Dư địa bộ đệm và độ trễ phản hồi
    accDescr: Tăng lượng âm thanh tích trữ trước giúp dễ hấp thụ các lần nạp trễ tạm thời hơn, nhưng thời gian chờ cho tới khi âm thanh mới được phát cũng tăng.
    A["Tăng âm thanh tích trữ trước"] --> B["Dễ hấp thụ nạp trễ"]
    B -->|"Đổi lại"| C["Âm thanh mới chờ phía sau"]
    C --> D["Từ thao tác tới âm thanh bị trễ"]

Hình 7: Tăng bộ đệm là phép điều chỉnh tạo dư địa, đổi lại là tốc độ phản hồi.

Không phải “càng nhỏ càng hiệu năng cao”, cũng không phải “càng lớn càng đúng”. Hãy giữ lại tốc độ phản hồi cần thiết trong khi tạo đủ dư địa để không bị ngắt.

Điều chỉnh tăng bộ đệm là để tạo dư địa trước những lần cung cấp trễ tạm thời. Nếu bản thân mức cung cấp trung bình không theo kịp mức tiêu thụ, tăng một bộ đệm hữu hạn chỉ kéo dài thời gian cho tới khi cạn, và cũng không khắc phục được việc thiết bị bị ngắt kết nối. Đây cũng không phải khuyến nghị rằng cứ dùng chế độ độc quyền là giải quyết được mọi thứ. Exclusive-Mode Streams

Âm thanh 48kHz, 480 frame

Frame PCM là đơn vị gộp các mẫu của tất cả các kênh được phát tại cùng một thời điểm. Không phải vì là stereo mà nhân đôi số frame để tính thời gian. Độ dài âm thanh mà số frame biểu thị được tính bằng “số frame ÷ tần số lấy mẫu”; với 48kHz và 480 frame thì là 480 ÷ 48000 giây, tức 10 mili giây. Nếu giữ nguyên 48kHz mà tăng số frame thì thời lượng âm thanh có thể tích trữ cũng dài hơn. Rendering a Stream

Khoảng thời gian này khác với tổng độ trễ từ lúc nhấn phím đàn tới lúc nghe thấy tiếng. Lý do là còn có thời gian của ứng dụng, driver, thiết bị, các bộ đệm và xử lý khác. Giá trị thiết lập trong DAW cũng cần được đọc sau khi xác nhận đơn vị và bộ đệm mà nó áp dụng. Low Latency Audio

flowchart TB
    accTitle: Thời gian tính từ số frame và tổng độ trễ
    accDescr: 10 mili giây có được khi chia 480 frame cho 48000 là thời gian mà bộ đệm biểu thị; cộng thêm xử lý của ứng dụng, driver, thiết bị, v.v. mới là tổng độ trễ từ phím đàn tới âm thanh.
    A["480 ÷ 48000"] --> B["10 mili giây của bộ đệm"]
    B -->|"Cộng thêm xử lý khác"| C["Tổng độ trễ từ phím tới tiếng"]

Hình 8: Thời gian tính từ số frame chỉ là một phần của tổng độ trễ.

So sánh điều kiện tái hiện

Trước tiên, hãy khoanh vùng tổ hợp điều kiện tái hiện được lỗi, và chỉ chuyển sang ghi lại chi tiết khi cần. Dưới đây là quy trình để xác minh nguyên nhân, không phải danh sách biện pháp để thực hiện mọi thay đổi thiết lập cùng lúc.

Hãy lưu công việc, kết thúc các cuộc họp hoặc buổi thu âm chính thức, rồi thử ở mức âm lượng không gây hại cho tai. Ghi lại đích đầu ra ban đầu, cải tiến âm thanh, giá trị bộ đệm, v.v. để có thể khôi phục. Bỏ qua các mục không có thiết lập, và không sửa Registry hay những chỗ tương tự chỉ để làm hiện ra mục thiết lập.

1. Chọn cùng một đoạn âm thanh ngắn và thời gian quan sát, rồi xác nhận lỗi tái hiện trong điều kiện ban đầu.

   Ghi lại phiên bản Windows, tên và phiên bản ứng dụng, thiết bị đầu ra, phương thức kết nối, phiên bản driver. Ghi cả thời điểm, thao tác và số lần xảy ra ngắt tiếng. Nếu lỗi không tái hiện trong điều kiện ban đầu, đừng kết luận là đã cải thiện mà hãy quay lại xác định điều kiện tái hiện.

2. Chọn một phép so sánh trong bảng dưới đây và chỉ thay đổi đúng điều kiện đó khi phát.

   Điều kiện so sánh	Điều cần kiểm tra
   Nguồn âm thanh lưu trên máy và phát qua mạng	Có chỉ xảy ra khi phát qua mạng không. Nếu cùng nội dung nhưng định dạng hoặc đường xử lý khác nhau, ghi lại cả điều đó.
   Phát cùng nguồn âm thanh bằng ứng dụng khác	Có tập trung ở một ứng dụng cụ thể không.
   Đầu ra Bluetooth, v.v. và đầu ra tích hợp, có dây	Có tập trung ở một đường đầu ra cụ thể không.
   Bật và tắt cải tiến âm thanh	Có thay đổi khi kết hợp với xử lý hiệu ứng không.
   Bộ đệm hiện tại của DAW, v.v. và giá trị lớn hơn một bậc	Tăng dư địa tích trữ trước có làm thay đổi không. Độ trễ từ thao tác tới âm thanh có chấp nhận được không.

3. Khi so sánh cải tiến âm thanh, hãy tạm thời tắt thiết lập này trên đầu ra cần kiểm tra.

   Trong “Cài đặt” → “Hệ thống” → “Âm thanh” của Windows, chọn đầu ra cần kiểm tra và, nếu môi trường của bạn có tùy chọn này, tắt “Cải tiến âm thanh”. Nếu cách hiển thị hoặc sự có mặt của các mục khác đi, hãy xem hướng dẫn cho phiên bản và thiết bị đó. Fix distorted or crackling audio in Windows

4. Khôi phục thiết lập đã thay đổi, rồi thử lại với cùng nguồn âm thanh và thời gian quan sát.

   Đặt cạnh nhau kết quả của “điều kiện ban đầu”, “điều kiện đã thay đổi một mục” và “điều kiện đã khôi phục”. Thay đổi nào không có tác dụng thì đưa về trạng thái ban đầu rồi mới chuyển sang phép so sánh khác. Nếu cứ liên tục thay đổi tổ hợp thiết lập, bạn sẽ không biết điều gì đã có tác dụng.

5. Nếu thử thay đổi driver, hãy xác nhận nguồn phát hành chính thức và cách khôi phục trước khi thực hiện.

   Dùng Windows Update hoặc bản phát hành chính thức của nhà sản xuất thiết bị, và ghi lại phiên bản cùng thiết lập trước và sau khi thay đổi. Xác nhận trước rằng có thể khôi phục lại, và với PC được quản lý thì trao đổi với quản trị viên. Đừng coi là đã giải quyết chỉ vì phát được một lần ngay sau khi cập nhật; hãy kiểm tra với cùng điều kiện tái hiện. Fix distorted or crackling audio in Windows

Kết quả cần có là bản ghi gắn triệu chứng với điều kiện, chẳng hạn “tái hiện khi dùng ứng dụng này với đầu ra này”. Ngay cả khi tìm được thiết lập giúp cải thiện, hãy tách điều đó khỏi việc xác định nguyên nhân.

flowchart TB
    accTitle: So sánh bằng cách đổi một điều kiện rồi khôi phục
    accDescr: Xác nhận lỗi tái hiện với cùng nguồn âm thanh, thay đổi một điều kiện như ứng dụng hoặc đầu ra, và ghi lại cả kết quả khi khôi phục.
    A["Phát với tổ hợp ban đầu"] --> B["Đổi một điều kiện rồi phát"]
    B --> C["Khôi phục rồi phát"]
    C --> D["Ghi điều kiện và thời điểm ngắt"]

Hình 9: Thay vì một lần tốt lên, hãy xác nhận điều kiện và triệu chứng tương ứng với nhau một cách lặp lại.

Khả năng tái hiện trước và sau khi đổi điều kiện

“Đã kiềm chế được triệu chứng”, “đã khoanh vùng được điều kiện” và “đã xác định được nguyên nhân gốc” là những mức đạt được khác nhau. Hãy ghi kết luận tương ứng với phạm vi đã quan sát được.

flowchart TB
    accTitle: Ba kết quả cho thấy liên quan tới điều kiện
    accDescr: Nếu lỗi tái hiện trong điều kiện ban đầu, cải thiện khi đổi một điều kiện và tái hiện lại khi khôi phục, đó là manh mối cho thấy liên quan tới điều kiện đó, nhưng cần tách khỏi việc xác định nguyên nhân.
    A["Tái hiện ở điều kiện ban đầu"] --> B["Đổi một mục thì cải thiện"]
    B --> C["Khôi phục thì tái hiện"]
    C --> D["Manh mối liên quan điều kiện đó"]

Hình 10: Dù có đủ cả ba, điều biết được cũng chỉ dừng ở manh mối về sự liên quan.

Mức sử dụng CPU thấp không phải bằng chứng rằng hạn chót âm thanh đã được đáp ứng. Đồng thời, chỉ vì đã có ngắt tiếng cũng không thể nói việc nạp trễ là nguyên nhân gốc. Hãy so sánh nguồn âm thanh, xử lý của ứng dụng, hiệu ứng, đường đầu ra, v.v. và đánh giá trong phạm vi đã quan sát. Fix distorted or crackling audio in Windows

Khi áp dụng một cách khắc phục tạm thời, hãy ghi lại thiết lập ban đầu, nội dung thay đổi, thời gian quan sát, có tái phát hay không, và độ trễ có thể chấp nhận. Nếu nguyên nhân gốc chưa được xác định, hãy ghi rõ cả điều đó.

Ghi lại ngắt tiếng bằng WPR

Thực hiện bước này khi chỉ so sánh điều kiện không khoanh vùng được, hoặc khi cần điều tra xử lý phía driver. WPR là công cụ dùng để ghi, còn WPA dùng để phân tích dòng thời gian đã lưu. Chuẩn bị Windows Performance Toolkit, quyền cần thiết để ghi và nơi lưu tệp ETL. Khi cài công cụ và ghi trên PC được quản lý, hãy nhờ quản trị viên. Tên hiển thị và các profile khả dụng cần được kiểm tra trên phiên bản đã cài. Windows Performance Recorder

Tệp ETL có thể chứa tên tiến trình, đường dẫn tệp, v.v. Trước khi ghi, hãy xác nhận quy định nội bộ và đối tượng sẽ được chia sẻ, và không đính kèm nguyên trạng vào nơi công khai. Nếu đang có một phiên ghi khác chạy, đừng tự ý dừng mà hãy hỏi người phụ trách. WPR How-to Topics

1. Mở “More Options” trong WPR và chọn profile ghi phù hợp với mục đích.

   Các profile tiêu chuẩn có “Audio glitches” và “CPU usage”. Chọn thiết lập cho phép điều tra sự gián đoạn âm thanh và hoạt động của CPU. Kiểm tra các profile khả dụng, tên hiển thị và nội dung thu thập trên phiên bản đã cài, và không thiết lập ghi mọi loại trong thời gian dài. Built-in Recording Profiles

2. Bắt đầu ghi trước khi tái hiện ngắt tiếng.

   Nếu xuất hiện hộp thoại xác nhận dừng bản ghi hiện có, đừng tiếp tục mà hãy hủy việc bắt đầu và hỏi người phụ trách. Giữ điều kiện giống với khi không ghi, và ghi chú cả khả năng chính tải của việc ghi làm thay đổi triệu chứng. WPR How-to Topics

3. Phát với điều kiện đã tìm được khi so sánh, và ghi lại thời điểm ngắt tiếng cùng thao tác.

   Bao gồm thêm một chút khoảng không có vấn đề trước và sau triệu chứng. Với bản ghi không tái hiện được lỗi, hãy ghi rõ điều đó và không coi là bản ghi đã bắt được nguyên nhân.

4. Sau khi tái hiện, kết thúc việc ghi bằng “Save” và lưu tệp ETL.

   Bấm “Cancel” thì bản ghi không được lưu. Ghi lại nơi lưu, điều kiện tái hiện, có bản ghi hay không, và có cảnh báo mất sự kiện hay không. Với bản ghi bị thiếu, đừng đánh giá các khoảng không nhìn thấy là bình thường. WPR How-to Topics

Khi đã có tệp ETL và ghi chú về thời điểm, thao tác, điều kiện ngắt tiếng, bạn đã sẵn sàng đối chiếu trong WPA. Chỉ việc đã lưu bản ghi chưa chắc có nghĩa là đã thu được các sự kiện cần thiết. Hãy kiểm tra nội dung ở mục tiếp theo, “Thực thi và chờ quanh thời điểm ngắt tiếng”.

flowchart TB
    accTitle: Ghi một bản ngắn có chứa lúc ngắt tiếng
    accDescr: Bắt đầu ghi bằng WPR, tái hiện triệu chứng và ghi lại thời điểm, rồi dừng, lưu và xem bản ghi trong WPA.
    A["Bắt đầu ghi bằng WPR"] --> B["Tái hiện ngắt tiếng cùng điều kiện"]
    B --> C["Ghi thời điểm, thao tác rồi lưu"]
    C --> D["Phóng to khoảng trước sau trong WPA"]

Hình 11: Xem mức sử dụng CPU sau khi triệu chứng đã qua là không đủ; cần bản ghi của khoảng thời gian triệu chứng xảy ra.

Thực thi và chờ quanh thời điểm ngắt tiếng

Chuẩn bị tệp ETL đã lưu và ghi chú thời điểm tái hiện. Dưới đây là điểm xuất phát để điều tra trong WPA. Nếu cần phân tích chi tiết có cả stack và symbol, hãy cẩn trọng khi xử lý bản ghi và nhờ quản trị viên hoặc nhà phát triển.

1. Mở tệp ETL trong WPA và, dựa trên các sự kiện âm thanh đã thu được cùng thời điểm tái hiện, phóng to khoảng trước và sau lúc ngắt tiếng.

   Giữ lại cả khoảng không có triệu chứng để so sánh. Đừng chỉ nhìn bảng xếp hạng giá trị lớn nhất; hãy so sánh trên cùng một khoảng thời gian.

2. Trong cùng khoảng đó, xem “DPC/ISR” và “CPU Usage (Precise)”.

   Nếu không có dữ liệu cần thiết, hãy kiểm tra profile có thu được dữ liệu đó không rồi quay lại bước ghi bằng WPR. Không có bản ghi và không có vấn đề là hai chuyện khác nhau. CPU Analysis, Built-in Recording Profiles

3. Phân biệt thread liên quan tới âm thanh đang sẵn sàng thực thi nhưng phải chờ lượt, hay đang chờ dữ liệu hoặc thứ khác.

   Nếu là trường hợp đầu, đối chiếu xem DPC/ISR, v.v. có chạy lâu trên CPU logic liên quan hay không. Nếu là trường hợp sau, lần theo các sự kiện và stack đã thu được để xem điều gì đã giải trừ việc chờ. Vì thread đang chạy cũng có thể bị ngắt quãng bởi ngắt, đừng chỉ giới hạn ở thời gian Ready mà hãy chồng cả các khoảng DPC/ISR lên để xem.

4. Ghi lại cùng lúc sự tương ứng về thời điểm với lúc ngắt tiếng, CPU liên quan và kết quả khi thay đổi điều kiện.

   Đừng kết luận một thiết bị hay driver cụ thể là nguyên nhân chỉ dựa vào tên module của DPC/ISR kéo dài. Có thể bạn đang nhìn vào một giá trị lớn ở thời điểm khác, hoặc vào phần chung mà nhiều thiết bị cùng đi qua.

flowchart TB
    accTitle: Xem cách chờ trong khoảng ngắt tiếng
    accDescr: Phóng to khoảng trước và sau lúc ngắt tiếng để xem trạng thái thread âm thanh. Nếu đang sẵn sàng nhưng chờ lượt thì đối chiếu với DPC, ISR trên cùng CPU; nếu đang chờ dữ liệu hoặc thứ khác thì lần theo phần xử lý đã giải trừ việc chờ.
    A["Phóng to quanh lúc ngắt tiếng"] --> B{"Trạng thái thread"}
    B -->|"Chờ lượt"| C["DPC, ISR"]
    B -->|"Chờ dữ liệu"| D["Xử lý đã giải trừ chờ"]

Hình 12: Đừng chỉ nhặt giá trị lớn nhất; hãy đọc chồng lên khoảng thời gian mà xử lý âm thanh cần chạy.

Nếu không xác định được, hãy bàn giao cuộc điều tra ở trạng thái chưa xác định. Kèm theo phiên bản OS, ứng dụng, thiết bị, driver, các bước tái hiện, kết quả trước và sau khi thay đổi, thời điểm xảy ra, profile thu thập và việc có cảnh báo mất sự kiện hay không. Tệp ETL chỉ được chia sẻ cho người phụ trách điều tra, theo quy định nội bộ.

Đọc trước trong ứng dụng âm thanh

Khi tự xây dựng ứng dụng âm thanh, hãy thiết kế sao cho phần xử lý lấp đầy bộ đệm tiếp theo luôn kịp thời hạn mỗi lần. WASAPI có cách nhận thời điểm có thể xử lý bộ đệm thông qua sự kiện. Exclusive-Mode Streams

MMCSS là cơ chế phân bổ tài nguyên CPU cho các thread xử lý đa phương tiện có ràng buộc thời gian. Nó không có chức năng chuẩn bị trước dữ liệu từ đĩa hay loại bỏ việc chờ lock. Ngay cả khi tận dụng việc phân bổ của MMCSS, vẫn cần thiết kế riêng để chuẩn bị dữ liệu và giảm thời gian chờ. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Phạm vi MMCSS đảm nhận
    accDescr: MMCSS phân bổ tài nguyên CPU cho thread của các xử lý có ràng buộc thời gian, còn việc chuẩn bị dữ liệu và giảm chờ lock được thực hiện bằng thiết kế riêng.
    M["MMCSS: phân bổ tài nguyên CPU"] -.->|"Cần riêng"| D["Chuẩn bị dữ liệu và giảm chờ"]

Hình 13: Phân bổ tài nguyên CPU và thiết kế để dữ liệu kịp thời là hai việc khác nhau.

Phương châm thiết kế là tách phần xử lý đọc từ tệp hoặc mạng khỏi phần xử lý chuyển âm thanh. Những bước chuẩn bị khó đoán thời gian thì thực hiện trước, và dùng bộ đệm cấp phát sẵn để trao đổi dữ liệu. Ở phía âm thanh, hãy tổ chức sao cho không phải chờ phản hồi từ UI, lock giữ lâu hay việc ghi log đồng bộ.

flowchart TB
    accTitle: Tách phần chuẩn bị khó đoán thời gian khỏi việc cung cấp âm thanh
    accDescr: Thiết kế thực hiện việc đọc và các bước tương tự ở phần xử lý trước, chuyển dữ liệu đã chuẩn bị cho xử lý âm thanh qua bộ đệm, nhằm giảm những lần chờ lâu ngay trước hạn chót.
    A["Chuẩn bị dữ liệu ở xử lý trước"] --> B["Vùng trao đổi cấp phát sẵn"]
    B --> C["Xử lý âm thanh chuyển phần cần"]
    C --> D["Cung cấp cho đích đầu ra âm thanh"]

Hình 14: Đưa những việc tốn thời gian ra khỏi thời điểm ngay trước khi chuyển âm thanh.

Nếu phía chuẩn bị dừng lâu thì dù có tách như vậy, dữ liệu dự trữ vẫn cạn. Không chỉ thời gian xử lý trung bình, hãy ghi lại cả những lần xử lý hoặc chờ kéo dài và số lần không cung cấp kịp, bằng phương pháp không cản trở xử lý âm thanh. Hãy xác nhận lượng bộ đệm và chu kỳ thực sự được chọn qua API hoặc driver, và đừng giả định rằng giá trị đã chỉ định được áp dụng nguyên vẹn. Rendering a Stream, Low Latency Audio

Cả các ví dụ số lẫn ví dụ thiết kế đều nhằm minh họa, không phải giá trị thiết lập khuyến nghị cho thiết bị cụ thể, cũng không phải bảo đảm rằng sẽ không ngắt tiếng trong mọi môi trường.

Ảnh hưởng của mức ưu tiên thời gian thực

Việc người dùng đổi toàn bộ trình phát sang mức ưu tiên “Thời gian thực” không được khuyến nghị cho mọi trường hợp. Việc này có nguy cơ cản trở các xử lý quan trọng khác, và nâng mức ưu tiên của thread thông thường cũng không giải quyết được DPC/ISR hay việc chờ dữ liệu và lock. Trong phát triển, hãy dùng các cơ chế như MMCSS và thiết kế không đưa những lần chờ lâu vào việc cung cấp âm thanh. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Những lần chờ vẫn còn dù đổi sang ưu tiên thời gian thực
    accDescr: Dù đặt trình phát ở mức ưu tiên thời gian thực, thread thông thường vẫn không vượt được DPC hay ISR trên cùng CPU, việc chờ dữ liệu và lock vẫn còn, và còn có nguy cơ cản trở các xử lý quan trọng khác.
    A["Đặt trình phát ưu tiên thời gian thực"] --> B["Không vượt được DPC, ISR"]
    B --> C["Chờ dữ liệu, lock vẫn còn"]
    C --> D["Nguy cơ cản trở xử lý khác"]

Hình 15: Dù nâng mức ưu tiên, những lần chờ làm chậm việc nạp âm thanh vẫn còn đó.

Bài viết liên quan

• “Lập lịch bộ xử lý” và thiết lập dịch vụ nền trong Windows
• Khoanh vùng an toàn tình trạng đĩa 100% trên Windows
• Vì sao đường truyền nhanh mà RDP vẫn chậm?

Tài liệu tham khảo

• Microsoft Learn, Rendering a Stream. Cung cấp dữ liệu cho bộ đệm phát, lượng còn lại, kích thước bộ đệm thực tế và định nghĩa frame PCM.
• Microsoft Learn, Exclusive-Mode Streams. Thời điểm cung cấp bộ đệm và glitch âm thanh, cân bằng với độ trễ, cung cấp dữ liệu theo sự kiện. Đây không phải khuyến nghị dùng chế độ độc quyền cho mọi trường hợp.
• Microsoft Learn, Low Latency Audio. Đường đi âm thanh trong Windows, bộ đệm, thiết bị, xử lý hiệu ứng và độ trễ, các đánh đổi của độ trễ thấp.
• Microsoft Learn, CPU Analysis. CPU logic, trạng thái Ready/Waiting của thread, quan hệ giữa DPC/ISR và việc thực thi thread, phân tích CPU trong WPA.
• Microsoft Learn, Introduction to DPCs. Cơ chế rút ngắn xử lý ngắt và chuyển phần việc còn lại sang DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPC/ISR kéo dài hoặc dày đặc, thiếu hụt cung cấp dữ liệu và glitch âm thanh. Không khái quát giá trị cảnh báo của đánh giá thành tiêu chuẩn an toàn cho mọi thiết bị.
• Microsoft Support, Fix distorted or crackling audio in Windows. Kiểm tra cải tiến âm thanh, định dạng, driver, v.v.
• Microsoft Learn, Windows Performance Recorder. Ghi ETW và phân tích bằng WPA, sử dụng Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options của WPR và các profile tiêu chuẩn như Audio glitches, CPU usage.
• Microsoft Learn, WPR How-to Topics. Bắt đầu ghi và lưu bằng Save, xung đột với phiên hiện có, lưu ý về thông tin cá nhân và việc mất sự kiện.
• Microsoft Learn, Multimedia Class Scheduler Service. Phân bổ tài nguyên CPU cho xử lý đa phương tiện có ràng buộc thời gian.
• Microsoft Learn, Scheduling Priorities. Mức ưu tiên của tiến trình và thread, cùng lưu ý về mức ưu tiên thời gian thực.

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Đây là các trang chủ đề gần với chủ đề này. Từ bài viết, bạn có thể đi tiếp đến các dịch vụ liên quan và những bài viết khác.

Dịch vụ liên quan đến chủ đề này

Bài viết này dẫn đến các trang dịch vụ sau. Hãy xem từ lối vào gần nhất với bạn.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Vì sao mức sử dụng CPU chỉ khoảng 10% mà âm thanh vẫn bị ngắt?

Âm thanh có hạn chót phải nạp dữ liệu tiếp theo trước khi dữ liệu đang phát bị dùng hết. Dù mức sử dụng CPU tổng thể thấp, nếu đúng lúc đó xử lý âm thanh không được thực thi hoặc đang chờ dữ liệu cần thiết thì việc nạp có thể không kịp. Không phải mọi trường hợp ngắt tiếng đều do nguyên nhân này, nên cũng cần so sánh bằng cách đổi thiết bị đầu ra hoặc ứng dụng.

Tăng kích thước bộ đệm âm thanh có hết ngắt tiếng không?

Khi việc nạp bị trễ tạm thời, bộ đệm lớn có thể hấp thụ được độ trễ đó. Tuy nhiên, thời gian chờ cho tới khi phần âm thanh đã tích trữ được phát cũng tăng lên. Đây không phải thiết lập khắc phục được cả tình trạng thiếu năng lực xử lý kéo dài hay thiết bị bị ngắt kết nối. Với ứng dụng hoặc driver cho phép thay đổi, hãy ghi lại giá trị ban đầu rồi so sánh từng bậc một.

480 frame ở 48kHz tương ứng với bao nhiêu mili giây âm thanh?

Là 480 ÷ 48000 giây, tức 10 mili giây. Một frame PCM là đơn vị gộp các mẫu của tất cả các kênh tại cùng một thời điểm. Giá trị này là độ dài âm thanh mà số frame đó biểu thị, không phải tổng độ trễ bao gồm cả thiết bị và ứng dụng.

Driver có thời gian thực thi DPC hoặc ISR dài có phải là thủ phạm gây ngắt tiếng không?

Đó có thể là một ứng viên, nhưng không thể xác định chỉ bằng thứ hạng thời gian thực thi. Hãy đối chiếu khoảng thời gian xảy ra ngắt tiếng với việc chờ của thread âm thanh và việc thực thi DPC/ISR trên cùng CPU. Đừng khẳng định là lỗi của một thiết bị hay driver cụ thể chỉ dựa vào tên module; hãy kiểm tra cả kết quả khi thay đổi điều kiện tái hiện.

Đặt trình phát ở mức ưu tiên thời gian thực có cải thiện không?

Việc này không được khuyến nghị cho mọi trường hợp. Dù nâng mức ưu tiên của thread thông thường, thread đó vẫn không vượt được DPC hay ISR thông thường trên cùng CPU, và việc chờ dữ liệu hay lock cũng không biến mất. Nhà phát triển dùng các cơ chế như MMCSS và thiết kế không đưa việc chờ vào; người dùng trước hết hãy so sánh điều kiện tái hiện và đường đầu ra.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, với thế mạnh ở các dự án còn tài sản hiện có và việc điều tra những sự cố khó nhìn ra nguyên nhân.