Disebabkan pengeluaran besar-besaran telefon pintar tanpa bicu audio 3.5 mm, fon kepala Bluetooth tanpa wayar telah menjadi cara utama bagi ramai untuk mendengar muzik dan berkomunikasi dalam mod set kepala.
Pengilang peranti wayarles tidak selalu menulis spesifikasi produk terperinci, dan artikel tentang audio Bluetooth di Internet adalah bercanggah, kadangkala tidak betul, tidak bercakap tentang semua ciri, dan sering menyalin maklumat yang sama yang tidak sesuai dengan realiti.
Mari cuba memahami protokol, keupayaan tindanan OS Bluetooth, fon kepala dan pembesar suara, codec Bluetooth untuk muzik dan pertuturan, ketahui perkara yang mempengaruhi kualiti bunyi dan kependaman yang dihantar, ketahui cara mengumpul dan menyahkod maklumat tentang codec yang disokong dan peranti lain kemampuan.

TL; DR:

• SBC - codec biasa
• Fon kepala mempunyai penyamaan sendiri dan pasca pemprosesan untuk setiap codec secara berasingan
• aptX tidak sebaik yang diiklankan
• LDAC memasarkan omong kosong
• Kualiti panggilan masih lemah
• Anda boleh membenamkan pengekod audio C ke dalam penyemak imbas anda dengan menyusunnya ke dalam WebAssembly melalui emscripten, dan ia tidak akan menjadi perlahan.

Muzik melalui Bluetooth

Komponen fungsi Bluetooth ditentukan oleh profil - spesifikasi fungsi tertentu. Penstriman muzik Bluetooth menggunakan profil penghantaran audio satu arah A2DP berkualiti tinggi. Piawaian A2DP telah diterima pakai pada tahun 2003 dan tidak berubah dengan ketara sejak itu.
Dalam profil, 1 codec wajib SBC kerumitan pengiraan rendah, dibuat khusus untuk Bluetooth dan 3 codec tambahan diseragamkan. Anda juga boleh menggunakan codec tanpa dokumen pelaksanaan anda sendiri.

Sehingga Jun 2019 kami dalam komik xkcd dengan 14 codec A2DP:

• SBC ← diseragamkan dalam A2DP, disokong oleh semua peranti
• MPEG-1/2 Layer 1/2/3 ← diseragamkan dalam A2DP: terkenal MP3, digunakan dalam TV digital MP2, dan tidak diketahui MP1
• MPEG-2/4 AAC ← diseragamkan dalam A2DP
• ATTRAC ← codec lama daripada Sony, diseragamkan dalam A2DP
• LDAC ← codec baharu daripada Sony
• aptX ← codec dari 1988
• aptXHD ← sama seperti aptX, hanya dengan pilihan pengekodan yang berbeza
• aptX Latensi Rendah ← codec yang sama sekali berbeza, tiada pelaksanaan perisian
• aptX Adaptif ← codec lain daripada Qualcomm
• Aliran Pantas ← codec pseudo, pengubahsuaian SBC dua arah
• HWA LHDC ← codec baharu daripada Huawei
• Samsung HD ← disokong oleh 2 peranti
• Samsung Boleh Skala ← disokong oleh 2 peranti
• Samsung UHQ-BT ← disokong oleh 3 peranti

Mengapa kami memerlukan codec sama sekali, anda bertanya, apabila Bluetooth mempunyai EDR, yang membolehkan anda memindahkan data pada kelajuan 2 dan 3 Mbit/s, dan untuk PCM 16-bit dua saluran yang tidak dimampatkan, 1.4 Mbit/s sudah memadai?

Pemindahan data melalui Bluetooth

Terdapat dua jenis pemindahan data dalam Bluetooth: Asynchronous Connection Less (ACL) untuk pemindahan tak segerak tanpa penubuhan sambungan dan Synchronous Connection Oriented (SCO), untuk pemindahan segerak dengan rundingan sambungan awal.
Penghantaran dijalankan menggunakan skema pembahagian masa dan memilih saluran penghantaran untuk setiap paket secara berasingan (Frequency-Hop/Time-Division-Duplex, FH/TDD), yang mana masa dibahagikan kepada selang 625-mikrosaat dipanggil slot. Salah satu peranti menghantar dalam slot bernombor genap, satu lagi dalam slot bernombor ganjil. Paket yang dihantar boleh menduduki 1, 3 atau 5 slot, bergantung pada saiz data dan jenis penghantaran yang ditetapkan, dalam kes ini, penghantaran oleh satu peranti dijalankan dalam slot genap dan ganjil sehingga tamat penghantaran. Secara keseluruhan, sehingga 1600 paket boleh diterima dan dihantar sesaat, jika setiap satu daripada mereka menduduki 1 slot, dan kedua-dua peranti menghantar dan menerima sesuatu tanpa henti.

2 dan 3 Mbit/s untuk EDR, yang boleh didapati dalam pengumuman dan di tapak web Bluetooth, ialah kadar pemindahan saluran maksimum bagi semua data secara keseluruhan (termasuk pengepala teknikal semua protokol di mana data mesti dikapsulkan), dalam dua arah serentak. Kelajuan pemindahan data sebenar akan sangat berbeza.

Untuk menghantar muzik, kaedah tak segerak digunakan, hampir selalu menggunakan paket seperti 2-DH5 dan 3-DH5, yang membawa jumlah maksimum data dalam mod EDR masing-masing 2 Mbit/s dan 3 Mbit/s, dan menduduki 5 masa -slot perkongsian.

Perwakilan skematik penghantaran menggunakan 5 slot oleh satu peranti dan 1 slot oleh yang lain (DH5/DH1):


Disebabkan oleh prinsip pembahagian masa gelombang udara, kami terpaksa menunggu slot masa 625 mikrosaat selepas menghantar paket jika peranti kedua tidak menghantar apa-apa kepada kami atau menghantar paket kecil, dan lebih banyak masa jika peranti kedua menghantar dalam peket besar. Jika lebih daripada satu peranti disambungkan ke telefon (contohnya, fon kepala, jam tangan dan gelang kecergasan), maka masa pemindahan dikongsi antara kesemuanya.

Keperluan untuk merangkum audio dalam protokol pengangkutan khas L2CAP dan AVDTP mengambil masa 16 bait daripada jumlah maksimum muatan audio yang dihantar.

