Độ trễ vòng lặp âm thanh — Test loa không tiết lộ

Hầu hết test âm thanh chỉ kiểm tra âm thanh có phát và mic có thu không, chứ không đo độ trễ khứ hồi — thời gian từ sự kiện âm thanh vào mic đến khi tín hiệu xử lý ra loa. Con số duy nhất này quyết định nhạc sĩ có thể thu theo nhịp không, cuộc gọi video có tự nhiên không, và âm thanh không gian trong game có chính xác không. Một hệ thống có thể vượt qua mọi kiểm tra phát lại mà vẫn có độ trễ thảm họa, vì chức năng và thời gian là hai trục riêng biệt. Hướng dẫn này giải thích cách đo độ trễ khứ hồi, ý nghĩa các con số và cách giảm nó.

Mọi kiểm tra phần cứng bắt đầu giống nhau. Cắm loa mới, phát test tone, xác nhận có âm thanh ra, chuyển sang việc khác. Cắm mic, nói, xem level meter nhảy, chuyển sang việc khác. Hai test đó xác nhận đường đầu ra và đường đầu vào hoạt động. Không test nào đo câu hỏi thực sự quyết định hệ thống âm thanh của bạn có xử lý được công việc thực: một âm thanh mất bao lâu để đi từ mic, qua máy tính, và ra loa?

Con số đó là độ trễ khuth hồi, và nó âm thầm quyết định hệ thống của bạn có thể trung thực xử lý những nhiệm vụ nào:

  • Thu âm nhạc. Chơi theo nhịp hoặc backing track yêu cầu âm thanh của bạn gần như tức thời trở về tai. Trên khoảng bốn mươi mili giây khứ hồi, nhịp của bạn trôi, mỗi take nghe chậm, và không luyện tập nào sửa được. Các giao diện âm thanh chia sẻ bộ điều khiển USB với các thiết bị khác cũng có thể bị xung đột băng thông USB, gây thêm các đỉnh độ trễ trên nền độ trễ bộ đệm.
  • Đàm thoại. Cuộc gọi video chỉ cảm thấy tự nhiên khi đường ống âm thanh giữ chặt. Độ trễ quá mức tạo echo, lời nói chồng lấp và nhịp điệu gượng gạo của điện thoại vệ tinh.
  • Chơi game với âm thanh không gian. Âm thanh định vị chỉ hoạt động khi âm đến bước với hình. Khi đường âm thanh tụt sau hiển thị, tiếng bước chân và tiếng súng tách khỏi hành động trên màn hình.

Test loa và test mic của bạn trả lời “có hoạt động không?” Test độ trễ vòng lặp trả lời “nhanh bao nhiêu?” Trang này giải thích độ trễ khứ hồi là gì, từ đâu đến, và cách giảm xuống. Các con số ở đây đến từ kinh nghiệm chung trên nhiều cấu hình phần cứng và phần mềm. Kết quả của bạn sẽ khác tùy thuộc giao diện, driver và cài đặt buffer cụ thể. Giao diện âm thanh chuyên nghiệp với tai nghe và mic cho thiết lập thu âm phòng

Test tone không đo độ trễ

Test loa phát tone, sweep hoặc mẫu nhạc qua đường đầu ra và xác nhận có âm thanh. Nó là kiểm tra chức năng với kết quả đậu hoặc rớt: cáp đã nối, driver đã tải, âm lượng không tắt, converter digital sang analog còn sống. Nếu bạn nghe được tone, đường đầu ra hoạt động. Đó là tất cả những gì test có thể cho biết.

Test mic làm điều tương tự cho hướng đầu vào. Nó bắt những gì bạn nói, hiển thị level meter, xác nhận mic, preamp và converter analog sang digital hoạt động. Kết quả lại là đậu hoặc rớt.

Đo độ trễ là một loại test hoàn toàn khác. Thay vì hỏi tín hiệu có thể đi qua đường không, nó hỏi mất bao lâu. Quy trình đơn giản: gửi tín hiệu đã biết — một xung, một click, một burst ngắn — qua đầu ra, bắt ở đầu vào, tính chênh lệch thời gian giữa truyền và nhận. Chênh lệch đó là độ trễ khứ hồi, tính bằng mili giây.

