Đo độ trễ (latency) micro và loa

Đăng 2026-04-13 8 phút đọc

Tóm tắt (TL;DR)

Khi thu guitar acoustic qua interface USB cũ, tôi nghe độ trễ round-trip khoảng 35 ms ở tai nghe monitor; đổi sang MOTU M2 với driver ASIO, độ trễ rơi xuống khoảng 5 ms và cùng bản nhạc lập tức chuyển từ “không chơi nổi” sang “tự nhiên”. Hiện tượng “nói vào mic, tai nghe nghe trễ” không phải bug mà là bằng chứng vật lý của độ trễ round-trip. Độ trễ là tổng của năm giai đoạn: thời gian micro chứa tín hiệu đã lấy mẫu vào input buffer; thời gian DAW hoặc phần mềm truyền thông xử lý; thời gian gom lại vào output buffer; thời gian DAC chuyển ngược sang analog; và thời gian truyền vật lý từ loa tới tai (khoảng 1 ms mỗi 34 cm). Phần lớn dư địa tinh chỉnh trong năm khoản nằm ở kích thước buffer và mô hình driver. ASIO, WASAPI Exclusive, Core Audio, JACK có độ trễ tối thiểu điển hình khác nhau và ràng buộc theo nền tảng cũng khác nhau. Bài này tóm lược cấu trúc độ trễ, đánh đổi giữa sample rate và buffer size, đặc tính từng driver, và quy trình đo độ trễ round-trip thực tế bằng cáp loopback cộng tone test cộng phần mềm audio.

Bối cảnh và khái niệm

Quãng đường mà tiếng từ mic đi qua máy tính tới loa dài hơn ta tưởng. Đầu tiên ADC (bộ chuyển analog-digital) lấy mẫu tín hiệu mic ở sample rate cố định (ví dụ 48 kHz) và gom mẫu vào input buffer. Khi buffer đầy một khối (ví dụ 128 mẫu), driver chuyển tín hiệu cho phần mềm. Tới đây đã có độ trễ input. 128 mẫu / 48 kHz xấp xỉ 2,67 ms, tự nó đã đủ đáng kể. Nếu bạn nâng buffer lên 512 mẫu để CPU dễ thở hơn, con số đó đã là khoảng 10,67 ms chỉ riêng phía vào — đủ để một ca sĩ cảm thấy giọng mình “lệch nhịp” trong tai nghe.

Phần mềm (DAW, app truyền thông) áp xử lý (hiệu ứng, mix, chuẩn bị truyền mạng) lên buffer nhận được rồi ghi kết quả vào output buffer. Khối buffer output đầy được DAC chuyển sang analog và phát ra loa. Thời gian output buffer tính tương tự. Plugin nặng (reverb tích chập, phân tích FFT lớn) thêm độ trễ xử lý riêng — đặc biệt plugin “lookahead” như multiband limiter cần đọc trước vài ms để hoạt động, và bạn thấy con số đó cộng thẳng vào RTT.

Cuối cùng là truyền qua không khí. Tốc độ âm thanh ở nhiệt độ phòng khoảng 343 m/s, nên thêm khoảng 1 ms mỗi 34 cm. Tai nghe gần như không có quãng này, còn loa monitor ở phía bên kia phòng thêm vài ms. Ngồi trước cặp loa monitor cách 1,7 m khi thu nghĩa là thêm khoảng 5 ms độ trễ chỉ vì khoảng cách. Đây là lý do các kỹ sư âm thanh phòng thu tỉ mỉ đặt loa đối xứng và đo lại vị trí ghế ngồi — sai số vài cm có thể đổi cả cảm giác timing khi track.