Jenis pakej
Bilangan slot
Maks. bilangan bait dalam paket
Maks. bilangan bait muatan A2DP
Maks. Kadar bit muatan A2DP

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 dan 1429 kbps pastinya tidak mencukupi untuk menghantar audio yang tidak dimampatkan dalam keadaan sebenar, dengan julat 2.4 GHz yang bising dan keperluan untuk menghantar data perkhidmatan. EDR 3 Mbit/s menuntut kuasa penghantaran dan hingar di udara, oleh itu, walaupun dalam mod 3-DH5, penghantaran PCM yang selesa adalah mustahil, akan sentiasa ada gangguan jangka pendek, dan semuanya hanya akan berfungsi pada jarak satu beberapa meter.
Dalam amalan, walaupun aliran audio 990 kbit/s (LDAC 990 kbit/s) adalah sukar untuk dihantar.

Mari kembali kepada codec.

SBC

Codec diperlukan untuk semua peranti yang menyokong standard A2DP. Codec terbaik dan terburuk pada masa yang sama.

Kekerapan pensampelan
Kedalaman bit
Kadar bit
Sokongan pengekodan
Sokongan penyahkodan

16, 32, 44.1, 48 kHz
16 bit
10-1500 kbps
Semua peranti
Semua peranti

SBC ialah codec yang ringkas dan pantas dari segi pengiraan, dengan model psikoakustik primitif (hanya penutupan bunyi senyap digunakan), menggunakan modulasi kod nadi adaptif (APCM).
Spesifikasi A2DP mengesyorkan dua profil untuk digunakan: Kualiti Pertengahan dan Kualiti Tinggi.


Codec mempunyai banyak tetapan yang membolehkan anda mengawal kelewatan algoritma, bilangan sampel dalam blok, algoritma pengedaran bit, tetapi hampir di mana-mana parameter yang sama yang disyorkan dalam spesifikasi digunakan: Stereo Bersama, 8 jalur frekuensi, 16 blok dalam bingkai audio, kaedah pengedaran bit Loudness.
SBC menyokong perubahan dinamik parameter Bitpool, yang secara langsung mempengaruhi kadar bit. Jika gelombang udara tersumbat, paket hilang, atau peranti terletak pada jarak yang jauh, sumber audio mungkin mengurangkan Bitpool sehingga komunikasi kembali normal.

Kebanyakan pengeluar fon kepala menetapkan nilai Bitpool maksimum kepada 53, yang mengehadkan kadar bit kepada 328 kilobit sesaat apabila menggunakan profil yang disyorkan.
Walaupun pengeluar fon kepala telah menetapkan nilai Bitpool maksimum melebihi 53 (model sedemikian ditemui, contohnya: Beats Solo³, JBL Everest Elite 750NC, Apple AirPods, juga ditemui pada beberapa penerima dan unit kepala kereta), maka kebanyakan OS tidak akan membenarkan penggunaan kadar bit yang meningkat disebabkan oleh had nilai dalaman yang ditetapkan dalam tindanan Bluetooth.
Selain itu, sesetengah pengeluar menetapkan nilai Bitpool maksimum kepada rendah untuk sesetengah peranti. Contohnya, untuk Bluedio T ialah 39, untuk Samsung Gear IconX ialah 37, yang memberikan kualiti bunyi yang lemah.

Sekatan buatan di pihak pembangun tindanan Bluetooth kemungkinan besar timbul disebabkan ketidakserasian sesetengah peranti dengan nilai Bitpool yang besar atau profil atipikal, walaupun mereka melaporkan sokongan untuknya, dan ujian yang tidak mencukupi semasa pensijilan. Adalah lebih mudah bagi pengarang tindanan Bluetooth untuk mengehadkan diri mereka untuk bersetuju dengan profil yang disyorkan, daripada mencipta pangkalan data peranti yang salah (walaupun kini mereka melakukan ini untuk fungsi lain yang berfungsi dengan tidak betul).

SBC memperuntukkan bit pengkuantitian secara dinamik kepada jalur frekuensi pada asas rendah ke tinggi, dengan berat yang berbeza. Jika semua kadar bit digunakan untuk frekuensi rendah dan pertengahan, frekuensi tinggi akan "diputuskan" (sebaliknya akan ada senyap).

Contoh SBC 328 kbps. Di bahagian atas ialah yang asal, di bahagian bawah ialah SBC, secara berkala bertukar antara trek. Audio dalam fail video menggunakan codec mampatan tanpa kehilangan FLAC. Menggunakan FLAC dalam bekas mp4 tidak diseragamkan secara rasmi, jadi ia tidak dijamin bahawa penyemak imbas anda akan memainkannya, tetapi ia harus berfungsi dalam versi terkini desktop Chrome dan Firefox. Jika anda tidak mempunyai bunyi, anda boleh memuat turun fail dan membukanya dalam pemain video sepenuhnya.
ZZ Top - Lelaki Berpakaian Tajam

Spektrogram menunjukkan detik pensuisan: SBC secara berkala memotong bunyi senyap melebihi 17.5 kHz, dan tidak memperuntukkan sebarang bit sama sekali untuk jalur melebihi 20 kHz. Spektrogram penuh tersedia dengan mengklik (1.7 MB).

Saya tidak mendengar apa-apa perbezaan antara yang asal dan SBC pada trek ini.

Mari ambil sesuatu yang lebih baharu dan simulasikan audio yang akan diperoleh menggunakan fon kepala Samsung Gear IconX dengan Bitpool 37 (di atas - isyarat asal, di bawah - SBC 239 kbps, audio dalam FLAC).
Kemanjaan Diri Tanpa Fikiran - Saksikan

Saya mendengar bunyi berderak, kurang kesan stereo dan bunyi "klunking" yang tidak menyenangkan dalam vokal berfrekuensi tinggi.

Walaupun SBC ialah codec yang sangat fleksibel, ia boleh dikonfigurasikan untuk kependaman rendah, memberikan kualiti audio yang sangat baik pada kadar bit tinggi (452+ kbps) dan agak baik untuk kebanyakan orang pada Kualiti Tinggi standard (328 kbps), disebabkan oleh fakta bahawa standard A2DP tidak menyatakan profil tetap (tetapi hanya memberikan cadangan), pembangun tindanan telah menetapkan sekatan buatan pada Bitpool, parameter audio yang dihantar tidak dipaparkan dalam antara muka pengguna, dan pengeluar fon kepala bebas untuk menetapkan tetapan mereka sendiri dan tidak sekali-kali menunjukkan nilai Bitpool dalam spesifikasi teknikal produk, codec menjadi terkenal dengan kualiti bunyi yang rendah, walaupun ini bukan masalah dengan codec seperti itu.
Parameter Bitpool secara langsung mempengaruhi kadar bit hanya dalam satu profil. Nilai Bitpool 53 yang sama boleh memberikan kedua-dua kadar bit 328 kbps dengan profil Kualiti Tinggi yang disyorkan dan 1212 kbps dengan Saluran Dwi dan 4 jalur frekuensi, itulah sebabnya pengarang OS, sebagai tambahan kepada sekatan pada Bitpool, menetapkan had dan pada Kadar bit. Seperti yang saya lihat, keadaan ini timbul disebabkan oleh kecacatan dalam piawaian A2DP: adalah perlu untuk merundingkan kadar bit, bukan Bitpool.