Sự khác biệt quan trọng vì hai phép đo độc lập. Hệ thống có thể vượt mọi test phát lại trong khi có độ trễ thảm họa. Loa Bluetooth là ví dụ điển hình: chúng tái tạo tone trung thành, test loa báo thành công, trong khi codec không dây thêm một trăm đến một trăm tám mươi mili giây độ trễ mà không test phát nào nhận ra.

Đó là lý do giả định chung — “loa nghe ổn, nên hệ thống âm thanh ổn” — sụp đổ cho bất kỳ thứ gì nhạy thời gian. Chức năng và thời gian là hai trục riêng. Trước khi tin thiết lập cho thu, gọi hoặc game, bạn cần con số mà test phát không thể tạo ra.

Quan sát buffer đầy

Độ trễ khứ hồi không phải một độ trễ đơn lẻ. Nó là tổng các độ trễ tích lũy ở mỗi giai đoạn giữa màng mic và màng loa. Hiểu đường đi cho biết chính xác mili giây của bạn ẩn ở đâu:

  1. Buffer đầu vào. Converter analog sang digital lấy mẫu liên tục, nhưng hệ điều hành giao âm thanh theo khối. Driver đợi buffer đầy trước khi giao dữ liệu cho ứng dụng. Ở 48 kHz, buffer 128 mẫu mất 2.7 mili giây để đầy — đó là thời gian âm thanh chờ trước khi ai xử lý.
  2. Chuyển đổi analog sang digital. Converter cần thời gian lấy mẫu, lượng hóa và xung tín hiệu. Phần cứng tiêu dùng thường đóng góp một đến ba mili giây; giao diện chuyên nghiệp tốt hơn.
  3. Điều độ hệ điều hành. Engine âm thanh đánh thức ứng dụng theo timer, và việc thức dậy chịu điều độ thread bình thường. Ở chế độ dùng chung, hệ điều hành cũng trộn stream của bạn với mọi nguồn âm thanh khác, thêm một vòng xử lý.
  4. Xử lý ứng dụng. Phần mềm nhận — DAW, chuỗi hiệu ứng, đồ thị âm thanh trình duyệt — xử lý khối trước khi chuyển tiếp. Nhỏ, nhưng là một phần tổng.
  5. Chuyển đổi digital sang analog. Gương của giai đoạn hai, thêm một đến ba mili giây khi tín hiệu xử lý trở thành điện áp analog.
  6. Buffer đầu ra. Mẫu xử lý chờ trong buffer đầu ra cho đến khi converter sẵn sàng phát, lặp lại tính buffer từ phía đầu vào. Thêm năm đến tám mili giây trong cấu hình điển hình.

Cộng các giai đoạn, độ trễ khứ hồi chế độ dùng chung thường rơi giữa ba mươi và sáu mươi mili giây trên máy tính thường — không driver nào loại bỏ thời gian chuyển đổi, nhưng overhead buffer và điều độ, vốn chiếm phần lớn tổng, thu nhỏ đáng kể. Sơ đồ đường đi độ trễ âm thanh khứ hồi từ mic qua xử lý máy tính đến loa

Một con số, hai định nghĩa

Phần mềm âm thanh hiếm khi trích dẫn một con số. Mở cài đặt ứng dụng chuyên nghiệp, bạn thường thấy hai: độ trễ đầu vào, từ mic đến ứng dụng; và độ trễ đầu ra, từ ứng dụng đến loa. Driver như ASIO báo cả hai giá trị riêng, và tài liệu marketing thường trích dẫn số nào trông đẹp hơn.

Độ trễ khứ hồi là tổng hai giá trị cộng thời gian xử lý ứng dụng. Nếu hệ thống báo hai mươi mili giây một chiều, khứ hồi khoảng bốn mươi mili giây. Người dùng đọc “20 ms độ trễ” và cho đó là độ trễ sẽ nghe thì sai gấp đôi — và lỗi này phổ biến vì số một chiều là số in trên spec sheet.

Hệ điều hành quyết định trước bạn

Cùng mic, cùng loa, cùng cáp tạo độ trễ khác nhau trên các hệ điều hành, vì mỗi nền tảng định tuyến âm thanh qua stack phần mềm khác. Stack quyết định thêm bao nhiêu overhead buffer và điều độ lên thời gian chuyển đổi không thể tránh.

