På grunn av masseproduksjonen av smarttelefoner uten 3.5 mm lydkontakt, har trådløse Bluetooth-hodetelefoner blitt hovedmåten for mange å lytte til musikk og kommunisere i headset-modus.
Produsenter av trådløse enheter skriver ikke alltid detaljerte produktspesifikasjoner, og artikler om Bluetooth-lyd på Internett er motstridende, noen ganger feil, snakker ikke om alle funksjonene og kopierer ofte den samme informasjonen som ikke samsvarer med virkeligheten.
La oss prøve å forstå protokollen, egenskapene til Bluetooth OS-stabler, hodetelefoner og høyttalere, Bluetooth-kodeker for musikk og tale, finne ut hva som påvirker kvaliteten på overført lyd og ventetid, lære hvordan du samler inn og dekoder informasjon om støttede kodeker og andre enheter evner.

TL; DR:

• SBC - normal kodek
• Hodetelefonene har sin egen equalizer og etterbehandling for hver kodek separat
• aptX er ikke så bra som annonsert
• LDAC markedsfører tull
• Samtalekvaliteten er fortsatt dårlig
• Du kan bygge inn C-lydkodere i nettleseren din ved å kompilere dem i WebAssembly via emscripten, og de vil ikke bremse mye.

Musikk via Bluetooth

Den funksjonelle komponenten til Bluetooth bestemmes av profiler - spesifikasjoner av spesifikke funksjoner. Bluetooth-musikkstrømming bruker en høykvalitets A2DP enveis lydoverføringsprofil. A2DP-standarden ble tatt i bruk i 2003 og har ikke endret seg vesentlig siden den gang.
Innenfor profilen er 1 obligatorisk kodek med lav beregningskompleksitet SBC, laget spesielt for Bluetooth, og 3 ekstra kodek standardisert. Det er også mulig å bruke udokumenterte kodeker for egen implementering.

Fra juni 2019 er vi i xkcd-tegneserien med 14 A2DP-kodeker:

• SBC ← standardisert i A2DP, støttet av alle enheter
• MPEG-1/2 Layer 1/2/3 ← standardisert i A2DP: velkjent MP3, brukt i digital-TV MP2, og ukjent MP1
• MPEG-2/4 AAC ← standardisert i A2DP
• ATTRAC ← gammel kodek fra Sony, standardisert i A2DP
• LDAC ← ny kodek fra Sony
• APTX ← kodek fra 1988
• aptXHD ← samme som aptX, bare med forskjellige kodingsalternativer
• aptX Lav latens ← helt annen kodek, ingen programvareimplementering
• aptX Adaptiv ← en annen kodek fra Qualcomm
• FastStream ← pseudokodek, toveis SBC-modifikasjon
• HWA LHDC ← ny kodek fra Huawei
• Samsung HD ← støttes av 2 enheter
• Samsung skalerbar ← støttes av 2 enheter
• Samsung UHQ-BT ← støttes av 3 enheter

Hvorfor trenger vi i det hele tatt kodeker, spør du, når Bluetooth har EDR, som lar deg overføre data med hastigheter på 2 og 3 Mbit/s, og for ukomprimert to-kanals 16-bit PCM er 1.4 Mbit/s nok?

Dataoverføring via Bluetooth

Det er to typer dataoverføring i Bluetooth: Asynchronous Connection Less (ACL) for asynkron overføring uten tilkoblingsetablering, og Synchronous Connection Oriented (SCO), for synkron overføring med foreløpig tilkoblingsforhandling.
Overføring utføres ved å bruke et tidsdelingsskjema og velge en overføringskanal for hver pakke separat (Frequency-Hop/Time-Division-Duplex, FH/TDD), hvor tiden er delt inn i 625 mikrosekunders intervaller kalt spor. En av enhetene sender i partallsspor, den andre i spor med oddetall. Den overførte pakken kan okkupere 1, 3 eller 5 spor, avhengig av størrelsen på dataene og den angitte overføringstypen, i dette tilfellet utføres overføring fra en enhet i like og odde spor til slutten av overføringen. Totalt kan opptil 1600 pakker mottas og sendes per sekund, hvis hver av dem opptar 1 spor, og begge enhetene sender og mottar noe uten å stoppe.

2 og 3 Mbit/s for EDR, som finnes i kunngjøringer og på Bluetooth-nettstedet, er den maksimale kanaloverføringshastigheten for alle data totalt (inkludert tekniske overskrifter for alle protokoller der data må innkapsles), i to retninger samtidig. Faktisk dataoverføringshastighet vil variere sterkt.

For å overføre musikk brukes en asynkron metode, nesten alltid med pakker som 2-DH5 og 3-DH5, som har en maksimal mengde data i EDR-modus på henholdsvis 2 Mbit/s og 3 Mbit/s, og opptar 5 tid -deling av spor.

Skjematisk representasjon av overføring ved bruk av 5 spor av en enhet og 1 spor av en annen (DH5/DH1):


På grunn av prinsippet om tidsdeling av luftbølgene, er vi tvunget til å vente en 625 mikrosekunders tidsluke etter å ha sendt en pakke hvis den andre enheten ikke sender noe til oss eller sender en liten pakke, og mer tid hvis den andre enheten sender i store pakker. Hvis mer enn én enhet er koblet til telefonen (for eksempel hodetelefoner, klokker og et treningsarmbånd), så deles overføringstiden mellom dem alle.

Behovet for å kapsle inn lyd i spesielle transportprotokoller L2CAP og AVDTP tar 16 byte fra den mulige maksimale mengden overført lydnyttelast.

Pakke type
Antall spor
Maks. antall byte i pakken
Maks. antall byte med A2DP-nyttelast
Maks. A2DP nyttelast bitrate

2-DH3
3
367
351
936 kbps

3-DH3
3
552
536
1429 kbps

2-DH5
5
679
663
1414 kbps

3-DH5
5
1021
1005
2143 kbps

