- Chất lượng âm thanh thấp của codec SBC tiêu chuẩn không chỉ đến từ giới hạn của codec, mà còn từ các hạn chế bảo thủ trong Bluetooth stack và cấu hình tai nghe; các thiết bị hiện có vẫn có khả năng cải thiện bằng sửa đổi phần mềm
- Bluetooth stack thông thường thường thương lượng âm thanh stereo 44,1kHz ở 328kbps, nhưng nếu ép dùng Dual Channel thì với cùng bitpool 53 có thể tăng lên khoảng 617kbps
- Bản vá Android 8.1 và 9 thêm SBC Dual Channel vào phần cài đặt thiết bị Bluetooth như một tùy chọn HD Audio, và dùng 551kbps cho thiết bị EDR 3Mb/s, 452kbps cho thiết bị EDR 2Mb/s
- 551kbps và 452kbps là các giá trị được chọn có tính đến hiệu suất truyền 5-slot của Bluetooth; nếu tăng bitpool thêm, số khung có thể gộp lại sẽ giảm, làm tăng khả năng bị ngắt quãng trong môi trường không dây xấu
- Người dùng LineageOS, Resurrection Remix, crDroid có thể bật SBC bitrate cao bằng checkbox trong cài đặt; người dùng Linux có thể dùng bản vá PulseAudio để có bitrate SBC cao hơn và hỗ trợ các biến thể aptX
Vì sao chất lượng âm thanh SBC nghe kém
- Một số người dùng tai nghe không dây gặp tình trạng suy giảm chất lượng âm thanh và thiếu dải cao với codec SBC, vốn được mọi thiết bị âm thanh Bluetooth hỗ trợ
- Cũng có thể mua thiết bị và tai nghe hỗ trợ aptX hoặc LDAC, nhưng các codec này cần phí bản quyền và có thể làm tăng giá thiết bị
- Nguyên nhân cốt lõi của chất lượng SBC thấp là các giới hạn nhân tạo trong Bluetooth stack hiện tại và cấu hình tai nghe; ngay cả thiết bị hiện có cũng có thể vượt qua bằng sửa đổi phần mềm
Tham số SBC và bitrate
- SBC thương lượng nhiều tham số trong giai đoạn thiết lập kết nối
- Loại và số lượng kênh âm thanh: Joint Stereo, Stereo, Dual Channel, Mono
- Số dải tần: 4 hoặc 8
- Số block âm thanh trong mỗi gói: 4, 8, 12, 16
- Cách phân bổ bit lượng tử hóa: Loudness, SNR
- bitpool tối thiểu/tối đa dùng cho lượng tử hóa: thường là 2..53
- Bộ giải mã phải hỗ trợ mọi tổ hợp tham số này, nhưng bộ mã hóa có thể chỉ triển khai một phần
- Các Bluetooth stack hiện nay thường thương lượng tổ hợp Joint Stereo, 8 bands, 16 blocks, Loudness, bitpool 2..53; khi đó âm thanh stereo 44,1kHz được mã hóa ở 328kbps
- bitpool là giá trị thay đổi bitrate mã hóa; giá trị càng cao thì bitrate và chất lượng càng tăng
- Tương ứng chính xác giữa giá trị bitpool và bitrate chỉ đúng trong một profile cụ thể
- Loại kênh, số dải tần và số block âm thanh cũng ảnh hưởng lớn đến bitrate
- Khác với Stereo hoặc Joint Stereo, Dual Channel mã hóa từng kênh riêng biệt và dùng bitpool riêng cho mỗi kênh
- Nếu ép dùng Dual Channel thay vì Joint Stereo, ngay cả với cùng bitpool 53, bitrate cũng tăng gần gấp đôi, lên khoảng 617kbps
Đặc tả A2DP và giới hạn của các stack hiện tại
- A2DP specification v1.2, có hiệu lực từ năm 2007 đến 2015, yêu cầu bộ giải mã hỗ trợ mọi giá trị bitpool không vượt quá bitrate tối đa
- Profile này giới hạn bitrate tối đa ở 320kb/s với mono và 512kb/s với chế độ 2 kênh
- Đặc tả mới không nêu rõ giới hạn bitrate
- Có thể giả định rằng tai nghe đời mới hỗ trợ EDR, phát hành sau năm 2015, có thể hỗ trợ tối đa 730kbps
- Các Bluetooth stack đã thử nghiệm gồm Linux PulseAudio, Android, Blackberry, macOS đều đặt giới hạn nhân tạo lên tham số bitpool tối đa
- Gần như mọi tai nghe cũng giới hạn giá trị bitpool tối đa ở 53
- Với Bluetooth stack đã sửa, phần lớn thiết bị hoạt động ở 551kbps mà không bị ngắt quãng hay nhiễu, nhưng Bluetooth stack mặc định không thương lượng bitrate này trong điều kiện thông thường
Bản vá Bluetooth stack cho Android
- Mọi Bluetooth stack tương thích A2DP đều phải hỗ trợ chế độ Dual Channel, nhưng người dùng phổ thông không có cách ép dùng chế độ này
- Bản vá cho Android 8.1 và Android 9 thêm Dual Channel vào stack và menu nhà phát triển, đồng thời xử lý nó như một tùy chọn codec HD Audio trong phần cài đặt thiết bị Bluetooth, giống aptX, AAC, LDAC
- Liên kết bản vá
- Checkbox này bật/tắt chế độ Dual Channel và dùng bitrate sau tùy theo thiết bị
- Thiết bị EDR 3Mb/s: 551kbps
- Thiết bị EDR 2Mb/s: 452kbps
- Bộ bản vá đã được merge vào các firmware thay thế sau
- LineageOS 15.1: từ ngày 31/3/2019
- LineageOS 16.0: từ ngày 13/5/2019
- Resurrection Remix: từ ngày 14/5/2019
- crDroid: từ ngày 13/5/2019
Vì sao chọn 551kbps và 452kbps
- Truyền phân chia thời gian của Bluetooth được thiết kế để gửi hiệu quả các gói lớn có kích thước cố định
- Số slot tối đa có thể gửi trong một lần truyền là 5, và cũng có chế độ truyền 1-slot và 3-slot, nhưng không có chế độ 2-slot và 4-slot
- Lượng dữ liệu có thể gửi trong truyền 5-slot như sau
- Kết nối 2Mbps: tối đa 679 bytes
- Kết nối 3Mbps: tối đa 1021 bytes
- Lượng dữ liệu tối đa của truyền 3-slot như sau
- Kết nối 2Mbps: 367 bytes
- Kết nối 3Mbps: 552 bytes
- Nếu gửi dữ liệu lớn hơn 367 hoặc 552 bytes nhưng nhỏ hơn 679 hoặc 1021 bytes, vẫn cần 5-slot, khiến hiệu suất truyền giảm
- Khi mã hóa âm thanh 44,1kHz bằng SBC Dual Channel, bitpool 38, 16 blocks, 8 frequency bands, ta có khung âm thanh 164-byte và bitrate 452kbps
- Audio payload phải được bọc bằng các giao thức truyền L2CAP và AVDTP; trong quá trình này, audio payload mất 16 bytes overhead
- Với EDR 2Mb/s DH5, một lần truyền âm thanh 5-slot có thể chứa 4 khung âm thanh
679 - 4(L2CAP) - 12(AVDTP/RTP) - 1(SBC header) - (164*4) = 6- Gói còn dư 6 bytes
- Một gói đơn có thể chứa tối đa 11,7ms dữ liệu âm thanh và được truyền trong 3,75ms
- Chỉ cần tăng bitpool một chút là không thể chứa 4 khung âm thanh trong một lần truyền, buộc phải gửi từng nhóm 3 khung
- Hiệu suất truyền giảm
- Lượng âm thanh chứa trong một gói giảm
- Khả năng âm thanh bị ngắt quãng trong môi trường không dây xấu tăng lên
- 551kbps cho EDR 3Mb/s cũng được chọn theo cùng nguyên lý
- Với bitpool 47, 16 blocks per frame, 8 frequency bands, kích thước khung là 200 bytes
- Có thể gộp tối đa 5 khung trong một lần truyền, tức 14,6ms nhạc
- Việc tính tham số SBC phức tạp và dễ sai khi tính thủ công; có công cụ web để tính toán
Khác biệt chất lượng âm thanh giữa aptX và SBC
- Trái với quan niệm rằng aptX luôn tốt hơn SBC, trong một số trường hợp aptX có thể cho chất lượng âm thanh thấp hơn SBC 328kbps tiêu chuẩn
- SBC phân bổ động các bit lượng tử hóa cho các dải tần, phân phối bit từ dải thấp lên dải cao
- Nếu dùng toàn bộ bitrate cho tần số thấp và trung, tần số cao sẽ bị cắt hoặc xử lý thành im lặng
- aptX là codec bitrate cố định, luôn lượng tử hóa các dải tần bằng cùng số bit
- 352kbps ở 44,1kHz
- 384kbps ở 48kHz
- aptX không thể chuyển bit sang các tần số cần thiết và tuy không cắt tần số, nó thêm nhiễu lượng tử hóa, làm giảm dải động của âm thanh và đôi khi tạo ra nhiễu
- Ngược lại, SBC bỏ các vùng yên tĩnh; so với SBC 328kbps, aptX trung bình có ít méo hơn với nhạc có dải tần rộng
- Với nhạc có dải tần hẹp và dải động rộng, SBC 328kbps đôi khi có thể tốt hơn aptX
- Trong ví dụ bản ghi piano, phần lớn năng lượng nằm ở 0–4kHz và kéo dài đến 10kHz
- SBC 328kbps định kỳ cắt hoàn toàn dải từ 16kHz trở lên
- aptX đưa nhiều méo hơn vào phổ tần mà con người nghe được
- SBC 328kbps tạo ít méo hơn trong dải 0–10kHz và cắt các tần số còn lại
- SBC 485kbps đủ để bảo toàn toàn bộ dải tần mà không cắt
- Có cung cấp dữ liệu âm thanh gốc và các tệp mã hóa SBC/aptX
- Dùng SBC bitrate cao sẽ cho âm thanh tốt hơn aptX trong phần lớn trường hợp; với tai nghe hỗ trợ EDR 3Mb/s, SBC 551kbps cho âm thanh rất gần với aptX HD
Tùy chọn bitrate cao hơn
- Bộ bản vá Android có tùy chọn bổ sung để tăng bitrate cho thiết bị EDR 2Mb/s
- Nếu đặt giá trị
persist.bluetooth.sbc_hd_higher_bitrate thành 1, có thể tăng bitrate từ 452kbps lên 595kbps
- Tùy chọn này có thể làm giảm độ ổn định truyền trong môi trường không dây đông đúc
# setprop persist.bluetooth.sbc_hd_higher_bitrate 1
- Bản vá bitrate cực cao hiện chỉ được merge vào LineageOS 15.1, chưa được merge vào LineageOS 16.0
Thiết bị tương thích và công cụ so sánh
- SBC Dual Channel được hỗ trợ trên hầu hết tai nghe, loa và head unit trên ô tô
- Vì tiêu chuẩn yêu cầu mọi thiết bị giải mã phải hỗ trợ chế độ này, nó hoạt động trên phần lớn thiết bị
- Có một số ít thiết bị gặp vấn đề ở chế độ này, nhưng đây là trường hợp rất hiếm
- Có thể xem thông tin thiết bị tương thích trong các cộng đồng sau
- Cũng có dịch vụ web mã hóa âm thanh theo thời gian thực sang SBC, aptX, aptX HD trong trình duyệt
- btcodecs.valdikss.org.ru/sbc-encoder
- Có thể so sánh âm thanh của nhiều profile SBC và các codec khác trên tai nghe hoặc loa có dây mà không cần truyền thực tế qua Bluetooth
- Có thể trực tiếp thay đổi tham số mã hóa ngay cả khi đang phát âm thanh
Nỗ lực đưa vào AOSP và cách sử dụng
- Đã liên hệ với các nhà phát triển Bluetooth stack của Google để đề nghị đưa bản vá vào nhánh chính của Android là AOSP, nhưng không nhận được phản hồi
- Bản vá đưa lên Gerrit code review system for Android cũng không nhận được bình luận từ những người liên quan đến phát triển Android
- Bộ bản vá trên Gerrit là một trong các revision ban đầu đã cũ, và có thể được cập nhật nếu nhà phát triển quan tâm
- Người dùng LineageOS, Resurrection Remix, crDroid có thể bật checkbox trong phần cài đặt thiết bị Bluetooth để tăng chất lượng âm thanh Bluetooth
- Người dùng Linux có thể cài bản vá PulseAudio của Pali Rohár để dùng bitrate SBC cao hơn
- Bản vá này cũng thêm hỗ trợ các codec aptX, aptX HD, FastStream
1 bình luận
Ý kiến trên Hacker News
Cái này rất tuyệt: SBC được hỗ trợ rộng rãi, và trông như một phần mở rộng tự nhiên của tiêu chuẩn hiện có
Cá nhân tôi thấy vấn đề không phải là SBC hay LDAC/AAC, mà là HFP quá tệ. Ngay khoảnh khắc micro được bật, cảm giác như quay về thập niên 90; nếu có thể làm âm thanh Bluetooth hai chiều cho tử tế thì thật đáng mừng
Hoặc có thể là AVRCP, nhưng dù là cái nào thì âm thanh cũng kinh khủng
Bài này không nói về Bluetooth nói chung, mà đào sâu vào một lỗi bị chôn trong ngăn xếp Bluetooth của Android
Điều tác giả hoàn toàn không thừa nhận là phần cứng nền tảng rất đa dạng. Android chạy trên vô số chipset Bluetooth, nên việc bản vá có vẻ hoạt động trên phần cứng của tác giả không đảm bảo nó cũng chạy được trên các điện thoại Android khác
Ngoài ra, thiết bị đang làm gì tại thời điểm đó cũng có ảnh hưởng. Nếu trên chipset dùng chung BT+Wi-Fi, bạn stream video qua Wi-Fi đồng thời gửi âm thanh tới tai nghe, thiết bị phải phân bổ tài nguyên giữa lưu lượng Wi-Fi và Bluetooth. Vì vậy âm thanh lưu cục bộ và âm thanh stream không nhất thiết nhận cùng tham số codec
Chủ đề này có quá nhiều yếu tố tinh vi mà tác giả chưa xét đến, nên cần thận trọng với những gì đọc được
Nhờ vậy có thể dùng bitrate cao hơn mà không vượt quá bitpool tối đa do Android và bộ thu Bluetooth áp đặt
Việc thương lượng giữa nguồn và bộ thu vẫn diễn ra; nếu một trong hai bên không hỗ trợ SBC kênh đôi thì sẽ quay về phương thức được hỗ trợ. Các thiết bị tôi bảo trì đều hỗ trợ, còn một số loa giá rẻ tôi thử lúc đó không hỗ trợ nên đã thương lượng thành phiên joint stereo
Trên Windows, Alternative A2DP Driver cung cấp tính năng này. Nó cho phép điều chỉnh tham số SBC, và cũng dùng được AAC hoặc aptX
Theo trải nghiệm của tôi thì hoạt động tốt, và cũng giúp dùng LDAC trên Sony XM4. Nó theo dạng dùng thử nhưng giá rẻ
Tôi từng thấy phạm vi Bluetooth giảm khi ở chế độ chất lượng cao, trông như dấu hiệu rằng codec, hoặc ít nhất là một thứ gì đó, thực sự đã thay đổi chứ không phải hiệu ứng placebo
Không liên quan gì đến https://www.bluetoothgoodies.com/a2dp/
Dải nghe được của con người thường được ghi nhận tới 20KHz, nhưng một số người trẻ có thể nghe được tần số nhỉnh hơn một chút
Nhân tiện, trên Linux cũng có thể bật âm thanh SBC bitrate cao hơn bằng cách gọi là SBC XQ. Tương tự, cũng có thể dùng mSBC để có âm thanh headset tốt hơn
Tất nhiên vẫn hoàn toàn chưa đạt tới mức như SBC hay aptX
Ước gì phía Google đã merge những thứ như vậy rồi. Các codec âm thanh tốt hơn được nhiều tai nghe và thiết bị hỗ trợ, nhưng không phổ quát; cải thiện âm thanh hai chiều thì đặc biệt vẫn còn thiếu
Tôi cũng muốn biết cách kiểm tra headset hiện đang dùng gì
Tôi nhớ trước đây từng dùng một bản PulseAudio đã vá để lộ ra các thiết lập phù hợp, sau đó nghe nói đã được “merge vào mainstream”, nhưng rốt cuộc không tìm được thiết lập hay thông tin sử dụng thực tế
Ước gì ai đó tạo ra một profile âm thanh Bluetooth có thể buffer trước thật lâu
Ví dụ khi phát một bài hát dài 1 phút, toàn bộ bài hát nên được đưa vào buffer. Tất nhiên nếu tạm dừng hoặc đổi âm lượng thì buffer phải bị bỏ
Có buffer dài thì điện thoại có thể ngủ thường xuyên hơn để tiết kiệm điện, và cũng chịu được kết nối không dây kém
Dù chỉ khoảng 1–2MB RAM, tai nghe vẫn phải dùng lượng pin quý giá để giữ RAM đó ở trạng thái hoạt động
Từ chút kinh nghiệm từng làm với ứng dụng âm thanh, tôi nghĩ hỗ trợ ở phía ứng dụng cũng sẽ rắc rối
Vì vậy đây gần với một tính năng do từng sản phẩm thiết kế đưa vào, và cho phép người dùng bật/tắt trong ứng dụng, hơn là vấn đề giao thức
Tôi đã dùng tính năng này trên LineageOS và thật lòng là nó rất tốt. Có thể gửi âm thanh chất lượng cao hơn tới những thiết bị như stereo trên xe hơi không hỗ trợ codec bên thứ ba, và cũng khá hữu ích với tai nghe
Trải nghiệm người dùng cần được trau chuốt, nhưng bản thân tính năng thì tuyệt vời
Nên thêm 2019 vào tiêu đề. Có những cụm như “mọi ngăn xếp Bluetooth hiện nay”, nhưng các thứ này đã được triển khai trong PulseAudio và PipeWire một thời gian rồi
Tôi hơi hoài nghi việc Dual Channel 551kbps cho chất lượng tốt hơn rõ rệt so với Joint Stereo 328kbps. Có thể chỉ là dùng nhiều bit hơn để mã hóa thông tin trùng lặp
Ít nhất là với phần lớn nhạc, dù có thể có ngoại lệ như các bài cố ý đặt các track thu âm khác nhau ở kênh trái/phải
Một câu hỏi liên quan: không biết có cách nào cải thiện Bluetooth HFP trên macOS không
Cùng một headset đó trên Linux tôi dùng mSBC với chất lượng khá tốt, nhưng trên macOS thì hoàn toàn tệ hại và chuyển sang chất lượng đường dây điện thoại/mono. Tôi tự hỏi đã có hack nào để nó hoạt động đúng trên Darwin chưa
Trước khi xem bài này tôi còn không biết mình đang dùng SBC. Lineage 18.1 không hiển thị checkbox UI đó ngay cả khi kết nối thiết bị hỗ trợ SBC. Như ma thuật vậy -