A 3.5 mm-es audio jack nélküli okostelefonok tömeggyártása miatt a vezeték nélküli Bluetooth fejhallgatók sokak számára a zenehallgatás és a headset módban történő kommunikáció fő módja lettek.
A vezeték nélküli eszközök gyártói nem mindig írnak részletes termékleírást, az interneten a Bluetooth hangról szóló cikkek ellentmondásosak, esetenként tévesek, nem beszélnek minden funkcióról, és gyakran ugyanazokat az információkat másolják, amelyek nem felelnek meg a valóságnak.
Próbáljuk megérteni a protokollt, a Bluetooth OS stackek, fejhallgatók és hangszórók képességeit, a zenéhez és beszédhez használható Bluetooth kodekeket, megtudjuk, mi befolyásolja az átvitt hang minőségét és a késleltetést, tanuljuk meg, hogyan gyűjthetünk és dekódolhatunk információkat a támogatott kodekekről és egyéb eszközökről képességeit.

TL, DR:

• SBC - normál kodek
• A fejhallgatók mindegyik kodekhez külön hangszínszabályzóval és utófeldolgozással rendelkeznek
• Az aptX nem olyan jó, mint hirdetik
• Az LDAC marketing baromság
• A hívás minősége továbbra is gyenge
• A C hangkódolókat beágyazhatja a böngészőjébe, ha az emscriptenen keresztül WebAssembly-be fordítja őket, és nem lassulnak le sokat.

Zene Bluetooth-on keresztül

A Bluetooth funkcionális komponensét a profilok – az egyes funkciók specifikációi – határozzák meg. A Bluetooth zene streaming kiváló minőségű A2DP egyirányú hangátviteli profilt használ. Az A2DP szabványt 2003-ban fogadták el, és azóta nem változott jelentősen.
A profilon belül 1 kötelező, alacsony számítási bonyolultságú, kifejezetten Bluetooth-ra készült SBC kodek és további 3 szabványosított. Lehetőség van saját megvalósítású, nem dokumentált kodekek használatára is.

2019 júniusától mi vagyunk az xkcd képregényben 14 A2DP kodekkel:

• SBC ← A2DP szabványos, minden eszköz támogatja
• MPEG-1/2 Layer 1/2/3 ← A2DP-ben szabványosítva: jól ismert MP3, digitális TV-ben használatos MP2, és ismeretlen MP1
• MPEG-2/4 AAC ← szabványosítva A2DP-ben
• ATTRAC ← régi kodek a Sony-tól, szabványos A2DP
• LDAC ← új kodek a Sony-tól
• aptX ← kodek 1988-ból
• aptX HD ← ugyanaz, mint az aptX, csak különböző kódolási beállításokkal
• aptX alacsony késleltetés ← teljesen más kodek, nincs szoftveres implementáció
• aptX adaptív ← egy másik kodek a Qualcommtól
• FastStream ← pszeudo kodek, kétirányú SBC módosítás
• HWA LHDC ← új kodek a Huawei-től
• Samsung HD ← 2 eszköz támogatja
• Samsung méretezhető ← 2 eszköz támogatja
• Samsung UHQ-BT ← 3 eszköz támogatja

Egyáltalán miért van szükségünk kodekekre, kérdezed, amikor a Bluetooth-on van EDR, amivel 2 és 3 Mbit/s sebességgel lehet adatot vinni, a tömörítetlen kétcsatornás 16 bites PCM-hez pedig elég az 1.4 Mbit/s?

Adatátvitel Bluetooth-on keresztül

Kétféle adatátvitel létezik a Bluetooth-ban: Asynchronous Connection Less (ACL) a kapcsolat létrehozása nélküli aszinkron átvitelhez, és Synchronous Connection Oriented (SCO), szinkron átvitelhez előzetes csatlakozási egyeztetéssel.
Az átvitel időosztásos sémával történik, és minden egyes csomaghoz külön-külön választanak ki egy átviteli csatornát (Frequency-Hop/Time-Division-Duplex, FH/TDD), amelyre az időt 625 mikroszekundumos időközökre osztják, úgynevezett slot-okra. Az egyik készülék páros, a másik páratlan számú slotokban sugároz. A továbbított csomag az adatok nagyságától és a beállított átviteli típustól függően 1, 3 vagy 5 rést foglalhat el, ebben az esetben az átvitel egy eszközzel páros és páratlan résekben történik az átvitel végéig. Összesen másodpercenként akár 1600 csomag fogadható és küldhető, ha mindegyik 1 slotot foglal el, és mindkét eszköz megállás nélkül küld és fogad valamit.

2 és 3 Mbit/s EDR esetén, ami a közleményekben és a Bluetooth weboldalon is megtalálható, az összes adat maximális csatornaátviteli sebessége összesen (beleértve az összes olyan protokoll műszaki fejléceit, amelyekbe az adatokat be kell zárni), két irányban. egyidejűleg. A tényleges adatátviteli sebesség nagymértékben változhat.

A zene továbbítására aszinkron módszert alkalmaznak, szinte mindig olyan csomagokat használva, mint a 2-DH5 és 3-DH5, amelyek EDR módban maximum 2 Mbit/s, illetve 3 Mbit/s adatmennyiséget hordoznak, és 5 időt foglalnak el. - slot megosztása.

Az átvitel sematikus ábrázolása 5 slot használatával az egyik eszközzel és 1 slottal egy másik eszközzel (DH5/DH1):


Az éter időosztásának elve miatt egy csomag továbbítása után 625 mikromásodperces időrést vagyunk kénytelenek várni, ha a második készülék nem továbbít nekünk semmit, vagy kis csomagot továbbít, és több időt, ha a második eszköz ad. nagy csomagokban. Ha egynél több eszköz csatlakozik a telefonhoz (például fejhallgató, óra és fitnesz karkötő), akkor az átviteli idő megoszlik mindegyik között.

Az, hogy a hangot speciális L2CAP és AVDTP átviteli protokollokba kell beágyazni, 16 bájtot vesz el az átvitt audio hasznos terhelés lehetséges maximális mennyiségéből.

Csomag Típus
Résidők száma
Max. bájtok száma a csomagban
Max. Az A2DP hasznos adat bájtjainak száma
Max. A2DP hasznos adatátviteli sebesség

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