Jadual sokongan untuk keupayaan SBC dalam OS yang berbeza:

OS
Kadar pensampelan yang disokong
Hadkan maks. Bitpool
Hadkan maks. Kadar bit
Kadar Bit Biasa
Pelarasan dinamik Bitpool

Windows 10
44.1 кГц
53
512 kbps
328 kbps
✓*

Linux (BlueZ + PulseAudio)
16, 32, 44.1, 48 kHz
64 (untuk sambungan masuk), 53 (untuk sambungan keluar)
Tiada had
328 kbps
✓*

macOS High Sierra
44.1 кГц
64, lalai 53***
Tidak diketahui
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
✗

OS Blackberry 10
48 кГц
53
Tiada had
328 kbps
✗

* Bitpool hanya berkurangan, tetapi tidak meningkat secara automatik, jika keadaan pemindahan bertambah baik. Untuk memulihkan Bitpool anda perlu menghentikan main balik, tunggu beberapa saat dan mulakan audio semula.
** Nilai lalai bergantung pada tetapan tindanan yang ditentukan semasa menyusun perisian tegar. Dalam Android 8/8.1 kekerapan hanya sama ada 44.1 kHz atau 48 kHz, bergantung pada tetapan semasa penyusunan, dalam versi lain 44.1 kHz dan 48 kHz disokong serentak.
*** Nilai Bitpool boleh ditingkatkan dalam program Bluetooth Explorer.

aptX dan aptX HD

aptX ialah codec yang ringkas dan pantas dari segi pengiraan, tanpa psikoakustik, menggunakan modulasi kod nadi pembezaan adaptif (ADPCM). Muncul sekitar 1988 (tarikh pemfailan paten bertarikh Februari 1988), sebelum Bluetooth, ia digunakan terutamanya dalam peralatan audio wayarles profesional. Pada masa ini dimiliki oleh Qualcomm, memerlukan pelesenan dan royalti. Sehingga 2014: $6000 sekali dan ≈$1 setiap peranti, untuk kelompok sehingga 10000 peranti (sumber, ms 16).
aptX dan aptX HD adalah codec yang sama, dengan profil pengekodan yang berbeza.

Codec hanya mempunyai satu parameter - memilih kekerapan pensampelan. Walau bagaimanapun, terdapat pilihan nombor/mod saluran, tetapi dalam semua peranti yang saya ketahui (70+ keping) hanya Stereo disokong.

codec
Kekerapan pensampelan
Kedalaman bit
Kadar bit
Sokongan pengekodan
Sokongan penyahkodan

aptX
16, 32, 44.1, 48 kHz
16 bit
128 / 256 / 352 / 384 kbps (bergantung pada kadar pensampelan)
Windows 10 (desktop dan mudah alih), macOS, Android 4.4+/7*, Blackberry OS 10
Pelbagai peranti audio (perkakasan)

* Versi sehingga 7 memerlukan pengubahsuaian tindanan Bluetooth. Codec hanya disokong jika pengeluar peranti Android telah melesenkan codec daripada Qualcomm (jika OS mempunyai perpustakaan pengekodan).

aptX membahagikan audio kepada 4 jalur frekuensi dan mengukurnya dengan bilangan bit yang sama sentiasa: 8 bit untuk 0-5.5 kHz, 4 bit untuk 5.5-11 kHz, 2 bit untuk 11-16.5 kHz, 2 bit untuk 16.5-22 kHz ( angka untuk kadar persampelan 44.1 kHz).

Contoh audio aptX (di bahagian atas - isyarat asal, di bahagian bawah - aptX, spektrogram saluran kiri sahaja, bunyi dalam FLAC):

Puncak menjadi lebih merah sedikit, tetapi anda tidak dapat mendengar perbezaannya.

Disebabkan oleh pengedaran tetap bit pengkuantitian, codec tidak boleh "mengalih bit" kepada frekuensi yang paling memerlukannya. Tidak seperti SBC, aptX tidak akan "memotong" frekuensi, tetapi akan menambah hingar kuantisasi padanya, mengurangkan julat dinamik audio.

Ia tidak boleh diandaikan bahawa menggunakan, sebagai contoh, 2 bit setiap jalur mengurangkan julat dinamik kepada 12 dB: ADPCM membenarkan sehingga 96 dB julat dinamik walaupun apabila menggunakan 2 bit kuantisasi, tetapi hanya untuk isyarat tertentu.
ADPCM menyimpan perbezaan berangka antara sampel semasa dan sampel seterusnya, bukannya menyimpan nilai mutlak seperti dalam PCM. Ini membolehkan anda mengurangkan keperluan untuk bilangan bit yang diperlukan untuk menyimpan maklumat yang sama (tanpa kehilangan) atau hampir sama (dengan ralat pembundaran yang agak kecil). Untuk mengurangkan ralat pembundaran, jadual pekali digunakan.
Semasa mencipta codec, pengarang mengira pekali ADPCM pada set fail audio muzik. Semakin dekat isyarat audio dengan set muzik di mana jadual dibina, semakin sedikit ralat pengkuantitian (bunyi) yang dihasilkan aptX.

Oleh sebab itu, ujian sintetik akan sentiasa menghasilkan keputusan yang lebih teruk daripada muzik. Saya membuat contoh sintetik khas di mana aptX menunjukkan hasil yang buruk - gelombang sinus dengan frekuensi 12.4 kHz (di atas - isyarat asal, di bawah - aptX. Audio dalam FLAC. Kurangkan volum!):

Graf spektrum:


Bunyi bising jelas kedengaran.

Walau bagaimanapun, jika anda menjana gelombang sinus dengan amplitud yang lebih kecil supaya lebih senyap, hingar juga akan menjadi lebih senyap, menunjukkan julat dinamik yang luas:

Untuk mendengar perbezaan antara trek muzik asal dan yang dimampatkan, anda boleh menyongsangkan salah satu isyarat dan menambah saluran trek mengikut saluran. Pendekatan ini, secara umum, tidak betul, dan tidak akan memberikan hasil yang waras dengan codec yang lebih kompleks, tetapi khusus untuk ADPCM ia agak sesuai.
Perbezaan antara asal dan aptX
Perbezaan purata kuasa dua akar bagi isyarat adalah pada tahap -37.4 dB, yang tidak banyak untuk muzik mampat tersebut.

aptXHD

