Pěkný článek, díky. Jen bych upozornil, že OGG je formát kontejneru, nikoli komprese, ta se jmenuje Vorbis (nebo třeba Speex, nebo třeba Opus, nebo třeba FLAC).
Jinak si myslím, že by stálo za to vyzkoušet i kvalitu AAC v oné omezené, svobodné variantě v porovnání s SBC. Možná by to nakonec byla lepší varianta. Pokud sluchátka nejsou od Sony, asi kodek LDAC podporovat nebudou.
Co se týká latence, ne vždy to jde vyřešit zpomalením všeho okolo, třeba při hraní her by se to hráčům asi moc nelíbilo. Proto je asi špatný nápad používat kodek jako MP3, který má mnohem větší latenci než MP2 nebo AAC. Ze stejného důvodu se MP3 nikdy nepoužívá v TV a rozhasovém vysílání.
S OGG máš samozřejmě pravdu, ach ty kontejnery a kodeky :)
Jinak asi žádný kodek není univerzální a dobrý na všechno. LDAC je nejlepší, co se týče kvality zvuku. Při 990 kbps se dokážou dost přiblížit Hi-Res (24bit, 96 kHz), AptX (a jeho varianty) je zase nejlepší z pohledu výpočetní náročnosti, proto je víc rozšířený na levných sluchátkách. AAC má zase tu výhodu, že (hlavně na platformách od Applu) je v něm velké množství obsahu (iTunes, Apple Music), takže nutnost překódování úplně odpadá. Na hraní a hovory jsou tu potom ty AptX Low Latency a FastStream. Obě řešení, která jsem zmiňoval, už buď podporují nebo plánují podporovat přepínání kodeku za běhu, znamená to jen výpadek zvuku na 1-2s, takže v budoucnu bude moct člověk běžně používat LDAC a když si chce zahrát, tak si přepne třeba na FastStream.
Dneska většina zařízení zvládne v profilu A2DP maximální šířku pásma nějakých 720 kbps, Sony dokázalo nějakým trikem vykouzlit pro LDAC 990 kbps, ale Bluetooth 5 by mělo mít pro A2DP několikanásobně větší šířku pásma, takže teoreticky bude možné v budoucnu použít bezztrátový kodek i pro Hi-Res.
K tomu ne-překódování zdrojových AAC, byl bych dost překvapený, kdyby se to tak někde skutečně dělo.
Aspoň v Linuxu si nedokážu představit, že by třeba prohlížeč ve kterém běží YouTube posílal do PulseAudio rovnou AAC stream a ten ho beze změny předával rovnou do sluchátek. Nemyslím si ani, že by to tak mohlo fungovat kdekoli jinde, už třeba jen proto, že hudební přehrávače chtějí skladby mezi sebou prolínat, nebo třeba uplatňovat ekvalizér. Procesory jsou výkonné a takováto optimalizace by způsobila značné množství problémů.
Prekvapivo, je to mozne.
PulseAudio podporuje passthrough (https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Passthrough/), momentalne sice iba s A/V receivermi, ale API na to je a je len otazkou zaujmu a zdrojov, ci sa to v buducnosti rozsiri aj o dalsie rozhrania.
Ono to totiz vyuzivaju hlavne video prehravace, ked ma zdrojove medium stopu v AC3 alebo DTS, tak prehravac iba posunie bistream dalej po linke, nech si to dekoduje nieco dalej, co si mohol pouzivatel aj nejako nakonfigurovat (napr. pozna to topologiu reproduktorov, je zapnute DRC, apod).
Takze v principe v buducnosti nic nebrani tomu, aby si aplikacia dohodla kodek, aky chce dalej posuvat a dekodovala iba ako fallback.
Trik je v tom, že minimálně iOS (o MacOS nevím) posílá do sluchátek dva streamy: jeden multimediální a druhý se systémovými zvuky, k mixování dochází až ve sluchátkách po dekódování. Na multimédia používají AAC 265 kbps, což jim nechává dost pásma na další stream. O tom, co je jaký stream, dávají sluchátkům vědět přes signály, které jsou součástí standardu Bluetooth. Pokud tedy mají obsah, který můžou poslat rovnou v AAC, tak ho pošlou, zbytek můžou poslat druhým streamem. U mobilního systému to je jednoduché, tam typicky generuje zvuk jenom jedna multimediální aplikace, takže tam je to fakt jenom o mixování streamu z jednoho multimediálního zdroje a systémových zvuků. Samozřejmě pokud si uživatel na tom multimediálním zdroji zapne třeba ekvalizér, tak jim nezbyde nic jiného, než to dekódovat a zase kódovat, ale to je záležitost té aplikace, ta může systému zase předat jenom AAC a ten to rovnou posílá dál. Detaily jsou popsané zde: https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf
Samozřejmě tento přístup je mnohem hůře uplatnitelný u desktopového systému, kde jsou nároky na mixování vyšší. Navíc úspora výpočetního výkonu a energie tu hraje mnohem menší roli než na mobilu. I tam to popravdě dnes není zásadní problém.
Tohle se v tom dokumentu nepíše. Tam se píše, že se pomocí AVRCP signalizuje, zda zařízení přehrává hudbu, nebo notifikace a jak se má na základě toho chovat připojené příslušenství – tedy notifikace případně zamíchat například s poslechem rádia, při přehrávání hudby naopak rádio vypnout. Že by sluchátka uměla míchat dva streamy, to mi připadá příliš nepravděpodobné, zvláště s ohledem na širokou paletu BT sluchátek a jejich nízkým cenám.
Ale v tom případě to zařízení musí tak jako tak zvládat zpracovávat více zdrojů a mixovat je, proč by mu jinak iOS posílal informace o tom, o jaký typ streamu se jedná a jak s ním má naložit, jestli stopnout ten druhý nebo ho s ním promixovat.
Jinak AAC nepodporují kdejaká levná sluchátka. Ty mají většinou jenom SBC, maximálně AptX, u nich iOS posílá stream v SBC.
Já to chápu tak, že jde o případy, kdy mám třeba v autě puštěné třeba CD a zároveň spárovaný telefon. Teď telefon začne posílat audio a rádio by se mělo rozhodnout, jestli jde jen o nějaké cinknutí nebo informaci z navigace, nebo jestli jsem na telefonu začal přehrávat hudbu. V prvním případě je správným chováním ztišení CD a přimíchání zvuku z telefonu, v tom druhém by mělo dojít k zastavení přehrávání CD. V případech, kdy hraje hudba i notifikace z telefonu takhle informace podle mě není relevantní, přijde to už z telefonu smíchané. Ale možná to jen chápu špatně.
A nezáleží spíš na bluetooth profilu? Hudba by měla jít přes A2DP, telefonní hovor přes HFP, jak si to potom zařízení zpracuje je už na něm. Ale taky to možná jen chápu špatně... :-)
https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
Nejjednodušeji asi zprovozněním v článku uvedených patchů a následným připojením sluchátek a výpisu příkazu pactl list | grep a2dp_codec
.
Případně v Androidu, v podrobnostech o Bluetooth zařízení, je u připojeného zařízení přepínač „HD zvuk“ doplněný o název kodeku, který byl domluven, v mém případě je to AAC.
No on by ale uživatel spíš potřeboval tohle zjistit před nákupem... A tohle je bohužel problém, přesnost informací výrobců je bídná skoro u všech. Třeba Sony tak u 60ti procent BT sluchátek má na svém webu specifikace pěkně rozepsané (profily i kodeky), ale u zbytku ze záhadného důvodu ne. A to je Sony ještě dost nadprůměr. Informace u prodejců jseou ještě horší, dohledání na internetu v různých testech někdy vyjde, někdy ale ne.
Řešit to vrácením ve 14ti dnech je jak "u blbejch" a při nákupu nějakých atypů z Číny je to už vůbec mimo.
Bohužel tohle je u BT sluchátek velký problém a spíš se to pořád horší, AptX má totiž mračno variant :-(
Mám ještě jeden námět, co by se dalo v budoucnu v Linuxu implementovat: ovládání hlasitosti jako má Android.
Dnes když mám BT sluchátka připojená k počítači, mám ovládání hlasitosti v počítači, které mění úroveň signálu ještě před přenosovou kompresí. Sluchátka mají svoje vlastní tlačítka hlasitosti, které dokáží měnit hlasitost na straně sluchátek.
Když přitom připojím ta samá sluchátka k Androidu, telefon do nich začne pouštět audio v plné hlasitosti a při ovládání tlačítky jak na telefonu, tak i na sluchátkách, dochází k zeslabení signálu ve sluchátkách, se zpětnou vazbou na displeji telefonu.
Dekuji za podnetny clanek. Jsem pripojen k BT bednicce, co mam v byte, ale kdyz se snazim vypsat kodek, pres jaky mi tece audio, tak mi to nic nevypisuje:
$ pactl list | grep codec
Kdyz grepnu bluetooth, tak na vystupu vidim toto:
$ pactl list | grep bluetooth
Name: module-bluetooth-policy
module.description = "Policy module to make using bluetooth devices out-of-the-box easier"
Name: module-bluetooth-discover
bluetooth.protocol = "a2dp_sink"
device.bus = "bluetooth"
device.icon_name = "audio-headset-bluetooth"
device.bus = "bluetooth"
device.icon_name = "audio-headset-bluetooth"
device.bus = "bluetooth"
device.icon_name = "audio-headset-bluetooth"
Moje "avinfo" mi prijde nejake orezane (oproti verzi, co jsem nasel na netu - https://manpages.debian.org/wheezy/avinfo/avinfo.1), takze netusim co mu mam dat za parametry:
$ avinfo
avinfo - Audio/Video Info Tool ver 5.50
Usage:
avinfo [options] <remote address>
Muzu pozadat o radu ci nakopnuti spravnym smerem? Dekuji :]
PS: Nejde mi zformatovat vystup z prikazu "avinfo". Netusim co tam mam spatne a jak to opravit. Ale tagy \<code\> (bez lomitek) mi nezachovavaji odsazeni a ani vse do nich uvedu.