AAC, aptX, LDAC के बिना हेडफ़ोन की ऑडियो क्वालिटी बढ़ाने के लिए Bluetooth stack में बदलाव

 (habr.com)
1 पॉइंट द्वारा GN⁺ 2023-11-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मानक SBC codec की कम ऑडियो क्वालिटी सिर्फ codec की सीमा की वजह से नहीं, बल्कि Bluetooth stack और हेडफ़ोन सेटिंग्स में रखी गई conservative सीमाओं की वजह से भी होती है; मौजूदा डिवाइसों में भी software बदलाव से सुधार की गुंजाइश है
  • सामान्य Bluetooth stack 44.1kHz stereo को आमतौर पर 328kbps पर negotiate करता है, लेकिन Dual Channel को force करने पर वही bitpool 53 लगभग 617kbps तक पहुँच जाता है
  • Android 8.1·9 patches Bluetooth device settings में SBC Dual Channel को HD Audio option की तरह जोड़ते हैं, और EDR 3Mb/s डिवाइसों पर 551kbps तथा EDR 2Mb/s डिवाइसों पर 452kbps इस्तेमाल करते हैं
  • 551kbps और 452kbps के मान Bluetooth 5-slot transmission efficiency को ध्यान में रखकर चुने गए हैं; bitpool और बढ़ाने पर frame bundling कम हो जाती है, जिससे खराब wireless माहौल में audio drop होने की संभावना बढ़ती है
  • LineageOS, Resurrection Remix, crDroid उपयोगकर्ता settings checkbox से high-bitrate SBC चालू कर सकते हैं, और Linux उपयोगकर्ता PulseAudio patch के जरिए ऊँचा SBC bitrate व aptX परिवार का समर्थन पा सकते हैं

SBC की आवाज़ कमज़ोर क्यों लगती है

  • कुछ wireless हेडफ़ोन उपयोगकर्ताओं को SBC codec, जिसे सभी Bluetooth audio डिवाइस support करते हैं, में ऑडियो क्वालिटी गिरना और high-frequency detail की कमी महसूस होती है
  • aptX या LDAC support वाले डिवाइस और हेडफ़ोन खरीदना एक विकल्प है, लेकिन इन codecs के लिए license cost लगती है, जिससे डिवाइस की कीमत बढ़ सकती है
  • कम SBC क्वालिटी की मुख्य वजह मौजूदा Bluetooth stack और हेडफ़ोन सेटिंग्स में लगी कृत्रिम सीमाएँ हैं, और इन्हें software बदलाव से मौजूदा डिवाइसों पर भी bypass किया जा सकता है

SBC parameters और bitrate

  • SBC connection setup चरण में कई parameters negotiate करता है
    • audio channel type और count: Joint Stereo, Stereo, Dual Channel, Mono
    • frequency bands की संख्या: 4 या 8
    • packet में audio blocks की संख्या: 4, 8, 12, 16
    • quantization bit allocation method: Loudness, SNR
    • quantization के लिए minimum-maximum bitpool: आमतौर पर 2..53
  • decoder को इन सभी parameter combinations का support करना होता है, लेकिन encoder केवल कुछ combinations ही implement कर सकता है
  • मौजूदा Bluetooth stack आमतौर पर Joint Stereo, 8 bands, 16 blocks, Loudness, bitpool 2..53 combination negotiate करता है, और इस स्थिति में 44.1kHz stereo audio को 328kbps पर encode किया जाता है
  • bitpool वह मान है जो encoding bitrate बदलता है; value जितनी अधिक होगी, bitrate और quality उतनी बढ़ेगी
    • bitpool value और bitrate का सटीक संबंध केवल किसी खास profile के भीतर ही लागू होता है
    • channel type, frequency bands की संख्या और audio blocks भी bitrate पर बड़ा असर डालते हैं
  • Dual Channel, Stereo या Joint Stereo से अलग, हर channel को अलग encode करता है और प्रति channel अलग bitpool इस्तेमाल करता है
    • Joint Stereo की जगह Dual Channel force करने पर वही bitpool 53 पर bitrate लगभग 617kbps हो जाता है, यानी लगभग दोगुना

