På grund av massproduktionen av smartphones utan 3,5 mm ljuduttag har trådlösa Bluetooth-hörlurar blivit huvudalternativet för många när det kommer till att lyssna på musik och kommunicera i headsetläge.
Tillverkare av trådlösa enheter skriver inte alltid detaljerade specifikationer för sina produkter, och artiklar om Bluetooth-ljud på internet är ofta motsägelsefulla, ibland felaktiga, och de täcker inte alla detaljer, utan kopierar ofta samma missledande information.
Låt oss försöka förstå protokollet, funktionerna hos Bluetooth-stacken i operativsystem, hörlurar och högtalare, Bluetooth-codecs för musik och tal, ta reda på vad som påverkar ljudkvaliteten och latensen, samt lära oss att samla in och avkoda information om stödja codecs och andra funktioner hos enheterna.

TL;DR:

• SBC — en vanlig codec
• Hörlurar har sin egen equalizer och efterbearbetning för varje codec.
• aptX är inte så bra som reklamen påstår.
• LDAC — marknadsföringsbedrägeri.
• Ljudkvaliteten under samtal är fortfarande låg.
• Webbläsaren kan integrera ljudkodare i C, kompilera dem i WebAssembly via emscripten, och de kommer inte att bromsa särskilt mycket.

Musik över Bluetooth

De funktionella aspekterna av Bluetooth definieras av profiler — specifikationer för specifika funktioner. Överföring av musik via Bluetooth görs med hjälp av profilen för högkvalitativ envägs ljudöverföring A2DP. A2DP-standarden antogs 2003 och har inte förändrats radikalt sedan dess.
Inom profilen standardiseras 1 obligatorisk codec med låg beräkningskomplexitet, SBC, som skapades speciellt för Bluetooth, och 3 ytterligare. Användning av icke-dokumenterade codecs med egen implementation är också tillåten.

I juni 2019 befinner vi oss i comic xkcd med 14 A2DP-codecs:

• SBC ← standardiserad i A2DP, stöds av alla enheter.
• MPEG-1/2 Layer 1/2/3 ← standardiserade i A2DP: välkänd MP3, används i digital TV. MP2, och okänd MP1
• MPEG-2/4 AAC ← standardiserad i A2DP.
• ATRAC ← gammal codec från Sony, standardiserad i A2DP.
• LDAC ← ny codec från Sony.
• aptX ← codec från 1988.
• aptX HD ← samma som aptX, bara med andra kodningsparametrar.
• aptX Low Latency ← helt annan codec, ingen mjukvaruimplementation.
• aptX Adaptive ← ännu en codec från Qualcomm.
• FastStream ← pseudocodec, en tvåvägsmodifiering av SBC.
• HWA LHDC ← ny codec från Huawei
• Samsung HD ← stöds av 2 enheter
• Samsung Scalable ← stöds av 2 enheter
• Samsung UHQ-BT ← stöds av 3 enheter

Varför behövs kodexer, undrar du, när Bluetooth har EDR som tillåter datatransfer i hastigheter på 2 och 3 Mbit/s, medan 1.4 Mbit/s är tillräckligt för okomprimerad tvåkanalig 16-bit PCM?

Datatransfer via Bluetooth

Bluetooth har två typer av datatransfer: Asynchronous Connection Less (ACL) för asynkron överföring utan föregående anslutning, och Synchronous Connection Oriented (SCO) för synkron överföring med förhandsavtalad anslutning.
Överföringen utförs med hjälp av en tidsdelning och kanalval för varje paket (Frequency-Hop/Time-Division-Duplex, FH/TDD), där tiden delas in i 625-mikrosekunders intervaller som kallas slotar. En enhet sänder under jämna slotnummer, och den andra under udda. Det paket som överförs kan ta upp 1, 3 eller 5 slotar, beroende på datastorlek och typ av överföring som är inställd; i så fall överförs datan ett av enheterna i både jämna och udda slotar tills överföringen är klar. Totalt kan upp till 1600 paket tas emot och sändas per sekund om varje paket tar 1 slot och båda enheterna hela tiden sänder och tar emot.

2 och 3 Mbit/s för EDR, som kan ses i annonser och på Bluetooth:s webbplats, är den maximala kanalhastigheten för överföring av all data totalt (inklusive tekniska rubriker för alla protokoll till vilka data behöver inkapslas) i båda riktningar samtidigt. Den faktiska datatransferhastigheten kommer att skilja sig avsevärt.

För musiköverföring används en asynkron metod, nästan alltid med paket av typen 2-DH5 och 3-DH5, som bär det maximala datamängden i EDR-läget på 2 Mbit/s och 3 Mbit/s respektive, och upptar 5 slotar av tidsdelning.

Schematisk representation av överföringen med 5 slotar av en enhet och 1 slot av den andra (DH5/DH1):


På grund av tidsavskiljningens princip måste vi vänta på en 625-mikrosekunders tidslucka efter att ett paket har skickats, om den andra enheten varken skickar något eller skickar ett litet paket, och en längre tid om den andra enheten överför stora paket. Om fler än en enhet är ansluten till telefonen (till exempel hörlurar, klockor och fitnessarmband) delas överföringstiden mellan dem alla.

Behovet av att kapsla in ljud i specialiserade transports protokoll L2CAP och AVDTP tar 16 byte från den möjliga maximala mängden överförd nyttolast av ljud.

Pakettyp
Antal luckor
Max. antal byte per paket
Max. antal byte nyttolast A2DP
Max. bithastighet för nyttolast A2DP

2-DH3
3
367
351
936 kbit/s

3-DH3
3
552
536
1429 kbit/s

2-DH5
5
679
663
1414 kbit/s

3-DH5
5
1021
1005
2143 kbit/s