Windows: chế độ dùng chung, độc quyền và ASIO

Windows cung cấp ba cách tiếp cận phần cứng:

macOS: Core Audio

Core Audio của Apple được tối ưu tốt, ứng dụng native thường đạt 8-20 mili giây. Đường dùng chung hiệu quả, ngay cả độ trễ trình duyệt trên macOS thường tốt hơn Windows.

Linux: ALSA, PulseAudio và PipeWire

Độ trễ Linux là mục tiêu di động. ALSA nhanh nhưng đặc thù ứng dụng. PulseAudio thêm overhead buffer. PipeWire, bản thay thế hiện đại, thiết kế cho âm thanh thấp độ trễ. Biểu đồ mã màu cho thấy dải độ trễ âm thanh chấp nhận từ dưới 20ms chuyên nghiệp đến trên 120ms không phù hợp

60 mili giây thực sự có nghĩa gì

Một con số mili giây thô không có nghĩa gì cho đến khi bạn đối chiếu với dự định sử dụng. Bốn vùng bao phủ phạm vi thực tế:

  • Dưới 20 ms — xuất sắc. Sản xuất âm nhạc chuyên nghiệp thoải mái ở đây. Nhạc sĩ có thể thu theo nhịp, giám sát với hiệu ứng, và chơi đúng thời gian vì đường trả về gần như tức thời. Âm thanh không gian trong game khóa với hình.
  • 20–60 ms — chấp nhận cho hầu hết sử dụng. Podcast, gọi video, game chung và thu casual đều hoạt động tốt. Thu nhạc chặt bắt đầu khó gần đỉnh phạm vi: người chơi cảm nhận âm thanh trả về kéo nhẹ, và công việc chính xác khó hơn rõ rệt trên khoảng bốn mươi mili giây.
  • 60–120 ms — có vấn đề cho sản xuất, chấp nhận cho casual. Karaoke, chat thoại và nghe được. Thu theo backing track thực sự khó, và trong game âm thanh bắt đầu tách khỏi hành động, phá hủy cue vị trí mà âm thanh không gian phụ thuộc.
  • Trên 120 ms — kém. Công việc nhạy thời gian thực sự không thể. Cuộc gọi phát echo nghe được, hiệu suất cảm giác ngắt kết nối, và âm thanh không gian nghe sai ngay cả trong sử dụng casual. Vùng này là nhà tự nhiên của âm thanh Bluetooth và hệ thống dùng chung cấu hình sai.

Ranh giới vùng là phán đoán, nhưng hình dáng đáng tin: sản xuất cần số thấp nhất, đàm thoại dung nhiều hơn, nghe casual dung nhiều nhất. Đo lường khứ hồi đặt hệ thống của bạn vào đúng một vùng, và vị trí đó cho biết sử dụng dự định nào sẽ dễ chịu và nào sẽ chống lại bạn.

Ba đòn bẩy: tốc độ mẫu, buffer, driver

Ba điều khiển quyết định độ trễ của bạn nằm ở đâu trong đường, và chúng không tác động ngang. Tốc độ mẫu đặt throughput, không trực tiếp quyết định độ trễ. Nó tương tác với buffer: 128 mẫu mất 2.9 mili giây ở 44.1 kHz nhưng chỉ 1.3 mili giây ở 96 kHz. Nhưng tốc độ cao hơn đòi hỏi xử lý nhiều hơn, thường buộc tăng buffer để ổn định, triệt tiêu lợi ích. Dùng 48 kHz cho nhạc và video.

Kích thước buffer là đòn bẩy độ trễ chính. Nó xuất hiện hai lần trong khứ hồi — đầu vào và đầu ra. Halving buffer halving phần độ trễ đó, nhưng cũng halving thời gian giao khối, tăng rủi ro underrun. Ma trận thực tế ở 48 kHz:

  • 64 mẫu — khoảng 8-12 ms khứ hồi trên phần cứng ASIO.
  • 128 mẫu — khoảng 12-20 ms. Sweet spot ASIO.
  • 256 mẫu — khoảng 20-35 ms. Nhỏ nhất ổn định trong chế độ dùng chung.
  • 512 mẫu — khoảng 35-60 ms.
  • 1024 mẫu — khoảng 60-100 ms.