1414 og 1429 kbps er definitivt ikke nok til å overføre ukomprimert lyd under reelle forhold, med det støyende 2.4 GHz-området og behovet for å overføre tjenestedata. EDR 3 Mbit/s er krevende for overføringskraft og støy i luften, derfor, selv i 3-DH5-modus, er komfortabel PCM-overføring umulig, det vil alltid være kortsiktige avbrudd, og alt vil bare fungere på en avstand på en et par meter.
I praksis er selv en 990 kbit/s lydstrøm (LDAC 990 kbit/s) vanskelig å overføre.

La oss gå tilbake til kodeker.

SBC

Codec kreves for alle enheter som støtter A2DP-standarden. Den beste og verste kodeken på samme tid.

Prøvetakingsfrekvens
Litt dybde
Bithastighet
Støtte for koding
Dekodingsstøtte

16, 32, 44.1, 48 kHz
16 bit
10-1500 kbps
Alle enheter
Alle enheter

SBC er en enkel og beregningsmessig rask kodek, med en primitiv psykoakustisk modell (kun maskering av stille lyder brukes), ved bruk av adaptiv pulskodemodulasjon (APCM).
A2DP-spesifikasjonen anbefaler to profiler for bruk: Middels kvalitet og høy kvalitet.


Kodeken har mange innstillinger som lar deg kontrollere den algoritmiske forsinkelsen, antall samples i en blokk, bitfordelingsalgoritmen, men nesten overalt brukes de samme parameterne som anbefales i spesifikasjonen: Joint Stereo, 8 frekvensbånd, 16 blokker i en lydramme, loudness bit distribusjonsmetode.
SBC støtter dynamisk endring av Bitpool-parameteren, som direkte påvirker bithastigheten. Hvis luftbølgene er tilstoppet, pakker går tapt, eller enheter er plassert på store avstander, kan lydkilden redusere Bitpool til kommunikasjonen går tilbake til det normale.

De fleste hodetelefonprodusenter setter den maksimale Bitpool-verdien til 53, noe som begrenser bithastigheten til 328 kilobits per sekund ved bruk av den anbefalte profilen.
Selv om hodetelefonprodusenten har satt den maksimale Bitpool-verdien over 53 (slike modeller finnes for eksempel: Beats Solo³, JBL Everest Elite 750NC, Apple AirPods, som også finnes på enkelte mottakere og bilhodeenheter), vil de fleste operativsystemer ikke tillate bruken av økte bithastigheter på grunn av innstilt intern verdigrense i Bluetooth-stabler.
I tillegg setter noen produsenter den maksimale Bitpool-verdien til lav for noen enheter. For eksempel er det for Bluedio T 39, for Samsung Gear IconX er det 37, noe som gir dårlig lydkvalitet.

Kunstige begrensninger fra utviklere av Bluetooth-stabler oppsto sannsynligvis på grunn av inkompatibiliteten til noen enheter med store Bitpool-verdier eller atypiske profiler, selv om de rapporterte støtte for dem, og utilstrekkelig testing under sertifiseringen. Det var lettere for forfatterne av Bluetooth-stabler å begrense seg til å bli enige om den anbefalte profilen, i stedet for å lage databaser med feil enheter (selv om de nå gjør dette for andre funksjoner som ikke fungerer korrekt).

SBC allokerer kvantiseringsbiter dynamisk til frekvensbånd på lav-til-høy-basis, med forskjellige vekter. Hvis all bithastigheten ble brukt for de lave og mellomste frekvensene, vil de høye frekvensene bli "kuttet av" (det blir stillhet i stedet).

Eksempel SBC 328 kbps. Øverst er originalen, nederst er SBC, og bytter med jevne mellomrom mellom spor. Lyden i videofilen bruker den tapsfrie FLAC-komprimeringskodeken. Å bruke FLAC i en mp4-beholder er ikke offisielt standardisert, så det er ikke garantert at nettleseren din vil spille den, men den skal fungere i de nyeste versjonene av Chrome og Firefox på skrivebordet. Hvis du ikke har lyd, kan du laste ned filen og åpne den i en fullverdig videospiller.
ZZ Topp - skarpkledd mann

Spektrogrammet viser bytteøyeblikket: SBC kutter med jevne mellomrom stille lyder over 17.5 kHz, og tildeler ingen biter i det hele tatt for båndet over 20 kHz. Hele spektrogrammet er tilgjengelig ved å klikke (1.7 MB).

Jeg hører ingen forskjell mellom originalen og SBC på dette sporet.

La oss ta noe nyere og simulere lyden som ville oppnås ved bruk av Samsung Gear IconX-hodetelefoner med Bitpool 37 (over - det originale signalet, under - SBC 239 kbps, lyd i FLAC).
Mindless Self Overbærenhet - Vitne

Jeg hører knitring, mindre stereoeffekt og en ubehagelig «klunkende» lyd i vokalens høye frekvenser.

Selv om SBC er en veldig fleksibel kodek, kan den konfigureres for lav latens, gir utmerket lydkvalitet ved høye bithastigheter (452+ kbps) og er ganske bra for de fleste med standard høy kvalitet (328 kbps), på grunn av det faktum at A2DP-standarden spesifiserer ikke faste profiler (men gir bare anbefalinger), stackutviklere har satt kunstige begrensninger på Bitpool, parametrene til den overførte lyden vises ikke i brukergrensesnittet, og hodetelefonprodusenter står fritt til å stille inn sine egne innstillinger og aldri angi Bitpool-verdien i de tekniske spesifikasjonene til produktet, ble kodeken kjent for sin lave lydkvalitet, selv om dette ikke er et problem med kodeken som sådan.
Bitpool-parameteren påvirker bare bithastigheten direkte innenfor én profil. Den samme Bitpool 53-verdien kan gi både en bitrate på 328 kbps med den anbefalte høykvalitetsprofilen, og 1212 kbps med Dual Channel og 4 frekvensbånd, som er grunnen til at OS-forfatterne, i tillegg til restriksjoner på Bitpool, setter en grense og på Bithastighet. Slik jeg ser det, oppsto denne situasjonen på grunn av en feil i A2DP-standarden: det var nødvendig å forhandle om bithastigheten, ikke Bitpool.