1414 och 1429 kbit/s är inte tillräckligt för att överföra okomprimerat ljud under verkliga förhållanden, med den bullriga 2.4 GHz-frekvensen och behovet av att överföra styrdata. EDR 3 Mbit/s kräver hög överföringskraft och tolerans för störningar, så även i 3-DH5-läget är bekväm överföring av PCM omöjlig, det kommer ständigt att finnas korta avbrott, och allt fungerar endast inom några meters avstånd.
I praktiken är till och med en 990 kbit/s ljudström (LDAC 990 kbit/s) svår att överföra.

Vi går tillbaka till codec:erna.

SBC

Codec som är obligatorisk för alla enheter som stödjer A2DP-standarden. Bästa och sämsta codec på en gång.

Samplingsfrekvens
Bitdjup
Bithastighet
Stöd för kodning
Stöd för avkodning

16, 32, 44.1, 48 kHz
16 bit
10-1500 kbit/s
Av alla enheter
Av alla enheter

SBC är en enkel och beräkningssnabb codec, med en primitiv psykoakustisk modell (använder endast maskering av tysta ljud), som använder adaptiv impuls-modulering (APCM).
A2DP-specifikationen rekommenderar två profiler: Middel Kvalitet och Hög Kvalitet.


Codec har många inställningar som gör det möjligt att styra algoritmisk fördröjning, antalet prov i en block, algoritmen för bitfördelning, men nästan alltid används samma rekommenderade parametrar från specifikationen: Joint Stereo, 8 frekvensband, 16 block i ljudramen, bitfördelningsmetod Loudness.
SBC stödjer dynamisk ändring av parameter Bitpool, vilket direkt påverkar biträkningen. Om radiofrekvensen är överbelastad, paketer förloras eller enheter är på stort avstånd, kan ljudkällan minska Bitpool tills förbindelsen normaliseras.

Tillverkarna av de flesta hörlurar ställer in det maximala värdet för parameter Bitpool på 53, vilket begränsar biträkningen till 328 kilobit per sekund när den rekommenderade profilen används.
Även om tillverkaren av hörlurarna har ställt in det maximala värdet för Bitpool högre än 53 (sådana modeller finns exempelvis: Beats Solo³, JBL Everest Elite 750NC, Apple AirPods, samt på vissa mottagare och bilstereoenheter), tillåter de flesta operativsystem inte att använda högre biträkningar på grund av det inbyggda interna begränsningarna inom Bluetooth-stacken.
Dessutom sätter vissa tillverkare ett lågt maximalt värde för Bitpool för vissa enheter. Till exempel, för Bluedio T är det 39, och för Samsung Gear IconX — 37, vilket ger dålig ljudkvalitet.

Artificiella begränsningar från utvecklarna av Bluetooth-stacken uppstod förmodligen på grund av inkompatibilitet hos vissa enheter med stora värden av Bitpool eller atypiska profiler, även om de angav att de stödde dem, och på grund av otillräcklig testning vid certifiering. Författarna av Bluetooth-stacken föredrog att hålla sig till den rekommenderade profilen snarare än att skapa en databas av felaktiga enheter (även om de nu gör detta för andra felaktiga funktioner).

SBC tilldelar dynamiskt kvantbits för frekvensband, fungerar enligt principen nedifrån och upp, med olika vikter. Om hela biträkningen används för låga och medelhöga frekvenser kommer höga frekvenser att «klippas» (i stället för dem blir det tyst).

Exempel på SBC 328 kbit/s. Överst — originalet, nederst — SBC, det förekommer periodiska växlingar mellan spåren. För ljudet i videofilen används en förlustfri komprimeringscodec, FLAC. Användningen av FLAC i mp4-behållaren är officiellt inte standardiserad, så det är inte säkert att din webbläsare kan spela upp det, men det bör fungera i de senaste versionerna av desktop Chrome och Firefox. Om du inte har ljud kan du ladda ner filen och öppna den i en fullfjädrad videospelare.
ZZ Top — Sharp Dressed Man

I spektrumdiagrammet kan man se ett ögonblick av omslag: SBC klipper periodiskt de tysta ljuden över 17.5 kHz och framhäver knappt bitarna för banden över 20 kHz. Den fullständiga spektrogrammet är tillgängligt genom ett klick (1.7 MB).

Jag hör ingen skillnad mellan originalet och SBC på denna låt.

Låt oss ta något nyare och modellera ljudet som skulle fås vid användning av Samsung Gear IconX hörlurar med Bitpool 37 (överst — det ursprungliga ljudet, nederst — SBC 239 kbit/s, ljudet i FLAC).
Mindless Self Indulgence — Witness

Jag hör knakande ljud, mindre stereo-effekt och obehagligt "klickande" av sången i de höga frekvenserna.

Även om SBC är en mycket flexibel codec som kan ställas in för låga fördröjningar, ger den utmärkt ljudkvalitet vid höga bithastigheter (452+ kbit/s) och är helt okej för de flesta vid standard High Quality (328 kbit/s). Eftersom A2DP-standarden inte anger fasta profiler (utan ger endast rekommendationer) har utvecklare av stackar infört konstgjorda begränsningar på Bitpool; parametrarna för det överförda ljudet visas inte i användargränssnittet, och tillverkarna av hörlurar är fria att ställa in sina egna inställningar och anger aldrig bitpool-värdet i produktens tekniska specifikationer. Codec har blivit känd för låg ljudkvalitet, även om det inte är ett problem med codec själv.
Bitpool-parametern påverkar direkt bithastigheten endast inom ramen för en profil. Samma Bitpool-värde på 53 kan ge en bithastighet av 328 kbit/s med den rekommenderade profilen High Quality, samt 1212 kbit/s med Dual Channel och 4 frekvensband, vilket leder till att OS-utvecklare, förutom begränsningar på Bitpool, även sätter begränsningar på Bitrate. Som jag ser det har en sådan situation uppstått på grund av brister i A2DP-standarden: man borde ha kunnat samordna bithastigheten snarare än Bitpool.

Tabell över SBC-funktioner i olika operativsystem:

