Poslední příspěvky

1

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

« Poslední příspěvek od Michal Šmucr kdy Dnes v 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

2

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

« Poslední příspěvek od Michal Šmucr kdy Dnes v 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

3

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

« Poslední příspěvek od RDa kdy Dnes v 22:33:10 »

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

4

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

« Poslední příspěvek od redustin kdy Dnes v 21:57:43 »

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

5

/dev/null / Re:Nechali byste si do mozku implantovat čip?

« Poslední příspěvek od Mlocik97 kdy Dnes v 21:51:26 »

Ja vôbec nechápem prečo ľudia majú potrebu cpať do svojho tela čokoľvek čo tam nepatrí, nie to ešte čipy... usekávame si organickú hmotu z tela, odstraňujeme dobrovoľne a svojvolne a bezdôvodne pohlavné orgány, potom tam cpeme silikón, kov, rôzne sračky, a teraz chceme ešte aj čipy... to je priam psychická choroba. Za život máme len jedno jediné ľudské telo a neslúži na experimentovanie. Čo bude o 50 rokov... dobrovolne si amputujeme ruky a dáme si robotické? Chrániť svoje telo je zakódované v DNA snáď každého normálneho jedinca, a to znamená necpať doň nič čo tam nepatrí a naopak neodoberať z neho čo netreba.

6

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

« Poslední příspěvek od Michal Šmucr kdy Dnes v 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.

7

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

« Poslední příspěvek od redustin kdy Dnes v 20:51:41 »

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.

8

Sítě / Re:Nová infrastruktura, 10-15 sekcí - VLAN? [Mikrotik]

« Poslední příspěvek od Pepek_Namornik kdy Dnes v 16:47:15 »

OK, díky všem za rady. Nebylo na to moc času tak to trvá, ale na stole to mám kromě FW a WLAN rozjeté (ne že by to nejelo, jen jsem s tím zatím nezačal).
Ty VLAN nejsou až tak složité, ale všude kde jsem na to narazil to vysvětlení není úplně ono a systémově, všude jen tuny příkladů a jak rozjet 2 VLAN na jednom-dvou routeru/switchi se statickou IP... Ale občas jen někde někdo zmíní jak to v pozadí pracuje, takže se z těch příkladů často blbě odvozuje co se týká routeru, co switche, jak páteřní switch, jak access switch... Nejlepší jsou borci na YT, co nakreslí a ukážou schéma co jdou dělat a hned na to řekne, že to má v jiném portu:D
Chápu to tak, že to co nastavuji v Bridge, tak se týká L2 switche, takže v momentě kdy se zapne VLAN filtering, tak jde komunikace s ROS do háje a swtich chip všechno řeší sám. Co se nastavuje v Interface-VLAN a nad těmi VLAN ITF, tak je L3 tlačící provoz do CPU a HW offload to neodřeže. Takže switche a porty se nastavují v Bridge (+1x MGMT VLAN), router je zase prakticky celý nastavený v interface. Pokud bych nechtěl na GW využít prázdné porty pro testovací přístup do jednotlivých VLAN, tak bridge na GW prakticky není potřeba (dalo by se všechny VLAN natlačit přímo na SFP1).
Nechce se mi anonymizovat celé schéma, tak jen stručný popis se zaokrouhlenými počty...
GW - 5009. SFP na páteřní switch, ETH1 WAN, ETH2-7 testovací přástup do vybraných VLAN, ETH8 MGMT (vlastně stejně jako 2-7, jen jiné číslo VLAN)
Páteřní switch - 317, vše spojené sem přes DAC / Maxlink BiDi. VLAN průchozí - pouze ETH1 pro MGMT
PoE switch 328 - 8x kamera, 6x wifi, 4x další PoE... Pro WiFi trunk, pro koncové zařízení access
Pracoviště+byty switche - 3x 310 a 2x 326 - ETH access porty, SFP1 trunk, SFP2 - hybrid záložní trunk + MGMT přes S-RJ01
Jestli se to někomu bude chtít projít a případně by k tomu měl nějaké připománky, určitě uvítám. Zatím to nejde do provozu, ale v principu by se to už moc měnit snad nemuselo (doplnění firewallu a wifi, případně u koncových acess switchů ořežu všechny VLAN na pouze potřebné)

