Příspěvky

1

Distribuce / Re:Obsahuje Debian 13 s GNOME taky PipeWire?

« kdy: 09. 05. 2026, 16:53:50 »

Otázka zní: Je tu někdo, kdo si v posledních měsících instaloval čistý Debian Stable a zvolil už při instalaci GNOME, aby mi řekl, jestli tam má PipeWire?

Ano instaluje se rovnou s metapackage GNOME, protože je to zřetězená závislost.
task-gnome-desktop -> gnome-core -> pipewire-audio

Můžete zjistit třeba přes apt info task-gnome-desktop, podívat se na řádek depends, pak apt info gnome-core.. atd.

Mám nainstalovaný Debian 13 stable a od instalačky je to by default s XFCE. Teď jsem někde četl, že XFCE v Debianu nepoužívá jako audio PipeWire, ale že je tam ještě pořád PulseAudio.

Měl jsem problém se sdílením plochy přes XRDP - nešel zvuk - a důvod měl být ten, že to potřebuje už novější PipeWire.

Tak jsem zkusil nainstalovat Gnome, jestli to pojede nad PipeWire, a nebylo tomu tak, stejně jako XFCE tam běří PulseAudio.

Zjistí se to příkazem

Kód: [Vybrat]

pactl info


- jestli jste na úvod instaloval jen XFce (task), tak se nainstaluje legacy PulseAudio server.

- novější PipeWire standardně emuluje PA pro klienty, takže jakmile nainstalujete metapackage pipewire-audio, odebere se legacy PulseAudio server (balíček pulseaudio).. je to buď jedno, nebo druhé.

- můžete klidně používat třeba XFce s PipeWire, akorát ty zvuky z desktopu (ne aplikací) a applet na panel pro ovládání hlasitosti pojedou přes emulované PA API.

- Xrdp pak umí pracovat jak s PulseAudio serverem, tak nativně s PipeWire.
Když nainstalujete jen balíček xrdp, tak v sobě má rovnou moduly pro PulseAudio.. není potřeba nic dalšího řešit, pokud běží legacy PulseAudio server. Když se spustí Xrdp, tak se moduly natáhnou natáhnou viz /etc/xrdp/pulse/default.pa
U PipeWire je to trochu jinak, protože zmíněné legacy moduly nejdou použít. Musí se nainstalovat balíček pipewire-module-xrdp. Což je v podstatě skript /usr/libexec/pipewire-module-xrdp/load_pw_modules.sh, který po startu session udělá xrdp-sink and xrdp-source a nastaví je jako výchozí.

- pactl je jen obslužný nástroj, který chodí jak s nativním PulseAudio serverem, tak i pokud je emulovaný z PipeWire.
Když spustíte pactl info, tak pokud bude ve výstupu "Server Name: pulseaudio", tak jde o původní server, jestliže tam bude "Server Name: PulseAudio (on PipeWire x.x.x)", je to ta emulovaná varianta.
Jinak ukáže i výchozí zařízení, potřebujete, aby tam bylo xrdp-sink (přehrávání) a xrdp-source (signál z klienta).

O co mi jde - protože měl Debian 13 s GNOME jet pod PipeWire, ale nejede, tak si kladu otázku, jestli tomu tak není proto, že jsem v instalaci Debianu zvolil XFCE a teď už nepomůže tam dát GNOME, protože si to drží původní závisloti na PulseAudio.

Zkoušel jsem podle návodu rozjet ten PipeWire, nakonec se to povedlo a šel i zvuk v Xrdp, ale nějak mi přestala po rastartu fungovat Wifi a po restartu shell pořád vypisovat nějaké error s hardwarem, což se nikdy nedělo, proto jsem ty
změny raději revertoval.

Spíš bych se snažil pochopit a řešit jednotlivé problémy. Jestli chcete používat XFce, tak bych tam nedával další kýble nesouvisejících balíčků z GNOME. Ani jedno by nemělo mít přímou souvislost s WiFi.

Zkusil bych:
apt install pipewire-audio (metapackage, odebere pulseaudio server)
apt install pipewire-module-xrdp

Pak bych to restartnul a zkontroloval, jestli se po přihlášení přes RDP objeví správně zmíněná virtuální zařízení.
pactl info (pro PulseAudio klienty), wpctl status (nativní PipeWire).

A ještě pro úplně blbé, co neumí odpovědět na dotaz a nebo vypadnout ven z vklákna: Zkoumám, jestli Debian s GNOME nenainstaluje pro běžného usera "lepší" závislosti, než když si někdo při instalaci zvolí třeba míň na Debianu podporované XFCE.