aptX HD bukan codec kendiri - ia adalah profil pengekodan yang dipertingkatkan bagi codec aptX. Perubahan mempengaruhi bilangan bit yang diperuntukkan untuk julat frekuensi pengekodan: 10 bit untuk 0-5.5 kHz, 6 bit untuk 5.5-11 kHz, 4 bit untuk 11-16.5 kHz, 4 bit untuk 16.5-22 kHz (digit untuk 44.1 kHz) .

codec
Kekerapan pensampelan
Kedalaman bit
Kadar bit
Sokongan pengekodan
Sokongan penyahkodan

aptXHD
16, 32, 44.1, 48 kHz
24 bit
192 / 384 / 529 / 576 kbps (bergantung pada kadar pensampelan)
Android 8+*
Sesetengah peranti audio (perkakasan)

* Versi sehingga 7 memerlukan pengubahsuaian tindanan Bluetooth. Codec hanya disokong jika pengeluar peranti Android telah melesenkan codec daripada Qualcomm (jika OS mempunyai perpustakaan pengekodan).

Kurang biasa daripada aptX: nampaknya memerlukan pelesenan berasingan daripada Qualcomm dan yuran lesen yang berasingan.

Mari kita ulangi contoh dengan gelombang sinus pada 12.4 kHz:


Jauh lebih baik daripada aptX, tetapi masih agak bising.

aptX Latensi Rendah

Codec daripada Qualcomm yang tidak mempunyai persamaan dengan aptX standard dan aptX HD, berdasarkan maklumat terhad daripada orang yang terlibat dalam pembangunannya. Direka untuk penghantaran audio kependaman rendah interaktif (filem, permainan), di mana kelewatan audio tidak boleh dilaraskan oleh perisian. Tiada pelaksanaan perisian yang diketahui bagi pengekod dan penyahkod; ia disokong secara eksklusif oleh pemancar, penerima, fon kepala dan pembesar suara, tetapi bukan oleh telefon pintar dan komputer.

Kekerapan pensampelan
Kadar bit
Sokongan pengekodan
Sokongan penyahkodan

44.1 кГц
276/420 kbps
Beberapa pemancar (perkakasan)
Sesetengah peranti audio (perkakasan)

AAC

AAC, atau Pengekodan Audio Lanjutan, ialah codec kompleks dari segi pengiraan dengan model psikoakustik yang serius. Digunakan secara meluas untuk audio di Internet, popular kedua selepas MP3. Memerlukan pelesenan dan royalti: $15000 sekali (atau $1000 untuk syarikat yang mempunyai kurang daripada 15 pekerja) + $0.98 untuk 500000 peranti pertama (sumber).
Codec diseragamkan dalam spesifikasi MPEG-2 dan MPEG-4, dan bertentangan dengan salah tanggapan biasa, ia bukan milik Apple.

Kekerapan pensampelan
Kadar bit
Sokongan pengekodan
Sokongan penyahkodan

8 - 96 kHz
8 - 576 kbps (untuk stereo), 256 - 320 kbps (biasa untuk Bluetooth)
macOS, Android 7+*, iOS
Pelbagai peranti audio (perkakasan)

* hanya pada peranti yang pengeluarnya telah membayar yuran pelesenan

iOS dan macOS menggunakan pengekod AAC terbaik semasa Apple untuk menyampaikan kualiti audio setinggi mungkin. Android menggunakan pengekod Fraunhofer FDK AAC kualiti kedua tertinggi, tetapi mungkin menggunakan pelbagai perkakasan terbina dalam platform (SoC) dengan kualiti pengekodan yang tidak diketahui. Mengikut ujian terkini di laman web SoundGuys, kualiti pengekodan AAC bagi telefon Android berbeza sangat berbeza:

Kebanyakan peranti audio wayarles mempunyai kadar bit maksimum 320 kbps untuk AAC, sesetengahnya hanya menyokong 256 kbps. Kadar bit lain sangat jarang berlaku.
AAC memberikan kualiti yang sangat baik pada kadar bit 320 dan 256 kbps, tetapi tertakluk kepada kehilangan pengekodan berurutan bagi kandungan yang telah dimampatkan, bagaimanapun, adalah sukar untuk mendengar sebarang perbezaan dengan yang asal pada iOS pada kadar bit 256 kbps walaupun dengan beberapa pengekodan berjujukan; dengan pengekodan tunggal, contohnya, MP3 320 kbps hingga AAC 256 kbps, kerugian boleh diabaikan.
Seperti codec Bluetooth lain, mana-mana muzik pertama kali dinyahkod dan kemudian dikodkan oleh codec. Apabila mendengar muzik dalam format AAC, ia pertama kali dinyahkod oleh OS, kemudian dikodkan ke dalam AAC sekali lagi untuk penghantaran melalui Bluetooth. Ini diperlukan untuk mencampurkan berbilang strim audio, seperti muzik dan pemberitahuan mesej baharu. iOS tidak terkecuali. Di Internet anda boleh menemui banyak kenyataan bahawa pada muzik iOS dalam format AAC tidak ditranskodkan apabila dihantar melalui Bluetooth, yang tidak benar.

MP1/2/3

Codec bagi keluarga MPEG-1/2 Part 3 terdiri daripada MP3 yang terkenal dan digunakan secara meluas, MP2 yang kurang biasa (digunakan terutamanya dalam TV digital dan radio), dan MP1 yang tidak diketahui sepenuhnya.

Codec MP1 dan MP2 lama tidak disokong sama sekali: Saya tidak menemui sebarang fon kepala atau tindanan Bluetooth yang akan mengekod atau menyahkodnya.
Penyahkodan MP3 disokong oleh beberapa fon kepala, tetapi pengekodan tidak disokong pada mana-mana susunan sistem pengendalian moden. Nampaknya timbunan BlueSoleil pihak ketiga untuk Windows boleh mengekod ke MP3 jika anda menukar fail konfigurasi secara manual, tetapi bagi saya memasangnya membawa kepada BSoD pada Windows 10. Kesimpulan - codec sebenarnya tidak boleh digunakan untuk audio Bluetooth.
Sebelum ini, pada 2006-2008, sebelum penyebaran standard A2DP dalam peranti, orang ramai mendengar muzik MP3 pada set kepala Nokia BH-501 melalui program MSI BluePlayer, yang tersedia di Symbian dan Windows Mobile. Pada masa itu, seni bina OS telefon pintar membenarkan akses kepada banyak fungsi peringkat rendah, dan pada Windows Mobile ia juga mungkin untuk memasang tindanan Bluetooth pihak ketiga.

Paten terakhir codec MP3 telah tamat tempoh, penggunaan codec tidak memerlukan yuran pelesenan sejak 23 April 2017.

Jika paten paling lama berjalan yang disebut dalam rujukan yang disebutkan di atas diambil sebagai ukuran, maka teknologi MP3 menjadi bebas paten di Amerika Syarikat pada 16 April 2017 apabila Paten AS 6,009,399, yang dipegang oleh dan ditadbir oleh Technicolor, tamat tempoh.

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

