Bit-perfect audio s ext usb DAC.
Android: 5 min + 230 Kc pripadne nikdy (dle mobilu a vyrobce)
Windows: 15 minut (foobar2000, nebo deadBeef, Tidal)
Linux: 2 dny pokusu nahradit pulseaudio za pipewire, 3 dny studovani manualu alsa + pipewire a prochazeni manualu. Na konci je staticke nastaveni bitrate v alsa+pipewire, ale na vyhradni rezim to porad nema. Samotny DAC/DAP ma jako OS linux a USB audio je funkcni na prvni pokus bez nejakych driveru a konfiguraci (ale jen s default vzorkovanim a mixerem).
Obdobna nocni mura podpora BT sluchatek s LDAC/aptX via pulseshit a default mixer.
Dalsi "legrace" - vetsina window manager a aplikaci pro GUI si uklada do nastaveni absolutni cesty misto $HOME/.....
=====
Bit-perfect audio s ext usb DAC.
Android: 5 min + 230 Kc pripadne nikdy (dle mobilu a vyrobce)
Windows: 15 minut (foobar2000, nebo deadBeef, Tidal)
Linux: 2 dny pokusu nahradit pulseaudio za pipewire, 3 dny studovani manualu alsa + pipewire a prochazeni manualu. Na konci je staticke nastaveni bitrate v alsa+pipewire, ale na vyhradni rezim to porad nema.
=====
Pokud výhradním režimem myslíš Wasapi exclusive, pak téměř přímým ekvivalentem je vypnout danou zvukovku v PA/PW a použít přímý výstup do alsy (hw:cardname). Dokonce bych si tipnul, že u wasapi (exclusive) se alsou tehdy inspirovali, použili i termín "period", který se jinde nevyskytuje (aspoň jsem jej u jiného audio API neviděl). Vypnutí zvukovky je v PA triviální (PW jsem zatím nepoužíval) a od té chvíle není potřeba PA vůbec řešit, nikdy ji nebude blokovat.
Téměř přímým jsem řekl proto, že alsa neumí nastavit prioritu pro exclusive, takže když je hw:cardname jednou zabrané např. PA/PW, jiný proces to nemůže přerušit a vzít si ji pro sebe. Proto to úvodní vypnutí dané zvukovky v PA/PW.
Naopak bitperfect/low-level audio je IMO to nejlepší, co linux nabízí. Detailní informace o libovolné zvukovce, detailních parametrech USB zvukovky, informace o parametrech aktuálního streamu do driveru (rate, samplesize, buffer/period size, detaily xrunů), nic z toho ve windows neexistuje.
Diky moc, dam tomu reseni ciste s alsa jeste sanci.
Beru to hodnoceni spis jako problem v ovladani a UI. Mam ruzne Debian based distribuce doma i v praci, a u kazde je to nejak jinak a pritom porad z pohledu end-user IMO celkem obskurne resene.
Kdybych to mohl vybrat jednou provzdy primo jen v menu UI aplikace, kterou tu hudbu prehravam, byla by to znacka ideal.
Pokud ma clovek audio zarizeni vicero (ext DAP+DAC, ext DAC, interni karta, monitor s HDMI) a do toho jeste ruzny vystupni hw (bedny, BT a USB sluchatka), kam potrebuje dostat jednak mixer s promenlivou kvalitou (videokonferencni sw, bezny zvuk z browseru, zvuky UI a aplikaci typu calendar a e-mail) a druhak i HD audio k izolovanymu a kvalitnejsimu poslechu, pak se kolikrat po restartu nebo dist-upgrade v linux OS nestaci divit.
Mozna me to proste jednoho dne donuti upgradovat na drazsi externi DAP s poradnym zesilovacem, ktery ma podporu Tidal i Tidal offline, abych furt nemusel prepinat mezi ruznymi PC a hw prehravaci, a PC pak prestanu k poslechu pouzivat uplne a bez ohledu na ruzne OS.
Pokud máš více zařízení a vstupů a potřebuješ to různě mixovat, pak trochu nechápu ten požadavek na bit-perfection - to z principu nelze. Ale samozřejmě lze vyčlenit konkrétní zařízení a ta ponechat pro přímý přístup jedním klientem.
Přesně pro tyhle účely vzniklo pipewire (jakožto náhrada pulseaudia, které z mně neznámého důvodu nechtěli vyvíjet dál - že by to souviselo s jeho asociálním zakladatelem?). IMO už je PW dál než windows mixer (např. grafy) a ten odstup jenom poroste. PW už podporuje i překvapivé vychytávky, jako feedback pro async UAC2 v USB gadgetu (kdy se linuxové zařízení chová jako USB device - zvukovka). PW se začíná používat i v profesionálních embedded-linux zařízeních na malých armech se spoustu I/O audio rozhraní, mimo jiné protože s nízkou režií umí adaptivní resampling mezi master-clock rozhraními (o tom windows mixer nikdy ani neslyšel).
5. 1. 2025, 09:59 editováno autorem komentáře
Pro běžné používání jsem s PW také spokojený, přesně z důvodů, co píšete. S minimální dodatečnou konfigurací a řekněme standardními UAC zařízeními to chodí velmi dobře. Dynamicky to přepíná vzorkovací frekvence podle aplikace/klienta tak, že zdroj hraje v nativní frekvenci (a je bit perfect - resp. dopadované nulami v případě 16 bitů). Samozřejmě pokud těch klientů hraje víc najednou a musí to míchat zdroje z různými frekvencemi, pak to pricipálně nejde a resampluje to podle prvního klienta.
Relativně dobře fungují i emulační vrstvy PW pro PulseAudio ze starších klientů i JACK z DAW (Reaper, Mixbus), pokud člověk nepotřebuje vymačkat úplně nejlepší výkon s nejkratšími buffery (pak má smysl buď přímo ALSA, nebo dedikovaný JACK démon a hrát si prioritami).
Praktické problémy vidím v podstatě dva. První je ten, že celý ten subsystém má super složité nastavení, což je bohužel opět daň za určitou míru flexibility a kompatibility. Statické části (systémové šablony, uživatelské overridy), dynamické části přes session manager jako WirePlumber. Takže když se běžný uživatel dostane do potíží, a je potřeba dohledat řešení, případně udělat i nějakou manipulaci (např. rozdělení vícekanálové zvukovky na samostatná stereo zařízení), tak to může být spousty zkoušení a připadat úplně na palici. Zvlášť když se třeba nějakou volbu vrací nebo nuluje ta dynamická část.
Druhý problém pak je v tom, že tam byl posledních pár let poměrně dynamický vývoj, spousty věcí se přidávalo, bylo hodně fixů - jak obecných, tak v součinnosti s nějakými konkrétním HW, reagovalo to na změny ve věcech okolo BT atd. A tam to naráží klasicky na nějaký release cyklus u standardních distribucí. Pokud má někdo třeba Ubuntu LTS, starší Debian nebo klon RHEL, SUSE Leap atp. kvůli jiným činnostem, tak se to k němu ty upstream opravy hned nedostanou. PW je závislost pro bambilion dalších balíčků a jen tak to normální uživatel nevymění - není to jako nainstalovat poslední VLC z Flatpaku.
Vím sám, jak jsem řešil na stejném HW hromadu workaroundů se starým PW v RHEL9 a jak to chodí v podstatě out-of-box v rolling Tumbleweedu.
Ale to se samozřejmě netýká jen PW, to samé v bleděmodrém je třeba MESA, grafické karty a OpenGL, Vulkan atp.
Ad problém 1 - jj, je to velice složitý a flexibilní systém, který má z principu složité nastavení. Postupně vznikají klikátka, ale složité detailní nastavení vždy bude nějakým textovým popisem, třeba ten wireplumber. I když třeba https://github.com/dimtpap/coppwr je hodně low-level. Základní uživatel holt na kliknutí nedokáže rozpadnout mch zvukovku na stereo páry, to neudělá triviálně na žádném OS. Naopak ve windows si na opačném procesu vyláme zuby, když obyč. MCH zvukovku "osvícení" autoři WDM ovladačů nabízejí jako sadu stereo zařízení, které běžný playback SW neumí pospojovat pro MCH výstup (ale custom ASIO ovladač nabízí komplet jedno multikanálové zařízení).
Ad 2 - je to prostě nový infrastrukturní projekt, který se stále rychle rozvíjí. Není to koncová aplikace, kterou lze snadno nahradit jinou verzí. Pokud to někdo potřebuje, pak mu asi nezbývá než rolling-release distribuce. Opět nic pro začátečníka, ale s tím lze zatím sotva něco dělat. Nicméně výhled je dobrý, narozdíl od ostatních OS, kde se defakto nic nepřidává (win ani OSX nemají v základu aní hloupý loopback pro spojení dvou aplikací).
5. 1. 2025, 13:33 editováno autorem komentáře
Ano souhlas, já to ani nezmiňoval jako svůj problém a to s tím rozdělováním nebo slučováním kanálů dal jako příklad, ale spíš konstatoval, že tohle třeba můžou být potíže s kterými se budou potýkat uživatelé, když to budou provozovat.
A jasně, PW se pravděpodobně také jako většina podobných subsystémů ustabilizuje, nebude se tolik věcí měnit, fixovat atp. Jen tohle je prostě takový klasický problém v linuxovém desktop ekosystému, že se přechází z jednoho standardu na jiný (ALSA->Pulse->PW nebo X11->Wayland..) a tím otevřeným a relativně pozvolným vývojem, kdy se ty standardy a specifikace ještě třeba rozšiřují podle potřeb, do toho vychází v nějakém cyklu distribuce, tak to prostě může být několikaletý pain :) Což může docela kontrastovat se systémy, kde je uzavřený vývoj (Apple macOS), nebo víceméně centrální řízení a rozhodování o celém projektu (např. Android, Chrome OS) - neporovnávám teď nějaké konkrétní subsystémy, ale spíš to jak se nasazují.
Jo to máte pravdu. Ty repozitáře s backporty jsou na Debianu fajn a shodou okolností (neznám úplně klíč pro výběr balíčků, co tam budou) tam teď je i Pipewire, nebo zmíněná MESA. To je proti některým ostatním distribucím určitě výhoda.
Byť ten hlavní point bylo spíš to, že PW jako takové není vůbec špatné, řeší dobře spousty věcí nejen pro audio, akorát se prostě běžný uživatel může dostat do problémů díky výše zmíněným věcem, které souvisí tím, že to posledních pár let bylo ve vývoji spolu s věcmi okolo.. a v nejhorším případě si z toho vyvodí akorát, že audio v Linuxu je kompletně na <|> :)
Oproti tomu jak tu byly předtím zmíněné Windows nebo macOS, tak ty jejich zvukové systémy toho např. samy o sobě zdaleka neumí tolik co PW, ale jsou už dekády víceméně usazené, uživatelé i výrobci HW znají případná omezení, a když už se řeší nějaký problém, tak to typicky končí u výrobce zvukovky a jeho ovladače nebo firmware.
Spravuji javasound provider pro WASAPI exclusive https://github.com/pavhofman/csjsound-wasapi nasazený v dost používaném audio analyzátoru Roomeqwizard https://www.roomeqwizard.com/ . A nemám pocit, že by windows audio bylo bezproblémové. Spíš je to o tom, že si uživatelé moc nevymýšlí, protože nic moc nejde.
V linuxu si vymýšlejí složité chainy, které tam nastavit lze, ale samozřejmě pak narážejí na neznalost, jak to vlastně funguje. Protože jejich požadavky nebývají triviální a složité věci prostě vyžadují nějaké znalosti/snahu.