Možná byste mohl trochu ubrat plyn, jestli se chcete na něco ptát

2

Software / Re:Borg vs. Vykar

« kdy: 31. 03. 2026, 11:16:21 »

Také používám Restic. Ve své době jsem se rozhodoval mezi Borgem a Resticem, zvolil jsem druhý, mimo jiné protože to byla jedna binárka z Golang a chodila out-of-box na všech systémech včetně Windows, přímá podpora S3 je samozřejmě také velkou výhodou.
Vykar vypadá zajímavě, ale koukal jsem na to jen z rychlíku a je to příliš nové, abych to někde používal mimo pokusy.

3

Bazar / Re:Prodám GPU NVIDIA RTX A4000 16GB

« kdy: 26. 03. 2026, 22:44:45 »

Hmm, no necakal som ze to tu vyvola takuto debatu.
Uprime, pozeral som nejake ponuky pred tym nez som to sem dal, ale nebol som si isty, preto som radsej cenu nepisal.
...
No ak teda sa nenajde nikto s vyssou ponukou tak to asi skusim inde.

Ta debata byla trochu klasika root.cz Snad vás to nebo případného kupce neodradilo, zas tam padlo pár obecnějších technických věcí.

Jinak rozumím, co jste myslel s tou cenou.

Já žádnou kartu teď nepotřebuji, takže to prosím neberte jako můj příhoz
Byť je vždycky otázka nabídky a poptávky, tak realistickou cenu bych teď osobně viděl okolo 12 tisíc (~ 500 EUR).
Je samozřejmě možné, že ji někdo nabízí za víc - otázka je, jak dlouho ji bude prodávat a příp. kolikrát ten inzerát znovu vylistuje nebo bude muset případně slevit.

Sám ze zkušenosti vím, že tenhle trochu speciálnější HW může být komplikovanější prodat. Protože prostě zdaleka ne každý ocení ty specifické fíčury, co jsme tu např. probírali. A pokud to někdo používá na profi práci, tak už to má často rovnou v sestavě (a nebude upgradovat mínus dvě generace starou kartou). Takže to může být trochu na dýl to pak prodat, aby se to někomu vyloženě hodilo.
Jestliže by to někdo bral jen jako obecnou NVIDIA kartu do počítače, tak to moc smysl nedává, protože je to Ampere generace (4-5 let zpět) a cenově jsme pak zhruba na úrovni dnešní 5060 Ti 16G, 5070 z druhé ruky.
Ty budou pak mít delší podporu a případně podle workloadu i znatelně vyšší výkon. Nejen 3D, ale např. Tensor/RT cory novější generace - rychlejší rendery, lokální inference. HW. akceleraci kódování AV1 přes NVENC atd.

Držím palce, ať se vám to povede prodat.

4

Bazar / Re:Prodám GPU NVIDIA RTX A4000 16GB

« kdy: 26. 03. 2026, 11:52:31 »