Độ trễ round-trip (RTT) = input buffer + xử lý + output buffer + DAC và truyền vật lý. Cùng sample rate, giảm kích thước buffer giảm độ trễ nhưng tăng tải CPU vì CPU phải thức dậy thường xuyên hơn. Nếu định nghĩa buffer theo số mẫu, tăng sample rate làm buffer cùng “số mẫu” ngắn lại về thời gian, nhưng sample rate cao cũng tăng throughput và ảnh hưởng CPU/driver theo cách khác. Một mẹo đáng nhớ: trên cùng hệ thống, đặt 64 mẫu ở 96 kHz (khoảng 0,67 ms/hướng) thường ổn định hơn đặt 128 mẫu ở 48 kHz (khoảng 2,67 ms/hướng) nếu audio driver và phần cứng bạn ưu tiên khả năng xử lý cao.

So sánh và dữ liệu

Tiêu chíASIOWASAPI ExclusiveCore AudioJACK
Nền tảngChủ yếu WindowsChỉ WindowsChỉ macOSLinux chính, cross-platform
Độ trễ thấp nhất điển hìnhRất thấp, thường vài msThấp, kiểm soát riêng vài msThấp, ổn định vài msRất thấp cấu hình được, phức tạp
Chế độ chia sẻTuỳ driver (thường độc quyền)Chọn chia sẻ/độc quyền, độc quyền thấp hơnChia sẻ là mặc định nhưng tinh chỉnh tốtMa trận routing, nhiều client

Giá trị ms chính xác có biến thiên lớn theo phần cứng, driver, bản OS, nên thay vì tin con số marketing “độ trễ 1 ms”, thực dụng là đo RTT trong môi trường của bạn một lần để đặt mốc. Các interface phổ thông như Focusrite Scarlett 2i2 3rd Gen hay MOTU M2 kết hợp ASIO hoặc Core Audio có thể chạm vùng một chữ số ms. Trong khi đó, đường WASAPI chia sẻ mặc định của Windows hoặc driver vòng như ASIO4ALL có thể cho kết quả khác xa dù cùng phần cứng, nên “RTT của tôi” phải được xem là kết quả của tổ hợp ba biến: phần cứng, driver, buffer.

Tình huống thực tế

Tình huống 1 — Biểu diễn live và in-ear monitoring. Khi ca sĩ nghe giọng mình qua in-ear lúc hát, RTT lớn khiến giọng trở về chậm vài ms và phá cảm giác nhịp. Mục tiêu của khu vực này là RTT dưới 10 ms; để đạt, giảm buffer size tối đa, dùng driver độ trễ thấp như ASIO/Core Audio, và nếu có thể, dùng hardware direct monitoring của interface để vòng qua đường phần mềm. Núm monitor trên mặt trước MOTU M2 giải quyết vai trò này ngay lập tức.

Tình huống 2 — Thu podcast. Nếu không phải thu đồng thời nhiều người cùng phòng mà mỗi người thu bằng mic riêng, độ trễ 50–100 ms cũng chấp nhận được. Ở giai đoạn thu không bắt buộc độ trễ thấp; canh timeline khi hậu kỳ là được. Thực tế đặt buffer lớn để đảm bảo ổn định CPU thường có lợi cho chất lượng thu.

Tình huống 3 — Hội nghị video. Hội nghị WebRTC trên trình duyệt thường có độ trễ 100–200 ms trung bình do thêm độ trễ truyền mạng, encode, decode. Mức đó ở ngưỡng duy trì cảm giác hội thoại tự nhiên, và khi thêm độ trễ tai nghe không dây/Bluetooth thì cuộc trò chuyện bắt đầu chồng chéo. Nếu team bạn thường xuyên cắt lời nhau bất thường, thủ phạm gần như luôn là tai nghe Bluetooth thế hệ cũ cộng với Wi-Fi yếu, không phải kỹ năng giao tiếp.

Tình huống 4 — Chơi nhạc cụ với app tập. Ứng dụng loại Yousician hoặc Rocksmith cần nghe được nốt bạn chơi và hiển thị phản hồi trong khung thời gian thực. Ngay cả 40 ms cũng đủ làm lệch cảm giác tempo khi solo nhanh. Mẹo thực tế: nếu bạn không đạt được RTT thấp trên laptop tích hợp, đôi khi kết nối qua audio interface USB rời 100 USD còn cho trải nghiệm tốt hơn laptop “audiophile” 2.000 USD vì driver được tối ưu chặt chẽ hơn.

