Modifiera Bluetooth-stacken för att förbättra ljudet på hörlurar utan kodekarna AAC, aptX och LDAC

Innan du läser denna artikel rekommenderas det att du bekantar dig med den föregående artikeln: Ljud via Bluetooth: så detaljerat som möjligt om profiler, codecs och enheter

Vissa användare av trådlösa hörlurar rapporterar låg ljudkvalitet och brist på diskant när de använder standard Bluetooth-kodeken SBC, som stöds av alla ljudenheter. En vanlig rekommendation för att förbättra ljudet är att köpa enheter och hörlurar som stöder kodekarna aptX och LDAC. Dessa kodekar kräver licensavgifter, vilket gör att enheter med deras stöd är dyrare.

Det visar sig att den låga kvaliteten av SBC beror på artificiella begränsningar i Bluetooth-stacken och inställningarna för hörlurarna, och denna begränsning kan kringgås på alla befintliga enheter genom programvaruförändringar i smartphone eller dator.

Kodek SBC

Kodeken SBC har många olika parametrar som kommer överens om vid anslutningen. Bland dem:

• Antal och typ av kanaler: Joint Stereo, Stereo, Dual Channel, Mono;
• Antal frekvensband: 4 eller 8;
• Antal block i paketet: 4, 8, 12, 16;
• Algoritm för bitfördelning vid kvantisering: Loudness, SNR;
• Maximalt och minimalt värde på bitpoolen som används vid kvantisering: vanligtvis mellan 2 och 53.

Dekoderenheten måste stödja vilken kombination som helst av dessa parametrar. Kodarenheten kanske inte kan implementera alla.
Befintliga Bluetooth-stackar förenas vanligtvis med följande profil: Joint Stereo, 8 band, 16 block, Loudness, bitpool 2..53. Denna profil kodar 44,1 kHz ljud med en bithastighet av 328 kbps.
Bitpool-parametern påverkar direkt bithastigheten inom en profil: ju högre värde, desto högre bithastighet och därmed också kvalitet.
Men bitpool-parametern är inte bunden till en specifik profil; påverkan på bithastigheten beror också i stor grad på andra parametrar: kanaltyp, antal frekvensband, antal block. Bithastigheten kan ökas indirekt genom att godkänna icke-standardprofiler utan att ändra bitpoolen.

Formeln för att beräkna bithastigheten för SBC

Till exempel kodar Dual Channel-läget kanaler separat, vilket använder hela bitpoolen för varje kanal. Genom att få enheten att använda Dual Channel istället för Joint Stereo kan vi få nästan dubbelt så hög bithastighet vid samma maximala bitpoolvärde: 617 kbps.
Enligt min åsikt är användningen av ett icke-profilerat bitpool-värde vid samordning en brist i A2DP-standarden, vilket har lett till en konstgjord begränsning av SBC-kvaliteten. Det hade varit klokare att samordna bitrate istället för bitpool.

Dessa fasta värden för Bitpool och Bitrate har sitt ursprung i en tabell med rekommenderade värden för användning vid högkvalitativt ljud. Men en rekommendation är ingen anledning att begränsa sig till dessa värden.

A2DP v1.2-specifikationen, som var aktiv från 2007 till 2015, föreskriver att alla avkodande enheter korrekt ska fungera med bitrater upp till 512 kbps:

Avkodaren i SNK ska stödja alla möjliga bitpool-värden som inte överskrider den maximala bitraten. Denna profil begränsar den tillgängliga maximala bitraten till 320 kbps för mono och 512 kbps för tvåkanalslägen.

I den nya versionen av specifikationen saknas begränsningen för bitraten. Det antas att moderna hörlurar som släpptes efter 2015 och stödjer EDR kan hantera bitrater upp till ≈730 kbps.

Av någon anledning har de Bluetooth-stacks i Linux (PulseAudio), Android, Blackberry och macOS som jag har kontrollerat konstgjorda begränsningar på det maximala värdet av bitpool, vilket direkt påverkar den maximala bitraten. Men det är inte det största problemet, nästan alla hörlurar begränsar också det maximala värdet på bitpool till 53.
Som jag redan har konstaterat fungerar de flesta enheter utmärkt med en modifierad Bluetooth-stack med en bitrate på 551 kbps, utan avbrott och knäppande ljud. Men en sådan bitrate kommer aldrig att samordnas under normala förhållanden, på vanliga Bluetooth-stacks.

Modifiera Bluetooth-stacken