A2DP specification और मौजूदा stack की सीमाएँ

  • 2007 से 2015 तक लागू A2DP specification v1.2 में decoder को अधिकतम bitrate से नीचे आने वाले सभी bitpool values का support करना अनिवार्य था
    • इस profile में mono के लिए 320kb/s और 2-channel mode के लिए 512kb/s की अधिकतम bitrate सीमा थी
  • नई specification में bitrate सीमा स्पष्ट रूप से नहीं दी गई है
  • माना जाता है कि 2015 के बाद आए EDR-supported आधुनिक हेडफ़ोन अधिकतम 730kbps तक support कर सकते हैं
  • जिन Bluetooth stacks का परीक्षण किया गया — Linux PulseAudio, Android, Blackberry, macOS — वे सभी maximum bitpool parameter पर कृत्रिम सीमा लगाते हैं
  • लगभग सभी हेडफ़ोन भी maximum bitpool value को 53 पर सीमित करते हैं
  • बदले हुए Bluetooth stack के साथ अधिकांश डिवाइस 551kbps पर बिना drop या noise के चलते थे, लेकिन default Bluetooth stack सामान्य परिस्थितियों में यह bitrate negotiate नहीं करता

Android Bluetooth stack patch

  • सभी A2DP-compatible Bluetooth stacks को Dual Channel mode support करना चाहिए, लेकिन सामान्य उपयोगकर्ता के पास इसे force करने का तरीका नहीं होता
  • Android 8.1 और Android 9 के लिए patch Dual Channel को stack और developer menu में जोड़ता है, और aptX, AAC, LDAC की तरह Bluetooth device settings में HD Audio codec option की तरह दिखाता है
  • patch links
  • यह checkbox Dual Channel mode को toggle करता है, और डिवाइस के हिसाब से नीचे दिए गए bitrates इस्तेमाल करता है
    • EDR 3Mb/s डिवाइस: 551kbps
    • EDR 2Mb/s डिवाइस: 452kbps
  • patchset नीचे दिए गए alternative firmware में merge किया गया
    • LineageOS 15.1: 31 मार्च 2019 से
    • LineageOS 16.0: 13 मई 2019 से
    • Resurrection Remix: 14 मई 2019 से
    • crDroid: 13 मई 2019 से

551kbps और 452kbps क्यों चुने गए

  • Bluetooth time-division transmission को बड़े fixed-size packets को कुशलता से भेजने के लिए design किया गया है
  • एक transmission में भेजे जा सकने वाले अधिकतम slots की संख्या 5 है; 1-slot और 3-slot mode भी हैं, लेकिन 2-slot और 4-slot mode नहीं हैं
  • 5-slot transmission में भेजे जा सकने वाले data की मात्रा इस प्रकार है
    • 2Mbps connection: अधिकतम 679 bytes
    • 3Mbps connection: अधिकतम 1021 bytes
  • 3-slot transmission की अधिकतम data capacity इस प्रकार है
    • 2Mbps connection: 367 bytes
    • 3Mbps connection: 552 bytes
  • अगर data 367 या 552 bytes से बड़ा हो लेकिन 679 या 1021 bytes से छोटा हो, तब भी 5-slot की ज़रूरत पड़ती है, जिससे transmission efficiency कम हो जाती है
  • 44.1kHz audio को SBC Dual Channel, bitpool 38, 16 blocks, 8 frequency bands पर encode करने से 164-byte audio frame और 452kbps bitrate मिलती है
  • audio payload को L2CAP और AVDTP transport protocol में wrap करना पड़ता है, और इस प्रक्रिया में audio payload से 16 bytes का overhead चला जाता है
  • EDR 2Mb/s DH5 में एक 5-slot audio transmission में 4 audio frames समा सकते हैं
    • 679 - 4(L2CAP) - 12(AVDTP/RTP) - 1(SBC header) - (164*4) = 6
    • packet में 6 bytes बचते हैं
    • एक single packet अधिकतम 11.7ms audio data रखता है और 3.75ms में transmit हो जाता है
  • bitpool थोड़ा भी बढ़ाने पर एक transmission में 4 audio frames नहीं समा पाते और 3-3 frames भेजने पड़ते हैं
    • transmission efficiency घट जाती है
    • एक packet में समाया audio कम हो जाता है
    • खराब wireless माहौल में audio drop की संभावना बढ़ जाती है
  • EDR 3Mb/s के लिए 551kbps भी इसी सिद्धांत पर चुना गया
    • bitpool 47, 16 blocks per frame, 8 frequency bands पर frame size 200 bytes होता है
    • एक transmission में अधिकतम 5 frames, यानी 14.6ms music bundle की जा सकती है
  • SBC parameter calculation जटिल है, इसलिए manual calculation में गलती होना आसान है; इसके लिए एक web tool दिया गया है