Những hiểu lầm thường gặp

“Bluetooth luôn trễ lớn.” Truyền A2DP cổ điển chắc chắn trễ lớn. Nhưng các codec độ trễ thấp như LE Audio (codec LC3) hoặc aptX Low Latency có thể xuống vùng khá thấp, thay đổi cảm nhận thực sự. Cùng “tai nghe Bluetooth” nhưng codec hỗ trợ khác nhau cho giá trị rất khác. Tuy nhiên dùng cho monitoring và thu âm, dây vẫn là lựa chọn an toàn.

“USB audio luôn tốt hơn analog.” Nếu interface USB có DAC tốt, preamp nhiễu thấp, driver ổn thì sạch hơn analog, nhưng USB DAC giá rẻ có thể tệ hơn do jitter, nhiễu, vấn đề driver. Không phải “USB nên tốt” mà chất lượng linh kiện đi trước.

“Sample rate 192 kHz thì độ trễ thấp.” Trái với trực giác: nếu giữ buffer theo đơn vị thời gian (ms), nâng sample rate không rút ngắn thời gian vật lý. Chỉ khi cố định buffer theo số mẫu thì thời gian buffer (ms) giảm khi sample rate tăng, đồng thời tăng tải CPU và áp lực driver. Cốt lõi cấu hình độ trễ thấp không phải sample rate mà là buffer size và mô hình driver.

“RTT thấp luôn tốt.” Với monitoring live thì đúng, nhưng với mix và master, bạn không cần RTT thấp — bạn cần CPU rảnh tay để chạy nhiều plugin. Nhiều kỹ sư cố ý đặt buffer lớn (1024 hoặc 2048 mẫu) khi mix để plugin nặng như Pro-L 2 hoặc FabFilter Q3 không gây glitch. Hiểu khi nào cần thấp và khi nào cao là một phần của kỹ năng chứ không phải cài đặt “tốt nhất” cố định.

Danh sách kiểm tra

  1. Xác định RTT mục tiêu. Live < 10 ms, thu 50–100 ms, họp 100–200 ms tuỳ mục đích.
  2. Chọn mô hình driver. Windows → ASIO hoặc WASAPI Exclusive; macOS → Core Audio; Linux → JACK/PipeWire. Đường chia sẻ mặc định (MME, WASAPI shared) thường trễ lớn.
  3. Giảm dần buffer size để giảm RTT. Ngay trước khi xuất hiện crackle (dropout) là giới hạn thực tế của hệ thống đó.
  4. Đo loopback. Nối output và input interface bằng cáp, phát tone test và đọc chênh thời gian giữa tín hiệu nhận với gốc trong trình chỉnh sửa audio.
  5. Sample rate theo yêu cầu dự án. 48 kHz cho video, 44,1/48 kHz cho nhạc hợp lý; 96 kHz trở lên chỉ khi có lý do rõ.
  6. Kiểm đường monitoring. Thay vì monitor qua DAW phần mềm, dùng direct monitoring trên interface có thể đưa RTT gần như về 0.

Công cụ liên quan

Công cụ đo độ trễ audio của Patrache Studio thiết kế để ước lượng sơ bộ độ trễ round-trip của đường input/output trong trình duyệt, tốt để nắm trạng thái hệ thống mà không cần mua phần cứng. Để xem cùng tổng độ trễ thiết bị nhập, tham khảo Hướng dẫn N-Key Rollover (NKRO) và độ trễ nhập game; để truy vấn đồng bộ A/V trong gọi video, khớp cùng yếu tố độ trễ phía camera trong Chẩn đoán webcam: Tương quan giữa frame rate, độ phân giải và ánh sáng.

Tài liệu tham khảo

Công cụ liên quan

diagno.patrache.studio/audio/latency/