DaVinci Resolve používá s NIVIDA kartami CUDU a počítá s 32 bit floaty v celé pipeline. Tam nemá Quadro žádnou výhodu (resp. je to stejně ponížené jako GeForce oproti datacenter modelům . A často trochu pomůže prostě vyšší takt u těch herních karet. Ne že by na GeForce byl Resolve specificky a úmyslně optimalizovaný.

On je specificky "optimalizovany" pro nektere karty, napr. v 18.5.1 se nachazi tyhle retezce (prvni v okoli kodu na neuronky, takze muze jit jak o optimalizaci na vice vram), nebo naopak nejaky quirk na reseni problemu (K6000 a 1660):
...

To by dávalo smysl. Quirky na bugy v konkrétních modelech jsou v mnoha programech. A naopak třeba pro modely s dvojnásobnou paměti můžou použít nějaký jiný způsob práce s těmi neuronkami, byť je pak stejně otázka, proč si tu velikost dostupné VRAM nezjistí nějakou runtime detekcí a jsou tam nějaké hard-coded stringy.

Ale upřímně se přiznám, že zrovna ty funkce s neuronkami (AI upscale, maskování, generování Z bufferu), co jsou postupně rozšiřovány v posledních verzích Resolve, jsem nikdy takhle napřímo GF/Quadro neporovnával.
Dělal jsem to před pár lety a týkalo se to standardního dekódování RAWů, korekcí, transformací, exportu v různých projektech. Kdy tam opravdu žádný rozdíl nebyl, nebo když byl to to bylo díky vyšším taktům pamětí ve prospěch GF.

5

Bazar / Re:Prodám GPU NVIDIA RTX A4000 16GB

« kdy: 26. 03. 2026, 11:19:23 »

Pak u Quadro HW existuje sync port (ma ji i napr inzerovana A4000), ktery muzete napojit na "NVIDIA Quadro Sync II" a ziskat tim dokonce genlock na externi zdroj - pokud vam jde o nejaky serioznejsi aplikace LED sten. Geforce tento hw sync neumoznuji.

S tímhle mám jeden vcelku vtipný kousek.. Jeden nejmenovaný výrobce celých systémů (appliance, SDI video dovnitř, ven, synchronizace na GenLock - TriLevel/BiLevel, 3D engine běžící na NVIDIA kartě, Linux RT jádro) to měl udělané tak, že tam byla jejich HW SDI karta se vstupem pro synchronizaci a pak tam byla normální low-profile GeForce karta - ještě nějaký Gainward, kde byla proškrábnutá cesta na PCB a napájená propojka na synchronizaci z té jejich karty.

6

Bazar / Re:Prodám GPU NVIDIA RTX A4000 16GB

« kdy: 26. 03. 2026, 11:07:59 »

a

Máte pravdu, nicméně Catia je ještě mnohem lépe optimalizovaná a vymáčkne z "Quadra" více, než já ze Solidworks (ano, dlouhé roky funguju v Solidu čili jste se trefil).

Obojí je teď pod jednou firmou, Dassault. Takže mi vcelku dává smysl, že prostě mají užší vazby na NVIDII a v obou softech jsou specifické optimalizace s tím, že je to oboustranně výhodné.
NVIDIA poskytne expertízu a pomoc při vývoji, udělá dedikované aplikační profily v ovladačích (což může ovlivnit mnoho věcí, kámoš mi třeba říkal, že to může zásadně ovlivnit alokaci video paměti, kdy tam je tam třeba pro určité aplikace rovnou přiřazeno víc na geometrii).
Dassault to zas v aplikacích zařízne na konkrétní modely (což mělo podobě víc výrobců, pamatuju si třeba na Adobe, kdy v některých aplikacích neběžely konkrétní funkce na GeForce, dokud se nepřipsalo ID nebo model string do nějakého speciálního texťáku).

...
Už jsem na tohle téma dost alergický a podrážděný pokaždé, když naběhnou teoretici, co u toho nesedí 10 hodin denně a začnou vytahovat teorie, benchmárky a ilumináty. Proletáři, kteří počítají návázné výpočty dříve, než znají výsledek předchozího výpočtu. Tohle téma rezonuje na všech CAD fórech.

Ano chápu, ale zas to fakt chce vztáhnout ke konkrétní aplikaci. U těchhle hi-end CADů to i vzhledem k jejich ceně a typu nasazení nemá smysl řešit.
Na stranu druhou, pokud to fakt má někdo na výpočty přes CUDU a běžné 3D, nemusí se mu to zdát jako dobrá volba.

S tím zbytečným hádáním jsem to myslel tak, že máte s Danem (RDa) svým způsobem pravdu oba. Quadro opravdu sdíli čipy s GeForce a pro spousty aplikací je to jedno. Ale když patříš do skupiny uživatelů, která využije ty exkluzivní věci a speciální optimalizace, naprosto to dává smysl.
Stejně jako já taky docela dobře vím, proč v těch stanicích a serverech ty Quadra jsou a je mi tak nějak úplně jedno, jestli si někdo myslí, že by tam být nemusely

7

Bazar / Re:Prodám GPU NVIDIA RTX A4000 16GB

« kdy: 26. 03. 2026, 10:57:13 »

nam zrovna tahle karta lip drzela sync mezi vystupy nez podobny gforce. (delame velky ledky tak je to tam videt, napr diagonalni cara co jede odzhora dolu na vysupech vedle sebe bude mit zub). musime to bezet na widlich tak buhvi jak certovina (drivery/vbios) v tom je, ale je to tak.

Ano, je to tak tohle je další oblast, kde jsou rozdíly. Tomu "zubu" se říká tearing.
Quadro/RTX má exklusivně fíčuru, které se říká Mosaic, což je to i co zmiňuje RDa. Ta umí spojit víc výstupů na jedné kartě a případně až čtyři karty v jednom počítači do jedné obrovské virtuální plochy (canvas), která se pro systém a aplikace tváří jako jeden monitor (byť to přes WDDM posílá hinty o vnitřním layoutu, kvůli umístění oken).

GeForce má podobnou technologii, té se říká NVIDIA Surround, ale je výrazně osekaná verze oproti Mosaic.
Ten zásadní rozdíl byl minimálně historicky v tom, že vykreslování na výstupy synchronizuje softwarově, kdežto Mosaic pokud má připojená zařízení se stejným režimem (podle EDIDu), tak se to přepne a Quadro karta sdílí pro výstupy ve skupině hardwarově stejný pixel clock.
Čímž neříkám, že se Surround tam bude vždycky a za všech okolností viditelný tearing.. ale je to trochu YMMV a když tam bude problém, většina dodavatelů/integrátorů od toho dá ruce pryč a řekne - kup si Quadro.

Stejně tak jsou na Quadru (mimo těch nejmenších) přítomné konektory pro externí synchronizaci. Tzn. když je v systému víc graf. karet, dá se dokoupit ještě speciální sync karta a propojí se s grafikami pomocí takových kšand.
To pak ve výsledku umožní HW synchronizaci karet mezi sebou (Framelock). Sync karta má pak ještě externí konektory (vstup a výstup) a BNC na genlock, takž jde následně synchronizovat víc počítačů mezi sebou, nebo všechno posadit na jeden centrální zdroj synchronizace.. (představte si třeba velké televizní studio nebo planetárium).

Pak jsou tam ještě další softwarové a funkční rozdíly. Surround na GF umí jen ořezávat část obrazu pro kompenzaci rámečku displeje (bezel correction). Kdežto Mosaic umí udělat i tzv. overlap, tzn. když mám třeba dva výstupy do dvou projektorů (široký layout vedle sebe), nastavím, že je tam vertikální pruh 200 px široký, který je v obou výstupech. Na projektorech to pak můžu domaskovat, aby tam byl plynulý přechod.
Nebo pokud neumí projektory samy maskovat a blendovat, tak je tam ještě speciální možnosti Quadro ovladači. Ty nejsou uživatelsky přístupné přes normální ovládací panel, ale dají se zavolat přes speciální API (Blend and Warp), což používají aplikace třetích stran. Pak to maskování, blending a deformace (při projekci na různé nerovné povrchy, video mapping atp.) běží téměř bez latence přímo na grafické kartě.

Ono, již i softwarový developeři, vědí, že lidé pracují na těch herních kartách. Kamarád dělá v TV produkci a prý ty herní dávají vyšší výkon než např. A4000 z obdobné generace. Např. DaVinci atd z té karty prostě vytáhne víc díky optimalizacím a pod...
Ono to s tou specializací nebude tak horké... kromě nějakých specifických případů... ale nejspíš i tam bude ten rozdíl nula nula nic... Já kupoval vloni na black friday rozbalenou GeForce 3060 12GB na alze za 5 tis asi můj nejlepší kup... ikdyž 32GB RAM v léte za 1600 proti nynějším 6000 taky nebyl špatný

Ano, jak jsem psal, pokud máte aplikace, kde žádné specifické optimalizace nejsou, ani to nepoužívá žádné exkluzivní fíčury, neřešíte certifikace kvůli sw podpoře.. tak většinou Quadro nedává žádný smysl.
DaVinci Resolve používá s NIVIDA kartami CUDU a počítá s 32 bit floaty v celé pipeline. Tam nemá Quadro žádnou výhodu (resp. je to stejně ponížené jako GeForce oproti datacenter modelům . A často trochu pomůže prostě vyšší takt u těch herních karet. Ne že by na GeForce byl Resolve specificky a úmyslně optimalizovaný.
Podobně to bude i se spoustou dalších softwarů pro 3D, vizuální efekty atp. - chodí to stejně. Byť tam třeba historicky předtím někde rozdíly byly.

8

Bazar / Re:Prodám GPU NVIDIA RTX A4000 16GB

« kdy: 25. 03. 2026, 22:34:07 »

Ano Quadro/RTX má některé funkce odlišné - např. možnost ECC, Mosaic, snadnou správu EDIDů na Windows, GPU Direct, synchronizaci více karet, případně víc session NVENCu u některých modelů, specifické optimalizace v uzavřeném software.. atd.
Ale většina je čistě softwarová a záležitost ovladače - prostě segmentace produktů od NVIDIA. Velikost firmware je větší úplně záměrně, aby nešly jednoduše přeflashovat a použít následně ten Quadro ovladač. Úplně stejně to bylo, když NVIDIA dělala modely grafik pro Intel Macy s PCIe sloty. Byli dokonce kutilové, co si přepájeli větší paměť na PC verzi a přeflashovali fw z Mac verze (a chodilo to).

Hardwarově se můžou lišit také, Quadra mají oproti ekvivalentní GF často nižší špičkové takty. Také je tam striktně u všech výrobců (PNY, HP, Dell, Lenovo) jen stejný referenční layout a chlazení s blowerem, oproti spoustě modelům GF, co mají větší chladiče a víc pomalejších ventilátorů.
Takže Quadra můžou být spolehlivější (aspoň moje zkušenost s desítkami karet) v dlouhodobějším provozu, jdou bez problémů používat vedle sebe ve slotech (SLI, multi GPU). Naopak bývají zas často hlučnější v zátěži oproti některým slušnějším "herním" GeForce modelům.

Pokud někdo ty zmíněné fíčury nebo proprietární optimalizace využije, je naprosto adekvátní za tu kartu zaplatit i násobky ceny GeForce.
Když já budu mít třeba server pro video (on-air grafiku) s aplikací, co používá API GPU Direct for Video, tak to bude přenášet snímky mezi grafikou a video kartou (Matrox, AJA..) řádově efektivněji než přes buffer v RAMce a CPU.
Stejně tak, jestli má Buldr třeba Solidworks.. tak tam zas pokud vím prostě spolupracoval výrobce s NVIDII na speciální optimalizaci vykreslování. Ovladač detekuje specifického klienta, software zas vidí model karty a zapnou režim, co jinde neběží.
Neřekl bych že to je univerzální (jako že Quadro je obecně super na wireframe), protože třeba jiné softy můžou chodit úplně stejně i na ekvivalentní GeForce, ale když už tam ta optimalizace je, může to hrát významnou roli.
Třeba se mi to nemusí líbit nebo být smutný, že to není otevřené.. ale budiž, vyvinuli si tu optimalizaci jako HW/SW celek.
Naopak pokud v klíčové aplikaci tam nic podobného není, neřeším ISV certifikace, žádné API navíc nevyužiju a třeba nejvíc času strávím u nějakého GPU renderu přes CUDA, pak to Quadro nedává moc smysl, protože za tu cenu je mnohem větší přínos koupit buď rychlejší model GeForce (nebo víc kousků).

Takže nevím, ale přijde mi že se hádáte trochu zbytečně..

9

Sítě / Re:Mikrotik 2x WAN - nastavení port forward přes konkrétní WAN

« kdy: 25. 03. 2026, 09:16:04 »

Neměl by tohle všechno obsloužit NAT skrze který to jde? Značkování paketů si myslím je v tomhle případě nesmysl.

Nikdy jsem sice podobnou věc neřešil na Mikrotiku, ale není to nesmysl. Nejde v mangle o značkování paketů (mark), ale značkování spojení (connmark).
5nik má podle mě pravdu, nejde to udělat bez tzv. policy based routing.
NAT samotný tohle neřeší, ten prostě podle pravidla a bez další vazby na spojení přepisuje cílovou (dovnitř - dnat) nebo zdrojovou adresu (ven - maškaráda, resp. snat).
Problém nastává v tom, že bez dalších úprav se prostě pro všechny odchozí pakety vyhodnotí pořadí v hlavní směrovací tabulce a všechny pak jdou přes bránu venku na primární WAN.
Takže právě proto jsou potřeba použít ty přidané značky od spojení (navázaného zvenku přes sekundární WAN) a při směrování odpovědí použít druhou směrovací tabulku, kde bude nastavená jiná výchozí brána od druhého ISP.

10

Hardware / Re:Zvukovka Behringer 1820 se 7.1 na Kubuntu 24.10

« kdy: 23. 03. 2026, 19:16:44 »

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á.

Určitě by se dalo upravit ALSA API, aby tam byla např. nějaká priorita klientů, řešilo to odpojování atp. Exkluzivní přístup, ve smyslu - klient má výhradní kontrolu nad zařízením, je tam tak nějak od začátku. Ale obávám se, že po tom není extra poptávka, navíc je vcelku jednoznačný trend zachovat to jako specifické low-level rozhraní a všechny věci okolo pokročilejší správy přístupů řešit nad tím v PipeWire.

S ohledem na tu zmíněnou situaci mě teď napadají v podstatě tři scénáře.

1) na zvukovku vůbec nemusím přistupovat přes PW, mám ji vyhrazenou jen pro specifické aplikace s nativním ALSA API. To je nejjednodušší, vyřadím jí pomocí WirePlumberu, jak jsem psal.

2) budu v pohodě, když se bude používat emulované ALSA rozhraní z PipeWire
poměrně hodně toho můžu nastavit buď configu nebo přes systémové proměnné.. V proměnné PIPEWIRE_NODE ho přímo nasměruju na konkrétní sink resp. source. Pomocí PIPEWIRE_ALSA mu zas můžu dát konkrétní nastavení.
Takže třeba takhle si udělám zmíněný exkluzivní přístup (žádný jiný klient v tu chvíli nesáhne na ten sink nebo source):
PIPEWIRE_ALSA='{ node.exclusive=true }' aplay -D pipewire ./test.wav

