Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: kopevi2 18. 03. 2026, 12:20:22
-
Zdravím všechny,
na dětský den plánujeme s kroužkem udělat historickou únikovou hru. Z toho důvodu jsme koupili zvukovku Behringer 1820. Kubuntu ji detekuje, hraje přes ní, když dám nastavení repráků, tak to hraje krásně separátně (když dám test repráků).
https://www.behringer.com/product.html?modelCode=0805-AAN
Problém je, že neumím (nevím jak správně nastavit VLC, nebo cokoliv jinýho - ideálně něco co, přes cli umí hrát wav->instalace poběží na RPI5 s python scriptem a senzory přes MQTT), aby mi to hrálo správně prostorově tzn. mám wav se zvukovýma stopama, který hrajou dle očekávání na MACu, ale u mě na ntb s KUBUNTU je těch voleb milion a nevím jak to udělat, aby to správně rozhazovalo stopy na správný reprák (např. stopa1 -> line out 3, stopa 2 -> line out 4.... až line out 10). Máte s tím někdo zkušenosti? To wav dělal kolega přes app asi MyBand (iBand nebo nějak tak) na MAC OS.
AI nepomohlo, google neví, tak se ptám skutečné inteligence.
Děkuji za případné rady.
-
Ja bych zacal koumat, jak prostrednictvim .alsarc vytvorit virtualni 7.1 zvukovku z diskretnich zarizeni.
Zda to neni neco jako zde:
https://unix.stackexchange.com/questions/310164/create-virtual-device-in-asoundrc-file
tj. pritahnout nekolik slaves, a nastavit tomu bindings podle vzoru:
pcm.mdev {
type multi
slaves.a.pcm pcm.MixReale
slaves.a.channels 2
slaves.b.pcm pcm.MixLoopback
slaves.b.channels 2
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave b
bindings.2.channel 0
bindings.3.slave b
bindings.3.channel 1
}
A mozna se nemusite omezovat na 7.1, ale vytvorit ruzne skupiny s ruznym poctem kanalu, podle toho, jak spolu jednotlive regiony / instalace beden existuji.
-
Skus nejaky DAW (napr. https://ardour.org/) tam si vies jednotlive wav natiahnut ako stopy a kazdu stopu routovat na vystup ktory potrebujes (ak to mas ako sadu wav suborov po jednej stope, nie ako osem stop v jednom subore).
-
Děkuji za rady, zítra máme další setkání, tak to tam vyzkouším rovnou na tom RPI5.
-
Dle https://www.diyaudio.com/community/threads/camilladsp-with-behringer-umc1820-how-to-access-s-pdif-input.428523/post-8052046 je ta zvukovka 12-kanálové výstupní zařízení s formátem S24_3LE, tedy klasický 24bit (3 bajty). Někde jsem četl, že 10 kanálů je analog a zbylé dva jsou SPDIF výstup. Ale to je jedno, podstatné je, že alsa vyžaduje 12 kanálů.
Pokud ti stačí přes řádek přehrávat nějaký wav, nejsnazší by byl sox - na vstup mu dáš ten wav, na výstup tu zvukovku přes alsu, a v konfiguračním řetězci efektů si nastavíš, kam půjde který kanál toho wavu. Zřejmě si to budeš muset vyzkoušet. Konkrétní parametry příkazu viz jakýkoliv slušnější LLM.
Jen pozor - pokud by systém měl pulsaudio/pipewire, je potřeba zvukovku v něm vypnout, aby ji neblokoval pro přímý přístup přes alsu.
-
Ja bych zacal koumat, jak prostrednictvim .alsarc vytvorit virtualni 7.1 zvukovku z diskretnich zarizeni.
Ta zvukovka má kanálů víc než dost, není potřeba spojovat více zvukovek. Navíc plugin multi vyžaduje, aby všechna spojená zařízení běžela synchronně (měla synchronizované hodiny), což téměř nikdy není splněno.
-
Dle ... je ta zvukovka 12-kanálové výstupní zařízení s formátem S24_3LE, tedy klasický 24bit (3 bajty). Někde jsem četl, že 10 kanálů je analog a zbylé dva jsou SPDIF výstup.
Tak, prvych 10 je analog, potom 2 spdif, a potom dalsich 8 ADAT (ak je zapojene). Vid zadny panel :)
(https://cdn.mediavalet.com/aunsw/musictribe/r9BPgBZhHUeFK_yN2vgUcw/QNOJi5L400S6Yz6VIldf0g/Original/Image_BE_0805-AAN_UMC1820_Rear_XL.png)
-
Nejjednodušší varianta je k tomu přistupovat přímo přes konkrétní ALSA zařízení.
Bude to fungovat i na nějakém minimálním headless RPi bez grafického rozhraní, stačí mít nainstalovanou knihovnu ALSA libasound2 a alsa-utils + přímé závislosti.
Pokud to zkoušíte na nějakém stroji s DE (KDE, GNOME), bude nad tím sedět ještě pravděpodobně další vrstva - PipeWire (audio server) spolu s WirePlumber (nástroj pro její dynamickou konfiguraci). Pokud nějaká typická GUI aplikace (VLC, prohlížeč, DAW) používá audio zařízení, tak ve výchozím stavu přistupuje na právě přes PipeWire server. Buď nativním rozhraním nebo přes emulaci (PulseAudio, JACK, emulované ALSA rozhraní).
Za normálních okolností to ale to, že je to zařízení mimo ALSU napřímo přístupné také přes PipeWire, nemusí vůbec vadit. Protože pokud v tu chvíli nebude mít žádná aplikace zařízení aktivně otevřené (přehrávání, nahrávání) přes PipeWire, tak je normálně použitelné rovnou přes ALSU.
V nejhorším se dá také udělat pravidlo ve WirePlumberu, kde se zařízení pro PipeWire kompletně zakáže. Ale jak jsem zmiňoval, nebývá to nezbytně nutné a v případě headless RPi, tam tyhle další vrstvy vůbec nemusíte mít.
A teď jak tam přehrávat vícekanálový wav.
Nejdřív si vypíšu názvy ALSA hw zařízení přes příkaz: aplay -l
mám např. vícekanálovou PCIe zvukovku, která má název: HDSPMxcb26e5
card 2: HDSPMxcb26e5 [RME AIO_cb26e5], device 0: RME AIO [RME AIO]
Subdevices: 1/1
Subdevice #0: subdevice #0
Dá se použít i index (v mém případě: 2), ale název je lepší, protože se nemění při různém pořadí zavádění modulů, připojování USB zařízení atp.
Teď základní test.
speaker-test -D plughw:HDSPMxcb26e5 -c 16
Program pouští testovací šum postupně do všech kanálů v zařízení, v počtu specifikovaném pomocí parametru -c.. (já mám 16 kanálovou zvukovku, a takhle bych otestovat všechny kanály, ale může otestovat klidně jen třeba první 4). Při testu to vypisuje aktuální číslo kanálu.
Důležitý parametr pak je -D, kde se zadává název zařízení. Pokud bych tam zadal pouze HDSPMxcb26e5, tak bych musel mít přesný počet výstupních kanálů a sample formát, který konkrétní zvukovka vyžaduje (např. S32_LE, S24_3LE, jak zmiňoval Redustin atp.).
Ale tím, že jsem před to napsal plughw:, tak se tam automaticky vřadí ALSA plugin, který sample formát převede a počty kanálů automaticky upraví podle výstupního zařízení.
Pokud jsem s tím v pohodě, můžu zkusit zahrát ten vícekanálový (poly) wav. Řekněme, že by měl třeba 8 kanálů..
aplay -D plughw:HDSPMxcb26e5 ./multichannel.wav
Tohle by mi mělo zahrát wav tak, že bude mapování kanálů 1:1. Tzn. zahraje mi to z prvních osmi kanálů na zvukovce (moje má 16), v těch zbylých bude ticho.
Což je jeden ze způsobů, jak k tomu přistupovat. Pokud mi nebude vyhovovat pořadí, můžu si to proházet přímo při přípravě toho wavu (v DAW) a nebo přepojit ty výstupní TRS jacky na zvukovce :)
Pokud bych to chtěl někam posunout (hrát např. z posledních osmi) nebo proházet pořadí, tak to bude vyžadovat vytvoření virtuálního ALSA audio zařízení s dalším pluginem na směrování audio kanálů.
To udělám v souboru ~/.asoundrc (pro aktuálního uživatele), kam přidám např. takovéhle sekce.
pcm.virtual1 {
type route
slave {
pcm "plughw:HDSPMxcb26e5"
channels 16
}
ttable.0.1 1
ttable.1.0 1
ttable.2.2 1
ttable.3.3 1
ttable.4.4 1
ttable.5.5 1
ttable.6.6 1
ttable.7.7 1
}
V definici slave se přes pcm odkážu na fyzickou zvukovku, úplně stejně jako v předchozích případech.
A následně např. prohodím první dva kanály přes tabulku.
Tam je fomát: ttable.in-channel.out-channel gain
Přičemž gain je jako float multiplikátor (tzn. 1 = beze změny).
pcm.virtual2 {
type route
slave {
pcm "plughw:HDSPMxcb26e5"
channels 16
}
ttable.0.2 1
ttable.1.3 1
ttable.2.4 1
ttable.3.5 1
ttable.4.6 1
ttable.5.7 1
ttable.6.8 1
ttable.7.9 1
}
V tomhle druhém případě jsem to posunul o dva výstupy.
Když to pak chci zahrát, tak použiju např.
aplay -D virtual1 ./multichannel.wav nebo aplay -D virtual2 ./multichannel.wav
Takže to je v kostce asi všechno. aplay se dá zavolat z Python programu normálně jako systémový příkaz přes modul subprocess.
Možná kdyby to mělo být hezčí, tak bych se asi poohlédnul po nějakém modulu, co umí s ALSA zařízeními pracovat přímo z Pythonu, třeba jako pyalsaaudio (v podstatě wrapper okolo libasound, ale dýl jsem to neviděl).
Čtení PCM wavů je přímo ve standardní knihovně Pythonu.
Udělat z toho nějakou přehrávací funkci, kterou pak můžu volat například z vláken. Což se zas může hodit, jestli to má dynamicky reagovat na nějaké řídící eventy z toho MQTT.. minimálně se to dá nějak zamykat, synchronizovat, lidsky zastavovat přehrávání atd.
Ale samozřejmě, jestli je to nějaká jednorázovka s opravdu základním spouštěním, nemusí to dávat smysl.
-
Moc děkuji všem za pomoc, velký dík patří panu Šmucrovi za parádní kuchařku, během pár minut hotovo a hraje to skvěle, přesně dle očekávání. ;D
-
Není vůbec zač.
Jen jak to teď po sobě čtu, tak se musím ještě opravit. Jak jsem psal o tom, že plughw:HDSPMxcb26e5 zařídí konverzi formátu a počtu kanálů přes plugin, tak ten zápis bez konverze je samozřejmě hw:HDSPMxcb26e5 a ne jen HDSPMxcb26e5, překlep - omlouvám se.
Ještě dodám, že vícekanálová virtuální PCM zařízení, co si takhle definujete v .asoundrc, jdou případně používat ve většině aplikací, které mají přímo výstup přes ALSA rozhraní.
Jen se typicky neukazují v těch rozbalovacích seznamech v UI. Takže se musí většinou přímo specifikovat v příkazu, nebo napsat do nějakého configu aplikace.
Další zádrhel, co se týká hlavně obecných přehrávačů, je v tom, že to směruje přehrávané audio podle metadat s kanály (L, R, C, Ls.. atp.), které u těchhle virtuálních rozhraní nejsou.. Za normálních okolností tohle dodá PipeWire nebo PulseAudio.
Podobně pak, když je těch kanálů ve wavu víc a nesedne to přehrávači heuristikou do žádného známého layoutu (5.1, 7.1 atp.).
Takže třeba u VLC bych to přehrál asi takhle. To 4967 není počet kanálů, ale jeho interní ID pro layout 7.1, je tam enum, a hodnoty se dají zjistit, když pustím vlc -H.
cvlc -A alsa --alsa-audio-device virtual --alsa-audio-channels 4967 ./audio-8ch.wav
U mpv je pak volba --alsa-ignore-chmap, co to pak vypne mapování podle logických kanálů a pustí to tam 1:1.
mpv --audio-device=alsa/virtual --audio-channels=auto --alsa-ignore-chmap ./audio-8ch.wav
Zmiňuji tyhle přehrávače proto, že se je někdy hodí použít i pro podobné účely jako u vás.
Třeba pro automatizované přehrávaní videí nebo zvuků, kdy to můžete řídit z venku.
Oba zmíněné přehrávače mají možnost povolit rozhraní na posílání příkazů.. ať už přes unix socket nebo named pipe na Windows, případně u VLC je tam i TCP server s telnet like rozhraním.
Takže se dají spustit jako služba a pak z nějaké řídící aplikace (napsané např. v Pythonu) posíláte jen příkazy pro ovládání playlistu, přehrávání atp.
-
Za normálních okolností to ale to, že je to zařízení mimo ALSU napřímo přístupné také přes PipeWire, nemusí vůbec vadit. Protože pokud v tu chvíli nebude mít žádná aplikace zařízení aktivně otevřené (přehrávání, nahrávání) přes PipeWire, tak je normálně použitelné rovnou přes ALSU.
Z mé zkušenosti PA/PW k zařízením často přistupuje a funčnost přes alsu je velice nespolehlivá. Někdy je zařízení volné a alsa dostane přístup, jindy jej má PA/PW otevřené a alsa přístup již nemá.
V nejhorším se dá také udělat pravidlo ve WirePlumberu, kde se zařízení pro PipeWire kompletně zakáže. Ale jak jsem zmiňoval, nebývá to nezbytně nutné a v případě headless RPi, tam tyhle další vrstvy vůbec nemusíte mít.
Pokud v systému běží PA/PW, z mé zkušenosti je pro spolehlivý provoz přes alsu nutné to zařízení v PA/PW vypnout/zakázat.
-
Z mé zkušenosti PA/PW k zařízením často přistupuje a funčnost přes alsu je velice nespolehlivá. Někdy je zařízení volné a alsa dostane přístup, jindy jej má PA/PW otevřené a alsa přístup již nemá.
...
Pokud v systému běží PA/PW, z mé zkušenosti je pro spolehlivý provoz přes alsu nutné to zařízení v PA/PW vypnout/zakázat.
Osobně jsem s tímhle problémy neměl, mám pár aplikací, co jsou nastaveny přímý přístup přes zařízení ALSA a kdykoliv potřebuji, tak si je otevřou, přestože na něj může také PipeWire.
Ale samozřejmě nevylučuji, že se to třeba na jiné HW, SW konfiguraci může chovat jinak, distribuce mohou mít jiné nastavení (používám primárně OpenSUSE a Fedoru) atp.
Jak jsem už zmiňoval, u mě je jediná podmínka - že tam na zařízení nemůže být v tu chvíli připojen žádný jiný PW klient, když není, tak to ALSA zařízení PW pustí, což je pak vidět i v procfs. A ano i tohle výchozí chování se dá přerazit, když WirePlumber nastaví na alsa monitoru session.suspend-on-idle = false, pak ho samozřejmě PW drží pořád.
A souhlasím, že kdybych to měl na nějaké trvalé použití přes ALSA zařízení (dedikovaný player/služba) a k přístupu přes PW nebude důvod, tak to samozřejmě také vyřadím. Také to takhle někde používám.
-
když není, tak to ALSA zařízení PW pustí, což je pak vidět i v procfs
IMO v linuxu není možnost, jak by proces zjistil, že se jiný proces snaží zařízení otevřít, aby je zavřel a uvolnil. Buď jej má otevřené, a pak mají všichni ostatní smůlu, nebo je volné, a pak první vyhrává. Narozdíl např. od windows wasapi, kde exclusive může mít zakliknutou prioritu a pak windows mixer (tj. wasapi shared) zařízení uvolní, když přijde požadavek od klienta v režimu exclusive. To mi přijde hodně šikovné.
-
Narozdíl např. od windows wasapi, kde exclusive může mít zakliknutou prioritu a pak windows mixer (tj. wasapi shared) zařízení uvolní, když přijde požadavek od klienta v režimu exclusive. To mi přijde hodně šikovné.
Tak mozna zvukove API to resi.. ale souborovy system s tou exkluzivitou kdy nejde smazat adresar protoze nejaky proces tam ma CWD, byl hlavni duvod odchodu od Win
-
když není, tak to ALSA zařízení PW pustí, což je pak vidět i v procfs
IMO v linuxu není možnost, jak by proces zjistil, že se jiný proces snaží zařízení otevřít, aby je zavřel a uvolnil. Buď jej má otevřené, a pak mají všichni ostatní smůlu, nebo je volné, a pak první vyhrává. Narozdíl např. od windows wasapi, kde exclusive může mít zakliknutou prioritu a pak windows mixer (tj. wasapi shared) zařízení uvolní, když přijde požadavek od klienta v režimu exclusive. To mi přijde hodně šikovné.
Jo, to je šikovné a analogicky to funguje i na MacOSu s CoreAudio a exclusive režimem.
Na úrovni ALSA zařízení, žádná takováhle klasifikace klientů (normální, exclusive) není.. tam by se nejspíš muselo něco dohackovat (nevím, přes BPF sledovat, který proces to otevírá, ale asi by to byla prasečina, protože jakmile by s tím nepočítalo vyploženě API, musel by se ten ne-exklusivní klient nějak zvenku urvat).
Ale myslím, že tohle má v sobě právě přímo Pipewire.
https://docs.pipewire.org/page_man_pipewire-props_7.html#:~:text=node%2Eexclusive,source
Nikdy jsem to nezkoušel, ale chápu (možná blbě) to tak, že když se vytvoří klient (node) s tímhle příznakem a pak se připojí na sink, tak to po dobu spojení vyruší ostatní klienty.
Teoreticky i pokud to nepodporuje přímo aplikace při vytváření, tak by to pak mohlo jít přidat nějakým pravidlem (match jména "privilegovaného" procesu) i přes WirePluber.
Jinak to, co jsem myslel předtím, že PW zavře ALSA zařízení, tak jen klasicky přes sw_params.
grep -H '^' /proc/asound/*/pcm*/sub?/sw_params
-
Možná, když už jsme to tu zmínili a někdo by to tu případně hledal.
Přidám konkrétní návod na vyřazení ALSA zařízení z PipeWire pomocí WirePlumberu. Třeba se to někomu bude hodit.
- spustím si příkaz: wpctl status a pak najdu ve stromečku "Audio > Devices" číslo zařízení (ID), co chci zakázat
- zjistím další informace příkazem: wpctl inspect <ID>
- ve výpisu dohledám (grepnu) řádek device.name = "..."
např. device.name = "alsa_card.pci-0000_07_00.0"
- pokud neexistuje, tak vytvořím adresářovou strukturu: ~/.config/wireplumber/wireplumber.conf.d/ a v ní následně libovolný .conf soubor.
Např. disable-my-alsa-device.conf
monitor.alsa.rules = [{
matches = [
{ device.name = "alsa_card.pci-0000_07_00.0" } # Tady použiju jméno z předchozího výstupu
]
actions = {
update-props = {
device.disabled = true
}
}
}]
- spustím: systemctl --user restart wireplumber
- zkontroluji znova: wpctl status, zařízení by tam už nemělo být
- profit
-
Tak mozna zvukove API to resi.. ale souborovy system s tou exkluzivitou kdy nejde smazat adresar protoze nejaky proces tam ma CWD, byl hlavni duvod odchodu od Win
Kdyby to bylo jen CWD v terminálu. Tohle tvrdé zamykání (oproti eleganci s unlink()) je i důvod, proč je nutné spousty aktualizací na Windows fakticky naplánovat na další boot v nějaké early stage. Resp. když to jde, tak komplet zastavit služby, vyměnit binárky a pak znovu spustit.
Ale už jedu trochu off-topic, každý systém má něco.. ;)
-
Na úrovni ALSA zařízení, žádná takováhle klasifikace klientů (normální, exclusive) není.. tam by se nejspíš muselo něco dohackovat (nevím, přes BPF sledovat, který proces to otevírá, ale asi by to byla prasečina, protože jakmile by s tím nepočítalo vyploženě API, musel by se ten ne-exklusivní klient nějak zvenku urvat).
Samozřejmě přes lsof /dev/snd/* lze zjistit, který proces má zařízení otevřené, a ten by se dal zabít, ale to je hodně na hulváta.
Ale myslím, že tohle má v sobě právě přímo Pipewire.
https://docs.pipewire.org/page_man_pipewire-props_7.html#:~:text=node%2Eexclusive,source
Nikdy jsem to nezkoušel, ale chápu (možná blbě) to tak, že když se vytvoří klient (node) s tímhle příznakem a pak se připojí na sink, tak to po dobu spojení vyruší ostatní klienty.
Teoreticky i pokud to nepodporuje přímo aplikace při vytváření, tak by to pak mohlo jít přidat nějakým pravidlem (match jména "privilegovaného" procesu) i přes WirePluber.
V rámci PW to lze, v podstatě to znamená, že nebude docházet k mixování, node má sink jen sám pro sebe. Ale jakmile se něco připojí na alsí zařízení, už je to natvrdo, ani PW s tím nic neudělá.
Jinak to, co jsem myslel předtím, že PW zavře ALSA zařízení, tak jen klasicky přes sw_params.
grep -H '^' /proc/asound/*/pcm*/sub?/sw_params
Jj, zjistit proces, který zařízení používá, je snadné. Ale pak už jen jej killnout natvrdo, aby zařízení pustil. Zatím jsem nikde neviděl, že by to někdo takhle používal, ale technicky takovému ošklivému hacku nic nebrání.
-
Možná, když už jsme to tu zmínili a někdo by to tu případně hledal.
Přidám konkrétní návod na vyřazení ALSA zařízení z PipeWire pomocí WirePlumberu. Třeba se to někomu bude hodit.
Super, díky, to je hodně užitečné. Vypínání zařízení v PA bylo snadné přes CLI pactl, ale v PW se nezdá, že to takhle napřímo fungovalo.
-
Možná, když už jsme to tu zmínili a někdo by to tu případně hledal.
Přidám konkrétní návod na vyřazení ALSA zařízení z PipeWire pomocí WirePlumberu. Třeba se to někomu bude hodit.
Super, díky, to je hodně užitečné. Vypínání zařízení v PA bylo snadné přes CLI pactl, ale v PW se nezdá, že to takhle napřímo fungovalo. Přitom mi to přijde velice důležité a řešení přes wireplumber je dost přes ruku.