aptX और SBC की sound quality का अंतर

  • aptX हमेशा SBC से बेहतर होता है, इस आम धारणा के विपरीत, कुछ मामलों में aptX मानक SBC 328kbps से भी कम quality दे सकता है
  • SBC frequency bands में quantization bits को dynamically allocate करता है, और नीचे से ऊपर की ओर bits बाँटता है
    • अगर पूरी bitrate low और mid frequencies पर खर्च हो जाए तो high frequencies कट सकती हैं या mute हो सकती हैं
  • aptX एक fixed-bitrate codec है जो frequency bands को हमेशा समान bit count से quantize करता है
    • 44.1kHz पर 352kbps
    • 48kHz पर 384kbps
  • aptX ज़रूरी frequency bands की ओर bits नहीं खिसका सकता; यह frequencies को काटता नहीं, लेकिन quantization noise जोड़ता है, जिससे audio की dynamic range घटती है और कभी-कभी noise भी बन सकता है
  • इसके उलट SBC शांत हिस्सों को छोड़ देता है; 328kbps SBC की तुलना में aptX व्यापक frequency range वाले music में औसतन कम distortion दे सकता है
  • लेकिन संकरी frequency range और व्यापक dynamic range वाले music में SBC 328kbps कभी-कभी aptX से बेहतर हो सकता है
  • piano recording के उदाहरण में अधिकांश energy 0~4kHz में थी और 10kHz तक जाती थी
    • SBC 328kbps ने 16kHz से ऊपर का range समय-समय पर पूरी तरह काट दिया
    • aptX ने इंसानों को सुनाई देने वाले frequency spectrum में अधिक distortion जोड़ा
    • SBC 328kbps ने 0~10kHz range में कम distortion दिया और बाकी frequencies काट दीं
    • SBC 485kbps पूरे frequency range को बिना काटे बनाए रखने के लिए पर्याप्त था
  • original audio और SBC/aptX-encoded files का material उपलब्ध कराया गया है
  • high-bitrate SBC इस्तेमाल करने पर ज़्यादातर मामलों में aptX से बेहतर sound मिल सकती है, और EDR 3Mb/s support वाले हेडफ़ोन पर 551kbps SBC की आवाज़ aptX HD के बहुत क़रीब पहुँचती है

और ऊँचे bitrate options

  • Android patchset में EDR 2Mb/s डिवाइसों के bitrate को और बढ़ाने का एक अतिरिक्त option है
  • persist.bluetooth.sbc_hd_higher_bitrate value को 1 पर set करने से bitrate 452kbps से बढ़कर 595kbps हो सकती है
  • यह option भीड़भाड़ वाले wireless माहौल में transmission stability कम कर सकता है