Nastavení GateWay RB5009 (kromě obecných nesouvisejících věcí jako DNS, NTP...):

Kód: [Vybrat]

/interface bridge
add frame-types=admit-only-vlan-tagged name=bridge1 protocol-mode=none vlan-filtering=no #vlan-filtering až na konci po nastavení VLAN

# L2 rozhraní - aby jim šly přidělit IP a routovat je, "správa VLAN"
/interface vlan
add interface=bridge1 name=vlan10 vlan-id=10
add interface=bridge1 name=vlan20 vlan-id=20
add interface=bridge1 name=vlan30 vlan-id=30
...
add interface=bridge1 name=vlan99-MGMT vlan-id=99
add interface=bridge1 name=vlan100-Public vlan-id=100
add interface=ether1 name=vlan848 vlan-id=848

# Porty do bridge - SFP je trunk - pouze nastavení only tagged, zbytek je testovací přístup do VLAN - untaged access porty
/interface bridge port
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=sfp-sfpplus1
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=10
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=20
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=30
...
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether8 pvid=99
# Před rozjetím je dobré jeden port nechat mimo bridge - pokud se podělá přístup, aby se dalo z Winbox připojit na MAC a opravit to, do Bridge ho dát až to celé funguje i a je ověřené přes VLAN

# Trunk port - všechny VLAN pustit do SFP směrem na páteřní switch - musí se pro TRUNK. Pro untagged access a L3 VLAN interface se přidá samo dynamicky
/interface bridge vlan
add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=10-100

# DSL připojení přes terminátor
/interface pppoe-client
add add-default-route=yes disabled=no interface=vlan848 name=pppoe-out1 user=o2...
/ip firewall nat
add action=masquerade chain=srcnat comment="NAT na WAN" out-interface=pppoe-out1

# IP adresy a DHCP servery pro jednotlivé sítě
/ip address
add address=192.168.10.1/24 interface=vlan10 network=192.168.10.0
add address=192.168.20.1/24 interface=vlan20 network=192.168.20.0
add address=192.168.30.1/24 interface=vlan30 network=192.168.30.0
...
add address=192.168.99.1/24 interface=vlan99-MGMT network=192.168.99.0
add address=192.168.100.1/24 interface=vlan100-Public network=192.168.100.0

/ip pool
add name=pool10 ranges=192.168.10.100-192.168.10.200
add name=pool20 ranges=192.168.20.100-192.168.20.200
add name=pool30 ranges=192.168.30.100-192.168.30.200
...
add name=pool99 ranges=192.168.99.100-192.168.99.200
add name=pool100 ranges=192.168.100.100-192.168.100.200

/ip dhcp-server network
add address=192.168.10.0/24 dns-server=192.168.10.1 domain=p1.local gateway=192.168.10.1 ntp-server=192.168.10.1
add address=192.168.20.0/24 dns-server=192.168.20.1 domain=p2.local gateway=192.168.20.1 ntp-server=192.168.20.1
add address=192.168.30.0/24 dns-server=192.168.30.1 domain=p3.local gateway=192.168.30.1 ntp-server=192.168.30.1
...
add address=192.168.99.0/24 dns-server=192.168.99.1 domain=sys.local gateway=192.168.99.1 ntp-server=192.168.99.1
add address=192.168.100.0/24 dns-server=192.168.100.1 gateway=192.168.100.1 ntp-server=192.168.100.1

/ip dhcp-server
add address-pool=pool10 interface=vlan10 lease-time=10m name=server10
add address-pool=pool20 interface=vlan20 lease-time=10m name=server20
add address-pool=pool30 interface=vlan30 lease-time=10m name=server30
...
add address-pool=pool99 interface=vlan99-MGMT lease-time=10m name=server99
add address-pool=pool100 interface=vlan100-Public lease-time=10m name=server100

