Bạn gọi Google Meet, bật loa ngoài thật to, vậy mà người bên kia không hề nghe thấy giọng mình dội lại. Quạt trần vù vù, tiếng gõ phím lạch cạch, nhưng giọng bạn đến tai họ vẫn khá sạch. Việc này do một bộ xử lý âm thanh chạy ngầm trong trình duyệt làm: WebRTC Audio Processing. Bài này đi qua từng khâu của nó, giải thích vì sao nó làm tốt, vì sao đôi khi nó làm hỏng giọng bạn, và khi nào nên tắt nó đi.
Vấn đề: micro không biết chọn lọc
Micro chỉ là một cái màng rung. Nó thu mọi thứ có trong phòng, gồm:
- Giọng bạn (thứ duy nhất cần gửi đi).
- Tiếng loa đang phát giọng của người bên kia.
- Tiếng ồn nền: quạt, điều hoà, xe ngoài đường.
- Tiếng ồn đột ngột: gõ phím, đóng cửa, chó sủa.
- Tiếng vang của chính căn phòng, tức âm thanh dội qua tường, trần, mặt bàn.
Nếu gửi nguyên tín hiệu này đi, người bên kia sẽ nghe một mớ hỗn độn. Tệ nhất là họ nghe lại chính giọng mình sau vài trăm mili giây, vì giọng họ phát ra loa của bạn rồi lọt ngược vào micro. Ai từng gọi điện mà nghe tiếng mình vọng lại đều biết cảm giác đó khó chịu đến mức gần như không nói tiếp được.
Audio Processing Module là gì và ai đang dùng nó
Tên chính thức của bộ xử lý này là Audio Processing Module (APM). Nó là một phần của thư viện WebRTC mã nguồn mở do Google phát triển. Vì là mã nguồn mở và chạy được trên nhiều nền tảng, APM có mặt ở rất nhiều nơi:
- Trình duyệt Chrome, Edge và các trình duyệt nhân Chromium, mỗi khi một trang web xin quyền dùng micro qua
getUserMedia. - Các ứng dụng gọi điện chạy trên web như Google Meet hay Discord bản web.
- Nhiều ứng dụng gọi điện, livestream, trợ lý giọng nói tự nhúng thư viện này vào thay vì tự viết lại từ đầu.
Nói cách khác, khi bạn gọi qua trình duyệt, khả năng rất cao là giọng bạn đã đi qua đúng bộ xử lý này trước khi được mã hoá và gửi lên mạng.
Điểm mấu chốt: nhận cùng lúc hai luồng âm thanh
Hầu hết bộ lọc âm thanh thông thường chỉ nhìn thấy một tín hiệu: thứ micro thu được. APM khác ở chỗ nó nhận hai luồng song song:
| Luồng | Tên trong WebRTC | Nội dung | Dùng để làm gì |
|---|---|---|---|
| Luồng xa | render (reverse stream) | Âm thanh sắp phát ra loa, tức giọng người bên kia | Làm "tham chiếu" để biết tiếng vọng trông như thế nào |
| Luồng gần | capture | Âm thanh micro vừa thu | Tín hiệu cần làm sạch rồi gửi đi |
Nhờ biết trước loa sắp phát ra cái gì, APM có thể đi tìm đúng "bản sao" của âm thanh đó trong tín hiệu micro rồi loại bỏ nó. Đây là nền tảng của khử tiếng vọng, khâu khó nhất trong cả dây chuyền.
Nhịp xử lý: từng khối 10 mili giây
APM không xử lý cả đoạn ghi âm một lần. Nó làm việc theo khối (frame) dài 10 ms. Ở tần số lấy mẫu 48.000 mẫu/giây, mỗi khối gồm 480 mẫu. Một giây âm thanh tương ứng với 100 khối, nên hàm xử lý được gọi 100 lần mỗi giây cho mỗi luồng.
Lý do chọn khối ngắn là độ trễ. Cuộc gọi thời gian thực cần độ trễ đầu cuối càng thấp càng tốt. Nếu bộ xử lý chờ gom 200 ms rồi mới làm, mọi câu nói đều bị chậm thêm 200 ms. Với khối 10 ms, phần trễ mà APM thêm vào chỉ ở mức vài mili giây, gần như không cảm nhận được.
Ở tần số lấy mẫu cao như 48 kHz, APM tách tín hiệu thành nhiều dải tần con trước khi xử lý. Phần lớn thuật toán tập trung vào dải thấp, nơi chứa hầu hết năng lượng giọng nói, giúp tiết kiệm CPU mà vẫn giữ chất lượng.
Dây chuyền 4 bước và vì sao thứ tự quan trọng
Mỗi khối capture đi qua một dây chuyền cố định:
- Lọc thông cao (high-pass filter)
- Khử tiếng vọng (AEC, acoustic echo cancellation)
- Khử nhiễu (noise suppression)
- Tự cân âm lượng (AGC, automatic gain control)
Thứ tự này có lý do. Khử vọng phải chạy trước khử nhiễu và AGC, vì bộ khử vọng cần so tín hiệu micro với tín hiệu loa theo quan hệ gần như tuyến tính. Nếu khử nhiễu đã cắt xén phổ, hay AGC đã tăng giảm âm lượng trước đó, quan hệ này bị phá vỡ và bộ lọc thích nghi không còn mô phỏng đúng được nữa. AGC đứng cuối vì nó cần đo mức của giọng nói đã sạch. Nếu đứng đầu, nó sẽ khuếch đại luôn cả tiếng vọng lẫn tiếng ồn.
Bước 1: Lọc thông cao
Bộ lọc này cắt các tần số rất trầm, khoảng dưới 80 Hz: tiếng ù điện lưới, tiếng rung khi ai đó đập tay xuống bàn, tiếng gió thổi trực tiếp vào micro. Giọng nói của người gần như không có năng lượng hữu ích ở vùng này, nên cắt đi không làm giọng mỏng hơn. Ngược lại, nó dọn sạch một lượng năng lượng thừa có thể làm các bước sau tính toán sai.
Khử tiếng vọng: khâu khó nhất
Bộ lọc thích nghi
Ý tưởng của AEC khá gọn: đã biết tín hiệu loa (luồng render), giờ chỉ cần biết căn phòng biến đổi tín hiệu đó ra sao trước khi nó tới micro. Đường đi "loa → phòng → micro" được mô hình hoá bằng một bộ lọc thích nghi. Bộ lọc này liên tục tự điều chỉnh để đầu ra của nó giống phần tiếng vọng trong micro nhất có thể. Có được bản dự đoán rồi thì chỉ cần trừ nó khỏi tín hiệu micro.
"Thích nghi" là vì căn phòng không cố định. Bạn xoay laptop, có người đi ngang, bạn chỉnh âm lượng loa, và đường truyền âm thay đổi theo. Bộ lọc phải học lại liên tục.
Độ trễ: điểm yếu chết người
Từ lúc âm thanh được đưa xuống card âm thanh để phát ra loa cho đến lúc nó quay lại trong tín hiệu micro có một độ trễ. Độ trễ này gồm bộ đệm của hệ điều hành, driver, phần cứng và quãng đường âm thanh đi trong không khí. Tuỳ máy, nó có thể từ vài chục đến vài trăm mili giây, và có thể thay đổi giữa cuộc gọi.
Nếu bộ lọc thích nghi bị đặt lệch thời gian, nó đang so tín hiệu micro với sai đoạn tín hiệu loa, và tiếng vọng lọt qua. Phiên bản khử vọng hiện tại của WebRTC là AEC3, có bộ ước lượng độ trễ riêng chạy liên tục để dò đúng độ lệch giữa hai luồng rồi căn chỉnh lại.
Nén tiếng vọng dư và chuyện "nói cùng lúc"
Phép trừ không bao giờ hoàn hảo. Loa rẻ tiền gây méo phi tuyến, phòng có vang dài, và phần còn sót lại gọi là tiếng vọng dư. AEC3 có thêm bộ nén tiếng vọng dư (residual echo suppressor), giảm biên độ ở những dải tần mà nó cho là vẫn còn vọng.
Tình huống khó nhất là double-talk, khi cả hai bên cùng nói. Lúc này micro chứa cả giọng bạn lẫn tiếng vọng của người kia. Bộ nén phải chọn: nén mạnh thì sạch vọng nhưng giọng bạn bị "nuốt", nén nhẹ thì giữ giọng nhưng người kia nghe vọng. Hiện tượng mất vài chữ đầu câu khi hai người tranh lời trong cuộc gọi thường bắt nguồn từ đây.
Đeo tai nghe. Khi âm thanh không phát ra loa, không có gì để dội ngược vào micro, và bộ khử vọng gần như không phải làm việc. Đây là lý do gọi bằng tai nghe luôn nghe tự nhiên hơn bật loa ngoài, kể cả khi thuật toán đã rất tốt.
Khử nhiễu: giỏi với nhiễu đều, kém với nhiễu đột ngột
Bước thứ ba dựa trên một quan sát đơn giản: tiếng quạt hay điều hoà gần như không đổi theo thời gian. Bộ khử nhiễu tận dụng những lúc bạn im lặng để học phổ tần của tiếng ồn nền. Sau đó, ở từng dải tần, nó ước lượng tỉ lệ giữa giọng nói và nhiễu. Dải nào nhiễu lấn át thì giảm mạnh biên độ, dải nào giọng nói chiếm ưu thế thì giữ lại.
Phương pháp này hiệu quả với nhiễu dừng (stationary). Nhưng tiếng gõ phím, tiếng đập cửa, tiếng chó sủa xuất hiện đột ngột và có phổ rộng, bộ khử nhiễu chưa kịp học thì chúng đã qua. Đây là giới hạn của cách khử nhiễu cổ điển, và cũng là lý do nhiều ứng dụng hiện nay bổ sung thêm khử nhiễu bằng mạng nơ-ron bên cạnh APM.
Khi mức khử nhiễu bị đẩy quá cao, bộ lọc bắt đầu cắt vào chính các dải tần của giọng nói. Kết quả là giọng nghe méo, có tiếng "lục bục" như đang nói dưới nước. Giọng sạch nhưng nghe như robot thường tệ hơn giọng có chút tiếng quạt.
Tự cân âm lượng (AGC) và bộ phát hiện giọng nói
Người nói nhỏ, người ngồi xa micro, người hét to. Nếu không can thiệp, người nghe phải liên tục chỉnh âm lượng. AGC đo mức của giọng nói rồi tự tăng hoặc giảm độ khuếch đại để đưa về một mức mục tiêu ổn định. Cuối dây chuyền có thêm bộ giới hạn (limiter) chặn đỉnh tín hiệu, tránh âm thanh bị vỡ khi ai đó đột ngột nói to.
Để không khuếch đại nhầm tiếng ồn trong lúc im lặng, AGC dựa vào bộ phát hiện giọng nói (VAD, voice activity detection). Khi không có ai nói, AGC giữ nguyên độ khuếch đại thay vì kéo tiếng quạt lên cho "đủ to". Tín hiệu có hay không có giọng nói này còn có ích cho khâu sau: bộ mã hoá Opus có chế độ DTX, có thể gửi rất ít dữ liệu trong những đoạn im lặng, giúp tiết kiệm băng thông.
Trong trình duyệt: bật mặc định, tắt khi cần
Khi một trang web xin micro qua getUserMedia, ba tuỳ chọn echoCancellation, noiseSuppression và autoGainControl thường được bật sẵn. Với cuộc gọi, đó là lựa chọn đúng. Nhưng nếu bạn làm ứng dụng thu nhạc, podcast, hay thu âm nhạc cụ, cả ba lại gây hại:
- Khử nhiễu coi tiếng đàn kéo dài, tiếng pad hay tiếng vang tự nhiên là nhiễu và cắt bớt.
- AGC làm phẳng dải động: đoạn nhỏ bị kéo lên, đoạn to bị ép xuống.
- Khử vọng có thể nuốt mất âm thanh khi bạn vừa phát nhạc nền vừa thu.
Lập trình viên có thể tắt từng tuỳ chọn khi xin micro:
const stream = await navigator.mediaDevices.getUserMedia({
audio: {
echoCancellation: false,
noiseSuppression: false,
autoGainControl: false,
},
});
Muốn xem APM đang hoạt động thế nào trong một cuộc gọi trên Chrome, bạn có thể mở trang chrome://webrtc-internals ở tab khác. Trang này hiện thống kê chi tiết của từng kết nối WebRTC đang chạy.
Checklist nhanh cho người gọi điện thường xuyên:
- [ ]Dùng tai nghe khi có thể, nhất là ở phòng nhiều vang.
- [ ]Hạ âm lượng loa ngoài nếu bắt buộc phải dùng loa.
- [ ]Đặt micro gần miệng hơn để giọng lấn át tiếng ồn nền.
- [ ]Tránh để micro sát quạt, điều hoà hay bàn phím.
- [ ]Nếu thu nhạc hoặc podcast trên web, tìm tuỳ chọn tắt khử nhiễu và tự cân âm lượng trong ứng dụng.
Thuật toán tốt đến đâu cũng chỉ sửa được phần nào. Đưa micro lại gần và bớt tiếng loa vẫn là cách khử vọng, khử ồn hiệu quả nhất.
Tóm tắt nhanh
- WebRTC Audio Processing (APM) là bộ xử lý âm thanh mã nguồn mở của Google, chạy trong Chrome và nhiều ứng dụng gọi điện.
- Nó nhận hai luồng: tín hiệu sắp phát ra loa (render) và tín hiệu micro (capture), xử lý theo khối 10 ms.
- Dây chuyền gồm lọc thông cao, khử tiếng vọng (AEC3), khử nhiễu và tự cân âm lượng, theo đúng thứ tự đó.
- Khử vọng dựa vào bộ lọc thích nghi và ước lượng độ trễ. Khi hai người cùng nói, giọng có thể bị nuốt vài chữ.
- Ba tuỳ chọn khử vọng, khử nhiễu, tự cân âm lượng bật mặc định trong trình duyệt. Nên tắt khi thu nhạc hoặc podcast.
Câu hỏi thường gặp
Vì sao gọi bằng loa ngoài đôi khi vẫn nghe tiếng vọng?
Thường do độ trễ giữa loa và micro trên máy đó thay đổi thất thường, hoặc loa bị méo khi để âm lượng quá lớn, khiến bộ lọc thích nghi không mô phỏng đúng. Giảm âm lượng loa hoặc dùng tai nghe thường giải quyết được.
Vì sao giọng tôi bị cụt chữ khi cả hai cùng nói?
Đó là tình huống double-talk. Bộ nén tiếng vọng dư không phân biệt được hoàn toàn giọng bạn với tiếng vọng của người kia, nên đôi khi nén luôn cả giọng bạn. Dùng tai nghe loại bỏ gần hết vấn đề này.
Có nên tắt khử nhiễu khi họp online không?
Không nên, trừ khi phòng bạn rất yên tĩnh và micro tốt. Khử nhiễu giúp người nghe đỡ mệt hơn nhiều. Chỉ nên tắt khi thu nhạc, podcast hoặc âm thanh cần giữ nguyên chất.
APM có làm tăng độ trễ cuộc gọi không?
Có, nhưng rất ít. Vì xử lý theo khối 10 ms, phần trễ mà APM thêm vào chỉ ở mức vài mili giây, nhỏ hơn rất nhiều so với độ trễ mạng.
