Vlákno názorů k článku Lepší zvuk přes Bluetooth na Linuxu díky kodeku LDAC od Ondřej Caletka - Pěkný článek, díky. Jen bych upozornil, že OGG...

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.

(minimálně u internetových rádií se mp3 používá, ale je pravda že pak má vysílaný zvuk celkem velké zpoždění)