I varje Bluetooth-stack som är kompatibel med A2DP-standarden finns stöd för Dual Channel-läget, men det är inte möjligt att aktivera det från gränssnittet.

Låt oss lägga till en omswitch i gränssnittet! Jag har gjort patchar för Android 8.1 och Android 9, som lägger till fullt stöd för Dual Channel i stacken, lägger till läget i omkopplingsmenyn i utvecklarverktyg, och hanterar SBC med stöd för Dual Channel som om det vore en extra codec, som aptX, AAC eller LDAC (Android kallar det HD Audio), vilket lägger till en kryssruta i Bluetooth-enhetsinställningarna. Så här ser det ut:

Patch för Android 9
Patch för Android 8.1

När kryssrutan aktiveras börjar Bluetooth-ljudet att överföras med en bitrate på 551 kbps, om hörlurarna stöder en anslutning med en hastighet på 3 Mbps, eller 452 kbit/s, om hörlurarna endast stöder 2 mbit/s.

Denna patch ingår i följande alternativa firmware:

• LineageOS
• Resurrection Remix
• crDroid

Var kommer 551 och 452 kbit/s ifrån?

Tekniken för och delning av luft i Bluetooth är avsedd för effektiv överföring av stora paket av fast storlek. Dataöverföringen sker i slottar, det största antalet slottar som kan sändas under en överföring är 5. Det finns också överföringslägen som använder 1 eller 3 slottar, men inte 2 eller 4. I 5 slottar kan man överföra upp till 679 byte vid en anslutningshastighet på 2 mbit/s och upp till 1021 byte vid en hastighet på 3 mbit/s, och i 3 slottar 367 och 552 byte respektive.

Om vi vill överföra mindre data än 679 eller 1021 byte, men mer än 367 eller 552 byte, kommer överföringen fortfarande att ta 5 slottar, och data kommer att överföras på samma tid, vilket minskar överföringseffektiviteten.

SBC i Dual Channel-läget, vid 44100 Hz-ljud med parametrar Bitpool 38, 16 block i ramarna, 8 frekvensband, kodar ljud i ramar av storlek 164 byte, med en bithastighet på 452 kbit/s.
Ljudet måste inkapslas i L2CAP och AVDTP-överföringsprotokoll, som tar 16 byte från den nyttiga ljudbelastningen.

Således kan en Bluetooth-överföring med 5 slottar rymma 4 ljudramar:

679 (EDR 2 mbit/s DH5) - 4 (L2CAP) - 12 (AVDTP/RTP) - 1 (SBC-header) - (164*4) = 6

Vi rymde 11,7 ms ljuddata i det sända paketet, vilket kommer att överföras på 3,75 ms, och vi har 6 oanvända byte kvar i paketet.
Om vi höjer bitpoolen något, går det inte längre att packa 4 ljudramar i ett paket. Vi måste skicka 3 ramar i taget, vilket minskar överföringseffektiviteten, minskar mängden ljud som överförs i varje paket och snabbare leder till ljudhackningar under dåliga radioförhållanden.

På samma sätt valdes bithastigheten 551 kbit/s för EDR 3 mbit/s: med Bitpool 47, 16 block i ramarna, 8 frekvensband får vi en rams storlek av 200 byte, vid en bithastighet på 551 kbit/s. I ett paket får vi plats med 5 ramar eller 14,6 ms musik.

Algoritmen för beräkning av alla SBC-parametrar är ganska komplex, man kan enkelt bli förvirrad om man räknar manuellt, så jag gjorde en interaktiv kalkylator för dem som är intresserade: btcodecs.valdikss.org.ru/sbc-bitrate-calculator

Varför behövs allt detta?

Trots den vanliga uppfattningen om aptX-kodens ljudkvalitet, kan den på vissa filer ge resultat som är sämre än SBC med en standard bitrate på 328 kbit/s.

SBC tilldelar dynamiskt kvantisering av bitar till frekvensband, vilket fungerar enligt principen "från låga till höga". Om hela bitraten används för låga och mellanregisterfrekvenser, kommer de högre frekvenserna att "kapas" (istället för att det blir tystnad).
aptX kvantiserar frekvensband med samma antal bitar konstant, vilket innebär att den har en konstant bitrate: 352 kbit/s för 44,1 kHz, 384 kbit/s för 48 kHz, och den kan inte "flytta bitar" till de frekvenser som mest behöver dem. Till skillnad från SBC kommer aptX inte "att kapa" frekvenser, utan kommer att lägga till kvantiseringsbrus i dem, vilket minskar ljudets dynamiska omfång och ibland medför typiska knastrande ljud. SBC "slukar detaljer" — den kastar bort de tystaste delarna.
I genomsnitt, jämfört med SBC 328k, introducerar aptX färre förvrängningar i musik med ett brett frekvensområde, men på musik med snävt frekvensområde och stort dynamiskt omfång vinner SBC 328k ibland.