Kekerapan pensampelan
Kadar bit
Sokongan pengekodan
Sokongan penyahkodan

16 - 48 kHz
8 - 320 kbps
Tidak disokong di mana-mana sahaja
Sesetengah peranti audio (perkakasan)

LDAC

Codec "Hi-Res" baharu dan dipromosikan secara aktif daripada Sony, menyokong kadar pensampelan sehingga 96 kHz dan 24-bit, dengan kadar bit sehingga 990 kbps. Ia diiklankan sebagai codec audiophile, sebagai pengganti codec Bluetooth sedia ada. Ia mempunyai fungsi pelarasan bitrate adaptif, bergantung pada keadaan siaran radio.

pengekod LDAC (libldac) disertakan dalam pakej Android standard, jadi pengekodan disokong pada mana-mana telefon pintar Android bermula dengan OS versi 8. Tiada penyahkod perisian yang tersedia secara percuma, spesifikasi codec tidak tersedia untuk orang awam, namun, pada pandangan pertama pada pengekod, struktur dalaman codec adalah serupa dengan ATRAC9 - Codec Sony yang digunakan dalam PlayStation 4 dan Vita: kedua-duanya berfungsi dalam domain frekuensi, menggunakan transformasi kosinus diskret (MDCT) dan pemampatan yang diubah suai menggunakan algoritma Huffman.

Sokongan LDAC disediakan hampir secara eksklusif oleh fon kepala daripada Sony. Keupayaan untuk menyahkod LDAC kadangkala ditemui pada fon kepala dan DAC daripada pengeluar lain, tetapi sangat jarang.

Kekerapan pensampelan
Kadar bit
Sokongan pengekodan
Sokongan penyahkodan

44.1 - 96 kHz
303/606/909 kbit/s (untuk 44.1 dan 88.2 kHz), 330/660/990 kbit/s (untuk 48 dan 96 kHz)
Android 8 +
Beberapa fon kepala Sony dan beberapa peranti daripada pengeluar lain (perkakasan)

Memasarkan LDAC sebagai codec Hi-Res memudaratkan komponen teknikalnya: adalah bodoh untuk membelanjakan kadar bit untuk menghantar frekuensi yang tidak dapat didengari ke telinga manusia dan meningkatkan kedalaman bit, manakala ia tidak mencukupi untuk menghantar kualiti CD (44.1/16) tanpa kehilangan . Nasib baik, codec mempunyai dua mod operasi: penghantaran audio CD dan penghantaran audio Hi-Res. Dalam kes pertama, hanya 44.1 kHz/16 bit dihantar melalui udara.

Memandangkan penyahkod LDAC perisian tidak tersedia secara bebas, adalah mustahil untuk menguji codec tanpa peranti tambahan yang menyahkod LDAC. Menurut keputusan ujian LDAC pada DAC dengan sokongannya, yang disambungkan oleh jurutera SoundGuys.com melalui output digital dan merekodkan bunyi output pada isyarat ujian, LDAC 660 dan 990 kbps dalam mod kualiti CD menyediakan isyarat-ke- nisbah hingar lebih baik sedikit daripada aptX HD.

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

LDAC juga menyokong kadar bit dinamik di luar profil yang ditetapkan - daripada 138 kbps hingga 990 kbps, tetapi setakat yang saya tahu, Android hanya menggunakan profil piawai 303/606/909 dan 330/660/990 kbps.

Codec lain

Codec A2DP lain tidak digunakan secara meluas. Sokongan mereka sama ada hampir tiada sepenuhnya atau hanya tersedia pada model fon kepala dan telefon pintar tertentu.
Codec ATRAC yang diseragamkan dalam A2DP tidak pernah digunakan sebagai codec Bluetooth walaupun oleh Sony sendiri, codec Samsung HD, Samsung Scalable dan Samsung UHQ-BT mempunyai sokongan yang sangat terhad daripada menghantar dan menerima peranti, dan HWA LHDC terlalu baharu dan hanya menyokong tiga (?) peranti.

Sokongan codec untuk peranti audio

Tidak semua pengeluar menerbitkan maklumat tepat tentang codec yang disokong oleh fon kepala wayarles, pembesar suara, penerima atau pemancar tertentu. Kadang-kadang ia berlaku bahawa sokongan untuk codec tertentu hanya untuk penghantaran, tetapi bukan untuk penerimaan (berkaitan untuk gabungan pemancar-penerima), walaupun pengilang hanya mengisytiharkan "sokongan", tanpa nota (saya menganggap bahawa pelesenan berasingan pengekod dan penyahkod beberapa codec harus dipersalahkan untuk ini). Dalam peranti termurah, anda mungkin tidak menemui sokongan aptX yang diisytiharkan sama sekali.

Malangnya, antara muka kebanyakan sistem pengendalian tidak memaparkan codec yang digunakan di mana-mana sahaja. Maklumat tentang perkara ini hanya tersedia dalam Android, bermula dari versi 8 dan macOS. Walau bagaimanapun, walaupun dalam OS ini, hanya codec yang disokong oleh kedua-dua telefon/komputer dan fon kepala akan dipaparkan.

Bagaimanakah anda boleh mengetahui codec yang disokong oleh peranti anda? Merekod dan menganalisis pembuangan trafik dengan parameter rundingan A2DP!
Ini boleh dilakukan pada Linux, macOS dan Android. Di Linux anda boleh menggunakan Wireshark atau hcidump, pada macOS anda boleh menggunakan Bluetooth Explorer, dan pada Android anda boleh menggunakan fungsi penjimatan buangan HCI Bluetooth standard, yang tersedia dalam alat pembangun. Anda akan menerima pembuangan dalam format btsnoop, yang boleh dimuatkan ke dalam penganalisis Wireshark.
Perhatikan: longgokan yang betul hanya boleh diperoleh dengan menyambung dari telefon/komputer anda ke fon kepala/pembesar suara (tidak kira betapa lucunya bunyi itu)! Fon kepala boleh secara bebas mewujudkan sambungan dengan telefon, dalam hal ini mereka akan meminta senarai codec daripada telefon, dan bukan sebaliknya. Untuk memastikan pembuangan yang betul dirakam, mula-mula nyahgandingkan peranti dan kemudian pasangkan telefon anda dengan fon kepala semasa merakam pembuangan itu.

Gunakan penapis paparan berikut untuk menapis trafik yang tidak berkaitan:

btavdtp.signal_id

Akibatnya, anda akan melihat sesuatu yang serupa dengan ini:

Anda boleh mengklik pada setiap item dalam arahan GetCapabilities untuk melihat ciri terperinci codec.