OS
Stödda samplingsfrekvenser
Maximalt Bitpool-gräns
Maximalt Bitrate-gräns
Typiskt Bitrate
Dynamisk justering av Bitpool

Windows 10
44.1 kHz
53
512 kbit/s
328 kbit/s
✓*

Linux (BlueZ + PulseAudio)
16, 32, 44.1, 48 kHz
64 (vid inkoppling), 53 (vid utkoppling)
Inga begränsningar
328 kbit/s
✓*

macOS High Sierra
44.1 kHz
64, standard 53***
Okänt
328 kbit/s
✗

Android 4.4-9
44.1/48 kHz**
53
328 kbit/s
328 kbit/s
✗

Android 4.1-4.3.1
44.1, 48 kHz**
53
229 kbit/s
229 kbit/s
✗

Blackberry OS 10
48 kHz
53
Inga begränsningar
328 kbit/s
✗

* Bitpool minskar bara och ökar inte automatiskt vid förbättrade överföringsförhållanden. För att återställa Bitpool måste du pausa uppspelningen, vänta några sekunder och sedan starta om ljudet.
** Standardvärdet beror på inställningarna för stacken som angavs vid kompilering av fastvaran. I Android 8/8.1 är frekvensen antingen 44.1 kHz eller 48 kHz, beroende på inställningarna vid kompilering. I andra versioner stöds 44.1 kHz och 48 kHz samtidigt.
*** Bitpool-värdet kan höjas i programmet Bluetooth Explorer.

aptX och aptX HD

aptX är ett enkelt och beräkningssnabbt codec utan psykoakustik, som använder adaptiv differential pulskodmodulering (ADPCM). Det uppkom omkring 1988 (datumet för inlämningen av patentet är daterat februari 1988), innan Bluetooth användes det främst i professionell trådlös ljudutrustning. För närvarande ägs det av Qualcomm, kräver licensiering och royaltybetalningar. Sedan 2014: $6000 en gång och ≈$1 per enhet, vid beställningar upp till 10000 enheter (ClickHouse-Ninja/Proton, s. 16).
aptX och aptX HD är samma codec, med olika kodningsprofiler.

Codecet har bara en parameter – val av samplingsfrekvens. Det finns visserligen också val av antal/läge kanaler, men i alla kända enheter (70+ stycken) stöds uteslutande stereo.

Codec
Samplingsfrekvens
Bitdjup
Bithastighet
Stöd för kodning
Stöd för avkodning

aptX
16, 32, 44.1, 48 kHz
16 bit
128 / 256 / 352 / 384 kbps (beroende på samplingsfrekvens)
Windows 10 (stationär och mobil), macOS, Android 4.4+/7*, Blackberry OS 10
Ett brett antal ljudenheter (hårdvaru)

* Versioner före 7 kräver modifiering av Bluetooth-stacken. Codec stöds endast om tillverkaren av Android-enheten har licensierat användningen av codecet från Qualcomm (om OS har kodningsbibliotek).

aptX delar upp ljudet i 4 frekvensband och kvantiserar dem med samma antal bitar konstant: 8 bitar för 0-5.5 kHz, 4 bitar för 5.5-11 kHz, 2 bitar för 11-16.5 kHz, 2 bitar för 16.5-22 kHz (siffror för samplingsfrekvensen 44.1 kHz).

Exempel på aptX-ljud (överst – originalsignalen, nederst – aptX, spektrogram endast för vänster kanal, ljud i FLAC):

De högre frekvenserna blev något rödare, men skillnaden är inte hörbar.

På grund av den fasta bitfördelningen kan codec inte "flytta bitar" till de frekvenser som mest behöver dem. Till skillnad från SBC kommer aptX inte att "klippa" frekvenser utan kommer istället att lägga till kvantiseringsbrus, vilket minskar ljudets dynamiska omfång.

Man bör inte tro att användningen av till exempel 2 bitar för bandet minskar det dynamiska omfånget till 12 dB: ADPCM kan möjliggöra upp till 96 dB dynamiskt omfång även med 2 bitar kvantisering, men endast för ett visst signal.
ADPCM lagrar skillnaden i det numeriska värdet mellan den aktuella och nästa sampling istället för att spela in det absoluta värdet, som i PCM. Detta gör att man kan minska kraven på antalet bitar som behövs för att lagra samma (förlustfria) eller praktiskt sett samma (med relativt liten avrundningsfel) information. För att minska avrundningsfel används koefficienttabeller.
Vid skapandet av codec beräknade författarna ADPCM-koefficienterna på en uppsättning musikaliska ljudfiler. Ju närmare ljudsignalen är den uppsättning musik som tabellerna byggdes på, desto färre kvantiseringsfel (brus) genererar aptX.

Därför kommer syntetiska tester alltid att ge sämre resultat än musik. Jag skapade ett speciellt syntetiskt exempel där aptX visar dåliga resultat — en sinusvåg med en frekvens av 12,4 kHz (ovanför - originalsignalen, nedanför - aptX. Ljudet är i FLAC. Sänk volymen!):

Spektrumdiagram:


Brus hörs tydligt.

Men om man genererar en sinusvåg med lägre amplitud så att den är tystare, kommer också bruset att bli tystare, vilket visar på ett brett dynamiskt omfång:

För att höra skillnaden mellan det originala musikspåret och det komprimerade kan man invertera en av signalerna och addera spåren kanalvis. Denna metod är generellt sett felaktig och skulle inte ge rimliga resultat med mer komplexa codecs, men för ADPCM fungerar den bra.
Skillnaden mellan originalet och aptX
Det genomsnittliga kvadratiska värdet av signalernas skillnader ligger på -37.4 dB, vilket inte är mycket för sådan komprimerad musik.

aptX HD

aptX HD är inte en fristående codec — det är en förbättrad kodningsprofil av aptX-codec. Ändringarna berör antalet bitar som avsatts för kodning av frekvensområden: 10 bitar för 0-5,5 kHz, 6 bitar för 5,5-11 kHz, 4 bitar för 11-16,5 kHz, 4 bitar för 16,5-22 kHz (siffror för 44,1 kHz).