Låt oss betrakta ett specifikt fall. Spektrogrammet av en inspelning på piano:

Huvudenergin ligger i frekvenserna från 0 till 4 kHz och sträcker sig upp till 10 kHz.
Spektrogrammet av filen som komprimerats med aptX ser ut som följande:

Och så här ser SBC 328k ut.

Det är tydligt att SBC 328k periodiskt helt stängde av området över 16 kHz och använde hela tillgängliga bitraten på områden nedanför detta värde. Dock introducerade aptX fler förvrängningar i det hörbara ljudspektrumet, vilket kan ses på den subtraherade originalspetragrammet från spektrogrammet av aptX (ju mörkare, desto fler förvrängningar):

Medan SBC 328k hade mindre påverkan på signalen i området 0 till 10 kHz, medan resten stängdes av:

Bitraten 485k SBC räckte för att bevara hela frekvensspektrumet utan att stänga av banden.

SBC 485k överträffar avsevärt aptX i kompositionen i intervallet 0-15 kHz, och med en mindre, men ändå märkbar skillnad — i 15-22 kHz (ju mörkare, desto färre förvrängningar):

Arkiv med originalljud, SBC och aptX.

Genom att byta till högbitrat SBC får du ljud som ofta överträffar aptX, på alla hörlurar. På hörlurar som stöder EDR-anslutning 3 Mbit/s, ger bitrate 551 kbit/s ljud som står på samma nivå som aptX HD.

Finns det mer?

I patchen för Android finns också ett alternativ för att öka bithastigheten ytterligare för EDR-enheter till 2 Mbit/s. Bithastigheten kan ökas från 452 kbit/s till 595 kbit/s, vilket medför en minskad stabilitet i överföringen under svåra radioförhållanden.
Det räcker att ställa in variabeln persist.bluetooth.sbc_hd_higher_bitrate till värdet 1:

# setprop persist.bluetooth.sbc_hd_higher_bitrate 1

Patchen för extrem bithastighet har hittills bara godkänts i LineageOS 15.1, men inte i 16.0.

Kompatibilitet med enheter

SBC Dual Channel stöds av nästan alla hörlurar, högtalare och bilstereonheter. Det är inte förvånande — standarden föreskriver att den ska stödjas av alla avkodningsenheter. Det finns ett fåtal enheter där detta läge orsakar problem, men detta är undantagsfall.
För mer information om kompatibla enheter kan du titta på 4pda eller xda-developers.

Jämförelse av ljudskillnader

Jag har skapat en webbtjänst som kodar ljud i SBC (samt aptX och aptX HD) i realtid, direkt i webbläsaren. Med den kan du jämföra ljudet mellan olika SBC-profiler och andra codec, utan att faktiskt överföra ljud via Bluetooth, på alla trådbundna hörlurar, högtalare och din favoritmusik, samt justera kodningsparametrarna direkt under ljuduppspelningen.
btcodecs.valdikss.org.ru/sbc-encoder

Kontakt med Android-utvecklarna

Jag har skrivit till många utvecklare av Bluetooth-stacken från Google med en begäran att överväga att inkludera patchar i huvudgrenen av Android — AOSP, men har inte fått något svar. Mina patchar i systemet för patchhantering Gerrit för Android har också förblivit utan kommentarer från någon involverad.
Jag skulle vara tacksam om jag kunde få hjälp med att nå utvecklarna på Google och implementeringen av SBC HD i Android. Patchen i Gerrit är redan föråldrad (detta är en av de tidiga reviserna), och jag kommer att uppdatera den om utvecklarna är intresserade av mina ändringar (det är svårt för mig att uppdatera den, jag har inga enheter som är kompatibla med Android Q).

Slutsats

Användare av smartphones med LineageOS, Resurrection Remix och crDroid kan redan nu njuta av förbättrad ljudkvalitet, det räcker att aktivera alternativet i Bluetooth-enhetens inställningar. Linux-användare kan också få högre bithastighet för SBC genom att installera patchen från Pali Rohár, som förutom allt annat lägger till stöd för codec:erna aptX, aptX HD och FastStream.

Källa: habr.com