Napadají mě jen dvě situace, kdy by mi to mohlo vadit - chtěl bych co nejmenší latenci nebo bych z nějakého důvodu používal mmap přístup na zařízení (který PW emulace neumí).

3) v momentě, kdy budu na ALSA zvukovku přistupovat aplikací přímo bez PW, tak si ji zamknu pomocí příkazu pw-reserve.
https://docs.pipewire.org/page_man_pw-reserve_1.html
Jakmile aplikaci skončím, zase zámek pustím, aby se dala standardně používat přes PW.
Tzn. napíšu si buď nějaký wrapper script, nebo když to bude služba, tak třeba využiju ExecStartPre= atp.

Ukázka s komentářem:

Kód: [Vybrat]

#!/usr/bin/env bash

# Číslo karty v /proc/asound, buď se nemění a vím ho, nebo si ho vyparsuju podle názvu
CARD_NUM=1
# Název pro rezervaci je vždycky Audio a číslo, dá se zjistit i přes pw-dump
# řádek např. "api.dbus.ReserveDevice1": "Audio1"
RESERVE_DEV="Audio${CARD_NUM}"

echo "Requesting reservation for ALSA card $CARD_NUM..."
pw-reserve -n $RESERVE_DEV -r &
RESERVE_PID=$!
# zůstává běžet jako proces na pozadí, uložím si PID
# nastavím trap, aby ho ukončil, ať už skript doběhne, nebo se ukončí natvrdo
trap 'echo "Releasing reservation..."; kill $RESERVE_PID; exit' EXIT INT TERM