Tabell over støtte for SBC-funksjoner i forskjellige operativsystemer:

operativsystem
Støttede samplingsfrekvenser
Grense maks. Bitpool
Grense maks. Bithastighet
Typisk bitrate
Bitpool dynamisk justering

Windows 10
44.1 kilo
53
512 kbps
328 kbps
✓*

Linux (BlueZ + PulseAudio)
16, 32, 44.1, 48 kHz
64 (for innkommende tilkoblinger), 53 (for utgående tilkoblinger)
Ingen grense
328 kbps
✓*

MacOS High Sierra
44.1 kilo
64, standard 53***
Ukjent
328 kbps
✗

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

Android 4.1-4.3.1
44.1, 48 kHz**
53
229 kbps
229 kbps
✗

Blackberry OS 10
48 kilo
53
Ingen grense
328 kbps
✗

* Bitpool reduseres bare, men øker ikke automatisk hvis overføringsforholdene blir bedre. For å gjenopprette Bitpool må du stoppe avspillingen, vente et par sekunder og starte lyden på nytt.
** Standardverdien avhenger av stabelinnstillingene som ble spesifisert ved kompilering av fastvaren. I Android 8/8.1 er frekvensen bare enten 44.1 kHz eller 48 kHz, avhengig av innstillingene under kompilering, i andre versjoner støttes 44.1 kHz og 48 kHz samtidig.
*** Bitpool-verdien kan økes i Bluetooth Explorer-programmet.

aptX og aptX HD

aptX er en enkel og beregningsmessig rask kodek, uten psykoakustikk, som bruker adaptiv differensiell pulskodemodulasjon (ADPCM). Dukket opp rundt 1988 (innleveringsdato patentere datert februar 1988), før Bluetooth, ble den først og fremst brukt i profesjonelt trådløst lydutstyr. For tiden eid av Qualcomm, krever lisensiering og royalties. Fra 2014: $6000 1 engangs og ≈$10000 per enhet, for grupper på opptil XNUMX XNUMX enheter (kilde, s. 16).
aptX og aptX HD er den samme kodeken, med forskjellige kodingsprofiler.

Kodeken har bare én parameter – valg av samplingsfrekvens. Det er imidlertid et valg av antall/modus for kanaler, men i alle enheter kjent for meg (70+ stykker) støttes kun Stereo.

Codec
Prøvetakingsfrekvens
Litt dybde
Bithastighet
Støtte for koding
Dekodingsstøtte

APTX
16, 32, 44.1, 48 kHz
16 bit
128 / 256 / 352 / 384 kbps (avhengig av samplingshastighet)
Windows 10 (stasjonær og mobil), macOS, Android 4.4+/7*, Blackberry OS 10
Bredt utvalg av lydenheter (maskinvare)

* Versjoner opptil 7 krever modifikasjon av Bluetooth-stakken. Kodeken støttes bare hvis Android-enhetsprodusenten har lisensiert kodeken fra Qualcomm (hvis operativsystemet har kodingsbiblioteker).

aptX deler lyd inn i 4 frekvensbånd og kvantiserer dem med samme antall biter konstant: 8 bits for 0-5.5 kHz, 4 bits for 5.5-11 kHz, 2 bits for 11-16.5 kHz, 2 bits for 16.5-22 kHz ( tall for samplingsfrekvens 44.1 kHz).

Eksempel på aptX-lyd (øverst - det originale signalet, nederst - aptX, spektrogrammer av bare de venstre kanalene, lyd i FLAC):

Høydene ble litt rødere, men man kunne ikke høre forskjellen.

På grunn av den faste fordelingen av kvantiseringsbiter, kan ikke kodeken "skifte bitene" til frekvensene som trenger dem mest. I motsetning til SBC, vil ikke aptX "kutte" frekvenser, men vil legge til kvantiseringsstøy til dem, og redusere det dynamiske området til lyden.

Det bør ikke antas at bruk av for eksempel 2 bits per bånd reduserer det dynamiske området til 12 dB: ADPCM tillater opptil 96 dB dynamisk område selv ved bruk av 2 kvantiseringsbiter, men kun for et bestemt signal.
ADPCM lagrer den numeriske forskjellen mellom gjeldende prøve og neste prøve, i stedet for å lagre den absolutte verdien som i PCM. Dette lar deg redusere kravene til antall biter som trengs for å lagre den samme (uten tap) eller nesten den samme (med en relativt liten avrundingsfeil) informasjon. For å redusere avrundingsfeil brukes koeffisienttabeller.
Da de opprettet kodeken, beregnet forfatterne ADPCM-koeffisienter på et sett med musikklydfiler. Jo nærmere lydsignalet er musikksettet som bordene ble bygget på, jo mindre kvantiseringsfeil (støy) skaper aptX.

På grunn av dette vil syntetiske tester alltid gi dårligere resultater enn musikk. Jeg laget et spesielt syntetisk eksempel der aptX viser dårlige resultater - en sinusbølge med en frekvens på 12.4 kHz (over - det originale signalet, under - aptX. Lyd i FLAC. Senk volumet!):

Spektrumgraf:


Støy er tydelig hørbare.

Men hvis du genererer en sinusbølge med en mindre amplitude slik at den er roligere, vil støyen også bli roligere, noe som indikerer et bredt dynamisk område:

For å høre forskjellen mellom det originale musikksporet og det komprimerte, kan du invertere et av signalene og legge til sporene kanal for kanal. Denne tilnærmingen er generelt feil, og vil ikke gi fornuftige resultater med mer komplekse kodeker, men spesifikt for ADPCM er den ganske egnet.
Forskjellen mellom original og aptX
Root mean square differansen til signalene er på nivået -37.4 dB, som ikke er mye for slik komprimert musikk.

aptXHD