Codec
Samplingsfrekvens
Bitdjup
Bithastighet
Stöd för kodning
Stöd för avkodning

aptX HD
16, 32, 44.1, 48 kHz
24 bitar
192 / 384 / 529 / 576 kbit/s (beroende på samplingsfrekvens)
Android 8+*
Vissa ljudenheter (hårt)

* Versioner före 7 kräver modifiering av Bluetooth-stacken. Codec stöds endast om tillverkaren av Android-enheten har licensierat användningen av codecet från Qualcomm (om OS har kodningsbibliotek).

Mindre vanligt än aptX: verkar kräva separat licensiering från Qualcomm och separata licensavgifter.

Låt oss återgå till exemplet med sinusvåg vid 12,4 kHz:


Mycket bättre än med aptX, men fortfarande lite brusigt.

aptX Low Latency

Codec från Qualcomm, som inte har något gemensamt med standarderna aptX och aptX HD, enligt den begränsade informationen från personer involverade i dess utveckling. Designad för interaktiv överföring av ljud med låg latens (filmer, spel), där ljudfördröjning inte kan justeras programvarumässigt. Kända mjukvaruimplementationer av kodare och dekodare saknas, stöds enbart av sändare, mottagare, hörlurar och högtalare, men inte smartphones och datorer.

Samplingsfrekvens
Bithastighet
Stöd för kodning
Stöd för avkodning

44.1 kHz
276/420 kbit/s
Av vissa sändare (hårt)
Vissa ljudenheter (hårt)

AAC

AAC, eller Advanced Audio Coding — en beräkningsmässigt komplex codec med en avancerad psykoakustisk modell. Har blivit allmänt utbredd för ljud på internet, näst mest populär efter MP3. Kräver licensiering och licensavgifter: $15000 engångsavgift (eller $1000 för företag med färre än 15 anställda) + $0.98 för de första 500000 enheterna (ClickHouse-Ninja/Proton).
Codecen är standardiserad inom MPEG-2 och MPEG-4 specifikationer, och trots vanlig missuppfattning, tillhör den inte Apple.

Samplingsfrekvens
Bithastighet
Stöd för kodning
Stöd för avkodning

8 — 96 kHz
8 — 576 kbit/s (för stereo), 256 — 320 kbit/s (typisk för Bluetooth)
macOS, Android 7+*, iOS
Ett brett antal ljudenheter (hårdvaru)

* bara på enheter vars tillverkare har betalat licensavgifter

I iOS och macOS används den bästa tillgängliga kodaren från Apple AAC, vilket säkerställer maximal ljudkvalitet. I Android används den näst bästa kodaren Fraunhofer FDK AAC, men olika hårdvarulösningar som är inbyggda i plattformen (SoC) kan användas, med okänd kodningskvalitet. Enligt nyliga tester från SoundGuys, kodningskvaliteten för AAC som används av olika Android-telefoner skiljer sig mycket:

För de flesta trådlösa ljudenheter för AAC är den maximala bitrate inställd på 320 kbps, medan vissa endast stöder 256 kbps. Andra bitrates förekommer sällan.
AAC erbjuder utmärkt kvalitet vid bitrates på 320 och 256 kbps, men är känslig för förluster vid sekventiell kodning av redan komprimerat innehåll., men att höra några skillnader från originalet på iOS vid en bitrate på 256 kbps är svårt även vid flera sekventiella kodningar, vid enstaka kodning, till exempel MP3 320 kbps till AAC 256 kbps, kan förluster försummas.
Som med andra Bluetooth-codecs decodas all musik först och kodas sedan av codec. När man lyssnar på musik i AAC-format decodas den först av operativsystemet och kodas sedan en gång till i AAC för att överföras via Bluetooth. Detta är nödvändigt för att blanda flera ljudströmmer, till exempel musik och meddelanden om nya notifieringar. iOS är inget undantag. Det finns många påståenden på internet om att musik i AAC-format inte transkodas vid överföring via Bluetooth på iOS, vilket är felaktigt.

MP1/2/3

Codecs i MPEG-1/2 Part 3-familjen består av den kända och allmänt använda MP3, den mindre vanliga MP2 (som främst används inom digital TV och radio), och den helt okända MP1.

Gamla codecs MP1 och MP2 stöds inte alls: jag lyckades inte hitta några hörlurar eller någon Bluetooth-stack som kodar eller decodar dem.
Dekodning av MP3 stöds av vissa hörlurar, men kodning stöds inte av någon av de moderna operativsystemens stackar. Det verkar som att den tredjepartsstacken BlueSoleil för Windows kan koda till MP3 om man manuellt ändrar konfigurationsfilen, men installationen av den resulterar i BSoD på Windows 10. Slutsatsen är att codec faktiskt inte kan användas för Bluetooth-ljud.
Tidigare, mellan 2006 och 2008, innan standarden A2DP blev vanlig i enheter, lyssnade människor på MP3-musik med Nokia BH-501 hörlurar genom programmet MSI BluePlayer, som var tillgängligt på Symbian och Windows Mobile. Vid den tiden tillät smarttelefoners operativsystemsarkitektur åtkomst till många lågnivåfunktioner, och på Windows Mobile kunde man till och med installera tredjeparts Bluetooth-stackar.

Det senaste patentet på MP3-codec har löpt ut, och användning av codec kräver inga licensavgifter sedan den 23 april 2017.

Om det längsta patentet som nämns i de ovanstående referenserna tas som mått, blev MP3-teknologin patentfri i USA den 16 april 2017 när det amerikanska patentet 6,009,399, som ägdes och administrerades av Technicolor, gick ut.

Källa: www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html

Samplingsfrekvens
Bithastighet
Stöd för kodning
Stöd för avkodning

16 — 48 kHz
8 — 320 kbps
Stöds inte någonstans
Vissa ljudenheter (hårt)