# setprop persist.bluetooth.sbc_hd_higher_bitrate 1
  • extreme bitrate patch अभी केवल LineageOS 15.1 में merge किया गया है; LineageOS 16.0 में नहीं

compatible devices और comparison tools

  • SBC Dual Channel लगभग सभी हेडफ़ोन, speakers और car head units में support होता है
  • क्योंकि standard सभी decoding devices में इस mode का support अनिवार्य करता है, इसलिए यह ज़्यादातर डिवाइसों पर काम करता है
  • इस mode में समस्या करने वाले कुछ डिवाइस मौजूद हैं, लेकिन ऐसे मामले बहुत दुर्लभ हैं
  • compatible devices की जानकारी नीचे दिए गए communities में मिल सकती है
  • browser में audio को real time में SBC, aptX, aptX HD में encode करने वाली एक web service भी उपलब्ध है
    • btcodecs.valdikss.org.ru/sbc-encoder
    • असली Bluetooth transmission के बिना भी wired हेडफ़ोन या speakers पर अलग-अलग SBC profiles और दूसरे codecs की sound compare की जा सकती है
    • audio playback के दौरान भी encoding parameters को सीधे बदला जा सकता है

AOSP में शामिल करने की कोशिश और उपयोग का तरीका

  • Google के Bluetooth stack developers से Android की main branch AOSP में patch शामिल करने का अनुरोध किया गया, लेकिन कोई जवाब नहीं मिला
  • Gerrit code review system for Android पर डाले गए patch पर भी Android development से जुड़े लोगों की कोई टिप्पणी नहीं आई
  • Gerrit patchset पुरानी शुरुआती revisions में से एक है, और अगर developers रुचि दिखाएँ तो इसे update किया जा सकता है
  • LineageOS, Resurrection Remix, crDroid उपयोगकर्ता Bluetooth device settings में checkbox चालू करके Bluetooth audio quality बढ़ा सकते हैं
  • Linux उपयोगकर्ता Pali Rohár के PulseAudio patch को install करके ऊँचा SBC bitrate इस्तेमाल कर सकते हैं
    • यह patch aptX, aptX HD, FastStream codec support भी जोड़ता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-25