# Bulharská konstanta, než se zavřou připojení klienti.
# Dalo by se udělat líp, kdy bych čekal, až bude zařízení volné.
sleep 1

# Původní aplikace.. např.
aplay -D plughw:${CARD_NUM},0 "$@"


11

Hardware / Re:Zvukovka Behringer 1820 se 7.1 na Kubuntu 24.10

« kdy: 23. 03. 2026, 19:15:52 »

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.

Není zač.
A ano s tím ekosystémem okolo PW je to občas fakt komplikované - takže to může působit přes ruku.
Je to teď podle mě ve stavu, kdy do toho běžný uživatel do toho sice málokdy musí hrabat, ale na tyhle pokročilejší věci to může být občas docela boj. Některé kroky dává smysl udělat jen ve WirePlumberu (aby se to dynamicky aplikovalo třeba podle konkrétního zařízení, jména procesu, nebo naopak nepřeráželo), některé zas staticky na úrovni configů PipeWire a pak je tam překryv toho, co jde udělat v obojím. Do toho ještě systemwide vs. lokální a nakonec dvě syntaxe - SPA-JSON a Lua (samotné skriptování pro složitější záležitosti ve WP) a také si jde vybrat, jestli to udělám pravidly nebo třeba ze skriptu s pomocí pw-cli.
Nakonec ještě ta emulovaná API (Pulse, JACK, ALSA), která se nastavují buď svými configy nebo pomocí systémových proměnných.

12

Hardware / Re:Zvukovka Behringer 1820 se 7.1 na Kubuntu 24.10

« kdy: 22. 03. 2026, 23:08:57 »

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..

13

Hardware / Re:Zvukovka Behringer 1820 se 7.1 na Kubuntu 24.10

« kdy: 22. 03. 2026, 22:47:38 »

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

Kód: [Vybrat]

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

14

Hardware / Re:Zvukovka Behringer 1820 se 7.1 na Kubuntu 24.10

« kdy: 22. 03. 2026, 22:43:53 »

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

15

Hardware / Re:Zvukovka Behringer 1820 se 7.1 na Kubuntu 24.10

« kdy: 22. 03. 2026, 21:51:03 »

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.