Abans de llegir aquest article, us recomanem que llegiu l'article anterior:
Alguns usuaris d'auriculars sense fil denuncien una mala qualitat del so i la manca d'altes freqüències quan utilitzen el còdec Bluetooth SBC estàndard, que és compatible amb tots els dispositius d'àudio. Una recomanació habitual per millorar el so és comprar dispositius i auriculars compatibles amb còdecs aptX i LDAC. Aquests còdecs requereixen drets d'autor, de manera que els dispositius que els admeten són més cars.
Resulta que la baixa qualitat de l'SBC es deu a limitacions artificials de les piles Bluetooth i la configuració dels auriculars, i aquesta limitació es pot eludir en qualsevol dispositiu existent mitjançant canvis de programari al telèfon intel·ligent o a l'ordinador.
Còdec SBC
El còdec SBC té molts paràmetres diferents que es negocien durant la fase de configuració de la connexió. Entre ells:
- Nombre i tipus de canals: Joint Stereo, Stereo, Dual Channel, Mono;
- Nombre de bandes de freqüència: 4 o 8;
- Nombre de blocs en un paquet: 4, 8, 12, 16;
- Algorisme per a la distribució de bits durant la quantificació: sonoritat, SNR;
- El valor màxim i mínim del conjunt de bits utilitzat durant la quantificació (bitpool): normalment de 2 a 53.
El descodificador ha de suportar qualsevol combinació d'aquestes opcions. És possible que el codificador no implementi tot.
Les piles de Bluetooth existents solen coincidir amb el perfil següent: estèreo conjunt, 8 bandes, 16 blocs, sonoritat, bitpool 2..53. Aquest perfil codifica àudio de 44.1 kHz a una velocitat de bits de 328 kbps.
El paràmetre bitpool afecta directament la taxa de bits dins d'un perfil: com més alta sigui, més alta serà la taxa de bits i, per tant, la qualitat.
Tanmateix, la configuració de bitpool no està lligada a un perfil específic; altres paràmetres també afecten significativament la taxa de bits: el tipus de canals, el nombre de bandes de freqüència, el nombre de blocs. Podeu augmentar la taxa de bits de manera indirecta, negociant perfils no estàndard, sense canviar el bitpool.
Fórmula SBC Bitrate
Per exemple, el mode Dual Channel codifica els canals per separat, utilitzant tot el bitpool per a cada canal. En forçar el dispositiu a utilitzar el canal dual en lloc de l'estèreo conjunt, aconseguim gairebé el doble de la taxa de bits amb el mateix valor màxim de bitpool: 617 kbps.
Al meu entendre, l'ús d'un valor de bitpool sense perfil en l'etapa de negociació és un defecte en l'estàndard A2DP, que va provocar una limitació artificial de la qualitat de SBC. Seria més savi negociar bitrate, no bitpool.
Aquests valors fixos de Bitpool i Bitrate s'originen a partir d'una taula amb valors recomanats per utilitzar-los per a un àudio d'alta qualitat. Però una recomanació no és un motiu per limitar-se a aquests valors.
L'especificació A2DP v1.2, que va estar activa des del 2007 fins al 2015, requereix que tots els descodificadors funcionin correctament amb velocitats de bits de fins a 512 kbps:
El descodificador de l'SNK ha de suportar tots els valors de bitpool possibles que no superin la taxa de bits màxima. Aquest perfil limita la velocitat de bits màxima disponible a 320 kb/s per als modes mono i 512 kb/s per als modes de dos canals.
A la nova versió de l'especificació no hi ha límit de bitrate. S'estima que els auriculars moderns llançats després del 2015 que admeten EDR poden suportar velocitats de bits de fins a ≈730 kbps.
Per alguna raó, les piles Bluetooth de Linux (PulseAudio), Android, Blackberry i macOS que he provat tenen límits artificials sobre el valor màxim del paràmetre de bitpool, que afecta directament la taxa de bits màxima. Però aquest no és el problema més gran, gairebé tots els auriculars també limiten el valor màxim de bitpool a 53.
Com ja he vist, la majoria de dispositius funcionen perfectament en una pila de Bluetooth modificada amb una taxa de bits de 551 kbps, sense interrupcions ni crepitacions. Però aquesta taxa de bits mai serà coherent en condicions normals, en piles Bluetooth normals.
Modificació de la pila Bluetooth
Qualsevol pila de Bluetooth que sigui compatible amb l'estàndard A2DP té suport per al mode de canal dual, però no és possible activar-la des de la interfície.
Afegim un commutador a la interfície! He fet pedaços per a Android 8.1 i Android 9 que afegeixen suport complet de canal dual a la pila, afegeixen un mode al menú de commutació de mode a les eines de desenvolupament i tracten els SBC habilitats per canal dual com si fossin un còdec addicional com aptX. , AAC o LDAC (Android anomena això HD Audio) afegint una marca de verificació a la configuració del dispositiu Bluetooth. Aquí teniu el que sembla:
Quan la casella de selecció està activada, l'àudio Bluetooth es comença a transmetre a una velocitat de bits 551 kbps, si els auriculars admeten una connexió de 3 Mbps, o bé 452 kbpssi els auriculars només admeten 2 Mbps.
Aquest pedaç s'inclou al firmware alternatiu següent:
- LineageOS
- Remix de Resurrecció
- crDroid
D'on provenen els 551 i 452 kbps?
La tecnologia de compartició d'aire Bluetooth està dissenyada per transmetre eficaçment paquets grans de mida fixa. La transferència de dades es produeix en ranures, el major nombre de ranures enviades en una transferència és de 5. També hi ha modes de transferència que utilitzen 1 o 3 ranures, però no 2 o 4. En 5 ranures podeu transferir fins a 679 bytes a una velocitat de connexió de 2 Mbit/s i fins a 1021 bytes a una velocitat de 3 Mbit/s, i a 3 - 367 i 552 bytes, respectivament.
Si volem transferir menys dades de 679 o 1021 bytes, però més de 367 o 552 bytes, la transferència encara trigarà 5 ranures i les dades es transferiran al mateix temps, la qual cosa redueix l'eficiència de la transferència.
SBC en mode Dual Channel, a 44100 Hz d'àudio amb Bitpool 38 paràmetres, 16 blocs per fotograma, 8 bandes de freqüència, codifica l'àudio en trames de 164 bytes, amb una velocitat de bits de 452 kbps.
L'àudio s'ha d'encapsular als protocols de transferència L2CAP i AVDTP, que prenen 16 bytes de la càrrega útil d'àudio.
Així, en una transmissió Bluetooth amb 5 ranures, és possible encaixar 4 marcs d'àudio:
679 (EDR 2 mbit/s DH5) - 4 (L2CAP) - 12 (AVDTP/RTP) - 1 (заголовок SBC) - (164*4) = 6
Encaixem 11.7 ms de dades d'àudio en un paquet d'enviament que es transmetrà en 3.75 ms, i ens queden 6 bytes no utilitzats al paquet.
Si augmenteu lleugerament el bitpool, ja no es poden empaquetar 4 fotogrames d'àudio en un sol paquet. Heu d'enviar 3 fotogrames alhora, la qual cosa redueix l'eficiència de transmissió, redueix la quantitat d'àudio transmès per fotograma i farà que l'àudio tartamudei més ràpidament en condicions de ràdio pobres.
De la mateixa manera, es va seleccionar una taxa de bits de 551 kbit/s per EDR 3 Mbit/s: amb Bitpool 47, 16 blocs per fotograma, 8 rangs de freqüències, la mida de la trama és de 200 bytes, amb una taxa de bits de 551 kbit/s. Un paquet conté 5 fotogrames o 14.6 ms de música.
L'algoritme per calcular tots els paràmetres SBC és bastant complicat, podeu confondreu-vos fàcilment si compteu manualment, així que vaig fer una calculadora interactiva per ajudar els interessats:
Per què és necessari tot això?
Contràriament a la creença popular sobre la qualitat del so del còdec aptX, en alguns fitxers pot donar pitjors resultats que SBC amb una taxa de bits estàndard de 328 kbps.
L'SBC assigna dinàmicament bits de quantificació a bandes de freqüència de manera baixa a alta. Si s'ha utilitzat tota la taxa de bits per a les freqüències baixes i mitjanes, les freqüències altes es "tallaran" (en canvi hi haurà silenci).
aptX quantifica bandes de freqüència amb el mateix nombre de bits tot el temps, per això té una velocitat de bits constant: 352 kbps per a 44.1 kHz, 384 kbps per a 48 kHz, i no pot "transferir bits" a aquelles freqüències que els necessiten. la majoria. A diferència de l'SBC, l'aptX no "tallarà" les freqüències, sinó que hi afegirà soroll de quantificació, reduint el rang dinàmic de l'àudio i, de vegades, introduint crepitacions característiques. SBC, en canvi, "menja detalls": descarta les zones més tranquil·les.
De mitjana, en comparació amb l'SBC 328k, aptX introdueix menys distorsió a la música amb un ampli rang de freqüències, però en música amb un rang de freqüències estret i un ampli rang dinàmic, l'SBC 328k de vegades guanya.
Considerem un cas especial. Espectrograma d'enregistrament de piano:
L'energia principal es troba en freqüències de 0 a 4 kHz, i continua fins a 10 kHz.
L'espectrograma d'un fitxer comprimit amb aptX té aquest aspecte:
I així és l'SBC 328k.
Es pot veure que l'SBC 328k desactivava periòdicament completament el rang superior a 16 kHz i gastava tota la taxa de bits disponible en intervals per sota d'aquest valor. Tanmateix, aptX va introduir més distorsió en l'espectre de freqüències audible per l'oïda humana, com es pot veure a l'espectrograma original restat de l'espectrograma aptX (com més brillant, més distorsió):
Mentre que l'SBC 328k va fer malbé el senyal menys en el rang de 0 a 10 kHz i va tallar la resta:
La taxa de bits de 485k SBC va ser suficient per salvar tot el rang de freqüències, sense tallar les bandes.
SBC 485k està significativament per davant d'aptX en aquesta pista en el rang de 0-15 kHz, i amb una diferència més petita, però encara notable, en 15-22 kHz (com més fosc, menys distorsió):
.
Si canvieu a un SBC d'alta velocitat de bits, obtindreu un àudio que sovint supera l'aptX en qualsevol auricular. Als auriculars que admeten una connexió EDR de 3 Mbps, 551 kbps produeixen un so comparable a l'aptX HD.
I potser encara més?
El pedaç d'Android també inclou una opció per augmentar encara més la taxa de bits per als dispositius EDR de 2 Mbps. Podeu augmentar la taxa de bits de 452 kbit/s a 595 kbit/s, a costa de reduir l'estabilitat de la transmissió en condicions de ràdio difícils.
N'hi ha prou amb establir la variable persist.bluetooth.sbc_hd_higher_bitrate a 1:
# setprop persist.bluetooth.sbc_hd_higher_bitrate 1El pedaç per a una taxa de bits extrema només s'accepta a LineageOS 15.1, però no a la 16.0.
Compatibilitat de dispositius
SBC Dual Channel és compatible amb gairebé tots els auriculars, altaveus i unitats principals del cotxe. Això no és sorprenent: l'estàndard prescriu el seu suport en qualsevol dispositiu de descodificació. Hi ha un nombre reduït de dispositius en què aquest mode causa problemes, però es tracta d'instàncies individuals.
Per obtenir més informació sobre dispositius compatibles, vegeu o .
Comparació de diferències de so
Vaig fer un servei web que codifica l'àudio a SBC (així com aptX i aptX HD) en temps real, directament al navegador. Amb ell, podeu comparar el so de diferents perfils SBC i altres còdecs, sense transmetre àudio a través de Bluetooth, a qualsevol auricular, altaveus i la vostra música preferida, i també canviar els paràmetres de codificació directament mentre reproduïu l'àudio.
Contacta amb els desenvolupadors d'Android
He escrit a molts desenvolupadors de pila Bluetooth a Google, demanant-los que considerin incloure pedaços a la branca principal d'Android: AOSP, però no he rebut cap resposta. Els meus pegats estan dins també es va mantenir sense comentaris de ningú implicat.
Estaria encantat si pogués obtenir ajuda per posar-me en contacte amb els desenvolupadors de Google i portar SBC HD a Android. El pedaç de gerrit ja està obsolet (aquesta és una de les primeres revisions), i l'actualitzaré si els desenvolupadors estan interessats en els meus canvis (no és fàcil per a mi actualitzar-lo, no tinc dispositius compatibles amb Android Q). ).
Conclusió
Els usuaris de telèfons intel·ligents amb firmware LineageOS, Resurrection Remix i crDroid poden gaudir d'una qualitat de so millorada ara mateix, només cal que activeu l'opció a la configuració del dispositiu Bluetooth. Els usuaris de Linux també poden augmentar la taxa de bits SBC mitjançant la instal·lació , que afegeix suport per als còdecs aptX, aptX HD i FastStream, entre altres coses.
Font: www.habr.com