aptX HD er ikke en frittstående kodek - det er en forbedret kodingsprofil for aptX-kodeken. Endringene påvirket antall biter tildelt for koding av frekvensområder: 10 bits for 0-5.5 kHz, 6 bits for 5.5-11 kHz, 4 bits for 11-16.5 kHz, 4 bits for 16.5-22 kHz (siffer for 44.1 kHz) .

Codec
Prøvetakingsfrekvens
Litt dybde
Bithastighet
Støtte for koding
Dekodingsstøtte

aptXHD
16, 32, 44.1, 48 kHz
24 biter
192 / 384 / 529 / 576 kbps (avhengig av samplingshastighet)
Android 8+*
Noen lydenheter (maskinvare)

* Versjoner opptil 7 krever modifikasjon av Bluetooth-stakken. Kodeken støttes bare hvis Android-enhetsprodusenten har lisensiert kodeken fra Qualcomm (hvis operativsystemet har kodingsbiblioteker).

Mindre vanlig enn aptX: krever tilsynelatende separat lisensiering fra Qualcomm, og separate lisensavgifter.

La oss gjenta eksemplet med en sinusbølge på 12.4 kHz:


Mye bedre enn aptX, men fortsatt litt støyende.

aptX Lav latens

En kodek fra Qualcomm som ikke har noe til felles med standard aptX og aptX HD, å dømme etter den begrensede informasjonen fra personer involvert i utviklingen. Designet for interaktiv lydoverføring med lav latens (filmer, spill), der lydforsinkelsen ikke kan justeres av programvare. Det er ingen kjente programvareimplementeringer av kodere og dekodere; de ​​støttes utelukkende av sendere, mottakere, hodetelefoner og høyttalere, men ikke av smarttelefoner og datamaskiner.

Prøvetakingsfrekvens
Bithastighet
Støtte for koding
Dekodingsstøtte

44.1 kilo
276/420 kbps
Noen sendere (maskinvare)
Noen lydenheter (maskinvare)

AAC

AAC, eller Advanced Audio Coding, er en beregningsmessig kompleks kodek med en seriøs psykoakustisk modell. Mye brukt for lyd på Internett, nummer to i popularitet etter MP3. Krever lisensiering og royalties: $15000 1000 engangs (eller $15 for selskaper med mindre enn 0.98 ansatte) + $500000 for de første XNUMX XNUMX enhetene (kilde).
Kodeken er standardisert innenfor MPEG-2- og MPEG-4-spesifikasjonene, og i motsetning til vanlig misforståelse tilhører den ikke Apple.

Prøvetakingsfrekvens
Bithastighet
Støtte for koding
Dekodingsstøtte

8 - 96 kHz
8 - 576 kbps (for stereo), 256 - 320 kbps (typisk for Bluetooth)
macOS, Android 7+*, iOS
Bredt utvalg av lydenheter (maskinvare)

* bare på enheter hvis produsenter har betalt lisensavgifter

iOS og macOS bruker Apples nåværende beste AAC-koder for å levere høyest mulig lydkvalitet. Android bruker den nest høyeste kvaliteten Fraunhofer FDK AAC-koderen, men kan bruke forskjellig maskinvare innebygd i plattformen (SoC) med ukjent kodingskvalitet. Ifølge nylige tester på SoundGuys-nettstedet, AAC-kodingskvaliteten til forskjellige Android-telefoner varierer sterkt:

De fleste trådløse lydenheter har en maksimal bitrate på 320 kbps for AAC, noen støtter kun 256 kbps. Andre bithastigheter er ekstremt sjeldne.
AAC gir utmerket kvalitet ved 320 og 256 kbps bithastigheter, men er underlagt tap av sekvensiell koding av allerede komprimert innhold, men det er vanskelig å høre noen forskjeller med originalen på iOS med en bitrate på 256 kbps selv med flere sekvensielle kodinger; med enkeltkoding, for eksempel MP3 320 kbps til AAC 256 kbps, kan tap neglisjeres.
Som med andre Bluetooth-kodeker, blir all musikk først dekodet og deretter kodet av kodeken. Når du lytter til musikk i AAC-format, blir den først dekodet av operativsystemet, deretter kodet til AAC igjen for overføring via Bluetooth. Dette er nødvendig for å blande flere lydstrømmer, for eksempel musikk og nye meldingsvarsler. iOS er intet unntak. På Internett kan du finne mange utsagn om at musikk i AAC-format på iOS ikke blir transkodet når den overføres via Bluetooth, noe som ikke er sant.

MP1/2/3

Kodekene til MPEG-1/2 Part 3-familien består av den velkjente og mye brukte MP3, den mindre vanlige MP2 (brukes hovedsakelig i digital TV og radio), og den helt ukjente MP1.

De gamle MP1- og MP2-kodekene støttes ikke i det hele tatt: Jeg kunne ikke finne noen hodetelefoner eller Bluetooth-stabel som kunne kode eller dekode dem.
MP3-dekoding støttes av noen hodetelefoner, men koding støttes ikke på noen moderne operativsystemstabel. Det ser ut til at tredjeparts BlueSoleil-stabelen for Windows kan kode til MP3 hvis du manuelt endrer konfigurasjonsfilen, men for meg fører installasjonen til BSoD på Windows 10. Konklusjon - kodeken kan faktisk ikke brukes til Bluetooth-lyd.
Tidligere, i 2006-2008, før spredningen av A2DP-standarden i enheter, lyttet folk til MP3-musikk på Nokia BH-501-headsettet gjennom MSI BluePlayer-programmet, som var tilgjengelig på Symbian og Windows Mobile. På den tiden tillot OS-arkitekturen til smarttelefoner tilgang til mange funksjoner på lavt nivå, og på Windows Mobile var det til og med mulig å installere tredjeparts Bluetooth-stabler.

Det siste patentet til MP3-kodeken har utløpt, bruken av kodeken krever ikke lisensavgifter siden 23. april 2017.

Hvis det lengstvarende patentet nevnt i de nevnte referansene tas som et tiltak, ble MP3-teknologien patentfri i USA 16. april 2017 da US Patent 6,009,399 XNUMX XNUMX, inneholdt av og administrert av Technicolor, utløp.

