Kiểm traKiểm Tra Độ Trễ Âm Thanh
Công cụ kiểm tra độ trễ âm thanh trên trình duyệt. Báo cáo độ trễ cơ bản và đầu ra của Web Audio theo ms, tần số mẫu và buffer, kèm xuất CSV/JSON.
Có góp ý? Báo lỗi, đề xuất tính năng, hoặc chia sẻ suy nghĩ — chúng tôi đọc tất cảVề Công Cụ Kiểm Tra Độ Trễ Âm Thanh
Công cụ Kiểm Tra Độ Trễ Âm Thanh giúp bạn đo độ trễ giữa khi kích hoạt phát âm thanh và khi âm thanh thực sự phát ra qua loa hoặc tai nghe. Điều này rất quan trọng cho sản xuất nhạc (thu âm DAW), chơi game (đồng bộ audio-video), live streaming, chỉnh sửa video, và bất kỳ ứng dụng nào mà timing là quan trọng. Độ trễ thấp hơn nghĩa là phản hồi thời gian thực tốt hơn.
- Nhấn Bắt Đầu Test để khởi tạo hệ thống âm thanh và cấp quyền cho trình duyệt
- Công cụ sẽ tự động chạy nhiều lần test với tiếng bíp có thể nghe được
- Xem kết quả thời gian thực bao gồm độ trễ trung bình và khoảng độ trễ
- Kiểm tra nhật ký test để xem kết quả chi tiết của từng lần đo
- Chạy test nhiều lần để có kết quả chính xác hơn
Hiểu Về Độ Trễ Âm Thanh
- Độ Trễ Cơ Bản: Thời gian giữa audio context và buffer phần cứng (ước tính do trình duyệt báo cáo)
- Độ Trễ Đầu Ra: Độ trễ buffering bổ sung trong thiết bị đầu ra — Safari không cung cấp nên hiển thị Không có
- Ước tính tổng: độ trễ cơ bản + đầu ra theo ms — đây là ước tính của trình duyệt, không phải khứ hồi âm thanh thực
- Kích Thước Buffer: khung suy ra = độ trễ cơ bản x tần số mẫu; nhỏ hơn thì độ trễ thấp hơn nhưng rủi ro hơn
- Độ trễ tốt: < 10ms (không cảm nhận được), Chấp nhận được: 10-30ms, Cao: > 30ms
- Kích thước buffer nhỏ hơn giảm độ trễ nhưng có thể gây giật âm thanh
- Dùng tai nghe để test chính xác hơn so với loa (có độ trễ phòng)
- Đóng các ứng dụng nền để giảm tải hệ thống và cải thiện độ trễ
- Sound card chuyên nghiệp thường có độ trễ thấp hơn card tích hợp
- Chơi game và sản xuất nhạc cần độ trễ thấp nhất có thể
- Stream video có thể chịu độ trễ cao hơn (50-100ms là chấp nhận được)
Câu Hỏi Thường Gặp
Độ trễ âm thanh là sự chậm trễ giữa khi âm thanh được phần mềm yêu cầu và khi nó thực sự đến tai người nghe. Công cụ đo đường khứ hồi bên trong trình duyệt: thời gian giữa việc gọi Web Audio API để lên lịch âm thanh và khoảnh khắc engine âm thanh báo cáo buffer đã sẵn sàng để phát. Nó nắm bắt kích thước buffer (theo khung), tốc độ mẫu (thường 44,1 hoặc 48 kHz) và độ trễ tính toán bằng mili giây. Nó không đo độ trễ thêm vào bởi DAC, giao diện USB, codec Bluetooth hoặc loa ngoài — chúng thêm độ trễ riêng mà trình duyệt không thể kiểm tra. Để có độ trễ hệ thống đầy đủ, bạn cần ghi đầu ra bằng micro và so sánh thời gian.
Độ trễ vô hình cho đến khi vượt ngưỡng cảm nhận, sau đó trở nên không thể chịu đựng. Nhạc sĩ chơi nhạc cụ ảo cần dưới 10 ms khứ hồi tổng hoặc nốt cảm thấy mất kết nối với phím nhấn. Theo dõi trực tiếp khi ghi âm cần dưới 5 ms để tránh "tiếng vang" gây phân tâm. Game thủ hưởng lợi với dưới 30 ms vì tiếng bước chân và súng cần đồng bộ với tín hiệu hình ảnh để định vị chính xác. Streamer và người sáng tạo nội dung cần âm thanh và video đồng bộ trong 40 ms hoặc người xem nhận thấy lệch khẩu hình. Cuộc gọi video chịu được độ trễ cao hơn (100–200 ms) vì hội thoại hai chiều và con người tự nhiên thích nghi, nhưng trên 250 ms gây chen ngang và lú lẫn hội thoại.
Cho âm thanh trình duyệt cụ thể: dưới 20 ms là xuất sắc và phù hợp cho mọi biểu diễn âm nhạc; 20–50 ms tốt cho phát lại đa phương tiện và hầu hết game; 50–100 ms chấp nhận được cho streaming thụ động và video; trên 100 ms sẽ đáng chú ý là chậm trễ giữa hành động người dùng và phản hồi âm thanh. Lưu ý rằng tai nghe Bluetooth thêm 40–300 ms trên những gì công cụ này báo cáo — Bluetooth Classic A2DP có thể là 200 ms, aptX Low Latency đạt khoảng 40 ms, AirPods Pro khoảng 130 ms nhưng cải thiện xuống 80 ms trên thiết bị Apple. Tai nghe có dây thêm về cơ bản không độ trễ. Giao diện âm thanh USB thường thêm 3–10 ms.
Trình duyệt hiện đại điều tiết tab nền để tiết kiệm pin và CPU. Khi tab này mất tiêu điểm, luồng audio worklet có thể chạy ở ưu tiên thấp hơn, độ phân giải timer giảm từ 1 ms xuống tới 1 giây, và underruns buffer trở nên phổ biến. Bạn cũng có thể thấy độ trễ nhảy khi HĐH vào chế độ tiết kiệm năng lượng (laptop dùng pin, di động ở chế độ tiết kiệm), khi ứng dụng ưu tiên cao khác như cuộc gọi video chiếm thiết bị âm thanh độc quyền, hoặc khi trình điều khiển âm thanh đàm phán lại kích thước buffer trước tải. Để đo nhất quán, chạy bài kiểm tra này trên tab mới ở tiền cảnh, cắm laptop, đóng các ứng dụng khác dùng âm thanh (Zoom, Spotify, Discord) và tắt tiện ích trình duyệt bắt âm thanh.
Kích thước buffer là số mẫu âm thanh xử lý mỗi chu kỳ callback. Buffer nhỏ hơn nghĩa là ít âm thanh chờ trong hàng đợi và do đó độ trễ thấp hơn, nhưng cũng nhiều callback hơn và hạn chế CPU chặt hơn — bỏ lỡ một và bạn có glitch nghe được (rạn hoặc bung). Ở tốc độ mẫu 48 kHz, buffer 256 mẫu là 256/48000 = 5,33 ms độ trễ một chiều; buffer 128 mẫu giảm một nửa xuống 2,67 ms nhưng gấp đôi áp lực CPU. Giao diện âm thanh chuyên nghiệp thường chạy ở 32 hoặc 64 mẫu để theo dõi trực tiếp, trong khi thẻ tiêu dùng mặc định 512–1024 mẫu để ổn định. Trình duyệt thường chọn kích thước buffer dựa trên thiết bị và tải hiện tại — bạn không thể ghi đè từ JavaScript mà không đàm phán lại AudioContext.
Âm thanh Bluetooth thêm độ trễ đáng kể qua ba lớp: mã hóa codec, truyền radio và giải mã codec. Yếu tố chiếm ưu thế là codec. SBC (mặc định phổ quát) thường thêm 200–300 ms vì xử lý khung lớn và dùng sửa lỗi chuyển tiếp tích cực. AAC (ưa thích của Apple) khoảng 150–200 ms với tối ưu trên iOS. aptX khoảng 70 ms. aptX Low Latency khoảng 32–40 ms nhưng yêu cầu cả máy phát và máy thu hỗ trợ. aptX Adaptive và LC3 (Bluetooth 5.2 LE Audio) giảm xuống 20–40 ms. AirPods của Apple dùng AAC với điều chỉnh độc quyền đạt khoảng 130 ms trên iPhone. Để giảm độ trễ Bluetooth: dùng kết nối có dây khi có thể, ghép nối thiết bị hỗ trợ cùng codec độ trễ thấp và cập nhật firmware.
Tốc độ mẫu là bao nhiêu mẫu âm thanh mỗi giây hệ thống xử lý. Tốc độ cao hơn nắm bắt chi tiết thời gian tinh hơn (tần số Nyquist = tốc_độ_mẫu / 2, nên 48 kHz nắm bắt tới 24 kHz âm thanh) và giảm thời gian buffer mỗi mẫu tuyến tính: ở 48 kHz buffer 256 mẫu là 5,33 ms, ở 96 kHz cùng buffer là 2,67 ms. Tuy nhiên, gấp đôi tốc độ mẫu gấp đôi tải CPU, tăng kích thước tập tin và trên 48 kHz không tạo khác biệt nghe được cho người nghe vì 20 kHz là giới hạn thính giác. Âm thanh pro dùng 96 kHz để cho không gian xử lý tín hiệu cho plugin phi tuyến. Hầu hết âm thanh tiêu dùng là 44,1 kHz (di sản CD) hoặc 48 kHz (di sản video). Web Audio mặc định tốc độ ưa thích của thiết bị, thường 48 kHz trên phần cứng hiện đại.
Khuyến nghị âm thanh chuyên nghiệp đến từ nhiều nguồn. ITU-R BS.1116 quy định độ chính xác thời gian dưới 1 ms cho kiểm tra chất lượng âm thanh mù đôi. Theo dõi buổi hòa nhạc trực tiếp theo khuyến nghị AES dưới 10 ms cho monitor trong tai và dưới 20 ms cho wedge sàn. Trình điều khiển ASIO trên Windows có thể đạt 1–5 ms khứ hồi với phần cứng phù hợp. CoreAudio trên macOS thường đạt 2–10 ms. Web Audio trình duyệt với API AudioWorklet có thể đạt 5–20 ms trên máy tính để bàn và 30–100 ms trên di động. Ngăn xếp trình duyệt thêm chi phí từ thực thi JavaScript, truyền tin nhắn giữa các luồng và đường ống đa phương tiện của Chromium. Cho công việc chuyên nghiệp quan trọng về độ trễ, DAW gốc (Logic, Reaper, Pro Tools) vẫn là tiêu chuẩn; trình duyệt đang bắt kịp nhưng chưa tương đương.
Công cụ này đọc AudioContext.baseLatency và AudioContext.outputLatency. Chrome và Edge cung cấp cả hai trên máy tính và Android. Firefox cung cấp baseLatency và các phiên bản gần đây cũng có outputLatency. Safari (macOS và iOS) có baseLatency nhưng KHÔNG cung cấp outputLatency, nên thẻ Độ Trễ Đầu Ra sẽ hiển thị Không có và ước tính tổng chỉ phản ánh độ trễ cơ bản. Không cần quyền micro — công cụ chỉ phát một tiếng bíp ngắn và đọc các số do context báo cáo; không ghi âm gì cả. Vì dùng Web Audio API, nó yêu cầu context an toàn (HTTPS); trên nguồn gốc không an toàn sẽ hiển thị thông báo không hỗ trợ. Mọi thứ chạy cục bộ trong trình duyệt: không có âm thanh, phép đo hay tệp xuất nào rời khỏi thiết bị — tệp tải CSV/JSON được tạo ở phía máy khách.
Độ Trễ Cơ Bản là độ trễ do trình duyệt báo cáo giữa việc lên lịch âm thanh và buffer phần cứng; Độ Trễ Đầu Ra là phần buffering thêm mà HĐH/thiết bị thêm vào trước khi âm thanh ra khỏi loa. Tổng nổi bật là độ trễ cơ bản + đầu ra theo mili giây và là ƯỚC TÍNH của trình duyệt — không phải khứ hồi âm thanh thực được xác minh bằng micro, và không bao gồm DAC, giao diện USB, codec Bluetooth hay độ trễ loa của bạn. Safari hiển thị Không có cho độ trễ đầu ra, nên hãy coi tổng của nó chỉ là cơ bản. Để đo loopback chuẩn, hãy phát một tiếng click sắc và ghi lại bằng micro đặt tại loa, rồi tương quan chéo thời điểm bắt đầu được ghi với thời điểm kích hoạt; chênh lệch là độ trễ đầu cuối thực. Dùng ước tính cơ bản/đầu ra của công cụ này cùng kích thước buffer suy ra và xuất CSV/JSON để ghi và so sánh thiết bị, và dành phương pháp micro-loopback khi bạn cần con số tuyệt đối được chứng nhận.
CHẩN đOáN11
CôNG Cụ âM THANH40
WUTOOLS