LDAC

Den nya och aktivt marknadsförda «Hi-Res»-codecen från Sony, som stödjer samplingsfrekvenser upp till 96 kHz och 24-bitars upplösning, med en bitrate på upp till 990 kbps. Marknadsförs som en audiophile codec, som en ersättning för befintliga Bluetooth-codecs. Har en funktion för adaptiv justering av bitrate, beroende på radiovillkoren.

Encoder LDAC (libldac) ingår i standardleveransen av Android, så kodning stöds på vilken Android-smartphone som helst från och med version 8 av operativsystemet. Programvarudekodare saknas i allmän tillgång, kodexens specifikation är inte offentlig, men vid första ögonkastet av kodarens interna konstruktion liknar den ATRAC9 — en codec från Sony, som används i PlayStation 4 och Vita: båda arbetar i frekvensområdet, använder modifierad diskret cosinustransform (MDCT) och komprimering med Huffman-algoritmen.

Stödet för LDAC finns praktiskt taget endast på hörlurar från Sony. Möjligheten att dekoda LDAC förekommer ibland på hörlurar och DAC:ar från andra tillverkare, men mycket sällan.

Samplingsfrekvens
Bithastighet
Stöd för kodning
Stöd för avkodning

44.1 — 96 kHz
303/606/909 kbps (för 44.1 och 88.2 kHz), 330/660/990 kbps (för 48 och 96 kHz)
Android 8+
Vissa Sony-hörlurar och ett par enheter från andra tillverkare (hårdvarumässigt)

Marknadsföringen av LDAC som Hi-Res-codec skadar dess tekniska aspekt: det är dumt att slösa bitrate på att överföra frekvenser som inte hörs av det mänskliga örat och ökad upplösning när det inte räcker till för att överföra CD-kvalitet (44.1/16) utan förlust. Lyckligtvis har codec'en två driftslägen: överföring av CD-ljud och överföring av Hi-Res-ljud. I det första fallet överförs endast 44.1 kHz/16 bitar trådlöst.

Eftersom det inte finns någon programvarudekoder för LDAC tillgänglig för allmänheten, är det omöjligt att testa codec'en utan ytterligare enheter som dekodar LDAC. Enligt testen av LDAC på DAC med stöd för denne, som kopplades av ingenjörerna på SoundGuys.com via digital utgång och spelade in den utfärdade ljudet på testsignaler, ger LDAC 660 och 990 kbps i CD-kvalitet ett signal/brusförhållande något bättre än aptX HD.

Källa: www.soundguys.com/ldac-ultimate-bluetooth-guide-20026

LDAC stöder även dynamisk bithastighet utanför de angivna profilerna - från 138 kbit/s till 990 kbit/s, men såvitt jag kan bedöma används endast standardiserade profiler 303/606/909 och 330/660/990 kbit/s i Android.

Övriga kodekar

Andra A2DP-kodekar har inte fått något bredare genomslag. Deras stöd är antingen nästan helt obefintligt eller endast tillgängligt på vissa modeller av hörlurar och smartphones.
Den standardiserade A2DP-kodeken ATRAC har aldrig använts som Bluetooth-kodek ens av Sony själva, kodekar som Samsung HD, Samsung Scalable och Samsung UHQ-BT har mycket begränsat stöd från sändande och mottagande enheter, medan HWA LHDC är för nytt och stöds bara av tre(?) enheter.

Stöd för kodekar av ljudenheter

Inte alla tillverkare publicerar exakt information om vilka kodekar som stöds av olika trådlösa hörlurar, högtalare, mottagare eller sändare. Ibland är det så att stöd för en viss kodek endast finns för sändning, men inte för mottagning (gäller för kombinerade sändare-mottagare), även om tillverkaren bara uppger "stöd", utan kommentarer (jag misstänker att detta beror på separat licensiering av kodare och avkodare för vissa kodekar). I de billigaste enheterna kan den uppgivna stödet för aptX helt saknas.

Tyvärr visas den använda kodeken i gränssnitten för de flesta operativsystem ingenstans. Information om detta finns endast i Android, från version 8 och macOS. Men även i dessa operativsystem kommer bara de kodekar som både telefonen/datorn och hörlurarna stöder att visas.

Hur får man veta vilka kodekar enheten stöder? Spela in och analysera en dump av trafik med A2DP-förhandlingsparametrar!
Detta kan göras i Linux, macOS och Android. I Linux kan man använda Wireshark eller hcidump, i macOS - Bluetooth Explorer, och i Android - den inbyggda funktionen för att spara Bluetooth HCI-dump som är tillgänglig i utvecklarverktygen. Du får en dump i btsnoop-format som kan laddas upp till Wireshark-analysatorn.
Observera: en korrekt dump kan endast erhållas genom att ansluta telefonen/datorn till hörlurar/högtalare (hur märkligt det än låter)! Hörlurarna kan själva etablera en anslutning till telefonen, och i så fall kommer de att begära en lista över codecs från telefonen, och inte vice versa. För att garantera en riktig dump, koppla först bort enheten och koppla sedan, under dumpningen, telefonen till hörlurarna.

Använd följande filter för att filtrera bort irrelevant trafik:

btavdtp.signal_id

Som resultat bör du se något som liknar detta:

På varje punkt i kommandot GetCapabilities kan man klicka och se detaljerade specifikationer för codec.

Wireshark känner inte igen alla codec-id, så vissa codecs måste avkodas manuellt, genom att titta i tabellen med identifierare nedan:

Obligatoriska:
0x00 - SBC

Valfria:
0x01 - MPEG-1,2 (även känd som MP3)
0x02 - MPEG-2,4 (även känd som AAC)
0x04 - ATRAC