Driver đặt sàn. ASIO cho 32-128 mẫu; dùng chung sàn cao hơn; Bluetooth thêm 100 mili giây trước khi buffer được xem xét.

Trình duyệt không phải DAW

Trình duyệt có thể ước tính độ trễ khứ hồi dùng Web Audio API (MDN: Web Audio API, 2024). Đo lường loopback Web Audio điển hình báo 55-70 mili giây — gấp nhiều lần ASIO. Thời gian đo bao gồm đường âm thanh qua không khí, transducer loa và mic, xử lý echo cancellation, và toàn bộ stack âm thanh hệ thống. Đây là độ trễ khứ hồi âm học, liên quan cho gọi trong trình duyệt, karaoke và game, nhưng không tương đương độ trễ ASIO.

Sáu cách giảm độ trễ

Làm theo thứ tự tác động, dừng khi con số rơi vào vùng bạn chấp nhận:

  1. Sửa chế độ driver trước. Trên Windows, cài ASIO hoặc chuyển WASAPI độc quyền. Đòn bẩy lớn nhất và miễn phí.
  2. Giảm kích thước buffer. Giảm từ 512 xuống 256 xuống 128 xuống 64, test từng bước, cho đến khi nghe click. Quay lên một mức.
  3. Kiểm tra tốc độ mẫu. Dùng 48 kHz. Đuổi 96/192 kHz thường buộc buffer lớn hơn, cuối cùng chậm hơn.
  4. Đóng ứng dụng cạnh tranh. Streaming, capture và tab trình duyệt bận chiếm CPU.
  5. Xem xét giao diện âm thanh. Phần cứng chuyên dụng mang converter tốt hơn, driver ASIO đúng, và buffer onboard không đạt.
  6. Ưu tiên kết nối có dây. Tai nghe có dây beat Bluetooth 100 mili giây trở lên.

Kết luận

Test phát xác nhận loa hoạt động. Test loopback xác nhận chúng hoạt động đúng thời gian — và đó là hai câu hỏi khác nhau với câu trả lời khác nhau. Chạy test loa xác nhận đường đầu ra và test mic xác nhận đường đầu vào. Lưu ý site này hiện không cung cấp công cụ đo độ trễ loopback chuyên dụng.

Đo một lần và giữ kết quả. Dưới hai mươi mili giây nghĩa là timing cấp chuyên nghiệp. Hai mươi đến sáu mươi bao phủ hầu hết công việc hằng ngày. Trên một trăm hai mươi, mọi nhiệm vụ nhạy thời gian sẽ chống lại bạn, và sửa thường bắt đầu với driver, không phải phần cứng.

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

Test loa có cho biết thông tin về độ trễ âm thanh không?

Không. Test loa phát một âm qua loa và xác nhận có âm thanh ra. Nó đo xem đường đầu ra có hoạt động không, chứ không đo thời gian tín hiệu đi qua chuỗi đầu vào và đầu ra. Độ trễ là phép đo thời gian, không phải test chức năng, và hai thứ độc lập: hệ thống có thể vượt mọi kiểm tra phát lại mà vẫn có độ trễ thảm họa. Để đo độ trễ bạn cần test khứ hồi: gửi một xung đã biết qua đầu ra, bắt tín hiệu trả về ở đầu vào, và tính chênh lệch thời gian giữa gửi và nhận.

Độ trễ khứ hồi chính xác là gì?

Độ trễ khứ hồi là tổng thời gian từ khi tín hiệu vào hệ thống đến khi ra loa. Bao gồm buffer đầu vào, chuyển đổi A/D, lập lịch OS, xử lý app, chuyển đổi D/A, và buffer đầu ra. Đo bằng mili giây. WASAPI shared mode 30-60 ms, ASIO 8-15 ms, Core Audio 10-15 ms. Mỗi giai đoạn thêm trễ, tổng số quyết định khả năng ghi âm thời gian thực. Đo bằng trình duyệt bắt đường âm thanh qua không khí, còn ASIO báo đường điện nội bộ — không cùng con số.

Độ trễ đo được là 80 mili giây — có tệ cho sản xuất âm nhạc không?