Az 1414 és 1429 kbps határozottan nem elegendő a tömörítetlen hang átviteléhez valós körülmények között, a zajos 2.4 GHz-es tartomány és a szolgáltatási adatok átvitelének szükségessége mellett. Az EDR 3 Mbit/s igényes az adási teljesítményre és a zajra az éterben, ezért még 3-DH5 módban sem lehetséges a kényelmes PCM átvitel, mindig lesznek rövid távú megszakítások, és minden csak egy távolságra fog működni. pár méter.
A gyakorlatban még egy 990 kbit/s-os hangfolyamot (LDAC 990 kbit/s) is nehéz továbbítani.

Térjünk vissza a kodekekhez.

SBC

Codec szükséges minden olyan eszközhöz, amely támogatja az A2DP szabványt. A legjobb és a legrosszabb kodek egyszerre.

Mintavételi gyakoriság
Bit mélység
Bitráta
Kódolás támogatása
Dekódolás támogatása

16, 32, 44.1, 48 kHz
16 bit
10-1500 kbps
Minden eszköz
Minden eszköz

Az SBC egy egyszerű és számításilag gyors kodek, primitív pszichoakusztikus modellel (csak a halk hangok maszkolását alkalmazzák), adaptív impulzuskód modulációt (APCM) használ.
Az A2DP specifikáció két profil használatát javasolja: Közepes minőséget és kiváló minőséget.


A kodek számos beállítással rendelkezik, amelyek segítségével szabályozható az algoritmikus késleltetés, a minták száma egy blokkban, a bitelosztási algoritmus, de szinte mindenhol ugyanazokat a paramétereket használják, amelyeket a specifikációban ajánlott: Joint Stereo, 8 frekvenciasáv, 16 blokk hangkeret, Loudness bit elosztási módszer.
Az SBC támogatja a Bitpool paraméter dinamikus megváltoztatását, amely közvetlenül befolyásolja a bitsebességet. Ha a rádióhullámok eltömődtek, a csomagok elvesznek, vagy az eszközök nagy távolságra vannak, az audioforrás csökkentheti a Bitpoolt, amíg a kommunikáció vissza nem áll a normális kerékvágásba.

A legtöbb fejhallgató-gyártó 53-ra állítja a maximális Bitpool-értéket, ami az ajánlott profil használatakor 328 kilobit/s-ra korlátozza a bitsebességet.
Még ha a fejhallgató gyártója a maximális Bitpool-értéket 53 fölé állította (ilyen modellek találhatók például: Beats Solo³, JBL Everest Elite 750NC, Apple AirPods, néhány vevőegységen és autós fejegységen is megtalálható), a legtöbb operációs rendszer nem teszi lehetővé megnövelt bitsebesség használata a Bluetooth veremekben beállított belső értékhatár miatt.
Ezenkívül egyes gyártók bizonyos eszközökön alacsonyra állítják a maximális Bitpool-értéket. Például a Bluedio T-nél 39, a Samsung Gear IconX-nél 37, ami rossz hangminőséget ad.

A Bluetooth-veremek fejlesztőinek mesterséges korlátozásai valószínűleg egyes nagy Bitpool-értékekkel vagy atipikus profilokkal rendelkező eszközök inkompatibilitása miatt merültek fel, még akkor is, ha támogatásukról számoltak be, valamint a tanúsítás során végzett nem megfelelő tesztelés miatt. A Bluetooth-veremek készítőinek könnyebb volt az ajánlott profilban való megegyezésre korlátozódniuk, nem pedig a hibás eszközök adatbázisainak létrehozására (bár most ezt teszik más, hibásan működő funkciókhoz).

Az SBC dinamikusan allokálja a kvantálási biteket a frekvenciasávokhoz alacsonytól magasig, különböző súllyal. Ha az összes bitrátát az alacsony és középső frekvenciákhoz használtuk, a magas frekvenciák „levágódnak” (ehelyett csend lesz).

Példa SBC 328 kbps. Felül az eredeti, alul az SBC, időszakosan vált a sávok között. A videofájlban lévő hang a FLAC veszteségmentes tömörítési kodeket használja. A FLAC használata mp4 tárolóban nem hivatalosan szabványosított, így nem garantált, hogy a böngészője lejátssza, de működnie kell az asztali Chrome és Firefox legújabb verzióiban. Ha nincs hangja, letöltheti a fájlt, és megnyithatja egy teljes értékű videolejátszóban.
ZZ felső - éles öltözetű férfi

A spektrogram a váltás pillanatát mutatja: az SBC időszakosan levágja a 17.5 kHz feletti csendes hangokat, és egyáltalán nem allokál bitet a 20 kHz feletti sávra. A teljes spektrogram kattintással elérhető (1.7 MB).

Ezen a számon nem hallok különbséget az eredeti és az SBC között.

Vegyünk valami újabbat, és szimuláljuk azt a hangot, amelyet a Bitpool 37-es Samsung Gear IconX fejhallgatóval kapunk (fent - az eredeti jel, lent - SBC 239 kbps, hang FLAC-ban).
Mindless Self Engedence – Tanú

Az ének magas frekvenciájában recsegést, kevésbé sztereó effektust és kellemetlen "csengő" hangot hallok.

Bár az SBC egy nagyon rugalmas kodek, beállítható alacsony késleltetésre, kiváló hangminőséget biztosít magas bitsebességgel (452+ kbps), és a legtöbb ember számára meglehetősen jó szabványos magas minőségben (328 kbps), mivel az az A2DP szabvány nem határoz meg fix profilokat (de csak ajánlásokat ad), a veremfejlesztők mesterséges korlátozásokat állítottak be a Bitpoolra, a továbbított hang paraméterei nem jelennek meg a felhasználói felületen, a fejhallgató-gyártók pedig szabadon beállíthatják saját beállításaikat és soha a termék műszaki specifikációjában tüntesse fel a Bitpool értéket, a codec az alacsony hangminőségéről vált híressé, bár ez önmagában a kodekkel nem probléma.
A Bitpool paraméter közvetlenül csak egy profilon belül befolyásolja a bitsebességet. Ugyanaz a Bitpool 53 érték 328 kbps-os bitsebességet is tud adni az ajánlott High Quality profil mellett, és 1212 kbps-t Dual Channel és 4 frekvenciasáv esetén, ezért az operációs rendszer készítői a Bitpoolra vonatkozó korlátozások mellett korlátot és Bitráta. Ahogy látom, ez a helyzet az A2DP szabvány hibája miatt alakult ki: a bitrátát kellett egyeztetni, nem a Bitpoolt.