#Zapnout vlan-filtering... na GW celkem zbytečné - všechno se stejně routuje/NATuje...
Konfigurace páteřního SFP switche CRS317 (nerozlišuji, kde je která VLAN, všechno všude - asi ne ideální bezpečnost, ale všechno můžu libovolně přeházet a pořád to funguje):

Kód: [Vybrat]

/interface bridge
add frame-types=admit-only-vlan-tagged name=bridge1 protocol-mode=none vlan-filtering=no #vlan-filtering až na konci po nastavení VLAN

# MGMT přístup do nastavené ROS, jinak switch chip všcehno požere a switch je nedostupný
/interface vlan
add interface=bridge1 name=vlan99 vlan-id=99
/ip dhcp-client
add default-route-tables=main interface=vlan99

# Všechny SFP jako trunk, pouze eth1 jako access port pro MGMT
/interface bridge port
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=sfp-sfpplus1
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=sfp-sfpplus2
...
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=sfp-sfpplus16
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether1 pvid=99

# Nastavení všech VLAN na všechny SFP - musí se pro TRUNK. Pro untagged access a L3 VLAN interface se přidá samo dynamicky
/interface bridge vlan
add bridge=bridge1 tagged="sfp-sfpplus1,sfp-sfpplus2,...,sfp-sfpplus16" vlan-ids=10-100

#Zapnout vlan-filtering
Konfigurace koncových access switchů CRS310/326:

Kód: [Vybrat]

/interface bridge
add frame-types=admit-only-vlan-tagged name=bridge1 protocol-mode=none vlan-filtering=no #vlan-filtering až na konci po nastavení VLAN

# MGMT přístup do nastavené ROS, jinak switch chip všcehno požere a switch je nedostupný
/interface vlan
add interface=bridge1 name=vlan99 vlan-id=99
/ip dhcp-client
add default-route-tables=main interface=vlan99

# Všechny porty jako untagged acces, jen SFP1 jako TRUNK, SFP2 jako hybrid záložní trunk + MGMT přes S-RJ01
/interface bridge port
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether1 pvid=10
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=10
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=10
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=20
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=20
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether6 pvid=20
...
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether99 pvid=100
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether100 pvid=100

add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=sfp-sfpplus1

add bridge=bridge1 interface=sfp-sfpplus2 pvid=99

# Nastavení všech VLAN na oba SFP - musí se pro TRUNK. Pro untagged access a L3 VLAN interface se přidá samo dynamicky
/interface bridge vlan
add bridge=bridge1 tagged=sfp-sfpplus1,sfp-sfpplus2 vlan-ids=10-100

#Zapnout vlan-filtering
Pokud tedy chci port přehodit z jedné sítě do druhé (a na switchi mám příslušné VLAN přivedené TRUNK portem), tak jen na portu přepíšu PVID a to je vše...

9

Hardware / Re:Zalohovanie dat na Blu-ray

« Poslední příspěvek od Martin Poljak kdy Dnes v 16:43:37 »

S HDD (mechanické) mám takovou zkušenost že odcházejí tak po 3 až 5 letech provozu (. Další disk ať už je rotační či SDD je sázka na stále stejnou technologii a tím zvyšování rizika.

Co s těmi disky, proboha, děláte? V desktopu, který používám jako NAS mám disky staré i deset let a fungují úplně normálně. Jako ano, ty disky se tak 98 % času netočí, ale to bych od HDD používaných jen k zálohování fotografií tak nějak očekával také.

10

/dev/null / Re:Distro SLAX - fantastická úprava kernelu

« Poslední příspěvek od Martin Koleček kdy Dnes v 13:57:57 »

používám tento linux od roku 2013 , když něco budete chtít vědět můžete se mě na to zeptat tigerhareram@gmail.com

tady jsem tomu vytvořil strom svých úprav a historie : https://drive.google.com/drive/folders/1TRRcV-naolBYOorlzxkvqkyZHZUus-rG?usp=sharing