Wireshark tidak mengetahui semua pengecam codec, jadi sesetengah codec perlu dinyahsulit secara manual, melihat jadual pengecam di bawah:

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

Untuk tidak menganalisis pembuangan secara manual, saya membuat perkhidmatan yang akan menganalisis segala-galanya secara automatik: btcodecs.valdikss.org.ru

Perbandingan codec. Codec mana yang lebih baik?

Setiap codec mempunyai kelebihan dan kekurangannya sendiri.
aptX dan aptX HD menggunakan profil berkod keras yang tidak boleh ditukar tanpa mengubah pengekod dan penyahkod. Baik pengeluar telefon mahupun pengeluar fon kepala tidak boleh menukar faktor pengekodan kadar bit atau aptX. Pemilik codec, Qualcomm, menyediakan pengekod rujukan dalam bentuk perpustakaan. Fakta ini adalah kekuatan aptX - anda tahu terlebih dahulu kualiti bunyi yang anda akan dapat, tanpa sebarang "tetapi".

Sebaliknya, SBC mempunyai banyak parameter boleh dikonfigurasikan, kadar bit dinamik (pengekod boleh mengurangkan parameter bitpool jika gelombang udara sibuk), dan tidak mempunyai profil berkod keras, hanya "kualiti sederhana" dan "kualiti tinggi" yang disyorkan yang ditambah kepada spesifikasi A2DP pada tahun 2003. "Kualiti tinggi" tidak lagi setinggi itu mengikut piawaian hari ini, dan kebanyakan tindanan Bluetooth tidak membenarkan anda menggunakan parameter lebih baik daripada profil "kualiti tinggi", walaupun tiada sekatan teknikal untuk ini.
Bluetooth SIG tidak mempunyai pengekod SBC rujukan sebagai perpustakaan, dan pengilang melaksanakannya sendiri.
Ini adalah kelemahan SBC - tidak pernah jelas terlebih dahulu kualiti bunyi yang diharapkan daripada peranti tertentu. SBC boleh menghasilkan kedua-dua audio berkualiti rendah dan sangat tinggi, tetapi yang kedua tidak dapat dicapai tanpa melumpuhkan atau memintas pengehadan tiruan tindanan Bluetooth.

Situasi dengan AAC adalah samar-samar: di satu pihak, secara teorinya codec harus menghasilkan kualiti yang tidak dapat dibezakan daripada yang asal, tetapi dalam amalan, berdasarkan ujian makmal SoundGuys pada peranti Android yang berbeza, ini tidak disahkan. Kemungkinan besar, kesalahan terletak pada pengekod audio perkakasan berkualiti rendah yang dibina ke dalam pelbagai set cip telefon. Adalah wajar untuk menggunakan AAC hanya pada peranti Apple dan pada Android untuk mengehadkannya kepada aptX dan LDAC.

Perkakasan yang menyokong codec alternatif cenderung berkualiti tinggi, semata-mata kerana untuk peranti yang sangat murah dan berkualiti rendah, adalah tidak masuk akal untuk membayar yuran pelesenan untuk menggunakan codec tersebut. Dalam ujian saya, SBC berbunyi sangat baik pada peralatan berkualiti.

Saya membuat perkhidmatan web yang mengekod audio kepada SBC, aptX dan aptX HD dalam masa nyata, terus dalam penyemak imbas. Dengan itu, anda boleh menguji codec audio ini tanpa benar-benar menghantar audio melalui Bluetooth, pada mana-mana fon kepala berwayar, pembesar suara dan muzik kegemaran anda, dan juga menukar parameter pengekodan secara langsung semasa memainkan audio:
btcodecs.valdikss.org.ru/sbc-encoder
Perkhidmatan ini menggunakan perpustakaan pengekodan SBC daripada projek BlueZ dan libopenaptx daripada ffmpeg, yang disusun ke dalam WebAssembly dan JavaScript daripada C, melalui emscripten, untuk dijalankan dalam penyemak imbas. Siapa yang boleh mengimpikan masa depan sedemikian!

Inilah yang kelihatan seperti:

Perhatikan bagaimana tahap hingar berubah selepas 20 kHz untuk codec yang berbeza. Fail MP3 asal tidak mengandungi frekuensi melebihi 20 kHz.

Cuba tukar codec dan lihat jika anda mendengar perbezaan antara yang asal, SBC 53 Joint Stereo (profil standard dan paling biasa) dan aptX/aptX HD.

Saya boleh mendengar perbezaan antara codec dalam fon kepala!

Orang yang tidak mendengar perbezaan antara codec semasa ujian melalui perkhidmatan web mendakwa bahawa mereka mendengarnya semasa mendengar muzik pada fon kepala wayarles. Malangnya, ini bukan jenaka atau kesan plasebo: perbezaannya benar-benar boleh didengar, tetapi ia bukan disebabkan oleh perbezaan codec.

Sebilangan besar set cip audio Bluetooth yang digunakan dalam peranti penerima wayarles dilengkapi dengan Pemproses Isyarat Digital (DSP), yang melaksanakan penyama, pemampat, pengembang stereo dan perkara lain yang direka untuk menambah baik (atau menukar) bunyi. Pengilang peralatan Bluetooth boleh mengkonfigurasi DSP untuk setiap codec secara berasingan, dan apabila bertukar antara codec, pendengar akan berfikir bahawa mereka mendengar perbezaan dalam pengendalian codec, sedangkan sebenarnya mereka mendengar tetapan DSP yang berbeza.

Saluran paip pemprosesan audio DSP Kalimba dalam cip yang dikeluarkan oleh CSR/Qualcomm

Aktifkan fungsi DSP yang berbeza untuk setiap codec dan output secara berasingan

Sesetengah peranti premium disertakan dengan perisian yang membolehkan anda menyesuaikan tetapan DSP, tetapi kebanyakan fon kepala yang lebih murah tidak, dan pengguna tidak boleh mematikan pemprosesan pasca audio secara manual.

Ciri fungsi peranti

Versi moden standard A2DP mempunyai Fungsi "kawalan kelantangan mutlak". — kawalan kelantangan peranti menggunakan arahan khas protokol AVRCP, yang mengawal perolehan peringkat output, dan bukannya mengurangkan kelantangan aliran audio secara pemrograman. Jika apabila anda menukar kelantangan pada fon kepala anda, perubahan itu tidak disegerakkan dengan kelantangan pada telefon anda, maka fon kepala atau telefon anda tidak menyokong ciri ini. Dalam kes ini, masuk akal untuk sentiasa mendengar muzik dengan kelantangan maksimum pada telefon, melaraskan kelantangan sebenar dengan butang fon kepala - dalam kes ini, nisbah isyarat-ke-bunyi akan menjadi lebih baik dan kualiti audio mestilah di atas.
Pada hakikatnya, terdapat situasi yang menyedihkan. Pada fon kepala RealForce OverDrive D1 saya untuk SBC, compander yang kuat dihidupkan dan meningkatkan kelantangan membawa kepada peningkatan dalam tahap bunyi senyap, manakala kelantangan bunyi yang kuat tidak berubah (isyarat dimampatkan). Disebabkan ini, anda perlu menetapkan kelantangan pada komputer kepada kira-kira separuh, dalam kes ini hampir tiada kesan mampatan.
Mengikut pemerhatian saya, semua fon kepala dengan codec tambahan menyokong fungsi kawalan volum mutlak, nampaknya ini adalah salah satu keperluan untuk pensijilan codec.