Táblázat az SBC-képességek támogatásáról különböző operációs rendszerekben:

operációs rendszer
Támogatott mintavételi frekvenciák
Limit max. Bitpool
Limit max. Bitráta
Tipikus bitráta
Bitpool dinamikus beállítás

A windows 10
44.1 кГц
53
512 kbps
328 kbps
✓*

Linux (BlueZ + PulseAudio)
16, 32, 44.1, 48 kHz
64 (bejövő kapcsolatokhoz), 53 (kimenő kapcsolatokhoz)
Határ nélül
328 kbps
✓*

MacOS High Sierra
44.1 кГц
64, alapértelmezett 53***
Ismeretlen
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 кГц
53
Határ nélül
328 kbps
✗

* A Bitpool csak csökken, de nem növekszik automatikusan, ha az átviteli feltételek javulnak. A Bitpool visszaállításához le kell állítani a lejátszást, várni kell néhány másodpercet, és újra kell indítani a hangot.
** Az alapértelmezett érték a firmware fordításakor megadott verembeállításoktól függ. Android 8/8.1-ben a frekvencia a fordítás közbeni beállításoktól függően csak 44.1 kHz vagy 48 kHz, más verziókban a 44.1 kHz és a 48 kHz egyszerre támogatott.
*** A Bitpool értéke a Bluetooth Explorer programban növelhető.

aptX és aptX HD

Az aptX egy egyszerű és számításilag gyors kodek, pszichoakusztika nélkül, adaptív differenciális impulzuskód modulációval (ADPCM). 1988 körül jelent meg (bejegyzés dátuma szabadalom 1988 februárjában), a Bluetooth előtt elsősorban professzionális vezeték nélküli audioberendezésekben használták. Jelenleg a Qualcomm tulajdonában van, engedélyt és jogdíjat igényel. 2014-től: 6000 USD egyszeri és ≈1 USD eszközönként, legfeljebb 10000 XNUMX eszközből álló kötegek esetén (forrás, 16. oldal).
Az aptX és az aptX HD ugyanaz a kodek, különböző kódolási profilokkal.

A kodek csak egy paraméterrel rendelkezik - a mintavételezési frekvencia kiválasztása. A csatornák száma/módja viszont választható, de az általam ismert összes eszközön (70+ darab) csak a sztereót támogatja.

Codec
Mintavételi gyakoriság
Bit mélység
Bitráta
Kódolás támogatása
Dekódolás támogatása

aptX
16, 32, 44.1, 48 kHz
16 bit
128 / 256 / 352 / 384 kbps (a mintavételi sebességtől függően)
Windows 10 (asztali és mobil), macOS, Android 4.4+/7*, Blackberry OS 10
Audioeszközök széles választéka (hardver)

* A 7-ig terjedő verziók a Bluetooth-verem módosítását igénylik. A kodek csak akkor támogatott, ha az Android-eszköz gyártója engedélyezte a kodeket a Qualcommtól (ha az operációs rendszer rendelkezik kódolási könyvtárakkal).

Az aptX 4 frekvenciasávra osztja a hangot, és folyamatosan ugyanannyi bittel kvantálja: 8 bit a 0-5.5 kHz-hez, 4 bit az 5.5-11 kHz-hez, 2 bit a 11-16.5 kHz-hez, 2 bit a 16.5-22 kHz-hez ( a 44.1 kHz mintavételi frekvenciára vonatkozó adatok).

Példa aptX hangra (felül - az eredeti jel, alul - aptX, csak a bal oldali csatornák spektrogramja, hang FLAC-ban):

A magasságok kicsit vörösebbek lettek, de nem lehetett hallani a különbséget.

A kvantálási bitek rögzített eloszlása ​​miatt a kodek nem tudja „áthelyezni a biteket” azokra a frekvenciákra, amelyeknek leginkább szüksége van rájuk. Az SBC-vel ellentétben az aptX nem „levágja” a frekvenciákat, hanem kvantálási zajt ad hozzájuk, csökkentve a hang dinamikatartományát.

Nem szabad azt feltételezni, hogy például sávonként 2 bit használata a dinamikatartományt 12 dB-re csökkenti: az ADPCM 96 kvantálási bit használata esetén is akár 2 dB dinamikatartományt tesz lehetővé, de csak egy bizonyos jelre.
Az ADPCM az aktuális minta és a következő minta közötti numerikus különbséget tárolja, ahelyett, hogy az abszolút értéket tárolná, mint a PCM-ben. Ez lehetővé teszi az azonos (veszteség nélkül) vagy majdnem azonos (viszonylag kis kerekítési hibával) információ tárolásához szükséges bitek számának csökkentését. A kerekítési hibák csökkentésére együttható táblázatokat használnak.
A kodek létrehozásakor a szerzők ADPCM-együtthatókat számítottak ki egy zenei audiofájl készletére. Minél közelebb van az audiojel ahhoz a zenekészlethez, amelyre a táblák épültek, az aptX annál kevesebb kvantálási hibát (zajt) hoz létre.

Emiatt a szintetikus tesztek mindig rosszabb eredményt adnak, mint a zene. Csináltam egy speciális szintetikus példát, amelyben az aptX gyenge eredményeket mutat - 12.4 kHz-es szinuszhullám (felül - az eredeti jel, lent - aptX. Hang FLAC-ban. Csökkentse a hangerőt!):

Spektrum grafikon:


A zajok egyértelműen hallhatók.

Ha azonban kisebb amplitúdójú szinuszhullámot generál, hogy halkabb legyen, akkor a zaj is halkabb lesz, ami széles dinamikatartományt jelez:

Ha szeretné hallani az eredeti és a tömörített zeneszám közötti különbséget, megfordíthatja az egyik jelet, és csatornánként hozzáadhatja a számokat. Ez a megközelítés általában helytelen, és bonyolultabb kodekekkel nem adna józan eredményt, de kifejezetten az ADPCM számára nagyon megfelelő.
Az eredeti és az aptX közötti különbség
A jelek négyzetes különbsége -37.4 dB szinten van, ami nem sok egy ilyen tömörített zenénél.

aptX HD

Az aptX HD nem egy önálló kodek, hanem az aptX kodek továbbfejlesztett kódolási profilja. A változtatások a kódolási frekvenciatartományokhoz kiosztott bitek számát érintették: 10 bit a 0-5.5 kHz-hez, 6 bit az 5.5-11 kHz-hez, 4 bit a 11-16.5 kHz-hez, 4 bit a 16.5-22 kHz-hez (számjegyek a 44.1 kHz-hez) .