Kilde: www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html

Prøvetakingsfrekvens
Bithastighet
Støtte for koding
Dekodingsstøtte

16 - 48 kHz
8 - 320 kbps
Støttes ikke noe sted
Noen lydenheter (maskinvare)

LDAC

En ny og aktivt promotert "Hi-Res"-kodek fra Sony, som støtter samplingshastigheter på opptil 96 kHz og 24-bits bitrate, med bithastigheter på opptil 990 kbps. Det er annonsert som en audiofil kodek, som en erstatning for eksisterende Bluetooth-kodeker. Den har funksjonen til adaptiv bitratejustering, avhengig av radiosendingsforhold.

LDAC-koder (libldac) er inkludert i standard Android-pakken, så koding støttes på alle Android-smarttelefoner som starter med OS versjon 8. Det er ingen fritt tilgjengelige programvaredekodere, kodekspesifikasjonen er ikke tilgjengelig for allmennheten, men ved første øyekast på koderen ligner den interne strukturen til kodeken på ATRAC9 - Sonys kodek brukt i PlayStation 4 og Vita: begge fungerer i frekvensdomenet, bruker en modifisert diskret cosinustransformasjon (MDCT) og komprimering ved hjelp av Huffman-algoritmen.

LDAC-støtte leveres nesten utelukkende av hodetelefoner fra Sony. Evnen til å dekode LDAC finnes noen ganger på hodetelefoner og DAC-er fra andre produsenter, men svært sjelden.

Prøvetakingsfrekvens
Bithastighet
Støtte for koding
Dekodingsstøtte

44.1 - 96 kHz
303/606/909 kbit/s (for 44.1 og 88.2 kHz), 330/660/990 kbit/s (for 48 og 96 kHz)
Android 8 +
Noen Sony-hodetelefoner og noen enheter fra andre produsenter (maskinvare)

Markedsføring av LDAC som en Hi-Res-kodek skader dens tekniske komponent: det er dumt å bruke bitrate på å sende frekvenser som er uhørbare for det menneskelige øret og øke bitdybden, mens det ikke er nok å overføre CD-kvalitet (44.1/16) uten tap . Heldigvis har kodeken to driftsmoduser: CD-lydoverføring og Hi-Res-lydoverføring. I det første tilfellet sendes bare 44.1 kHz/16 bits over luften.

Siden en programvare-LDAC-dekoder ikke er fritt tilgjengelig, er det umulig å teste kodeken uten ekstra enheter som dekoder LDAC. I følge resultatene av LDAC-testen på en DAC med dens støtte, som SoundGuys.com-ingeniører koblet til via en digital utgang og registrerte utgangslyden på testsignaler, gir LDAC 660 og 990 kbps i CD-kvalitetsmodus et signal-til- støyforhold litt bedre enn for aptX HD.

Kilde: www.soundguys.com/ldac-ultimate-bluetooth-guide-20026

LDAC støtter også dynamiske bithastigheter utenfor etablerte profiler – fra 138 kbps til 990 kbps, men så vidt jeg kan se, bruker Android kun de standardiserte profilene 303/606/909 og 330/660/990 kbps.

Andre kodeker

Andre A2DP-kodeker er ikke mye brukt. Støtten deres er enten nesten helt fraværende eller bare tilgjengelig på visse modeller av hodetelefoner og smarttelefoner.
ATRAC-kodeken standardisert i A2DP har aldri blitt brukt som en Bluetooth-kodek selv av Sony selv, Samsung HD, Samsung Scalable og Samsung UHQ-BT-kodekene har svært begrenset støtte fra overførings- og mottaksenheter, og HWA LHDC er for ny og støttet kun tre (?) enheter.

Codec-støtte for lydenheter

Ikke alle produsenter publiserer nøyaktig informasjon om kodekene som støttes av enkelte trådløse hodetelefoner, høyttalere, mottakere eller sendere. Noen ganger hender det at støtte for en bestemt kodek bare er for overføring, men ikke for mottak (relevant for kombinerte sendere-mottakere), selv om produsenten ganske enkelt erklærer "støtte", uten merknader (jeg antar at separat lisensiering av kodere og dekodere for noen kodeker har skylden for dette). På de billigste enhetene finner du kanskje ikke den deklarerte aptX-støtten i det hele tatt.

Dessverre viser ikke grensesnittene til de fleste operativsystemer kodeken som brukes noe sted. Informasjon om dette er kun tilgjengelig i Android, fra og med versjon 8, og macOS. Selv i disse operativsystemene vil imidlertid bare de kodekene som støttes av både telefonen/datamaskinen og hodetelefonene vises.

Hvordan kan du finne ut hvilke kodeker enheten din støtter? Registrer og analyser trafikkdump med A2DP-forhandlingsparametere!
Dette kan gjøres på Linux, macOS og Android. På Linux kan du bruke Wireshark eller hcidump, på macOS kan du bruke Bluetooth Explorer, og på Android kan du bruke standard Bluetooth HCI dump lagringsfunksjon, som er tilgjengelig i utviklerverktøyene. Du vil motta en dump i btsnoop-format, som kan lastes inn i Wireshark-analysatoren.
Vær oppmerksom: en korrekt dump kan kun oppnås ved å koble fra telefonen/datamaskinen til hodetelefoner/høyttalere (uansett hvor morsomt det høres ut)! Hodetelefonene kan uavhengig opprette en forbindelse med telefonen, i så fall vil de be om en liste over kodeker fra telefonen, og ikke omvendt. For å sikre at riktig dump blir tatt opp, må du først koble fra enheten og deretter pare telefonen med hodetelefonene mens du tar opp dumpen.

Bruk følgende visningsfilter for å filtrere ut irrelevant trafikk:

btavdtp.signal_id

Som et resultat bør du se noe som ligner på dette:

Du kan klikke på hvert element i GetCapabilities-kommandoen for å se de detaljerte egenskapene til kodeken.