Sesetengah fon kepala menyokong menyambung dua peranti pada masa yang sama. Ini membolehkan anda, sebagai contoh, mendengar muzik dari komputer anda dan menerima panggilan daripada telefon anda. Walau bagaimanapun, anda harus sedar bahawa dalam mod ini codec alternatif dilumpuhkan dan hanya SBC digunakan.

AVDTP 1.3 Fungsi Pelaporan Kelewatan membenarkan fon kepala untuk menyampaikan kelewatan kepada peranti pemancar di mana bunyi sebenarnya dimainkan. Ini membolehkan anda melaraskan penyegerakan audio dengan video semasa melihat fail video: jika terdapat masalah dengan penghantaran radio, audio tidak akan ketinggalan di belakang video, tetapi sebaliknya, video akan diperlahankan oleh pemain video sehingga audio dan video disegerakkan semula.
Fungsi ini disokong oleh banyak fon kepala, Android 9+ dan Linux dengan PulseAudio 12.0+. Saya tidak mengetahui tentang sokongan untuk ciri ini pada platform lain.

Komunikasi dua arah melalui Bluetooth. Penghantaran suara.

Untuk menghantar suara dalam Bluetooth, Berorientasikan Sambungan Segerak (SCO) digunakan - penghantaran segerak dengan rundingan awal sambungan. Mod ini membolehkan anda menghantar bunyi dan suara dengan ketat mengikut urutan, dengan kelajuan penghantaran dan penerimaan simetri, tanpa menunggu pengesahan penghantaran dan penghantaran semula paket. Ini mengurangkan kelewatan keseluruhan penghantaran audio melalui saluran radio, tetapi mengenakan sekatan yang serius pada jumlah data yang dihantar setiap unit masa, dan menjejaskan kualiti secara negatif.
Apabila mod ini digunakan, kedua-dua suara dan audio dihantar dengan kualiti yang sama.
Malangnya, pada 2019, kualiti suara melalui Bluetooth masih lemah, dan tidak jelas mengapa Bluetooth SIG tidak melakukan apa-apa mengenainya.

CVSD

Codec suara asas CVSD telah diseragamkan pada tahun 2002, dan disokong oleh semua peranti komunikasi Bluetooth dua hala. Ia menyediakan penghantaran audio dengan frekuensi pensampelan 8 kHz, yang sepadan dengan kualiti telefon berwayar konvensional.

Contoh rakaman dalam codec ini.

mSBC

Codec mSBC tambahan telah diseragamkan pada tahun 2009, dan pada tahun 2010 cip menggunakannya untuk penghantaran suara telah muncul. mSBC disokong secara meluas oleh pelbagai peranti.
Ini bukan codec bebas, tetapi SBC biasa daripada standard A2DP, dengan profil pengekodan tetap: 16 kHz, mono, bitpool 26.

Contoh rakaman dalam codec ini.

Tidak cemerlang, tetapi jauh lebih baik daripada CVSD, tetapi ia masih menjengkelkan untuk digunakan untuk komunikasi dalam talian, terutamanya apabila anda menggunakan fon kepala untuk berkomunikasi dalam permainan - audio permainan juga akan dihantar pada kadar pensampelan 16 kHz.

Syarikat FastStreamCSR memutuskan untuk membangunkan idea menggunakan SBC. Untuk mengatasi had protokol SCO dan menggunakan kadar bit yang lebih tinggi, CSR menggunakan laluan yang berbeza - mereka memperkenalkan sokongan untuk audio SBC dua hala ke dalam standard penghantaran audio sehala A2DP, profil pengekodan piawai dan memanggilnya "FastStream".

FastStream menghantar audio stereo pada 44.1 atau 48 kHz dengan kadar bit 212 kbps ke pembesar suara, dan mono, 16 kHz, dengan kadar bit 72 kbps digunakan untuk menghantar audio daripada mikrofon (lebih baik sedikit daripada mSBC). Parameter sedemikian jauh lebih sesuai untuk komunikasi dalam permainan dalam talian - bunyi permainan dan lawan bicara akan berkualiti tinggi.

Contoh rakaman dalam codec ini (+ bunyi daripada mikrofon, sama seperti mSBC).

Syarikat itu menghasilkan tongkat yang menarik, tetapi disebabkan fakta bahawa ia bercanggah dengan piawaian A2DP, ia hanya disokong dalam beberapa pemancar syarikat (yang berfungsi sebagai kad audio USB, bukan peranti Bluetooth), tetapi ia tidak terima sokongan dalam tindanan Bluetooth. walaupun bilangan fon kepala dengan sokongan FastStream tidak begitu kecil.

Pada masa ini, sokongan FastStream dalam OS hanyalah sebagai tampalan untuk Linux PulseAudio daripada pemaju Pali Rohár, yang tidak termasuk dalam cabang utama program.

aptX Latensi Rendah

Amat mengejutkan anda, aptX Low Latency juga menyokong audio dwiarah, melaksanakan prinsip yang sama seperti FastStream.
Tidak mungkin menggunakan ciri codec ini di mana-mana sahaja - tiada sokongan untuk penyahkodan Kependaman Rendah dalam mana-mana OS atau dalam mana-mana tindanan Bluetooth yang saya ketahui.

Bluetooth 5, Klasik dan Tenaga Rendah

Terdapat banyak kekeliruan mengenai spesifikasi dan versi Bluetooth kerana kehadiran dua piawaian yang tidak serasi di bawah jenama yang sama, kedua-duanya digunakan secara meluas untuk tujuan yang berbeza.

Terdapat dua protokol Bluetooth yang berbeza dan tidak serasi: Bluetooth Klasik dan Bluetooth Tenaga Rendah (LE, juga dikenali sebagai Bluetooth Smart). Terdapat juga protokol ketiga, Bluetooth Berkelajuan Tinggi, tetapi ia tidak meluas dan tidak digunakan dalam peranti rumah.

Bermula dengan Bluetooth 4.0, perubahan dalam spesifikasi berkenaan terutamanya Bluetooth Tenaga Rendah, dan versi Klasik hanya menerima peningkatan kecil.