Codec
Mintavételi gyakoriság
Bit mélység
Bitráta
Kódolás támogatása
Dekódolás támogatása

aptX HD
16, 32, 44.1, 48 kHz
24 bites
192 / 384 / 529 / 576 kbps (a mintavételi sebességtől függően)
Android 8+*
Egyes audioeszközök (hardver)

* A 7-ig terjedő verziók a Bluetooth-verem módosítását igénylik. A kodek csak akkor támogatott, ha az Android-eszköz gyártója engedélyezte a kodeket a Qualcommtól (ha az operációs rendszer rendelkezik kódolási könyvtárakkal).

Kevésbé gyakori, mint az aptX: nyilvánvalóan külön licencet igényel a Qualcommtól, és külön licencdíjat.

Ismételjük meg a példát egy 12.4 kHz-es szinuszhullámmal:


Sokkal jobb, mint az aptX, de még mindig egy kicsit zajos.

aptX alacsony késleltetés

A Qualcomm kodek, aminek semmi köze nincs a szabványos aptX-hez és az aptX HD-hez, a fejlesztésben részt vevő személyek korlátozott információiból ítélve. Interaktív, alacsony késleltetésű hangátvitelre tervezték (filmek, játékok), ahol a hangkésleltetés szoftverrel nem állítható. A kódolók és dekóderek szoftveres implementációi nem ismertek, ezeket kizárólag adók, vevők, fejhallgatók és hangszórók támogatják, okostelefonok és számítógépek nem.

Mintavételi gyakoriság
Bitráta
Kódolás támogatása
Dekódolás támogatása

44.1 кГц
276/420 kbps
Egyes adók (hardverek)
Egyes audioeszközök (hardver)

AAC

Az AAC vagy Advanced Audio Coding egy számításilag összetett kodek komoly pszichoakusztikus modellel. Széles körben használják hangzáshoz az interneten, népszerűsége a második az MP3 után. Licenc és jogdíj szükséges: 15000 1000 USD egyszeri (vagy 15 0.98 USD 500000 főnél kevesebb alkalmazottat foglalkoztató cégek esetén) + XNUMX USD az első XNUMX XNUMX eszközért (forrás).
A kodek az MPEG-2 és MPEG-4 specifikációkon belül szabványosított, és a közkeletű tévhitekkel ellentétben nem az Apple-é.

Mintavételi gyakoriság
Bitráta
Kódolás támogatása
Dekódolás támogatása

8 - 96 kHz
8-576 kbps (sztereóhoz), 256-320 kbps (tipikus Bluetooth esetén)
macOS, Android 7+*, iOS
Audioeszközök széles választéka (hardver)

* csak azokon az eszközökön, amelyek gyártója licencdíjat fizetett

Az iOS és a macOS az Apple jelenlegi legjobb AAC kódolóját használja a lehető legjobb hangminőség biztosítása érdekében. Az Android a második legjobb minőségű Fraunhofer FDK AAC kódolót használja, de használhat különféle, a platformba épített hardvert (SoC), amelyek kódolási minősége ismeretlen. A SoundGuys weboldalán található legutóbbi tesztek szerint, a különböző Android telefonok AAC kódolási minősége nagyon eltérő:

A legtöbb vezeték nélküli audioeszköz maximális bitsebessége 320 kbps AAC esetén, néhányuk csak a 256 kbps-t támogatja. Más bitsebességek rendkívül ritkák.
Az AAC kiváló minőséget biztosít 320 és 256 kbps bitsebességgel, de ennek függvénye a már tömörített tartalom szekvenciális kódolásának elvesztése256 kbps bitsebességű iOS rendszeren azonban még több szekvenciális kódolással is nehezen hallható különbség az eredetihez képest, egyetlen kódolással, például MP3 320 kbps – AAC 256 kbps között, a veszteség elhanyagolható.
Más Bluetooth kodekekhez hasonlóan minden zenét először dekódol, majd kódol a kodek. Ha AAC formátumú zenét hallgat, először az operációs rendszer dekódolja, majd ismét AAC-ba kódolja a Bluetooth-on keresztüli továbbításhoz. Ez több hangfolyam keveréséhez szükséges, például zene és új üzenetek értesítései. Az iOS sem kivétel. Az interneten sok olyan állítást találhatunk, amely szerint az iOS rendszeren az AAC formátumú zene nem kerül átkódolásra Bluetooth-on keresztül, ami nem igaz.

MP1/2/3

Az MPEG-1/2 Part 3 család kodekei a jól ismert és széles körben használt MP3-ból, a kevésbé elterjedt MP2-ből (főleg digitális tévében és rádióban használatos), valamint a teljesen ismeretlen MP1-ből állnak.

A régi MP1 és MP2 kodekek egyáltalán nem támogatottak: nem találtam olyan fejhallgatót vagy Bluetooth stacket, amely kódolná vagy dekódolná őket.
Az MP3 dekódolást egyes fejhallgatók támogatják, de a kódolást egyetlen modern operációs rendszer sem támogatja. Úgy tűnik, hogy a harmadik féltől származó BlueSoleil stack for Windows képes MP3-ba kódolni, ha manuálisan módosítja a konfigurációs fájlt, de számomra a telepítés a BSoD-hez vezet a Windows 10 rendszeren. Következtetés - a kodek valójában nem használható Bluetooth hanghoz.
Korábban, 2006-2008-ban, az A2DP szabvány készülékekben való elterjedése előtt az emberek a Nokia BH-3 headsettel hallgattak MP501 zenét az MSI BluePlayer programon keresztül, amely Symbianon és Windows Mobile-on is elérhető volt. Abban az időben az okostelefonok operációs rendszer-architektúrája számos alacsony szintű funkció elérését tette lehetővé, és a Windows Mobile-on még harmadik féltől származó Bluetooth-veremek telepítésére is lehetőség volt.

Az MP3 kodek utolsó szabadalma lejárt, a kodek használata 23. április 2017. óta nem igényel licencdíjat.

Ha a fent említett referenciákban említett leghosszabb ideig fennálló szabadalmat vesszük mércének, akkor az MP3 technológia 16. április 2017-án vált szabadalommentessé az Egyesült Államokban, amikor lejárt a Technicolor által birtokolt és kezelt 6,009,399 XNUMX XNUMX számú US szabadalom.

Forrás: www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html