Leverantörsspecifika:
0xFF 0x004F 0x01   - aptX
0xFF 0x00D7 0x24   - aptX HD
0xFF 0x000A 0x02   - aptX Low Latency
0xFF 0x00D7 0x02   - aptX Low Latency
0xFF 0x000A 0x01   - FastStream
0xFF 0x012D 0xAA   - LDAC
0xFF 0x0075 0x0102 - Samsung HD
0xFF 0x0075 0x0103 - Samsung Scalable Codec
0xFF 0x053A 0x484C - Savitech LHDC

0xFF 0x000A 0x0104 - CSR True Wireless Stereo v3 Codec ID för AAC
0xFF 0x000A 0x0105 - CSR True Wireless Stereo v3 Codec ID för MP3
0xFF 0x000A 0x0106 - CSR True Wireless Stereo v3 Codec ID för aptX

För att inte behöva analysera dumps manuellt har jag skapat en tjänst som analyserar allt automatiskt: btcodecs.valdikss.org.ru

Jämförelse av codecs. Vilken codec är bäst?

Varje codec har sina egna fördelar och nackdelar.
aptX och aptX HD använder fastställda profiler som inte kan ändras utan modifiering av encoder och decoder. Varken tillverkaren av telefonen eller tillverkaren av hörlurarna kan ändra bitrate eller kodningsfaktorer för aptX. Codec-ägaren, Qualcomm, tillhandahåller en referensencoder i form av ett bibliotek. Dessa fakta är en stark punkt för aptX – du vet i förväg vilken ljudkvalitet du kommer att få, utan några "men."

SBC har å sin sida många anpassningsbara alternativ, dynamisk bitrate (kodaren kan minska bitpool-parametern om radiofrekvensen är belastad) och har inga fasta profiler, utan endast rekommenderade "medelkvalitet" och "hög kvalitet" som lades till i A2DP-specifikationen 2003. "Hög kvalitet" är redan inte så hög enligt moderna mått, och de flesta Bluetooth-stackar tillåter inte att använda parametrar som är bättre än profilen för "hög kvalitet", även om det tekniskt sett inte finns några begränsningar för detta.
Bluetooth SIG har ingen referenskodare för SBC i form av ett bibliotek, och tillverkare implementerar den själva.
Det här är SBC:s svagheter – man kan aldrig veta i förväg vilken ljudkvalitet man kan förvänta sig från en specifik enhet. SBC kan ge både låg och mycket hög ljudkvalitet, men den senare kan inte nås utan att stänga av eller kringgå artificiella begränsningar i Bluetooth-stackarna.

Situationen med AAC är otydlig: å ena sidan borde codec teoretiskt sätt ge ljud av kvalitet som är obeskedligt från originalet, men enligt tester från SoundGuys-laboratoriet på olika Android-enheter bekräftas detta inte i praktiken. Troligtvis beror det på de lågkvalitativa hårdvaru-ljudkodare som är inbyggda i olika telefonchipsets. Det är meningsfullt att använda AAC endast på Apple-enheter, medan man på Android bör hålla sig till aptX och LDAC.

Utrustning som stöder alternativa codecs är vanligtvis av högre kvalitet, helt enkelt eftersom det inte är meningsfullt att betala licensavgifter för att använda dessa codecs på riktigt billiga, lågkvalitativa enheter. Enligt mina tester låter SBC väldigt bra på kvalitetsutrustning.

Jag har skapat en webbtjänst som kodar ljud i SBC, aptX och aptX HD i realtid, direkt i webbläsaren. Med den kan du testa dessa ljudcodecs utan faktisk överföring av ljud via Bluetooth, på alla trådbundna hörlurar, högtalare och din favoritmusik, samt ändra kodningsparametrarna direkt under ljuduppspelningen:
btcodecs.valdikss.org.ru/sbc-encoder
Tjänsten använder SBC-kodningsbibliotek från BlueZ-projektet och libopenaptx från ffmpeg, som har kompilerats till WebAssembly och JavaScript från C, via emscripten, för att köras i webbläsaren. Vem kunde drömma om en sådan framtid!

Så här ser det ut:

Observera hur ljudnivån förändras efter 20 kHz för olika codec. I den ursprungliga MP3-filen saknas frekvenser över 20 kHz.

Försök att växla mellan codec och bedöm om du hör skillnaden mellan originalet, SBC 53 Joint Stereo (den standardmässigt mest använda profilen), och aptX/aptX HD.

Jag hör skillnaden mellan codec i hörlurarna!

Personer som inte hör någon skillnad mellan codecs under testning via webbservicen försäkrar att de hör den vid musiklyssning i trådlösa hörlurar. Tyvärr är det ingen skämt eller placeboeffekt: skillnaden hörs faktiskt, men den orsakas inte av skillnaderna mellan codecs.

Den överväldigande majoriteten av Bluetooth-audiochipset som används i mottagande trådlösa enheter är utrustade med digitala signalprocessorer (Digital Signal Processor, DSP) som implementerar ett equalizer, kompressor, stereoförstärkare och andra funktioner som syftar till att förbättra (eller förändra) ljudet. Tillverkare av Bluetooth-utrustning kan konfigurera DSP för varje codec separat, och när man växlar mellan codecs kan lyssnaren uppfatta att han hör skillnaden mellan codecs, när han i verkligheten hör olika DSP-inställningar.

DSP ljudprocessorkedjan Kalimba i chip från CSR/Qualcomm

Aktivering av olika DSP-funktioner för varje codec och utgång separat

Vissa enheter i premiumsegmentet levereras med programvara som gör det möjligt att justera DSP-inställningar, men de flesta budgetvänliga hörlurar har inte denna funktion, och användare kan inte stänga av ljudbehandlingen med hjälp av grundläggande medel.

Funktionella egenskaper hos enheter