Hacker News टिप्पणियाँ

  • यह बढ़िया है: SBC व्यापक रूप से supported है, और मौजूदा standard का एक स्वाभाविक extension लगता है
    व्यक्तिगत तौर पर मेरे लिए समस्या SBC बनाम LDAC/AAC नहीं है, बल्कि यह है कि HFP बहुत खराब है। जैसे ही mic ऑन होता है, ऐसा लगता है जैसे हम 90s में लौट गए हों, और अगर two-way Bluetooth audio को ठीक से बनाया जा सके तो यह सच में बहुत स्वागतयोग्य होगा

    • आखिरकार शायद इसकी वजह यह है कि low latency चाहिए। “media” music/videos में audio quality अच्छी होती है लेकिन latency ज्यादा होती है, और video को उतना ही delay करके compensate किया जा सकता है, पर phone calls के लिए वह delay बहुत ज्यादा है
    • समझ नहीं आता कि HFP अब भी industry standard क्यों है। MacBook / iPhone / AirPods जैसी एक ही ecosystem की devices भी audio quality के हिसाब से HFP इस्तेमाल करती लगती हैं
      या शायद AVRCP हो सकता है, लेकिन किसी भी हालत में sound भयानक है
    • यह feature LE Audio / Auracast के रूप में धीरे-धीरे market में आ रहा है। हालांकि अच्छा operating system support तैयार होने में शायद थोड़ा समय लगेगा

  • यह लेख पूरे Bluetooth के बारे में नहीं, बल्कि Android Bluetooth stack में दबी एक bug की गहराई से पड़ताल है
    लेखक जिस बात को बिल्कुल स्वीकार नहीं करता, वह यह है कि underlying hardware बहुत विविध है। Android ढेरों Bluetooth chipsets पर चलता है, इसलिए अपने hardware पर patch काम करता दिखे तो इसकी guarantee नहीं कि वह दूसरे Android phones पर भी चलेगा
    साथ ही उस पल device क्या कर रही है, इसका भी असर पड़ता है। BT+Wi‑Fi shared chipset पर Wi‑Fi से video stream करते हुए audio headphones को भेजें, तो device को Wi‑Fi usage और Bluetooth के बीच resources allocate करने पड़ते हैं। इसलिए local stored audio और streaming audio को जरूरी नहीं कि वही codec parameters मिलें
    इस विषय में ऐसे बहुत से subtle factors हैं जिन्हें लेखक ने consider नहीं किया, इसलिए पढ़ी जा रही बातों को सावधानी से लें

    • पहले custom ROM develop करने और valdikSS के fixes को review·integrate करने के अनुभव से कहूँ तो, यह patchset bug fix नहीं करता, बल्कि source और sink connection में dual channel SBC negotiation को संभव बनाता है
      इससे Android और Bluetooth receiver द्वारा impose किए गए maximum bitpool से ऊपर गए बिना भी higher bitrate इस्तेमाल किया जा सकता है
      source और sink के बीच negotiation अब भी होता है, और अगर दोनों में से कोई एक dual channel SBC support नहीं करता, तो supported mode पर fallback हो जाता है। जिन devices को मैं maintain करता था वे सभी support करती थीं, और उस समय test किए गए कुछ low-cost speakers support नहीं करते थे, इसलिए joint stereo session में negotiate हुआ
    • Bluetooth overall पर लेख यहाँ है: https://habr.com/en/articles/456182/

  • Windows पर Alternative A2DP Driver यह feature देता है। यह SBC parameters adjust करता है, और AAC या aptX भी इस्तेमाल करने देता है
    मेरे अनुभव में यह अच्छे से काम करता था, और Sony XM4 पर LDAC इस्तेमाल करने में भी मदद करता है। trial model है, लेकिन कीमत कम है
    high-quality mode में मैंने Bluetooth range घटती देखी है, जो इस बात का संकेत लगता है कि वास्तव में codec या कम से कम कुछ तो बदल रहा है और यह placebo नहीं है
    https://www.bluetoothgoodies.com/a2dp/ से मेरा कोई संबंध नहीं है

    • 48KHz से 44.1KHz पर downsampling करते समय जिस “Quality Loss” की बात है, वह क्या है समझ नहीं आता। resampling ठीक से किया जाए तो सिर्फ बहुत high frequencies, यानी 22050Hz से ऊपर, खोती हैं
      इंसानों की hearing range आम तौर पर 20KHz तक documented है, लेकिन कुछ young लोग उससे थोड़ी ज्यादा frequencies भी सुन सकते हैं

  • संदर्भ के लिए, Linux पर भी SBC XQ कहलाने वाले तरीके से higher-bitrate SBC audio चालू किया जा सकता है। इसी तरह mSBC से बेहतर headset audio भी इस्तेमाल किया जा सकता है
    बेशक यह अब भी SBC या aptX के level के करीब भी नहीं है
    काश Google ने ऐसी चीजें पहले ही merge कर दी होतीं। बेहतर audio codecs को कई headphones आदि support करते हैं, लेकिन वे universal नहीं हैं, और two-way audio improvement खास तौर पर अभी भी कम है

    • यह लेख 4 साल पुराना है, इसलिए उसके बाद Android में merge हुए LE Audio support जैसे बदलाव इसमें reflect नहीं हैं
    • Linux में उसे कैसे enable करते हैं, यह जानने की उत्सुकता है
      अभी headset क्या इस्तेमाल कर रहा है, यह check करने का तरीका भी जानना चाहता हूँ
      याद है कि पहले मैंने patched PulseAudio इस्तेमाल किया था जो proper settings expose करता था, बाद में सुना कि वह “mainstream में merge” हो गया, लेकिन असल में settings या actual usage info नहीं मिल पाई
    • Linux पर AirPods को किसी तरह support कराने भर में ही मैं बहुत जूझ रहा हूँ

  • काश कोई ऐसा Bluetooth audio profile बना दे जो पहले से लंबे समय तक buffer कर सके
    उदाहरण के लिए अगर 1 मिनट का गाना play करें, तो पूरा गाना buffer में आ जाना चाहिए। बेशक pause करने या volume बदलने पर buffer discard हो जाना चाहिए
    लंबा buffer होने से phone ज्यादा बार sleep कर सकता है, जिससे power बचती है, और wireless connection खराब हो तब भी काम चल सकता है

    • ऐसा होने की संभावना कम लगती है। ज्यादातर headphones में ऐसे buffer के लिए memory होगी, इस पर मुझे बहुत शक है
      मान लें सिर्फ 1–2MB RAM ही चाहिए, तब भी headphones को उस RAM को active रखने में कीमती battery खर्च करनी पड़ेगी
      पहले थोड़ा audio apps पर काम करने के अनुभव से, application support भी मुश्किल लगेगा
    • जब phone call आएगी, तो Led Zeppelin का अगला 1 मिनट पहले सुनने के बजाय, buffered content skip करके incoming call तुरंत उठाना चाहेंगे—बस उसी क्षण तक यह अच्छा लगेगा
    • पर्याप्त embedded memory हो तो यह संभव तो है, लेकिन audio और video sync करने की कोशिश में समस्या बन जाती है
      इसलिए यह protocol issue से ज्यादा individual products में design के तौर पर जोड़ी जाने वाली, और app में user द्वारा on/off की जा सकने वाली feature जैसी चीज है
    • अफसोस, यह audio से अधिकांश users जो चाहते हैं उसके लगभग सीधे उलट है

  • मैंने LineageOS में यह feature इस्तेमाल किया था और सच कहूँ तो यह बहुत अच्छा था। third-party codecs support न करने वाले car stereo जैसे equipment को higher-quality audio भेज सकता था, और headphones में भी काफी मदद मिलती थी
    user experience को polish करने की जरूरत है, लेकिन feature खुद शानदार है

    • दुर्भाग्य से latest Lineage versions में यह हट गया है। अब यह practically भुला दिया गया है

  • title में 2019 जोड़ना अच्छा होगा। “आज के सभी Bluetooth stacks” जैसी expressions आती हैं, लेकिन ये चीजें काफी समय से PulseAudio और PipeWire में implement हो चुकी थीं

  • इस बात पर मुझे थोड़ा संदेह है कि 551kbps Dual Channel, 328kbps Joint Stereo से noticeably बेहतर quality देता है। हो सकता है यह बस duplicate information encode करने में ज्यादा bits खर्च कर रहा हो
    कम से कम ज्यादातर music में ऐसा है, हालांकि ऐसे अपवाद हो सकते हैं जहाँ left-right में जानबूझकर अलग-अलग recording tracks रखे गए हों

  • संबंधित सवाल के तौर पर, जानना चाहता हूँ कि macOS पर Bluetooth HFP को improve करने का कोई तरीका है क्या
    वही headset Linux पर mSBC के साथ काफी अच्छी quality में इस्तेमाल कर रहा हूँ, लेकिन macOS पर यह पूरी तरह खराब होकर telephone-line/mono quality में बदल जाता है। जानना चाहता हूँ कि Darwin पर इसे ठीक से चलाने वाला कोई hack पहले से है क्या

  • इस लेख को देखने से पहले मुझे पता भी नहीं था कि मैं SBC इस्तेमाल कर रहा हूँ। Lineage 18.1 SBC-supporting device connect करने पर भी वह UI checkbox नहीं दिखाता। जादू जैसा है -