Wireshark kjenner ikke alle kodekidentifikatorer, så noen kodeker må dekrypteres manuelt ved å se på identifikasjonstabellen nedenfor:

Mandatory:
0x00 - SBC

Optional:
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC

Vendor specific:
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 - The CSR True Wireless Stereo v3 Codec ID for AAC
0xFF 0x000A 0x0105 - The CSR True Wireless Stereo v3 Codec ID for MP3
0xFF 0x000A 0x0106 - The CSR True Wireless Stereo v3 Codec ID for aptX

For ikke å analysere dumps manuelt, laget jeg en tjeneste som analyserer alt automatisk: btcodecs.valdikss.org.ru

Sammenligning av kodeker. Hvilken kodek er bedre?

Hver kodek har sine egne fordeler og ulemper.
aptX og aptX HD bruker hardkodede profiler som ikke kan endres uten å endre koderen og dekoderen. Verken telefonprodusenten eller hodetelefonprodusenten kan endre bitrate eller aptX-kodingsfaktorene. Eieren av kodeken, Qualcomm, gir en referansekoder i form av et bibliotek. Disse faktaene er styrken til aptX - du vet på forhånd hvilken lydkvalitet du vil få, uten noen "men".

SBC, derimot, har mange konfigurerbare parametere, dynamisk bitrate (koderen kan redusere bitpool-parameteren hvis radioen er opptatt), og har ikke hardkodede profiler, bare anbefalt "middels kvalitet" og "høy kvalitet" som var lagt til A2DP-spesifikasjonen i 2003 år. "Høy kvalitet" er ikke lenger så høy etter moderne standarder, og de fleste Bluetooth-stabler lar deg ikke bruke parametere bedre enn i "høy kvalitet" -profilen, selv om det ikke er noen tekniske begrensninger for dette.
Bluetooth SIG har ikke en referanse SBC-koder som et bibliotek, og produsenter implementerer det selv.
Dette er svakhetene til SBC - det er aldri klart på forhånd hvilken lydkvalitet du kan forvente fra en bestemt enhet. SBC kan produsere lyd av både lav og svært høy kvalitet, men sistnevnte er uoppnåelig uten å deaktivere eller omgå de kunstige begrensningene til Bluetooth-stabler.

Situasjonen med AAC er tvetydig: På den ene siden skal kodeken teoretisk produsere kvalitet som ikke kan skilles fra originalen, men i praksis, å dømme etter testene fra SoundGuys-laboratoriet på forskjellige Android-enheter, er dette ikke bekreftet. Mest sannsynlig ligger feilen i lydkodere for maskinvare av lav kvalitet innebygd i forskjellige telefonbrikkesett. Det er fornuftig å bruke AAC bare på Apple-enheter, og på Android for å begrense det til aptX og LDAC.

Maskinvare som støtter alternative kodeker har en tendens til å være av høyere kvalitet, ganske enkelt fordi det for svært billige enheter av lav kvalitet ikke gir mening å betale lisensavgifter for å bruke disse kodekene. I mine tester høres SBC veldig bra ut på kvalitetsutstyr.

Jeg laget en webtjeneste som koder lyd til SBC, aptX og aptX HD i sanntid, rett i nettleseren. Med den kan du teste disse lydkodekene uten å overføre lyd via Bluetooth, på kablede hodetelefoner, høyttalere og favorittmusikken din, og også endre kodingsparametere direkte mens du spiller av lyd:
btcodecs.valdikss.org.ru/sbc-encoder
Tjenesten bruker SBC-kodingsbibliotekene fra BlueZ-prosjektet og libopenaptx fra ffmpeg, som er kompilert til WebAssembly og JavaScript fra C, via emscripten, for å kjøre i nettleseren. Hvem kunne drømme om en slik fremtid!

Slik ser det ut:

Legg merke til hvordan støynivået endres etter 20 kHz for forskjellige kodeker. Den originale MP3-filen inneholder ikke frekvenser over 20 kHz.

Prøv å bytte kodeker og se om du hører forskjellen mellom originalen, SBC 53 Joint Stereo (standard og vanligste profil) og aptX/aptX HD.

Jeg kan høre forskjellen mellom kodeker i hodetelefoner!

Folk som ikke hører forskjell på kodeker under testing via en nettjeneste, hevder at de hører det når de hører på musikk på trådløse hodetelefoner. Akk, dette er ikke en spøk eller en placeboeffekt: forskjellen er virkelig hørbar, men den er ikke forårsaket av forskjeller kodeker.

De aller fleste Bluetooth-lydbrikkesett som brukes i trådløse mottaksenheter er utstyrt med en digital signalprosessor (DSP), som implementerer en equalizer, compander, stereoutvider og andre ting designet for å forbedre (eller endre) lyden. Produsenter av Bluetooth-utstyr kan konfigurere DSP for hver kodek separat, og når du bytter mellom kodeker, vil lytteren tro at de hører en forskjell i driften av kodekene, når de i virkeligheten lytter til forskjellige DSP-innstillinger.

DSP Kalimba lydbehandlingsrørledning i brikker produsert av CSR/Qualcomm

Aktiver forskjellige DSP-funksjoner for hver kodek og skriv ut separat

Noen premium-enheter kommer med programvare som lar deg tilpasse DSP-innstillinger, men de fleste billigere hodetelefoner gjør det ikke, og brukere kan ikke slå av etterbehandling av lyd manuelt.

Funksjonelle funksjoner til enheter