Cho hầu hết sản xuất âm nhạc thì cao. Nhạc sĩ thu theo nhịp đập hoặc backing track thường thích độ trễ dưới bốn mươi mili giây để chơi đúng nhịp không có echo cảm nhận được. Ở tám mươi mili giây, độ trễ rõ ràng nghe được giữa những gì bạn chơi và những gì bạn nghe lại, khiến giữ nhịp chặt rất khó. Cho thu âm casual hoặc podcast, độ trễ замет nhưng thường dung được. Cho giám sát trực tiếp trong phiên thu, tám mươi mili giây thường không dùng được. Lưu ý dung sai cá nhân thay đổi theo kinh nghiệm và thể loại.

Tại sao độ trễ đo bằng trình duyệt thường cao hơn phần mềm âm thanh chuyên nghiệp?

Trình duyệt được thiết kế cho nhất quán đa nền tảng, không phải hiệu suất âm thanh chuyên nghiệp. DAW chuyên nghiệp dùng ASIO, bỏ qua lớp OS, đạt 8-15 ms. Trình duyệt phải đi qua lớp âm thanh dùng chung của OS, thêm overhead trộn và điều độ, không thể truy cập chế độ độc quyền thấp độ trễ. Trình duyệt đo đường dùng chung, vốn cao hơn đường driver trực tiếp. Đây là hạn chế kiến trúc, không phải vấn đề hiệu suất.

Driver ASIO giảm độ trễ bao nhiêu?

Trên Windows, chuyển từ WASAPI shared sang ASIO hoặc WASAPI exclusive giảm trễ từ 30-60 ms xuống 8-15 ms. Mức giảm phụ thuộc giao diện âm thanh và driver. ASIO cho app truy cập trực tiếp buffer phần cứng, bỏ qua trình trộn Windows và overhead buffer liên quan. Không phải card nào cũng hỗ trợ ASIO; âm thanh onboard rẻ thường không. Cho công việc chuyên nghiệp trên Windows, giao diện âm thanh có ASIO là nâng cấp quan trọng nhất ảnh hưởng đến độ trễ.

Tốc độ mẫu cao hơn có nghĩa là độ trễ thấp hơn không?

Không trực tiếp. Tốc độ mẫu quyết định số lần đo âm thanh mỗi giây, ảnh hưởng đáp ứng tần số và chi phí xử lý nhưng không ảnh hưởng độ trễ buffer. Kích thước buffer là điều khiển độ trễ chính — buffer nhỏ hơn nghĩa là ít thời gian chờ dữ liệu tích lũy trước xử lý. Tuy nhiên, tốc độ mẫu cao hơn làm tăng throughput dữ liệu cho cùng kích thước buffer, có thể gây buffer underrun nếu hệ thống không theo kịp. Cách tiếp cận thực tế: đặt tốc độ mẫu phù hợp workflow, thường 48 kHz, rồi tối thiểu hóa kích thước buffer.

Kích thước buffer ảnh hưởng đến độ trễ và ổn định như thế nào?

Kích thước buffer quyết định bao nhiêu mẫu âm thanh được lưu trong bộ nhớ trước khi xử lý. Buffer nhỏ giảm độ trễ nhưng để lại cho hệ thống ít thời gian giao khối dữ liệu tiếp theo, tăng nguy cơ buffer underrun — click, pop hoặc dropout nghe được. Buffer lớn ổn định hơn nhưng thêm độ trễ. Điểm tối ưu phụ thuộc phần cứng: máy tính nhanh với giao diện âm thanh tốt có thể dùng buffer 64 hoặc 128 mẫu với độ trễ thấp và không glitch. Hệ thống chậm hơn có thể cần 512 hoặc 1024 mẫu để ổn định.

Tại sao tai nghe Bluetooth có độ trễ cao như vậy?

Codec Bluetooth thêm trễ xử lý đáng kể cho nén và truyền. SBC mặc định thêm 100-180 ms (Bluetooth.com), aptX 40-80 ms (Qualcomm, 2014), aptX Low Latency 32-40 ms. Trễ là vốn có của giao thức không dây — codec phải nén, truyền, giải nén mỗi khung. Cho ứng dụng nhạy thời gian — sản xuất âm nhạc, game, chỉnh sửa video — tai nghe có dây là lựa chọn thực tế. Bluetooth chỉ chấp nhận được cho nghe không yêu cầu thời gian.