Mintavételi gyakoriság
Bitráta
Kódolás támogatása
Dekódolás támogatása

16 - 48 kHz
8-320 kbps
Sehol nem támogatott
Egyes audioeszközök (hardver)

LDAC

A Sony új és aktívan népszerűsített „Hi-Res” kodekje, amely akár 96 kHz-es mintavételezési és 24 bites bitrátát is támogat, 990 kbps-ig. Audiofil kodekként hirdetik, a meglévő Bluetooth kodekek helyettesítőjeként. A rádióadás körülményeitől függően adaptív bitsebesség-beállítás funkcióval rendelkezik.

LDAC kódoló (libldac) tartalmazza a szabványos Android-csomagot, így a kódolás minden Android okostelefonon támogatott, az operációs rendszer 8-as verziójától kezdve. Nincsenek szabadon elérhető szoftverdekóderek, a kodek specifikációja nem elérhető a nagyközönség számára, azonban a kódolóra első ránézésre a kodek belső felépítése hasonló a ATRAC9 - A PlayStation 4-ben és a Vitában használt Sony kodek: mindkettő a frekvenciatartományban működik, módosított diszkrét koszinusz transzformációt (MDCT) és a Huffman algoritmussal történő tömörítést használ.

Az LDAC támogatást szinte kizárólag a Sony fejhallgatói biztosítják. Az LDAC dekódolásának képessége néha megtalálható más gyártók fejhallgatóin és DAC-jain, de nagyon ritkán.

Mintavételi gyakoriság
Bitráta
Kódolás támogatása
Dekódolás támogatása

44.1 - 96 kHz
303/606/909 kbit/s (44.1 és 88.2 kHz esetén), 330/660/990 kbit/s (48 és 96 kHz esetén)
Android 8 +
Néhány Sony fejhallgató és néhány más gyártótól származó eszköz (hardver)

Az LDAC Hi-Res kodekként való marketingje árt a technikai összetevőjének: hülyeség az emberi fül számára hallhatatlan frekvenciák átvitelére és a bitmélység növelésére költeni a bitrátát, miközben nem elég CD-minőségű (44.1/16) veszteség nélkül továbbítani. . Szerencsére a kodek két üzemmóddal rendelkezik: CD hangátvitel és Hi-Res hangátvitel. Az első esetben csak 44.1 kHz/16 bitet továbbítanak a levegőben.

Mivel a szoftveres LDAC dekóder nem elérhető szabadon, lehetetlen a kodek tesztelése további, LDAC dekódoló eszközök nélkül. A SoundGuys.com mérnökei egy digitális kimeneten keresztül csatlakoztatott és a tesztjelekre rögzített kimeneti hangot a támogatásával támogatott DAC-n végzett LDAC-teszt eredményei szerint az LDAC 660 és 990 kbps CD-minőségű módban biztosítja a jelet a a zajarány valamivel jobb, mint az aptX HD-é.

Forrás: www.soundguys.com/ldac-ultimate-bluetooth-guide-20026

Az LDAC a bevett profilokon kívül is támogatja a dinamikus bitrátát – 138 kb/s-tól 990 kb/s-ig, de amennyire én tudom, az Android csak a szabványos 303/606/909 és 330/660/990 kbps profilokat használja.

Egyéb kodekek

Más A2DP kodekeket nem használnak széles körben. Támogatásuk vagy szinte teljesen hiányzik, vagy csak bizonyos fejhallgató- és okostelefon-modelleknél érhető el.
Az A2DP-ben szabványosított ATRAC kodeket még maga a Sony sem használta Bluetooth kodekként, a Samsung HD, a Samsung Scalable és a Samsung UHQ-BT kodekek nagyon korlátozott mértékben támogatják az adó- és vevőeszközöket, a HWA LHDC pedig túl új, és csak három (?) eszközök.

Audioeszközök kodek támogatása

Nem minden gyártó tesz közzé pontos információkat azokról a kodekekről, amelyeket bizonyos vezeték nélküli fejhallgatók, hangszórók, vevők vagy adók támogatnak. Néha megesik, hogy egy bizonyos kodek támogatása csak az átvitelre vonatkozik, de nem a vételre (a kombinált adó-vevők esetében), bár a gyártó egyszerűen kijelenti, hogy „támogatás”, megjegyzések nélkül (feltételezem, hogy egyes kódolók és dekóderek külön engedélyezése a kodekek okolhatók ezért). A legolcsóbb eszközökön előfordulhat, hogy egyáltalán nem találja meg a deklarált aptX támogatást.

Sajnos a legtöbb operációs rendszer interfésze nem jeleníti meg a sehol használt kodeket. Az ezzel kapcsolatos információk csak Androidon, a 8-as verziótól kezdődően és macOS-en érhetők el. Azonban még ezekben az operációs rendszerekben is csak azok a kodekek jelennek meg, amelyeket a telefon/számítógép és a fejhallgató is támogat.

Honnan tudhatja meg, hogy készüléke mely kodekeket támogatja? Rögzítse és elemezze a forgalmi dumpot A2DP egyeztetési paraméterekkel!
Ez megtehető Linuxon, macOS-en és Androidon. Linuxon a Wireshark vagy a hcidump, macOS-en a Bluetooth Explorer, Androidon pedig a szabványos Bluetooth HCI dump mentési funkció használható, amely a fejlesztői eszközökben érhető el. Egy btsnoop formátumú kiírást kap, amelyet betölthet a Wireshark analizátorba.
Figyeljen oda: helyes dump csak úgy érhető el, ha telefonról/számítógépről fejhallgatóra/hangszóróra csatlakozik (bármilyen viccesen is hangzik)! A fejhallgató önállóan is képes kapcsolatot létesíteni a telefonnal, ebben az esetben a kodekek listáját kéri a telefontól, és nem fordítva. A helyes dump rögzítése érdekében először szüntesse meg a készülék párosítását, majd párosítsa a telefont a fejhallgatóval a kiíratás rögzítése közben.

Használja a következő megjelenítési szűrőt az irreleváns forgalom kiszűrésére:

btavdtp.signal_id

Ennek eredményeként valami ehhez hasonlót kell látnod:

A GetCapabilities parancs egyes elemeire kattintva megtekintheti a kodek részletes jellemzőit.

A Wireshark nem ismeri az összes kodek azonosítót, ezért néhány kodeket manuálisan kell visszafejteni, az alábbi azonosító táblázat alapján:

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