Den moderna versionen av A2DP-standarden har en funktion för "absolut volymkontroll" — styrning av enhetens volym med speciella kommandon från AVRCP-protokollet, vilket reglerar förstärkarens utgångsnivå istället för att programvarumässigt minska volymen på ljudströmmen. Om volymjusteringen på hörlurarna inte synkroniseras med volymen på telefonen, betyder det att dina hörlurar eller telefon inte stöder denna funktion. I så fall är det vettigt att alltid lyssna på musik med maximal volym på telefonen och justera den faktiska volymen med hörlurarnas knappar — på så sätt blir förhållandet signal/brus bättre och ljudkvaliteten. bör vara högre.
I verkligheten finns det dock sorgliga situationer. På mina hörlurar RealForce OverDrive D1 är en stark kompressor aktiverad för SBC, och att öka volymen leder till att nivån på låga ljud ökar, medan volymen av höga ljud förblir oförändrad (signalens kompression sker). Därför måste jag ställa in volymen på datorn på ungefär hälften, vid detta tillfälle finns det nästan ingen kompressionseffekt.
Enligt mina observationer stöder alla hörlurar med extra codecs funktionen för absolut volymkontroll, uppenbarligen är detta ett av kraven för certifiering av codecs.

Vissa hörlurar stöder anslutning av två enheter samtidigt. Detta möjliggör till exempel att lyssna på musik från datorn och ta emot samtal från telefonen. Men det är viktigt att veta att i detta läge inaktiveras alternativa codecs och endast SBC används.

AVDTP 1.3 Delay Reporting-funktionen ger hörlurarna möjlighet att rapportera fördröjningen till den sändande enheten, med vilken ljudet faktiskt spelas upp. Detta möjliggör justering av ljudsynkronisering med video när man tittar på videofiler: vid problem med överföring via radiobanden kommer ljudet inte att ligga efter videon, utan video kommer att stanna upp i videospelaren tills ljud och video synkroniseras igen.
Funktionen stöds av många hörlurar, Android 9+ och Linux med PulseAudio 12.0+. Jag vet inte om funktionen stöds på andra plattformar.

Tvåvägskommunikation via Bluetooth. Röstöverföring.

För överföring av ljud via Bluetooth används Synchronous Connection Oriented (SCO) — synkron överföring med förhandsgodkem för anslutningen. Detta läge tillåter ljud och röst att överföras strikt i ordning, med symmetrisk hastighet för avsändning och mottagning, utan att vänta på bekräftelse och omöverföring av paket. Detta minskar den totala latensen för ljudöverföring över radiokanalen, men medför allvarliga begränsningar på mängden data som kan överföras per tidsenhet, och påverkar kvaliteten negativt.
När detta läge används överförs både röst och ljud med samma kvalitet.
Tyvärr, enligt uppgifter från 2019, är kvaliteten på talöverföring via Bluetooth fortfarande låg, och det är oklart varför Bluetooth SIG inte gör något åt detta.

CVSD

Den grundläggande talöverföringskodeken CVSD standardiserades 2002 och stöds av alla dubbelriktade kommunikationsenheter via Bluetooth. Den möjliggör ljudöverföring med en samplingsfrekvens på 8 kHz, vilket motsvarar kvaliteten på vanlig trådad telekommunikation.

Exempel på inspelning i denna kodek.

mSBC

Den ytterligare kodeken mSBC standardiserades 2009, och redan 2010 kom det chip som använde den för talöverföring. mSBC stöds i stor utsträckning av olika enheter.
Det är ingen självständig kodek, utan en vanlig SBC från A2DP-standarden, med en fast kodningsprofil: 16 kHz, mono, bitpool 26.

Exempel på inspelning i denna kodek.

Inte imponerande, men mycket bättre än CVSD, ändå är det fortfarande obehagligt att använda den för kommunikation över internet, särskilt när du använder hörlurar för att prata i spel — spelets ljud kommer också överföras med en samplingsfrekvens på 16 kHz.

FastStream Företaget CSR bestämde sig för att vidareutveckla idén om att återanvända SBC. För att kringgå begränsningarna i SCO-protokollet och använda högre bitrate, tog CSR en annan väg — de införde stöd för dubbelriktad SBC-ljudöverföring i standarden för enkelriktad ljudöverföring A2DP, standardiserade kodningsprofiler och kallade det "FastStream".

FastStream överför stereoljud till högtalarna med 44,1 eller 48 kHz vid en bitrate på 212 kbit/s, medan ljudöverföring från mikrofonen använder mono, 16 kHz, med en bitrate på 72 kbit/s (lite bättre än mSBC). Dessa parametrar passar mycket bättre för kommunikation i onlinespel - ljudet från spel och samtalspartners blir av hög kvalitet.

Exempel på inspelning i denna kodek (+ ljud från mikrofonen, samma som mSBC).

Företaget har kommit på en intressant lösning, men eftersom den strider mot A2DP-standarden, finns supporten endast i vissa av företagets sändare (som fungerar som en USB-ljudkort, inte som en Bluetooth-enhet), men stöd i Bluetooth-stackar har den inte fått, trots att antalet hörlurar med stöd för FastStream inte är så litet.

För närvarande finns support för FastStream i operativsystemet endast i form av en patch för Linux PulseAudio från utvecklaren Pali Rohár, som inte ingår i den huvudsakliga grenen av programmet.

aptX Low Latency

Till stor förvåning stöder aptX Low Latency också tvåvägs ljud, och implementerar samma princip som FastStream.
Det går inte att använda denna codec-funktion någonstans – det finns inget stöd för avkodning av Low Latency i något operativsystem eller i någon av de Bluetooth-stackar jag känner till.

Bluetooth 5, Classic och Low Energy

Det har uppstått stor förvirring kring specifikationerna och versionerna av Bluetooth på grund av närvaron av två inkompatibla standarder under ett och samma varumärke, båda av vilka används i stor utsträckning för olika syften.

Det finns två olika, inkompatibla Bluetooth-protokoll: Bluetooth Classic och Bluetooth Low Energy (LE, även känt som Bluetooth Smart). Det finns också ett tredje protokoll, Bluetooth High Speed, men det är sällsynt och används inte i hushållsenheter.

Från och med Bluetooth 4.0 har ändringarna i specifikationen främst rört Bluetooth Low Energy, medan Classic-versionen endast fått små förbättringar.