Den moderne versjonen av A2DP-standarden har "absolutt volumkontroll" funksjon — enhetsvolumkontroll ved hjelp av spesielle kommandoer fra AVRCP-protokollen, som regulerer forsterkningen av utgangstrinnet, i stedet for å redusere volumet på lydstrømmen programmatisk. Hvis når du endrer volumet på hodetelefonene, endringen ikke synkroniseres med volumet på telefonen, støtter ikke hodetelefonene eller telefonen denne funksjonen. I dette tilfellet er det fornuftig å alltid lytte til musikk med maksimalt volum på telefonen, justere det faktiske volumet med hodetelefonknappene - i dette tilfellet vil signal-til-støy-forholdet være bedre og lydkvaliteten bør være ovenfor.
I virkeligheten er det triste situasjoner. På mine RealForce OverDrive D1-hodetelefoner for SBC er en sterk compander slått på, og å øke volumet fører til en økning i nivået av stille lyder, mens volumet på høye lyder ikke endres (signalet er komprimert). På grunn av dette må du sette volumet på datamaskinen til omtrent halvparten, i så fall er det praktisk talt ingen komprimeringseffekt.
I følge mine observasjoner støtter alle hodetelefoner med ekstra kodeker den absolutte volumkontrollfunksjonen, tilsynelatende er dette et av kravene for kodek-sertifisering.

Noen hodetelefoner støtter koble til to enheter samtidig. Dette lar deg for eksempel lytte til musikk fra datamaskinen og motta anrop fra telefonen. Du bør imidlertid være oppmerksom på at i denne modusen er alternative kodeker deaktivert og kun SBC brukes.

AVDTP 1.3 Forsinket rapportering funksjon lar hodetelefonene kommunisere forsinkelsen til sendeenheten der lyden faktisk spilles av. Dette lar deg justere synkroniseringen av lyd med video mens du ser på videofiler: hvis det er problemer med radiooverføring, vil ikke lyden ligge etter videoen, men tvert imot vil videoen bremses av videospilleren til lyd og video synkroniseres igjen.
Funksjonen støttes av mange hodetelefoner, Android 9+ og Linux med PulseAudio 12.0+. Jeg er ikke klar over støtte for denne funksjonen på andre plattformer.

Toveis kommunikasjon via Bluetooth. Stemmeoverføring.

For taleoverføring i Bluetooth benyttes Synchronous Connection Oriented (SCO) - synkron overføring med foreløpig forhandling av forbindelsen. Modusen lar deg overføre lyd og stemme strengt i rekkefølge, med symmetriske sende- og mottakshastigheter, uten å vente på bekreftelse av overføring og re-sending av pakker. Dette reduserer den totale forsinkelsen av lydoverføring over radiokanalen, men legger alvorlige begrensninger på mengden data som sendes per tidsenhet, og påvirker kvaliteten negativt.
Når denne modusen brukes, overføres både tale og lyd med samme kvalitet.
Dessverre, fra og med 2019, er stemmekvaliteten over Bluetooth fortsatt dårlig, og det er uklart hvorfor Bluetooth SIG ikke gjør noe med det.

CVSD

CVSD grunnleggende stemmekodeken ble standardisert i 2002, og støttes av alle toveis Bluetooth-kommunikasjonsenheter. Den gir lydoverføring med en samplingsfrekvens på 8 kHz, som tilsvarer kvaliteten på konvensjonell kablet telefoni.

Et eksempel på et opptak i denne kodeken.

mSBC

Den ekstra mSBC-kodeken ble standardisert i 2009, og i 2010 dukket det allerede opp brikker som brukte den til taleoverføring. mSBC er bredt støttet av ulike enheter.
Dette er ikke en uavhengig kodek, men en vanlig SBC fra A2DP-standarden, med en fast kodingsprofil: 16 kHz, mono, bitpool 26.

Et eksempel på et opptak i denne kodeken.

Ikke genialt, men mye bedre enn CVSD, men det er fortsatt irriterende å bruke til nettkommunikasjon, spesielt når du bruker hodetelefoner for å kommunisere i spillet – spillets lyd vil også bli overført med en samplingsfrekvens på 16 kHz.

FastStreamCSR-selskapet bestemte seg for å utvikle ideen om å bruke SBC. For å komme rundt begrensningene til SCO-protokollen og bruke høyere bithastigheter, gikk CSR en annen vei - de introduserte støtte for toveis SBC-lyd i A2DP enveis lydoverføringsstandard, standardiserte kodingsprofiler, og kalte det "FastStream".

FastStream overfører stereolyd på 44.1 eller 48 kHz med en bitrate på 212 kbps til høyttalerne, og mono, 16 kHz, med en bitrate på 72 kbps brukes til å overføre lyd fra mikrofonen (litt bedre enn mSBC). Slike parametere er mye bedre egnet for kommunikasjon i online spill - lyden av spillet og samtalepartnerne vil være av høy kvalitet.

Et eksempel på et opptak i denne kodeken (+ lyd fra mikrofon, samme som mSBC).

Selskapet kom med en interessant krykke, men på grunn av det faktum at den er i strid med A2DP-standarden, støttes den kun i noen av selskapets sendere (som fungerer som et USB-lydkort, ikke en Bluetooth-enhet), men det gjør det ikke motta støtte i Bluetooth-stabler, selv om antallet hodetelefoner med FastStream-støtte ikke er så lite.

For øyeblikket er det kun FastStream-støtte i OS som en oppdatering for Linux PulseAudio fra utvikler Pali Rohár, som ikke er inkludert i hovedgrenen av programmet.

aptX Lav latens

Til stor overraskelse støtter aptX Low Latency også toveis lyd, og implementerer samme prinsipp som FastStream.
Det er ikke mulig å bruke denne funksjonen til kodeken hvor som helst - det er ingen støtte for Low Latency-dekoding i noe OS eller i noen Bluetooth-stakk kjent for meg.

Bluetooth 5, Classic og Low Energy

Det har vært mye forvirring rundt Bluetooth-spesifikasjoner og -versjoner på grunn av tilstedeværelsen av to inkompatible standarder under samme merke, som begge er mye brukt til forskjellige formål.

Det er to forskjellige, inkompatible Bluetooth-protokoller: Bluetooth Classic og Bluetooth Low Energy (LE, også kjent som Bluetooth Smart). Det finnes også en tredje protokoll, Bluetooth High Speed, men den er ikke utbredt og brukes ikke i husholdningsapparater.

Fra og med Bluetooth 4.0 gjaldt endringer i spesifikasjonen hovedsakelig Bluetooth Low Energy, og Classic-versjonen fikk bare mindre forbedringer.

