Příspěvky

1

Distribuce / Re:Pomoc s orientací v současných distribucích

« kdy: 12. 08. 2026, 11:05:23 »

@kopevi2

Ty problémy ale přeci vůbec nemusí souviset s Waylandem nebo desktopovým prostředím.
Pokud ve Wayland DE pustíte nějakou X11 desktopovou aplikaci, typicky se normálně vykreslí přes XWayland.
Navíc si to můžete jednoduše vyzkoušet, abyste oboje vyloučil.. nevím, co máte za distribuci doma, co vám nechodí.. ale mělo by stačit buď v SDDM spustit Plasmu v X11 režimu (pokud už nemáte nějaké distro, kde to vůbec není), nebo třeba přidat jednoduchý X11 WM.. např. icewm, otevřít si tam Xterm a spustit. Pokud to nezabere, tak to tím není, a můžu odinstalovat všechny zbytky po X11, co se tam přidaly (uložil bych si log z APT, abych viděl co se tam přesně na pokus přidalo).

Ale já bych to na to moc netipoval.. může to být cokoliv jiného, jiné Java JRE.. nějaké chybějící bindingy, adresáře, syst. proměnné.
Pokud selže instalátor a spouštíte to jen rovnou přes nějaký JAR soubor, tak je dost pravděpodobné, že vám bude oproti celé instalaci něco dalšího chybět.

Osobně bych začal od toho instalátoru, spustil ho z terminálu, díval se do logů nebo nějakého stderr výstupu, co mu chybí.. zkouknul v práci (na tom funkčním setupu), jestli třeba nepoužívá své privátní JRE (což občas u některých aplikací bývá), místo systémového.
Případně postupně porovnal mezi sebou ta obě prostředí, včetně třeba těch zmíněných systémových proměnných (v bashi zadat env).

Takže nemám nějaké obecné magické řešení, ale zkusil bych prostě postupně dohledávat, proč to neběží. Poměrně často tohle nastává, pokud jde třeba o nějakou komerční aplikaci, která je výrobcem podporovaná jen na pár distribucích a verzích (typicky RHEL, Ubuntu LTS) a může pak předpokládat určité verze knihoven, jsou tam hardcodované nějaké cesty atp. Takže když to člověk chce rozjet jinde, tak to třeba jde, ale musí se s tím trochu potrápit.

2

Distribuce / Re:Pomoc s orientací v současných distribucích

« kdy: 11. 08. 2026, 14:32:54 »

Jen se zeptám, proč trváte na těch .deb balíčcích? Jakože máte třeba nějaké své balíčky, co si sám sestavujete? Jinak je to možná trochu jedno, pokud v repozitářích distribuce najdete software, který chcete/potřebujete. Čímž by se vám otevřely i dveře k nějakým dalším distribucím Fedora, Arch atp.

A stran zkoušení různých DE, kompozitorů atp. Není jednodušší si prostě doaktualizovat Ubuntu na nejnovější verzi, pro sichr udělat nějakou zálohu (nevím jak to máte nastavené, ale od image fs třeba přes partclone, až po různé Btrfs snapshoty). Pak do systému přidat, co chcete vyzkoušet a případně se vrátit.. To Ubuntu je tak majoritní distro, že má buď ve svých repozitářích nebo PPA skoro všechno.. od Cosmicu, přes Hyprland, LXQt.. a jen si otestovat, že má pro vás smysl, dál si s tím hrát.
Obdobně se ty distribuce dají otestovat třeba v lokálním KVM hypervizoru (např. s libvirt/virt-viewer) jako virtuály.. Není to samozřejmě stoprocentní, třeba rozjet EGL grafickou akceleraci uvnitř bývá trochu oříšek, ale na základní seznámení se systémem to většinou stačí i bez ní.

Jinak stran těch fokusovaných, odvozených "mikrodistribucí" (core tým má pět lidí a nestojí za ním žádná větší firma nebo komunita), mě to osobně nikdy netáhlo.. ale chápu, že pro někoho může být zajímavé, že je to celé přednastavené do jednoho koherentního nabarveného desktopu a zas ho nemusí trápit, že to má třeba nulovou podporu pro 99.5 % balíčků, co se jen přebírají.. nebo někdy dlouhé reakce na bezpečnostní problémy.

3

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

4

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.

5

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.

6

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.

7

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.

8

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

9

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.

10

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

11

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.

12

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 "$@"


13

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.

14

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

15

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