Annak érdekében, hogy ne elemezzem manuálisan a szemétlerakókat, létrehoztam egy szolgáltatást, amely mindent automatikusan elemz: btcodecs.valdikss.org.ru

Kodekek összehasonlítása. Melyik kodek a jobb?

Mindegyik kodeknek megvannak a maga előnyei és hátrányai.
Az aptX és az aptX HD keményen kódolt profilokat használ, amelyek nem módosíthatók a kódoló és a dekódoló módosítása nélkül. Sem a telefon gyártója, sem a fejhallgató gyártója nem módosíthatja a bitrátát vagy az aptX kódolási tényezőket. A kodek tulajdonosa, a Qualcomm egy referenciakódolót biztosít könyvtár formájában. Ezek a tények az aptX erőssége – előre tudja, milyen minőségű hangot kap, minden „de” nélkül.

Ezzel szemben az SBC-nek sok konfigurálható paramétere van, dinamikus bitrátája (a kódoló csökkentheti a bitpool paramétert, ha az adások foglaltak), és nincs kemény kódolt profilja, csak az ajánlott „közepes minőség” és „kiváló minőség”. 2-ban hozzáadták az A2003DP specifikációhoz. A „kiváló minőség” a mai szabványok szerint már nem olyan magas, és a legtöbb Bluetooth-stack nem teszi lehetővé a „kiváló minőségű” profilnál jobb paraméterek használatát, bár ennek nincs technikai megkötése.
A Bluetooth SIG nem rendelkezik referencia SBC kódolóval könyvtárként, és a gyártók maguk valósítják meg.
Ezek az SBC gyengeségei – sosem világos előre, hogy egy adott készüléktől milyen hangminőség várható. Az SBC alacsony és nagyon jó minőségű hangot is képes előállítani, de ez utóbbi elérhetetlen a Bluetooth-veremek mesterséges korlátainak letiltása vagy megkerülése nélkül.

Az AAC helyzete nem egyértelmű: egyrészt elméletileg a kodeknek az eredetitől megkülönböztethetetlen minőséget kellene produkálnia, de a gyakorlatban a SoundGuys laboratóriumának különböző Android-eszközökön végzett tesztjei alapján ez nem igazolódik. Valószínűleg a hiba a különböző telefonlapkakészletekbe épített gyenge minőségű hardveres hangkódolókban rejlik. Az AAC-t csak Apple-eszközökön érdemes használni, Androidon pedig az aptX-re és LDAC-ra korlátozni.

Az alternatív kodekeket támogató hardverek általában jobb minőségűek, egyszerűen azért, mert nagyon olcsó, gyenge minőségű eszközök esetén nincs értelme licencdíjat fizetni a kodekek használatáért. Tesztjeim során az SBC nagyon jól hangzik minőségi berendezéseken.

Készítettem egy webszolgáltatást, amely valós időben, közvetlenül a böngészőben kódolja a hangot SBC, aptX és aptX HD formátumba. Ezzel tesztelheti ezeket az audio kodekeket anélkül, hogy ténylegesen hangot továbbítana Bluetooth-on keresztül, bármilyen vezetékes fejhallgatón, hangszórón és kedvenc zenéjén, valamint közvetlenül módosíthatja a kódolási paramétereket hang lejátszása közben:
btcodecs.valdikss.org.ru/sbc-encoder
A szolgáltatás a BlueZ projekt SBC kódolókönyvtárait és az ffmpeg libopenaptx-ét használja, amelyek WebAssembly-be és JavaScript-be vannak fordítva C-ből az emscriptenen keresztül a böngészőben való futtatáshoz. Ki álmodhatna ilyen jövőről!

Így néz ki:

Figyelje meg, hogyan változik a zajszint 20 kHz után a különböző kodekeknél. Az eredeti MP3 fájl nem tartalmaz 20 kHz-nél nagyobb frekvenciákat.

Próbáljon meg kodekeket váltani, és nézze meg, hogy hallja-e a különbséget az eredeti, SBC 53 Joint Stereo (a szabvány és leggyakoribb profil) és az aptX/aptX HD között.

Hallom a különbséget a kodekek között fejhallgatóban!

Azok az emberek, akik nem hallják a kodekek közötti különbséget a webszolgáltatáson keresztüli tesztelés során, azt állítják, hogy meghallják, amikor zenét hallgatnak vezeték nélküli fejhallgatón. Sajnos ez nem vicc vagy placebo hatás: a különbség valóban hallható, de nem a különbségek okozzák kodekek.

A vezeték nélküli vevőeszközökben használt Bluetooth audio chipkészletek túlnyomó többsége digitális jelprocesszorral (DSP) van felszerelve, amely hangszínszabályzót, kompandert, sztereó bővítőt és más olyan dolgokat valósít meg, amelyek javítják (vagy megváltoztatják) a hangzást. A Bluetooth-berendezések gyártói konfigurálhatják a DSP-t minden kodek számára külön, és kodekek közötti váltáskor a hallgató azt gondolja, hogy eltérést hall a kodekek működésében, miközben a valóságban eltérő DSP beállításokat hallgat.

DSP Kalimba hangfeldolgozó csővezeték a CSR/Qualcomm által gyártott chipekben

Külön-külön aktiváljon különböző DSP-funkciókat minden kodekhez és kimenethez

Egyes prémium eszközökhöz olyan szoftver tartozik, amely lehetővé teszi a DSP beállítások testreszabását, de a legtöbb olcsóbb fejhallgató nem, és a felhasználók nem kapcsolhatják ki manuálisan a hang utófeldolgozását.

Az eszközök funkcionális jellemzői

Az A2DP szabvány modern változata rendelkezik „abszolút hangerőszabályzó” funkció — az eszköz hangerejének szabályozása az AVRCP protokoll speciális parancsaival, amely szabályozza a kimeneti fokozat erősítését, ahelyett, hogy programozottan csökkentené az audio stream hangerejét. Ha a fejhallgató hangerejének módosításakor a módosítás nem szinkronizálódik a telefon hangerejével, akkor a fejhallgató vagy a telefon nem támogatja ezt a funkciót. Ilyenkor érdemes mindig maximális hangerővel hallgatni a zenét a telefonon, a tényleges hangerőt a fejhallgató gombjaival beállítani - ilyenkor jobb lesz a jel-zaj arány és a hangminőség kellene magasabb.
A valóságban vannak szomorú helyzetek. Az SBC-hez készült RealForce OverDrive D1 fejhallgatómon egy erős kompander van bekapcsolva, és a hangerő növelése a halk hangok szintjének növekedéséhez vezet, míg a hangos hangok hangereje nem változik (a jel tömörítve van). Emiatt kb a felére kell állítani a hangerőt a számítógépen, ilyenkor gyakorlatilag nincs tömörítési hatás.
Megfigyeléseim szerint minden további kodekes fejhallgató támogatja az abszolút hangerőszabályzó funkciót, nyilván ez a kodek tanúsítás egyik követelménye.