Senarai perubahan antara Bluetooth 4.2 dan Bluetooth 5:

9 PERUBAHAN DARI v4.2 KE 5.0

9.1 CIRI-CIRI BARU

Beberapa ciri baharu diperkenalkan dalam Keluaran Bluetooth Core Specification 5.0. Bidang penambahbaikan utama ialah:
• Topeng Ketersediaan Slot (SAM)
• 2 Msym/s PHY untuk LE
•Jarak Jauh LE
• Pengiklanan Tidak Boleh Disambungkan Kitaran Tugas Tinggi
• Sambungan Pengiklanan LE
• Algoritma Pemilihan Saluran LE #2
9.1.1 Ciri Ditambah dalam CSA5 - Bersepadu dalam v5.0
•Kuasa Output yang Lebih Tinggi

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

Hanya satu perubahan yang mempengaruhi versi Klasik dalam rangka kerja spesifikasi Bluetooth 5: mereka menambah sokongan untuk teknologi Topeng Ketersediaan Slot (SAM), yang direka bentuk untuk menambah baik pengasingan siaran radio. Semua perubahan lain hanya mempengaruhi Bluetooth LE (dan Kuasa Output Lebih Tinggi juga).

semua Peranti audio hanya menggunakan Bluetooth Klasik. Adalah mustahil untuk menyambungkan fon kepala dan pembesar suara melalui Bluetooth Tenaga Rendah: tiada standard untuk menghantar audio menggunakan LE. Piawaian A2DP, yang digunakan untuk menghantar audio berkualiti tinggi, hanya berfungsi melalui Bluetooth Klasik, dan tiada analog dalam LE.

Kesimpulan - membeli peranti audio dengan Bluetooth 5 hanya kerana versi baharu protokol adalah sia-sia. Bluetooth 4.0/4.1/4.2 dalam konteks penghantaran audio akan berfungsi sama.
Jika pengumuman fon kepala baharu menyebut julat operasi berganda dan penggunaan kuasa dikurangkan berkat Bluetooth 5, maka anda harus tahu bahawa mereka sama ada tidak memahaminya sendiri atau mengelirukan anda. Tidak hairanlah, kerana walaupun pengeluar cip Bluetooth dalam pengumuman mereka keliru tentang perbezaan antara versi baharu standard, dan beberapa cip Bluetooth 5 menyokong versi kelima hanya untuk LE, dan menggunakan 4.2 untuk Klasik.

Kelewatan penghantaran audio

Jumlah kelewatan (lag) dalam audio bergantung pada banyak faktor: saiz penimbal dalam tindanan audio, dalam tindanan Bluetooth dan dalam peranti main balik wayarles itu sendiri, dan kelewatan algoritma codec.

Kependaman codec ringkas seperti SBC, aptX dan aptX HD adalah sangat kecil, 3-6 ms, yang boleh diabaikan, tetapi codec kompleks seperti AAC dan LDAC boleh menyebabkan ketinggalan yang ketara. Kependaman algoritma AAC untuk 44.1 kHz ialah 60 ms. LDAC - kira-kira 30 ms (berdasarkan analisis kasar kod sumber. Saya mungkin silap, tetapi tidak banyak.)

Latensi yang terhasil sangat bergantung pada peranti main balik, set cip dan penimbalnya. Semasa ujian, saya menerima sebaran 150 hingga 250 ms pada peranti berbeza (dengan codec SBC). Jika kami menganggap bahawa peranti yang menyokong codec tambahan aptX, AAC dan LDAC menggunakan komponen berkualiti tinggi dan saiz penimbal yang kecil, kami mendapat latensi biasa berikut:

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

Biar saya ingatkan anda: Kependaman Rendah aptX tidak disokong dalam sistem pengendalian, itulah sebabnya kependaman yang lebih rendah hanya boleh diperoleh dengan gabungan pemancar+penerima atau pemancar+fon kepala/pembesar suara dan semua peranti mesti menyokong codec ini.

Isu peranti, pensijilan dan logo Bluetooth

Bagaimana untuk membezakan peranti audio berkualiti tinggi daripada kraf murah? Dalam penampilan, pertama sekali!

Untuk fon kepala, pembesar suara dan penerima Cina murah:

1. Perkataan "Bluetooth" tiada pada kotak dan peranti, "Wayarles" dan "BT" paling kerap digunakan
2. Logo Bluetooth tiada pada kotak atau peranti
3. Tiada LED berkelip biru

Ketiadaan elemen ini menunjukkan bahawa peranti itu belum diperakui, yang bermaksud ia berpotensi berkualiti rendah dan bermasalah. Contohnya, fon kepala Bluedio tidak diperakui Bluetooth dan tidak mematuhi spesifikasi A2DP sepenuhnya. Mereka tidak akan lulus pensijilan.

Mari kita pertimbangkan beberapa peranti dan kotak daripadanya:

Ini semua peranti yang tidak diperakui. Arahan mungkin mengandungi logo dan nama teknologi Bluetooth, tetapi perkara yang paling penting ialah ia ada pada kotak dan/atau peranti itu sendiri.

Jika fon kepala atau pembesar suara anda menyebut "Ze bluetooth dewise berjaya disambungkan", ini juga tidak menunjukkan kualitinya:

Kesimpulan

Bolehkah Bluetooth menggantikan fon kepala dan set kepala berwayar sepenuhnya? Ia mampu, tetapi pada kos kualiti panggilan yang lemah, peningkatan kependaman audio yang boleh menjengkelkan dalam permainan, dan pelbagai codec proprietari yang memerlukan yuran pelesenan dan meningkatkan kos akhir kedua-dua telefon pintar dan fon kepala.

Pemasaran codec alternatif adalah sangat kuat: aptX dan LDAC dipersembahkan sebagai pengganti yang telah lama ditunggu-tunggu untuk SBC "lapuk dan buruk", yang tidaklah seburuk yang orang fikirkan.

Ternyata, had tiruan tindanan Bluetooth pada kadar bit SBC boleh dipintas, supaya SBC tidak akan lebih rendah daripada aptX HD. Saya mengambil inisiatif ke tangan saya sendiri dan membuat tampalan untuk perisian tegar LineageOS: Kami mengubah suai tindanan Bluetooth untuk menambah baik bunyi pada fon kepala tanpa codec AAC, aptX dan LDAC

Maklumat lanjut boleh didapati di laman web Lelaki Bunyi и SoundExpert.

Bonus: Pengekod rujukan SBC, maklumat aliran bit A2DP dan fail ujian. Fail ini pernah disiarkan secara terbuka di tapak web Bluetooth, tetapi kini hanya tersedia kepada ahli Bluetooth SIG.

Sumber: www.habr.com