Ändringar mellan Bluetooth 4.2 och Bluetooth 5:

9 ÄNDRINGAR FRÅN v4.2 TILL 5.0

9.1 NYA FUNKTIONER

Flera nya funktioner introduceras i Bluetooth Core Specification 5.0 Release. De främsta förbättringsområdena är:
• Slot Availability Mask (SAM)
• 2 Msym/s PHY för LE
• LE Long Range
• Hög arbetscykel Icke-anslutbar annonsering
• LE Annonsering Extensions
• LE Kanalvalalgoritm #2
9.1.1 Funktioner tillagda i CSA5 — Integrerade i v5.0
• Högre utgångseffekt

Källa: www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=421043 (sidan 291)

Bara en ändring påverkade Classic-versionen inom ramen för specifikationen Bluetooth 5: man lade till stöd för teknologin Slot Availability Mask (SAM), som syftar till att förbättra uppdelningen av radiospektrumet. Alla andra ändringar berör endast Bluetooth LE (och Högre utgångseffekt också).

Alla ljudenheter använder endast Bluetooth Classic. Hörlurar och högtalare kan inte anslutas via Bluetooth Low Energy: det finns ingen standard för överföring av ljud med hjälp av LE. A2DP-standarden, som används för överföring av högkvalitativt ljud, fungerar endast via Bluetooth Classic, och det finns ingen motsvarighet i LE.

Det är meningslöst att köpa ljudenheter med Bluetooth 5 endast på grund av den nya versionen av protokollet. Bluetooth 4.0/4.1/4.2 kommer att fungera exakt på samma sätt när det gäller ljudöverföring.
Om lanseringen av nya hörlurar nämner en fördubblad räckvidd och minskad energiförbrukning tack vare Bluetooth 5, så vet du att de antingen inte vet vad de pratar om eller lurar dig. Det är inte konstigt, eftersom till och med tillverkare av Bluetooth-chips i sina anmälningar blandar ihop skillnaderna i den nya versionen av standarden, och vissa Bluetooth 5-chips stöder den femte versionen endast för LE, medan de för Classic använder 4.2.

Ljudöverföringsfördröjning

Mängden ljudfördröjning beror på många faktorer: buffertstorleken i ljudstacken, i Bluetooth-stacken och i den trådlösa enheten som spelar upp ljudet, samt den algoritmiska fördröjningen av codec.

Fördröjningen i enkla codecs, såsom SBC, aptX och aptX HD, är ganska liten och ligger på 3-6 ms, vilket kan försummas, men mer komplexa codecs, såsom AAC och LDAC, kan ge avsevärd fördröjning. Den algoritmiska fördröjningen för AAC vid 44,1 kHz är 60 ms. LDAC - omkring 30 ms (en grov analys av källkoden. Jag kan ha fel, men inte mycket.)

Den totala fördröjningen beror starkt på uppspelningsenheten, dess chipset och buffert. Under tester fick jag en spridning från 150 till 250 ms på olika enheter (med SBC codec). Om man antar att enheter som stöder ytterligare codecs som aptX, AAC och LDAC använder kvalitetskomponenter och en liten buffertstorlek, skulle vi få följande typiska fördröjningar:

SBC: 150-250 ms
aptX: 130-180 ms
AAC: 190-240 ms
LDAC: 160-210 ms

Jag påminner om att aptX Low Latency inte stöds i operativsystem, vilket innebär att lägre fördröjning endast kan uppnås med en kombination av sändare + mottagare eller sändare + hörlurar/högtalare, och alla enheter måste stödja denna codec.

Problemen med enheter, certifiering och Bluetooth-logotyper

Hur kan man särskilja en kvalitetsljudenhet från en billig imitation? I första hand utseendet!

Billiga kinesiska hörlurar, högtalare och mottagare:

1. Ordet 'Bluetooth' saknas på lådan och enheten, 'Wireless' och 'BT' används oftast.
2. Bluetooth-logotypen saknas på lådan eller enheten
3. Det finns ingen blinkande blå LED

Avsaknaden av dessa element tyder på att enheten inte har certifierats, vilket innebär att den potentiellt är av låg kvalitet och problematisk. Till exempel är hörlurarna från Bluedio inte certifierade för Bluetooth och uppfyller inte helt A2DP-specifikationen. De skulle inte ha klarat certifieringen.

Låt oss titta på några enheter och lådor från dem:

Detta är allt icke-certifierade enheter. Instruktionen kan ha en logotyp och namn för Bluetooth-teknik, men det viktigaste är att de finns på lådan och/eller själva enheten.

Om dina hörlurar eller högtalare säger "Ze bluetooth dewise is connecteda successfulle", betyder inte det heller något om deras kvalitet:

Slutsats

Kan Bluetooth helt ersätta trådbundna hörlurar och headset? Ja, men med låg kvalitet i samtalsläge, ökad ljudfördröjning som kan irritera under spel, och många proprietära kodekar som kräver licensavgifter och ökar det slutliga priset på både smartphones och hörlurar.

Marknadsföringen av alternativa kodekar är mycket stark: aptX och LDAC presenteras som en efterlängtad ersättning för den "föråldrade och dåliga" SBC, som långt ifrån är så dålig som man brukar tro.

Det har visat sig att de artificiella begränsningarna i Bluetooth-stacken för bitrate SBC kan kringgås, så att SBC inte ligger efter aptX HD. Jag tog initiativet och gjorde en patch för LineageOS-firmware: Modifiera Bluetooth-stacken för att förbättra ljudet på hörlurar utan kodekarna AAC, aptX och LDAC

Mer information finns på webbplatserna SoundGuys och SoundExpert.

Bonus: referensencoder SBC, information om bitström A2DP och testfiler. Denna fil lades tidigare ut offentligt på Bluetooths webbplats, men nu är den endast tillgänglig för dem som gått med i Bluetooth SIG.

Källa: habr.com