Néhány fejhallgató támogatás két eszköz egyidejű csatlakoztatása. Ez lehetővé teszi például, hogy zenét hallgathasson a számítógépéről, és fogadjon hívásokat a telefonjáról. Tudnia kell azonban, hogy ebben a módban az alternatív kodekek le vannak tiltva, és csak az SBC-t használjuk.

AVDTP 1.3 Késleltetett jelentés funkció lehetővé teszi, hogy a fejhallgató közölje a késleltetést az adóeszközzel, amelyen a hang ténylegesen lejátszik. Ez lehetővé teszi a hang és a videó szinkronizálásának beállítását videofájlok megtekintése közben: ha problémák adódnak a rádióátvitellel, a hang nem marad le a videó mögött, hanem éppen ellenkezőleg, a videó lelassul a videó lejátszó által, amíg a hang és kép ismét szinkronizálva van.
A funkciót számos fejhallgató támogatja, Android 9+ és Linux PulseAudio 12.0+ rendszerrel. Nem tudok arról, hogy ez a funkció más platformokon támogatott.

Kétirányú kommunikáció Bluetooth-on keresztül. Hangátvitel.

A Bluetooth-os hangátvitelhez a szinkronkapcsolat-orientált (SCO) használatos - szinkron átvitel a kapcsolat előzetes egyeztetésével. Az üzemmód lehetővé teszi a hang és a hang szigorú sorrendben történő továbbítását, szimmetrikus küldési és vételi sebességgel, anélkül, hogy meg kellene várnia az átvitel megerősítését és a csomagok újraküldését. Ez csökkenti a rádiócsatornán keresztüli hangátvitel teljes késleltetését, de komoly korlátozásokat ró az egységnyi idő alatt továbbított adatmennyiségre, és negatívan befolyásolja a minőséget.
Ha ezt az üzemmódot használja, a hang és a hang átvitele azonos minőségben történik.
Sajnos 2019-től a Bluetooth-on keresztüli hangminőség továbbra is gyenge, és nem világos, hogy a Bluetooth SIG miért nem tesz semmit.

CVSD

Az alap CVSD beszédkodeket 2002-ben szabványosították, és minden kétirányú Bluetooth kommunikációs eszköz támogatja. 8 kHz-es mintavételezési frekvenciával hangátvitelt biztosít, ami megfelel a hagyományos vezetékes telefonálás minőségének.

Példa egy felvételre ebben a kodekben.

mSBC

A további mSBC kodeket 2009-ben szabványosították, 2010-ben pedig már megjelentek az azt hangátvitelre használó chipek. Az mSBC-t széles körben támogatják a különféle eszközök.
Ez nem egy független kodek, hanem egy normál SBC az A2DP szabványból, fix kódolási profillal: 16 kHz, mono, bitpool 26.

Példa egy felvételre ebben a kodekben.

Nem zseniális, de sokkal jobb, mint a CVSD, de még mindig bosszantó az online kommunikációhoz, különösen, ha fejhallgatóval kommunikálsz a játékon belül – a játék hangja is 16 kHz-es mintavételezési frekvenciával fog továbbítani.

A FastStreamCSR cég úgy döntött, hogy kidolgozza az SBC újrafelhasználásának ötletét. Az SCO protokoll korlátainak megkerülése és a magasabb bitráták használata érdekében a CSR más utat járt be – bevezették a kétirányú SBC hang támogatását az A2DP egyirányú hangátviteli szabványba, szabványosított kódolási profilokat, és „FastStream”-nek nevezték el.

A FastStream sztereó hangot 44.1 vagy 48 kHz-en továbbít 212 kbps bitsebességgel a hangszórókba, a 16 kHz-es monót pedig 72 kbps bitsűrűséggel (kicsit jobb, mint az mSBC) használják a hang átvitelére a mikrofonból. Az ilyen paraméterek sokkal jobban megfelelnek az online játékokban való kommunikációnak - a játék hangja és a beszélgetőpartnerek kiváló minőségűek lesznek.

Példa egy felvételre ebben a kodekben (+ hang a mikrofonból, ugyanaz, mint az mSBC).

A cég egy érdekes mankóval rukkolt elő, de az A2DP szabványnak ellentmondó ténye miatt csak a cég egyes adói támogatják (amelyek USB hangkártyaként működnek, nem Bluetooth eszközként), de nem Bluetooth stackben kaphat támogatást.bár a FastStream támogatással rendelkező fejhallgatók száma nem is olyan kicsi.

Jelenleg a FastStream támogatása csak az operációs rendszerben érhető el a Linux PulseAudio javításaként Rohár Pali fejlesztőtől, aki nem szerepel a program fő ágában.

aptX alacsony késleltetés

Legnagyobb meglepetésére az aptX Low Latency a kétirányú hangot is támogatja, ugyanazt az elvet, mint a FastStream.
A kodek ezen funkcióját sehol nem lehet használni - az alacsony késleltetésű dekódolást nem támogatja egyetlen operációs rendszer sem vagy az általam ismert Bluetooth-verem.

Bluetooth 5, klasszikus és alacsony energiafogyasztású

Sok zűrzavar támadt a Bluetooth specifikációi és verziói körül, mivel ugyanazon márka alatt két inkompatibilis szabvány található, mindkettőt széles körben használják különböző célokra.

Két különböző, nem kompatibilis Bluetooth protokoll létezik: a Bluetooth Classic és a Bluetooth Low Energy (LE, más néven Bluetooth Smart). Létezik egy harmadik protokoll is, a Bluetooth High Speed, de ez nem elterjedt, háztartási eszközökben sem használják.

A Bluetooth 4.0-tól kezdődően a specifikációban bekövetkezett változások elsősorban a Bluetooth Low Energy-t érintették, a Classic verzió pedig csak kisebb fejlesztéseket kapott.

A Bluetooth 4.2 és a Bluetooth 5 közötti változások listája:

9 VÁLTOZÁS 4.2-RŐL 5.0-RA