Liste over endringer mellom Bluetooth 4.2 og Bluetooth 5:

9 ENDRINGER FRA v4.2 TIL 5.0

9.1 NYE FUNKSJONER

Flere nye funksjoner introduseres i Bluetooth Core Specification 5.0-utgivelsen. De viktigste forbedringsområdene er:
• Slot Availability Mask (SAM)
• 2 Msym/s PHY for LE
•LE lang rekkevidde
• Ikke-tilkoblet annonsering med høy driftssyklus
• LE Advertising Extensions
• LE Channel Selection Algoritme #2
9.1.1 Funksjoner lagt til i CSA5 - Integrert i v5.0
• Høyere utgangseffekt

Kilde: www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=421043 (side 291)

Bare én endring påvirket den klassiske versjonen innenfor rammen av Bluetooth 5-spesifikasjonen: de la til støtte for Slot Availability Mask (SAM)-teknologi, designet for å forbedre separasjon av radiosendinger. Alle andre endringer påvirker bare Bluetooth LE (og høyere utgangseffekt også).

Alle Lydenheter bruker kun Bluetooth Classic. Det er umulig å koble til hodetelefoner og høyttalere via Bluetooth Low Energy: det er ingen standard for overføring av lyd med LE. A2DP-standarden, som brukes for overføring av høykvalitetslyd, fungerer kun gjennom Bluetooth Classic, og det er ingen analog i LE.

Konklusjon - å kjøpe lydenheter med Bluetooth 5 kun på grunn av den nye versjonen av protokollen er meningsløst. Bluetooth 4.0/4.1/4.2 i forbindelse med lydoverføring vil fungere nøyaktig det samme.
Hvis kunngjøringen av nye hodetelefoner nevner doblet rekkevidde og redusert strømforbruk takket være Bluetooth 5, bør du vite at de enten ikke forstår det selv eller villeder deg. Ikke rart, for selv produsenter av Bluetooth-brikker i sine kunngjøringer er forvirret over forskjellene mellom den nye versjonen av standarden, og noen Bluetooth 5-brikker støtter den femte versjonen kun for LE, og bruker 4.2 for Classic.

Forsinket lydoverføring

Mengden forsinkelse (lag) i lyd avhenger av mange faktorer: størrelsen på bufferen i lydstabelen, i Bluetooth-stabelen og i selve den trådløse avspillingsenheten, og den algoritmiske forsinkelsen til kodeken.

Latensen til enkle kodeker som SBC, aptX og aptX HD er veldig liten, 3-6 ms, noe som kan neglisjeres, men komplekse kodeker som AAC og LDAC kan forårsake merkbar forsinkelse. AAC algoritmisk latens for 44.1 kHz er 60 ms. LDAC - ca. 30 ms (basert på en grov analyse av kildekoden. Jeg kan ta feil, men ikke mye.)

Den resulterende ventetiden avhenger i stor grad av avspillingsenheten, brikkesettet og bufferen. Under tester fikk jeg en spredning på 150 til 250 ms på forskjellige enheter (med SBC-kodeken). Hvis vi antar at enheter som støtter ekstra kodeker aptX, AAC og LDAC bruker komponenter av høy kvalitet og en liten bufferstørrelse, får vi følgende typiske ventetider:

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

La meg minne deg på: aptX Low Latency støttes ikke i operativsystemer, og det er grunnen til at lavere latens kun kan oppnås med en sender+mottaker eller sender+hodetelefoner/høyttalerkombinasjon, og alle enheter må støtte denne kodeken.

Problemer med Bluetooth-enhet, sertifisering og logo

Hvordan skille en lydenhet av høy kvalitet fra et billig håndverk? Utseendemessig, først av alt!

For billige kinesiske hodetelefoner, høyttalere og mottakere:

1. Ordet "Bluetooth" mangler på esken og enheten, "Wireless" og "BT" brukes oftest
2. Bluetooth-logo mangler på boksen eller enheten
3. Ingen blå blinkende LED

Fraværet av disse elementene indikerer at enheten ikke er sertifisert, noe som betyr at den potensielt er av lav kvalitet og problematisk. For eksempel er Bluedio-hodetelefoner ikke Bluetooth-sertifisert og samsvarer ikke fullt ut med A2DP-spesifikasjonen. De ville ikke ha bestått sertifisering.

La oss vurdere flere enheter og bokser fra dem:

Disse er alle ikke-sertifiserte enheter. Instruksjonene kan inneholde en logo og navnet på Bluetooth-teknologien, men det viktigste er at de står på esken og/eller selve enheten.

Hvis hodetelefonene eller høyttaleren sier "Ze bluetooth dewise is connected vellykket", indikerer dette heller ikke kvaliteten:

Konklusjon

Kan Bluetooth fullstendig erstatte kablede hodetelefoner og hodesett? Den er kapabel, men på bekostning av dårlig samtalekvalitet, økt lydforsinkelse som kan være irriterende i spill, og en rekke proprietære kodeker som krever lisensavgifter og øker den endelige kostnaden for både smarttelefoner og hodetelefoner.

Markedsføringen av alternative kodeker er veldig sterk: aptX og LDAC presenteres som en etterlengtet erstatning for den «utdaterte og dårlige» SBC, som ikke er på langt nær så ille som folk tror den er.

Som det viste seg, kan de kunstige begrensningene til Bluetooth-stabler på SBC-bithastigheten omgås, slik at SBC ikke vil være dårligere enn aptX HD. Jeg tok initiativet i egne hender og laget en oppdatering for LineageOS-fastvaren: Endre Bluetooth-stabelen for å forbedre lyden på hodetelefoner uten AAC-, aptX- og LDAC-kodeker

Mer informasjon finner du på nettsidene Lyd gutter и SoundExpert.

Bonus: SBC-referansekoder, A2DP bitstrøminformasjon og testfiler. Denne filen pleide å bli lagt ut offentlig på Bluetooth-nettstedet, men er nå bare tilgjengelig for medlemmer av Bluetooth SIG.

Kilde: www.habr.com