9.1 ÚJ FUNKCIÓK

A Bluetooth Core Specification 5.0 kiadás számos új funkciót tartalmaz. A fő fejlesztési területek a következők:
• Slot Availability Mask (SAM)
• 2 Msym/s PHY LE-hez
•LE Long Range
• Nagy teljesítményű, nem csatlakoztatható reklámozás
• LE hirdetési bővítmények
• LE csatornaválasztási algoritmus #2
9.1.1 A CSA5-höz hozzáadott szolgáltatások – a v5.0-ba integrálva
•Nagyobb kimeneti teljesítmény

Forrás: www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=421043 (291. oldal)

A Bluetooth 5 specifikáció keretein belül egyetlen változás érintette a Classic verziót: hozzáadták a Slot Availability Mask (SAM) technológiát, amely a rádióadások szétválasztását hivatott javítani. Az összes többi változtatás csak a Bluetooth LE-t érinti (és a magasabb kimeneti teljesítményt is).

minden Az audioeszközök csak a Bluetooth Classicot használják. Lehetetlen a fejhallgatót és a hangszórót Bluetooth Low Energy-n keresztül csatlakoztatni: nincs szabvány az LE segítségével történő hangátvitelre. A kiváló minőségű hang továbbítására használt A2DP szabvány csak Bluetooth Classicon keresztül működik, az LE-ben nincs analóg.

Következtetés - a Bluetooth 5-ös audioeszközök vásárlása csak a protokoll új verziója miatt értelmetlen. A Bluetooth 4.0/4.1/4.2 a hangátvitel összefüggésében pontosan ugyanúgy fog működni.
Ha az új fejhallgató bejelentése a Bluetooth 5-nek köszönhetően megduplázódott működési tartományt és csökkentett energiafogyasztást említ, akkor tudnod kell, hogy vagy maguk nem értik, vagy félrevezetik Önt. Nem csoda, mert még a Bluetooth chipek gyártói közleményeikben is értetlenül állnak a szabvány új verziója közötti különbségek miatt, és egyes Bluetooth 5 chipek csak LE esetében támogatják az ötödik verziót, Classichoz pedig 4.2-t használnak.

Hangátviteli késleltetés

A hang késleltetése (lag) sok tényezőtől függ: az audio veremben, a Bluetooth veremben és magában a vezeték nélküli lejátszóeszközben lévő puffer méretétől, valamint a kodek algoritmikus késleltetésétől.

Az egyszerű kodekek, mint az SBC, aptX és aptX HD késleltetési ideje nagyon kicsi, 3-6 ms, ami elhanyagolható, de az olyan összetett kodekek, mint az AAC és az LDAC, észrevehető késést okozhatnak. Az AAC algoritmikus késleltetése 44.1 kHz esetén 60 ms. LDAC - körülbelül 30 ms (a forráskód durva elemzése alapján. Lehet, hogy tévedek, de nem sokat.)

A kapott késleltetés nagymértékben függ a lejátszó eszköztől, annak chipkészletétől és pufferétől. A tesztek során 150-250 ms-os szórást kaptam különböző eszközökön (SBC kodekkel). Ha feltételezzük, hogy a további aptX, AAC és LDAC kodekeket támogató eszközök kiváló minőségű komponenseket és kis pufferméretet használnak, a következő tipikus késéseket kapjuk:

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

Hadd emlékeztesselek: az aptX Low Latency nem támogatott operációs rendszerekben, ezért alacsonyabb késleltetést csak adó+vevő vagy adó+fejhallgató/hangszóró kombinációval lehet elérni, és minden eszköznek támogatnia kell ezt a kodeket.

Bluetooth-eszközzel, tanúsítvánnyal és logóval kapcsolatos problémák

Hogyan lehet megkülönböztetni egy jó minőségű audioeszközt egy olcsó kézművestől? Elsősorban külsőre!

Olcsó kínai fejhallgatókhoz, hangszórókhoz és vevőegységekhez:

1. A dobozról és az eszközről hiányzik a „Bluetooth” szó, leggyakrabban a „Wireless” és a „BT” használatos.
2. Bluetooth logó hiányzik a dobozon vagy a készüléken
3. Nincs kéken villogó LED

Ezen elemek hiánya azt jelzi, hogy az eszköz nem kapott tanúsítványt, ami azt jelenti, hogy potenciálisan rossz minőségű és problémás. Például a Bluedio fejhallgató nem rendelkezik Bluetooth-tanúsítvánnyal, és nem felel meg teljesen az A2DP specifikációnak. Nem mentek volna át az igazoláson.

Nézzünk meg néhány eszközt és dobozt belőlük:

Ezek mind nem tanúsított eszközök. Az utasítások tartalmazhatnak egy logót és a Bluetooth technológia nevét, de a legfontosabb, hogy a dobozon és/vagy magán az eszközön szerepeljenek.

Ha a fejhallgatón vagy a hangszórón a „Ze bluetooth dewise csatlakozás sikeresen megtörtént” üzenet jelenik meg, ez szintén nem jelzi a minőséget:

Következtetés

A Bluetooth teljesen helyettesítheti a vezetékes fejhallgatót és headsetet? Képes, de a gyenge hívásminőség, a megnövekedett hang késleltetés, ami bosszantó lehet a játékokban, és számos szabadalmaztatott kodek, amelyek licencdíjat igényelnek, és növelik az okostelefonok és a fejhallgatók végső költségeit.

Az alternatív kodekek marketingje nagyon erős: az aptX-et és az LDAC-t az „elavult és rossz” SBC régóta várt helyettesítőjeként mutatják be, amely közel sem olyan rossz, mint ahogy azt az emberek gondolják.

Mint kiderült, a Bluetooth stackek mesterséges korlátai az SBC bitrátán megkerülhetők, így az SBC nem lesz rosszabb, mint az aptX HD. Saját kezembe vettem a kezdeményezést, és készítettem egy javítást a LineageOS firmware-hez: Módosítottuk a Bluetooth-vermet, hogy javítsuk a hangzást az AAC, aptX és LDAC kodekek nélküli fejhallgatókon

További információk a weboldalakon találhatók Hangos srácok и SoundExpert.

bónusz: SBC referenciakódoló, A2DP bitfolyam információ és tesztfájlok. Ezt a fájlt korábban nyilvánosan tették közzé a Bluetooth webhelyen, de most már csak a Bluetooth SIG tagjai számára érhető el.

Forrás: will.com