PipeWire - mi ez?

Fórumok

Kezdetben volt az ALSA. (A korábbiakat hagyjuk, az ALSA-nak a kernelben van jelenleg a folytatása.) Lett a Pulseaudio, amely egy felsőbb réteg az ALSA fölé, bár nem teljesen, csak részben. Most meg azt olvasom, jön a PipeWire framework, egyelőre a Pulseaudio fölé, de talán lesz ez natívan a Pulseaudio helyett is.

Valaki tájékozottabb nálam, miről is van szó, mire jó, hogyan kell használni?

https://pipewire.org/

"We are planning major changes for Fedora Workstation 32 though, where we in fact plan to ship Pipewire as a tech preview for both Jack and PulseAudio users. The way it will work is that the system will still default to PulseAudio, but we will provide either a script or a UI option to switch over to Pipewire (and back again). There is also a plan to have a core set of ProAudio applications available as Flatpaks for Fedora Workstation 32 tested and verified to work perfectly with Pipewire, the current apps planned to be included are Ardour, Carla, a2jmidid, Hydrogen, Qtractor and Patroneo, but if there is interested contributors joining the effort we could have even more. Then for Fedora Workstation 33 the idea is to ship with Pipewire as the default audio handler, but with some way for users to switch back to PulseAudio if they have a need."

(Forrás)

Olvass el!

Hozzászólások

Hát ez ez ez.. Valami, ami még a PulseAudiónál is rosszabb és végképp váltani kell miatta BSD-re!! :D

:D

Én inkább azt remélem, hogy mindaz megjavul, ami a Pulseaudio-ban rossz volt. Ott valami nagyon el van szúrva. Elhiszem, hogy nem bugos abban az értelemben, amennyiben a programozó egy ideális világba képzeli magát, amikor is neki mit sem kell tudnia arról, hogyan működik a számítógép, továbbá arról sem kell semmit tudnia, amire a programot írja, elég, ha van egy specifikáció, majd azt szemellenzősen implementálja, ignorálva a gyakorlati problémákat.

Tehát lehet, hogy nem bugos a Pulseaudio, csak nem veszi figyelembe a Linux kernel ütemezőjének tulajdonságait, az ALSA driver-ek egy részének adottságait, s így tovább. A tapasztalatom így a 13-as verziót használva még mindig az, hogy ha valamiért - például resampling - viszonylag sok futásidőt eszik, akkor recseg-ropog a hangja, buffer underrun lesz.

Talán egy új megközelítés, egy más elképzelés és implementáció jobb, robosztusabb, megbízhatóbb kódot eredményez. Most úgy vagyok vele, hogy a Pulseaudio-t nehéz alulmúlni minőségben, noha nyilván nem lehetetlen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Még sose próbátam a PipeWire-t, írhatnál róla tapasztalatokat. Bár lehet tényleg simán jobb lesz, mint a Pulseadio, mivel ezt legalább nem Poettering jegyzi, úgyhogy ki tudja.

Nekem egyébként a Pulseaudio-val sem volt soha bajom, sose recsegett, ropogott, mindig működött, de nem szeretem, mert túl bloat, az én igényeimet egy egyszerű ALSA is kiszolgálná.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Meglepődtem a hozzászólásodon. Nem kezdem visszaolvasni magam, de ebben a topicban szerintem írtam a tapasztalataimról. Röviden: jó. :) Tetszik, hogy van alsa, jack, pulseaudio és természetesen natív pipewire interface-e, s ezeket szimultán, egy időben is használhatod. Megfelelő jack klienssel - pl. Carla - grafikus felületen kötözgetheted a bemeneteket, kimeneteket, mintha kábeleznél egy keverőpultot. Kicsi az erőforrásigénye, jóval kevesebb futásidővel beéri, mint a pulseaudio. Számomra egyetlen hátrány jelenleg, hogy a visszhangelnyomás még nincs implementálva. VoIP-hoz kellene.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem maga a PulseAudio, mint eszköz jó lenne. Mármint itt a megvalósítás valahol nagyon hibásra sikerült, de ha tényleg tudná hibátlanul azt, amire kitalálták, akkor szeretnék az emberek.

Akinek mondjuk két mikrofonja is van a gépen, és azt szeretné, hogy az egyik program csak az egyik hangját rögzítse, a másik meg a két mikrofont egyben, sztereó sávban, azt a PulseAudio előtt nem nagyon tudtam összehozni, mert ha az egyik program már figyelt egy eszközt, akkor a többi nem tudta használni. Emlékszem, hogy egy időben azzal is gond volt, hogy valamelyik programból már szólt a zene, így a másik program nem tudott ugyanazon az eszközön hangot lejátszani, mert éppen foglalt volt.

Remélem második nekifutásra sikerül megcsinálni tisztességesen.

Nagy Péter

Azzal kiegészítve, hogy a pipewire jack interface-ének felhasználásával akár grafikusan is kötözgetheted még lejátszás közben is a jelfolyamot. Közben persze az audio kliens lehet, hogy pulse illetve alsa interface-en csatlakozik hozzá, akár vegyesen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az úgy nem ér ám hogy az ábrán hagyjuk a legacy fosokat, amiket már egyik Linux se telepít, legalábbis nem defaultból :) Például az ESD valamikor a pubim környékén jött ki, azóta se weboldala, se létjogosultsága, se semmije :)

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Megpróbáltam megnézni ezt az egyetlen francos png képet amit belinkeltél. A kép helyett megjelent egy üzenet hogy engedélyeznem kell a jávaszkriptet. Engedélyeztem. Erre jön hogy ő valamiért ellenőrzi a browseremet...

MI A TÖKÖM...?!

De jól van ellenőrizze. Ez kb 5 teljes másodpercig tartott, a faszom tudja miért...

Ezután jött valami fura oldal, hogy valami captcha-t kéne kitöltenem...

Hát bassza meg az oldal meg a tervezője ahol van! Visszavontam minden temprary engedélyt tőle, és otthagytam a picsába... velem ennyit ne szórakozzon egy oldal egy tetves png kép megnézése érdekében! Inkább lemondok róla!

Köszi.

Nekem a képből az jön le, a helyes megoldás egyelőre az ha maradunk az ALSA mellett, mert az egyrészt közvetlen kapcsolatban áll az aktuális output audio device-vel, másrészt amúgyis eléggé megkerülhetetlen mert az ábra központi helyén látható és nagyjából minden kapcsolódik hozzá amúgyis.

E kép megerősít abban az érzésben hogy jól döntöttem amikor a magam LFS-based disztrójába csak az ALSA-t telepítettem és nem a pulseaudiót meg más efféle izémizéket.

Azért ez kicsit más mint a pulse, nem csak hang, hanem multimedia framework.
Ami nagyon nem tetszik benne az az, hogy gnome/gstreamer kötődést látok benne, de majd meglátjuk. Elég sokat ígérnek (Capture and playback of audio and video with minimal latency. Real-time Multimedia processing on audio and video. Multiprocess architecture to let applications share multimedia content.), ami ha rendesen megvalósulna, azért elég jó lenne.

Üdv ! Ritkán szólok, de most megérkezett a tegnapi Manjaro frissítéssel a Pipewire. Úgy vettem észre, hogy minden frissítés után ellenőrzök néhány alkalmazást, hogy rendben van-e. Elindítottam a Virtuálboxban egy W7-t és rövid időn belül  (2-3 perc) a gép, nem a program, kiakadt.  Megismétlem, újra.  Deepin elinditva: egy exec nevü valami már 60% ra viszi a CPU-t, ás 8,3 GB-nál tart a memória foglalása. Mi ez ? pipewire-media-session . Kilövöm, minden oké. Újraindítás: kezdődik elölről. Mindez viszont csak Plasma alatt, Gnome -al nem. 

Más. Kb decemberben kíváncsiságból telepítettem a manjaro-gnome-ra a plasma desktopot. Korábban valahányszor ránéztem a KDE-re, hanyatt homlok menekültem belőle, hogy finom legyek. Most azonban azonnal ott ragadtam. Egyszerűen lenyűgözött.  A tegnapi manjaro frissítés szépen széttúrta a gnome asztalt, katasztrófálisnak érzem a visszafejlődést, már azt is el tudom képzelni, hogy ez szándékos....

Kérdésem most csak annyi: másnál is előfordul, hogy ez a pipewire nevű újabb izé megeszi a teljes memóriát vagy csak nálam van a hiba?

Itt van róla egy  https://archive.fosdem.org/2019/schedule/event/pipewire/attachments/slides/2826/export/events/attachments/pipewire/slides/2826/PipeWire.pdf

Én nem tudom ti mit futtattok, mit hallgattok, milyen vájt-fűlűek vagytok, de nekem a KDE-vel és a Pulseaudioval nincsen semmi bajom Mageia Linuxon. Nem recseg, nem zabál. S mindez az alaplapi MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio-val. Igaz, nem vagyok zeneszerző.

Valószínűleg Lennart Pöttering is a works for me miatt nem kereste és nem találta a bugot. Ha olyan alkalmazást futtatsz, mint a Seren peer to peer VoIP alkalmazás, amely nem csak lejátszik, hanem kétirányú az audio stream, nem bufferelhet egy másodpercet, mert akkor szétesik a beszélgetés, kell visszhang elnyomás, amelyet a Pulseaudio biztosít, továbbá resampling, mert a Seren fix 48 kHz mintavétellel dolgozik, a hangkártya meg 44.1 kHz-en, valamint a Seren az Alsa kompatibilitási rétegen keresztül kommunikál a Pulseaudioval - tudom, mert megnéztem a forráskódját -, szóval ebben a nem legegyszerűbb esetben bizony sokszor buffer underrun-nal illetve overflow-val térnek majd vissza azok a függvény, amelyik átadják, átveszik az audio buffereket. Ezt is tudom a Seren debug üzeneteiből, konkrétan megnéztem, mikor írja ki ezt a hibát, s ez bizony Pulseaudio bug. Ekkor lezárja a Pulseaudio a stream-et, majd azt újra meg kell nyitni, ez idő, majd folytatni a lejátszást. Hidd el, gorombán recseg-ropog, annyira, hogy érthetetlenné válik a beszélgetés.

Workaround valamelyest, ha kikényszerítem, hogy a hangkártyát hardware-esen 48 kHz-en használja, akkor nem kell resampling. Viszont a kernel ütemező nem feltétlenül úgy osztja a futásidő szeletkéket, hogy az a Pulseaudionak kényelmes legyen, ekkor a kliens és a szerver egymásra várnak a bufferek átadásakor, mindkettő sok futásidőt visz el, vergődik az egész, és kegyetlenül recseg-ropog a hang.

Ez az, amit végre pipewire használata esetén nem tapasztalok. A pipewire törekszik arra, hogy nem mozgat adatot, csak a pointereket adja át, így a működése amíg csak lehet, copyless.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

plasma nalam akkor lett felejtos, amikor a hulladek electron appok terheleset megduplazta valami kde-s process (talan naplozo, vagy hasonlo). Sajna az appot melo miatt nem tudom megkerulni, maradt a desktop csere. De van tobb ilyen is, pl slack call nalam nem szerette a tilingWM-eket (i3/sway), szoval back to basics = openbox.

miért érzem azt, hogy valaki már megint nekiáll csillaghajót építeni oda, ahova a csónak is pont tökéletes lenne, csak a víz fölött maradjon :)

https://goo.gl/muWzKz (digitalocean)

Szerkesztve: 2020. 03. 27., p - 15:11

(nem ide, törölhető)

Szerkesztve: 2020. 09. 09., sze - 00:34

Már vagy három perce pipewire-on keresztül hallgatok zenét. Ez még kevés ahhoz, hogy blogoljak róla. Kevés futásidőt eszik, úgy tudom, a tervezésnél szempont volt, hogy nem másolgat buffereket, csak a pointereket adja át. Persze nyilván van, amikor kell futásidő, például resampling esetén.

pactl info | grep ^Server
Server String: pipewire-0
Server Protocol Version: 33
Server Name: pipewire-0
Server Version: 0.3.10

Szerk.: Ami borzalmas, nekem úgy tűnik, hogy a hangerő szabályozás lineáris. A fülünk amplitúdóban - és frekvenciában is, de ez itt nem érdekes - logaritmikusan hall.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hihetetlen, hogy a modern programozó nem hallott életében a B-s potméterről. Van egy Samsung LED TV-m ... ott is mindig felb*sz a hangerőszabályozó. Lineáris. Elejét nem tudod finoman szabályozni, 15..100% között pedig alig ér valamit.
Pedig ...  gain = pow(10, decibel/20) lenne C-ben és a skálát máris decibelskálán lehetne húzni. Tehát abszolut nem rakétatudomány.

Néha úgy érzem, hogy visszafejlődtünk bizonyos dolgokban az elmúlt néhány évtizedben. Vagy csak elfelejtjük és majd újra feltaláljuk mindazt, amit már egyszer tudott a világ.

Szerkesztve: 2020. 09. 09., sze - 22:53

No, mondom az eddigi tapasztalataimat, amelyek erősen szubjektívek. Feléleszteni nagyon könnyű, a függvényei többé-kevésbé pulseaudio és jack kompatibilisek, így ezek az alkalmazások elvileg működnek majd minden nehézség nélkül. Aki kísérletezni szeretne vele, itt nézzen körül.

Ha bluetooth-szal is játszani szeretnénk, mentsük a /etc/pipewire/pipewire.conf file-t például oda, mellé pipewire.conf.orig néven, majd szerkesszük a /etc/pipewire/pipewire.conf file-t. A végén a -d bluez5 részt  kell törölni, talán így világosabb:

diff -u pipewire.conf.orig pipewire.conf
--- pipewire.conf.orig	2020-08-18 13:41:17.000000000 +0200
+++ pipewire.conf	2020-09-09 20:23:42.908433936 +0200
@@ -74,4 +74,4 @@
 # Execute the given program. This is usually used to start the
 # session manager. run the session manager with -h for options
 #
-exec /usr/bin/pipewire-media-session -d bluez5 # -d alsa-seq,alsa-pcm,metadata
+exec /usr/bin/pipewire-media-session # -d alsa-seq,alsa-pcm,metadata

Viszont azt tapasztaltam, hogy a bluetooth csak olyan alkalmazással megy pipewire-en keresztül, amelynek van közvetlen alsa interface-e, ott meg is fog jelenni eszközként a pipewire média szerver. Ilyen alkalmazás például az audacious, ha alsa-t mondunk neki audio kimenetként, azon belül meg pipewire-t. Így hát a firefox bizony nem képes bluetooth interface felé lejátszani. Ugyanakkor a pipewire pulseaudio interface-ű alkalmazásokkal egész jól működik, ha valamilyen hangkártya, vagy usb-s audio interface-ünk van.

Ha például online rádió hallgatása közben leszakad egy kis időre az audacious a hálózatról, s nem tudja tunkolni az audio buffert, akkor nem elakad a lejátszás, nem záródik le a stream, hanem jár tovább a read pointer, s a buffer underrun miatt ciklikusan ismétli az utolsó buffer tartalmát, ami legfeljebb néhány tized másodperc. Olyan, mintha megfagyott volna az egész, pedig nem. :)

Legnagyobb meglepetésemre a seren nevű p2p terminálos/konzolos ncurses VoIP alkalmazás is megy pipewire-rel. Külön izgalmas volt, hogy a seren warningban jelezte, hogy nincs implementálva egy általa hívott függvény. Ahhoz képest működött. :)

Hangerő szabályozására, a stream-ek kezelésére érdemes használni a pasystray nevű alkalmazást. Ez egy keretrendszer, jó ha van pavucontrol, pavumeter, paman, mert ezek kellenek hozzá.

Nagyon karcos, kidolgozatlan még a project, de ígéretes. Ami hihetetlenül tetszik, hogy a pipewire futásidő igénye igen alacsony. Míg a seren-t használva a pulseaudio megeszik 15 %-ot, a seren, ugyanennyit, a pipewire használatával a seren 16 %-ot, a pipewire 1.8 %-ot, de többször 1 % alatt. Ráadásul a pulseaudio hangja teljesen szétesik, recseg-ropog, buffer underrun, ha a kernel ütemezője rossz fázisban ad futásidőt a pulseaudio hangszervernek és a seren kliensnek. Ez a probléma úgy tűnik, pipewire használatával végre orvosolódni látszik.

Carla nevű klienssel grafikusan lehet huzalozgatni akár valós időben, lejátszás közben a stream-et, mintha dugdosnánk a drótokat a keverőben. Így például fel lehet cserélni a bal és jobb oldalakat.

A hangerőszabályozó linearitása meg az a pont, ami végtelenül elszomorít. Egy programozónak nem csak programozni kell tudni, hanem annak az eszköznek a fizikáját is ismernie kell, amelyre a programot írja.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

pgrep -l 'pulse|pipe'
1909 pipewire
1931 pipewire-media-

Tehát nem megy a pulseaudio, megy a pipewire és szól. Mondjuk még egy rakás váratlan hibával, az igaz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ma kijött a 0.3.11-es pipewire. Ezzel már mennek a pulseaudio interface-szel rendelkező kliensek bluetooth-on is, bár egy-egy rövid pillanatra elakad a hang, de ezt csak bluetooth eszköznél tapasztalom. Viszont pl. YouTube video esetén a kép siet a hanghoz képest. Úgy látom, szépen fejlődik, ha még messze is van a tökéletestől.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tegnap jött még egy patch hozzá ezzel az általános megjegyzéssel:

- Add some patches to improve pulse compatibility

Azóta megy az audacious pulseaudio interface-en keresztül. Meg SDL-en is. Amúgy jack-en és alsa-n szintén. Egyedül annyi, hogy jack interface esetén a resampling-et a kliensnek kell elvégezni, így több futásidőt eszik. A legkevesebb futásidőt akkor eszi, ha a pipewire-hez alsa interface-en csatlakozik. Kicsivel több futásidőt eszik, ha a pulseaudio vagy SDL interface-t használjuk.

Van egy bosszantó jelenség. Amikor megjelenik egy új kliens, az éppen lejátszás alatt lévő stream egy pillanatra elakad.

Csináltam egy olyat, hogy audacious online rádió hangját játszotta le USB-s mikro-HiFi erősítőn, míg a Firefox egy bluetooth fülhallgatóra küldte a klip hangját. Mivel a bluetooth sajnos még nincs jól implementálva, akadozott a hang.

Tegnap néztem néhány videót a YouTube-on, s azt vettem észre, a video kicsit siet az audio stream-hez képest.

Mindezen gyermekbetegségek ellenére az látszik, hogy ez a cucc sokkal jobb lesz, mint a pulseaudio.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Eleinte szkeptikus voltam, és még nem is mertem kipróbálni - igaz ez most leginkább időhiány miatt vár. De kösz, hogy megosztod a tapasztalataid!
Ugyan nálam a pulse régóta teszi a dolgát gond nélkül, de emlékszem még, hogy anno mennyi nyűg volt vele, ez meg már most ígéretesebbnek tűnik.

A pulseaudio addig teszi a dolgát, amíg úgy használod, hogy nem jön elő egy mindig is fennálló bugja. Kap valamennyi futásidőt a kliens, valamennyit a pulseaudio szerver. Az ütemező a kernelben van, a kernel számára a kliens és a szerver is csak egy program, s aszinkron kerülnek ütemezésre. Igaz, hogy a szerver magasabb prioritással és nice-szal fut, de ez sem old meg mindent. Aztán van, hogy olyan ügyetlenül jönnek ki a dolgok, mint a közlekedésben egy „piros hullám”. Az egyik arra vár, hogy átadjanak neki egy buffert, a másik, hogy elvegyék tőle. Ez csak sejtés, de az már tapasztalat, hogy ekkor a pulseaudio - és jellemzően a kliens - futásideje megnő, majd a hang elkezd recsegni, ropogni. Külön jó, ha az audio stream két irányban megy pl. egy VoIP alkalmazás esetén. Akkor ennek a jelenségnek nagyobb az esélye.

A pipewire sem jó még, messze nem, de több esélyt látok arra, hogy megjavuljon, mert még nagyon az út elején jár. A seren VoIP klienst mindkét oldalon - távoli asztal eléréssel a távoli gépen - néhányszor újra kellett indítanom, hogy felépülhessen a kapcsolat. Zenét hallgatni tudok vele, bár bluetooth-on még nem. Értem, hogy erre nagyjából a kernel fölött az alsa-lib is elég volna, de a szándék látszik. Egyszerre képes pulseaudio, alsa és jack API-t nyújtani a kliensek felé.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kap valamennyi futásidőt a kliens, valamennyit a pulseaudio szerver. Az ütemező a kernelben van, a kernel számára a kliens és a szerver is csak egy program, s aszinkron kerülnek ütemezésre

Azert az milyen szep mar hogy egy durvan megabites adatfolyam max ~10k-nyi bufferelest igenylo kvazi valosideju manageleset egy kasznin belul 2020-ban nem lehet hatekonyan megoldani es kiscsilliard "audiorendszer" kell ahhoz hogy egyatalan valami menjen. Ugyahogy. Vagy lehet hogy mindenki azt hiszi hogy "ah, ez milyen egyszeru problema, nosza irjunk egyet mert epp van egy szabad delutanom?" ;) 

Nem trivi'lis probléma, hiszen ha az ütemezőt meg tudjuk fűzni közel valósidejű futásra, akkor ezt más processzek is igényelhetik, s ugyanott vagyunk. Nem ismerem annyira a kernelt, hogy erről sokkal értelmesebbet mondhassak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Van már 0.3.12-es pipewire. Egy gyöngyszem a changelog-ból:

* The sink/source format_info array is now filled up completely,
    this is actually not implemented yet in the real PulseAudio.

Hány éves a PulseAudio? És mikori a PipeWire? Ezek szerint a pulseaudioban a mai napig nincs rendesen kitöltve a formátum infó tömb, miközben a pipewire-ben ez épp elkészült. Vicces.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tehát apt remove pulseaudio && apt install pipewire után menni fog minden, vagy ennél azért többet kell mókolni?

Psszt, elárulom az IP-címemet: 192.168.0.14

Van a bevezetőben egy Olvass el! link. Olvasd el! :)

Szerk.: Nem kell eltávolítani a pulseaudio-t. A pipewire telepítése után kell csinálni talán 6 db symlinket, és kell egy ldconfig parancs.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Már van 0.3.13. Még nem volt időm megtapasztalni, a gyakorlatban mitől jobb az előző verziónál. A pasystray még belepusztul, ha találkozik a pipewire-rel. Bár nem minden esetben, és nem tudom, ez mitől függ.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csináltam egy git clone-t az aktuális forrásából, aztán lefordítottam, rpm csomagot csináltam belőle, majd frissítettem, hiszen már öt napja nem készült belőle friss build, ami már-már tarthatatlan. :) Persze, működik ez a legfrissebb házi build.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nagyon sok commitot tolt bele Wim, az aktuális állapotot kihúztam a git repóból, lefordítottam, feltelepítettem. Érzékelhetően javult.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kérdés: Mennyire drop-in replacement ez most a pulseaudio-ra nézve? Egy csomó szoftver van, amit azért száműztem a gépemről, mert pulse kellene neki, de ha ez tényleg működik (nem eszi meg reggelire a CPU-t, nem leakel, nem recsegteti kiszálláskor a fel nemszabadított buffereit - mint teszi a PA), akkor berakhatom helyette ezt.

Nagyon. Na jó, egyre jobban, folyamatosan implementálódnak az esetlegesen még hiányzó részek. Elég, ha annyit mondok, hogy már ezt használom pulseaudio helyett? A vicces, hogy egyes alkalmazásokat alsa, másokat pulseaudio interface-én keresztül, miközben a Carla segítségével jack interface-en grafikusan lehet kötözgetni, mi mivel legyen összekötve, bár ezt pulseaudio interface-en például a pasystray segítségével is megteheted. Tetszik a játék, mert noha messze nincs még kész, napról napra egyre jobb. Egyelőre nagyon hiányolom a visszhang elnyomást. A bluetooth nagyjából működik, de Wim szerint az még munkás, hogy korrekt legyen. Ezt értsd úgy, hogy munkahelyen már tudok zenét hallgatni pipewire-en keresztül bluetooth-on.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

top -p `pgrep -d, 'pipewire|audacious'`

top - 17:30:02 up 30 min,  1 user,  load average: 0.24, 0.30, 0.44
Tasks:   3 total,   0 running,   3 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3.8 us,  2.1 sy,  0.8 ni, 89.9 id,  2.1 wa,  0.8 hi,  0.7 si,  0.0 st
MiB Mem :   7953.2 total,   3215.9 free,   1543.8 used,   3193.6 buff/cache
MiB Swap:   8300.0 total,   8300.0 free,      0.0 used.   5857.8 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   2835 *****     20   0 1188292  77460  53076 S   3.0   1.0   0:07.57 audacious
   2265 *****     20   0  112080  13100   8324 S   0.3   0.2   0:00.76 pipewire
   2269 *****     20   0   21720   9460   6848 S   0.0   0.1   0:00.28 pipewire-media-

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A mai nap nem sikerült olyan jól Wimnek. A mai build-em eredményeképp 100 % CPU időt eszik a pipewire. Viszont így is tiszta a hangja. Visszatettem a tegnap este készített fordítást.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mik ennek a cuccnak a compile-time, ill. runtime dependenciái? Azt látom, hogy a build környezet az Python3-mal van megverve...

Virtuális gépben egy 12 éves host ócskavason beletelik talán három percbe is. :)

Mivel Fedorát használok, letöltöttem a disztribúcióhoz adott pipewire source rpm-jét, majd feltelepítettem. Utána a spec file-ban növeltem a build verziót és kigyomláltam a patch-eket. Kihúztam git clone-nal a legfrissebb forrást a project oldaláról. A forrásból töröltem a .git alkönyvtárat, mert ez nagy, és csak a verziókezeléshez kell. Ezt követően átneveztem a legfelső szintű, pipewire könyvtárat pipewire-0.3.13 nevűre, mert ezt várja a spec file. Összetömörítettem tar.gz formátumba, mert a spec így várja. Nyilván lehetne tar.xz is, de akkor módosítani kellene a spec file-t. Bemásoltam a tömörítvényt a forrás alkönyvtárba. Ezután rpmbuild -bb pipewire.spec, majd meg is vagyunk néhány perc múlva.

Ezt követően ssh-n keresztül a host-ra másolom, ezekkel a csomagokkal frissítek, majd sima felhasználóként

systemctl --user daemon-reload
systemctl --user restart pipewire
systemctl --user status pipewire

Nyilván az utolsó sor elhagyható, de szeretem látni, ha valami baja van.

A függőségét kiírja az rpmbuild, ha valami hiányzik. Épp ezért fordítok virtuális gépben, hogy egy rakás devel csomagot ne kelljen feltennem a hostra. De úgy emlékszem, nem sok. Azt hiszem, ANSI C-ben íródik, hogy gyors legyen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem a sebesség miatt rühellem elsősorban a Pythonos buildkörnyezeteket, hanem a spagettiság és a szemetelés miatt. Szeretnék leforgatni egy akármilyen programot és a fél világot fel kell rakni hozzá a gépre, mert mezon, meg ninnya, meg mittudomén.

Mindenesetre a hangsúly nem ezen volt, hanem azon, hogy mi kell neki. Nyomsz egy objdump-ot a legenerált .so-n?

Inkább a pipewire.spec file-ból idézek, szerintem beszédes, ki tudod belőle hámozni:

BuildRequires:  meson >= 0.49.0
BuildRequires:  gcc
BuildRequires:  pkgconfig
BuildRequires:  pkgconfig(libudev)
BuildRequires:  pkgconfig(dbus-1)
BuildRequires:  pkgconfig(glib-2.0) >= 2.32
BuildRequires:  pkgconfig(gio-unix-2.0) >= 2.32
BuildRequires:  pkgconfig(gstreamer-1.0) >= 1.10.0
BuildRequires:  pkgconfig(gstreamer-base-1.0) >= 1.10.0
BuildRequires:  pkgconfig(gstreamer-plugins-base-1.0) >= 1.10.0
BuildRequires:  pkgconfig(gstreamer-net-1.0) >= 1.10.0
BuildRequires:  pkgconfig(gstreamer-allocators-1.0) >= 1.10.0
%if 0%{?enable_vulkan}
BuildRequires:  pkgconfig(vulkan)
%endif
BuildRequires:  pkgconfig(bluez)
BuildRequires:  systemd-devel >= 184
BuildRequires:  alsa-lib-devel
BuildRequires:  libv4l-devel
BuildRequires:  doxygen
BuildRequires:  xmltoman
BuildRequires:  graphviz
BuildRequires:  sbc-devel
BuildRequires:  libsndfile-devel

Requires(pre):  shadow-utils
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
Requires:       systemd >= 184
Requires:       rtkit

%description
PipeWire is a multimedia server for Linux and other Unix like operating
systems.

%package libs
Summary:        Libraries for PipeWire clients
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}

%description libs
This package contains the runtime libraries for any application that wishes
to interface with a PipeWire media server.

%package gstreamer
Summary:        GStreamer elements for PipeWire
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}

%description gstreamer
This package contains GStreamer elements to interface with a
PipeWire media server.

%package devel
Summary:        Headers and libraries for PipeWire client development
License:        MIT
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
%description devel
Headers and libraries for developing applications that can communicate with
a PipeWire media server.

%package doc
Summary:        PipeWire media server documentation
License:        MIT

%description doc
This package contains documentation for the PipeWire media server.

%package utils
Summary:        PipeWire media server utilities
License:        MIT
Requires:       %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}

%description utils
This package contains command line utilities for the PipeWire media server.

%if 0%{?enable_alsa}
%package alsa
Summary:        PipeWire media server ALSA support
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}

%description alsa
This package contains an ALSA plugin for the PipeWire media server.
%endif

%if 0%{?enable_jack}
%package libjack
Summary:        PipeWire libjack library
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
BuildRequires:  jack-audio-connection-kit-devel >= 1.9.10
# Renamed in F32
Obsoletes:      pipewire-jack < 0.2.96-2

%description libjack
This package contains a PipeWire replacement for JACK audio connection kit
"libjack" library.

%package jack-audio-connection-kit
Summary:        PipeWire JACK implementation
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libjack%{?_isa} = %{version}-%{release}
BuildRequires:  jack-audio-connection-kit-devel >= 1.9.10
Conflicts:      jack-audio-connection-kit
Conflicts:      jack-audio-connection-kit-dbus
Provides:       jack-audio-connection-kit

%description jack-audio-connection-kit
This package provides a JACK implementation based on PipeWire

%package plugin-jack
Summary:        PipeWire media server JACK support
License:        MIT
BuildRequires:  jack-audio-connection-kit-devel
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
Requires:       jack-audio-connection-kit

%description plugin-jack
This package contains the PipeWire spa plugin to connect to a JACK server.
%endif

%if 0%{?enable_pulse}
%package libpulse
Summary:        PipeWire libpulse library
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
BuildRequires:  pulseaudio-libs-devel
# Renamed in F32
Obsoletes:      pipewire-pulseaudio < 0.2.96-2

%description libpulse
This package contains a PipeWire replacement for PulseAudio "libpulse" library.

%package pulseaudio
Summary:        PipeWire PulseAudio implementation
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libpulse%{?_isa} = %{version}-%{release}
BuildRequires:  pulseaudio-libs-devel
Conflicts:      pulseaudio-libs
Conflicts:      pulseaudio-libs-glib2
Provides:       pulseaudio-libs
Provides:       pulseaudio-libs-glib2

%description pulseaudio
This package provides a PulseAudio implementation based on PipeWire
%endif
 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igaz is. Gondolom, hogy az udev kell ahhoz, hogy feltérképezze, milyen audio és video eszközöket lát a kernel. Mondjuk valaki létrehoz egy bluetooth kapcsolatot, bedug egy usb-s hangkártyát, akkor ezt működés közben is látnia kell.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kihúztam git clone-nal a legfrissebb forrást a project oldaláról. A forrásból töröltem a .git alkönyvtárat, mert ez nagy, és csak a verziókezeléshez kell.

Biztos vagyok benne, hogy git esetén is van olyan lehetőség, hogy ne kelljen a fél világot leszedni csak a forráskód kedvéért - ha minden igaz, ezt a git clone --depth=1 paranccsal lehet megtenni.

Ez jogos, csak nagyobb a tanulási görbéje, mint bután kihúzni git clone-nal azt is, ami nem kell, törölni a felesleget, majd tar -czf-fel összecsomagolni. Ez olyasmi, mint amikor cat file | grep pattern formát használ valaki a grep pattern file helyett. Nyilván az első pazarló, de az esetek jelentős részében ennek semmi jelentősége nincs.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

cat file | grep pattern formát használ valaki a grep pattern file helyett.

naná hogy cat file|grep pattern!

Mert pattern változtatásához csak felfelé nyíl, pár backspace kell és lehet azonnal átírni a patternt?

grep pattern file esetén:

  1. felfelé nyíl
  2. home
  3. 5 jobbranyíl pattern p betűjéhez
  4. pattern karakterszámával egyenlő mennyiségű delete megnyomása
  5. új pattern beírása

vagy goto 2:

  1. felfelé nyíl
  2. home
  3. X darab jobbranyíl amíg pattern végére érünk
  4. Y darab backspace amíg pattern végéből visszatörlünk Y karaktert
  5. pattern átírása
  6. enter (megint elírtam patternt) - >goto 1.

Feltételezem 2Geza arra célzott, hogy Linuxon azért van szükség ilyen extra hangkezelő rétegekre az ALSA felett, mert az ALSA nem támogat olyan dolgokat, amiket ezek megoldanak, illetve a PA esetében inkább próbálnának megoldani. Az OSS4 az egyik legfejlettebb hang-alrendszer, valószínűleg ezeknek a hiányosságoknak egy jelentős részét pótolná. Részleteket ne kérdezz, mert sem az ALSA, sem az OSS4 belső működését nem ismerem annyira, hogy adekvát választ tudjak adni.

Ja, értem. Csak sejtem, hogy amikor Linus írni kezdte a kernelt, nem egy minden esetre felkészülő modell alapján kezdett kódolni, hanem nagyjából a mielőbb legyen látványos eredmény vezérfonal mentén. Ha a pulseaudio kínjait nézem, talán ott lehet a gond, hogy az ütemező nagy szabadságot enged meg magának, a valós idejű feladatok elhasalnak azon, hogy hamarabb kiszalad az adat a bufferből, mintsem megkapná a vezérlést az a process, amelyik azt megint feltölti.

Ha kellő távolból szemléled, ez egyáltalán nem triviális probléma, mert versenyhelyzet alakulhat ki. Lehet ugyan priorizálni a feladatokat, de mi van, ha egy másik process szintén roppant fontosnak gondolja magát? Egész egyszerűen adott futásteljesítménybe nem lehet végtelen sok feladatot bepakolni. A pipewire ígéretes project, mindhárom gépemen már ez a multimédia szerverem.

A fentiekhez visszatérve. Ha általános operációs rendszered van, amin bármi futhat, szerintem nem lehet garantálni, hogy egy általános audio stream, egy bármilyen általános audio hardware-en akadozás nélkül lejátszódjon. Más a helyzet, ha embedded környezetben eldöntöd, hogy ismert mennyiségű feladatot adsz a processzornak, s így garantálod, hogy a stream lejátszása belefér a futásidőbe.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Wim pénteken és ma egy rakás bluetooth a2dp patch-et tolt bele. Alakul ez, örülök neki. :) Természetesen csináltam belőle rpm csomagot, így használni is tudom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Még sajnos pár hét mire lesz időm kísérletezni. Lehet addigra lesz visszhangelnyomás is :D Szoktam néha telegramon beszélni "kihangosítva", az lehet használja. Meg talán a browserek is, mert pl jitsi meetingek sem szoktak visszhangzani. De tesztelni ezek nélkül is lehet ;)

A legutóbbi forráskód épp rossz, nálam csinál egy loopback-et az input stream-ről a kimenetre. A d55bc1eb az utolsó olyan patch, amivel nálam még jól működik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt a patch-et nem értem.

static inline uint32_t volume_from_linear(float vol)
{
	uint32_t v;
	if (vol <= 0.0f)
		v = VOLUME_MUTED;
	else
		v = SPA_CLAMP((uint64_t) lround(cbrt(vol) * VOLUME_NORM),
				VOLUME_MUTED, VOLUME_MAX);
	return v;
}

static inline float volume_to_linear(uint32_t vol)
{
	float v = ((float)vol) / VOLUME_NORM;
	return v * v * v;
}

Az egyik irányban köbgyökös, a másikban köbös. De miért? A hangerő decibelben hangzik lineárisnak, ami logaritmikus, nem pedig köbgyökös. A másik, amit nem értek, hogy miért float és miért nem double. Tudtommal C-ben a double jól definiált, szabványos típus, míg a float valami talán kompatibilitási okokból megtartott, architektúra függő képződmény.

De a köbös, köbgyökös konverzión jobban fennakadtam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Lefordítottam, kipróbáltam. Mindenképp jobb a lineárisnál így a hangerő, de természetellenes, hogy nem logaritmikus. Most átestünk a ló túloldalára. Az alsó hangerő tartományokban alig van változás, nagyon halk az egész, a felsőben viszont elég meredeken nő a hangerő.

A programozók tényleg nem hallottak arról, hogy mi a fene az a decibel, s hogy a szubjektív hangintenzítás érzet éppen logaritmikus? Pedig Wim nem fiatal, kezdő programozó.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Itt igazából az a kérdés, mi a bemeneten az értelmezési tartományunk, s ehhez a kimeneten az értékkészletünk. Az, hogy ln(), vagy 10-es alapú logaritmus, lényegtelen, mert csak konstanssal szorzás, s úgyis a kívánt értékkészletbe kell transzformálni az eredményt, tehát a kettő ekvivalens. Majd elgondolkodom rajta, aztán lehet, fordítok egyet, s ha tetszik, még az is lehet, elküldöm Wim-nek a patch-et.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Eredetileg így nézett ki:

volume = (int)round(pow(1.0 + (progression / 100.0), volume) / pow(1.0 + (progression / 100.0), 100) * volume);

Csak itt nem láttam semmiféle "progressziót", így kiszedtem, viszont az le se esett, hogy akkor az egy lesz hatványozva... Fel kéne már ébredni. :/

Most ezzel próbálkozom, de nem tökéletes:

diff -ur pipewire-0.3.13/src/modules/module-protocol-pulse/message.c pipewire/src/modules/module-protocol-pulse/message.c
--- pipewire-0.3.13/src/modules/module-protocol-pulse/message.c 2020-10-23 16:52:07.426393834 +0200
+++ pipewire/src/modules/module-protocol-pulse/message.c        2020-10-23 17:44:19.524043313 +0200
@@ -32,7 +32,7 @@
        if (vol <= 0.0f)
                v = VOLUME_MUTED;
        else
-               v = SPA_CLAMP((uint64_t) lround(cbrt(vol) * VOLUME_NORM),
+               v = SPA_CLAMP((uint64_t) lround(log((exp(1.0f) - 1.0f) * vol + 1.0f) * VOLUME_NORM),
                                VOLUME_MUTED, VOLUME_MAX);
        return v;
 }
@@ -40,7 +40,7 @@
 static inline float volume_to_linear(uint32_t vol)
 {
        float v = ((float)vol) / VOLUME_NORM;
-       return v * v * v;
+       return (exp(v) - 1.0f) / (exp(1.0f) - 1.0f);
 }

 struct descriptor {

Ugye a nehézség abban van, hogy a log(0) = -inf., s ez egy cseppet sem könnyíti meg a becsületességre törekvő honpolgár életét, mert valahol csalni kell. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez a patch-em jobbnak tűnik, azt hiszem, ennél maradok:

diff -ur pipewire-0.3.13/src/modules/module-protocol-pulse/message.c pipewire/src/modules/module-protocol-pulse/message.c
--- pipewire-0.3.13/src/modules/module-protocol-pulse/message.c 2020-10-23 16:52:07.426393834 +0200
+++ pipewire/src/modules/module-protocol-pulse/message.c        2020-10-23 17:44:19.524043313 +0200
@@ -32,7 +32,7 @@
        if (vol <= 0.0f)
                v = VOLUME_MUTED;
        else
-               v = SPA_CLAMP((uint64_t) lround(cbrt(vol) * VOLUME_NORM),
+               v = SPA_CLAMP((uint64_t) lround(log2(vol + 1.0f) * VOLUME_NORM),
                                VOLUME_MUTED, VOLUME_MAX);
        return v;
 }
@@ -40,7 +40,7 @@
 static inline float volume_to_linear(uint32_t vol)
 {
        float v = ((float)vol) / VOLUME_NORM;
-       return v * v * v;
+       return pow(2.0f, v) - 1.0f;
 }

 struct descriptor {

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> A programozók tényleg nem hallottak arról, hogy mi a fene az a decibel, s hogy a szubjektív hangintenzítás érzet éppen logaritmikus?

A programozók...úgy általában??? Nem. Azok sincsenek sokan, akik ismerik az exponenciális függvény tulajdonságait, pl. hogyan függ össze a hatványozással. Amúgy az említett patch sehol sem szól decibelről.

> Pedig Wim nem fiatal, kezdő programozó.

És tudja, hogy a köbös számítás (adott intervallumon) jó közelítése a logaritmikusnak, miközben a cpu-igénye jelentősen kisebb.

> a nehézség abban van, hogy a log(0) = -inf., s ez egy cseppet sem könnyíti meg a becsületességre törekvő honpolgár életét, mert valahol csalni kell.

A b.t.h.-ok tényleg nem hallottak a programozáselmélet, számítástudomány alapjairól? :) A megfelelő csalás annyi, hogy egy if...else kizárja a log(0) lehetőséget. És ez benne is van a vonatkozó forráskódban.

> Az alsó hangerő tartományokban alig van változás, nagyon halk az egész, a felsőben viszont elég meredeken nő a hangerő.

Próbáltad csak ALSA használatával? Az amixer-rel lehet min...max, %, dBFS értékeket használva hallgatni, hogy a driver/hardware mennyire természetesen szabályozza a hangerőt.

> a float valami talán kompatibilitási okokból megtartott

Erről tudnál linkelni valami dokumentációt?

A fentiekben jórészt igazad van, bár itt a futásidő nem igazán érv, ezt nem minden hangmintán kell elkövetni, csak hangerőállítás alkalmával az új lineáris szorzót kell kiszámolni.

Doksit nem tudok, de szigorúan szerintem a double egy IEEE szabvány, míg a float olyasmi, mint az int, csak lebegőpontosan: architektúrától függ, mekkora. Arra gondolok, hogy fiatalabb korában az int 16 bites volt, de ma egy 64 bites CPU-n szerintem legalább 32 bites. Fix 16 bitre ott az int16_t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerkesztve: 2020. 10. 31., szo - 10:53

Megjelent a 0.3.14-es változat. Nekem nem újdonság, mert napi szinten csináltam build-et, így folyamatosan érzékelhetően javult. Viszont 0.3.13-hoz képest nagyon sokat fejlődött, most már egész jól használható. Mindhárom gépemen kidobtam a pulseaudio-t, pipewire fut rajtuk.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerkesztve: 2020. 11. 04., sze - 18:13

Van már 0.3.15. Tekintve, hogy Wim ideiglenesen kikapcsolta a bluetooth működését, ha valakinek mégis kell a bluetooth, érdemes ezzel a patch-csel lefordítani:

diff -ur pipewire-0.3.15/src/examples/media-session/media-session.c pipewire/src/examples/media-session/media-session.c
--- pipewire-0.3.15/src/examples/media-session/media-session.c	2020-11-04 17:37:16.104106646 +0100
+++ pipewire/src/examples/media-session/media-session.c	2020-11-04 17:41:07.629885757 +0100
@@ -2067,6 +2067,7 @@
 				"alsa-acp,"		\
 				"alsa-seq,"		\
 				"v4l2,"			\
+				"bluez5,"		\
 				"suspend-node,"		\
 				"policy-node"
 #define EXTRA_ENABLED		""

Nem sejtésről beszélek, természetesen a saját gépemen kipróbáltam, teszteltem, működik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azt írja az újság, hogy nem kell megpatkolni, megy ez config file-ból is:

# The bluetooth module is disabled by default because it causes
# conflicts with PulseAudio. If you disable PulseAudio or don't
# load its bluetooth module, you can enable it here with -e bluez5

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerkesztve: 2020. 11. 05., cs - 08:40

Ma lattam meg tok veletlenul, hogy fut a gepemen. Debian testing.

Ugy tunik, hogy valamiert behuzta maganak a gnome. Ezt megint csak nem ertem, hogy mit keres a gepen.

#apt purge pipewire

The following packages will be REMOVED:
  chrome-gnome-shell* gdm3* gnome-session* gnome-shell* gstreamer1.0-pipewire* pipewire*

 

# dpkg -l pipewire*
ii  pipewire:amd64 0.3.12-1     amd64        audio and video processing engine multimedia server
ii  pipewire-bin   0.3.12-1     amd64        PipeWire multimedia server - programs

# ps xfa

   971 ?        Ss     0:00 /lib/systemd/systemd --user
    991 ?        Ssl    0:00  \_ /usr/bin/pipewire
    996 ?        Sl     0:00  |   \_ /usr/bin/pipewire-media-session -d bluez5

 

Ugy tunik, vissza kell ternem a heti nagytakaritashoz. Nem lehet mar a Debian se megbizni.

Nem biztos, hogy magával a PW-vel van a baja, lehet, hogy csak azon húzta fel magát, hogy a Debian csak úgy rolling-release módra kéretlenül feltelepítget neki olyan függőségeket, amik eddig nem voltak jelen egy állítólag stabil csomagkészletű rendszerben. (Mondom ezt úgy, hogy ha a GNOME3 azért húzta le a PW-t, mert a PA-t helyettesítik innentől vele, azt én egy nagyon üdvözölendő lépésnek tekintem, mert a PW-ben ugyan még nem vagyok biztos, hogy tényleg olyan nagyon jó lesz, de a PA-t alulmúlni aligha fogja.)

Tekintve, hogy nagyon rákaptam az ízére, napi szinten csinálok pipewire build-et, s ez a default multimédia szerverem, megváltam a pulseaudio-tól, látom, hogy már most nagyon jó. Egyfelől a pipewire kevés CPU-t eszik, működik egyszerre a pulse, alsa, jack interface-e, a natív pipewire felületét meg szerintem még nem nagyon van alkalmazás, amelyik használná. Egyedül a visszhangelnyomás hiányzik nekem belőle, viszont nem recseg-ropog a hangja, mint bizonyos körülmények között a pulseaudionak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jó, megértem. Nem azt mondtam, hogy elkészült, semmi munka vele. A pulseaudio kompatibilis rétegben vannak még nem implementált függvények is, tehát például a pulse-effects nem működik vele. Az alapok, mint felvétel, lejétszás, a stream-ek ide-oda kötözgetése, működnek. Meg valamennyire videót is tud átvinni, de ezt még nem próbáltam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Értem, hogy a pulse szar, és resource hog és egyébként is pötterix, tehát pfujj, de őszintén szólva én ebből nem sokat vettem észre, nekem nem recseg ropog, voipon se, biztos volt már olyan, hogy fejbe kellett verni, de nagy általánosságban megy. Ha ennél többször kéne belerúgni, akkor sem szívesen cserélném le valamire, ami ugyan nagyon szuperül tud lejátszani, csak hiányzik belőle a feature, amit használnék, ha épp úgy jön. Pulseal is annyi bajom volt, ami komoly, hogy a klassz céges füles mikrofonja nem megy, mert nem támogat valami új bluetooth profilet. Szóval ha lehet, majd akkor cseréljék ki, amikor már észre se veszem, hogy más van ott :)

Nálam is jól teljesít - és még sok más felhasználónál,akik nem kukorékolják tele a netes fórumokat hogy "jól működik" - ergo az, amit látsz róla véleményeket (de bármi  másról is), jellemzően negatív irányba torzított képet ad.

A két halmaz aránya a releváns, márpedig a "működik" halmaz számosságáról csak khalovány becslésed lehet, a sokkal hangosabb "nem működik" viszonz jól látható és érzékelhető vélemnéyhalmazt fogalmaz meg - egyoldalú lesz a kép, ami kialakul róla, ha a "tömeges tapasztalatokat" - hibásan - többséginek tekinted. 

Igazából az összes csoport számosságáról (szereti/utálja/gőze sincs mi az) csak halovány becsléseink lehetnek. Lehet mondani, hogy a nem működik csoportot lefedik a systemd-mentes disztrók userei, de ez is torz képet ad, mert vannak olyan userek, aki utálják, de nem vállalták be a mainstreammel való szembemenés kompromisszumait és váltottak systemd-re, annak ellenére, hogy bajaik vannak vele. Továbbá az sem feltétlenül igaz, hogy akinek baja van a systemd-vel, az annak hangot is ad. Nézd meg a legutóbbi HOVD szavazást, a systemd csak 8%-os többséget szerzett a többiekhez képest, de a systemd-t mégsem szidja a HUP 42%-a.
A csöndben lévők systemd-hez való hozzáállásáról leginkább gőzünk nincs, hogy működik nekik, vagy csak lenyelték a békát és tűrnek, vagy azt sem tudják, hogy mi az és hogy egy probléma, amivel épp szembesülnek, az a systemd sara-e, vagy sem.

Amire viszont reflektálni szerettem volna, hogy nem mindegy, hogy tíz ember mondja, hogy nem jó, vagy tízmillió. Az előbbi ugyanis nem egyszerűen kisebbség, hanem marginális kisebbség, míg az utóbbi az ha kisebbség is, de tömeg. Ha ennyi embernek van vele baja, akkor ott valami baj van. (És azért az elég sokatmondó, hogy a distrowatch népszerűségi listájának a tetején egy systemd-mentes disztró (MX Linux) van, ill. az is, hogy a számontartott élő disztrók 30.8%-a (77/250) systemd-mentes.)

Játszol a számokkal:

8%-os többséget szerzett a többiekhez képest

inkább 8%-os többséget szerzett az összes többihez képest, de aki megnézi a linket tudja értelmezni ha akarja :)

a systemd-t mégsem szidja a HUP 42%-a

hát ebben se vagyok biztos, HUP-on bárhol felmerül a téma lelkes ekézésbe kezd a közönség a hszekben. Nem beszélve arról, hogy aki nem használja, nem feltétlen érez kényszert arra, hogy foglalkozzon vele ;)
Én csendben használom már régóta, elég sok helyen, sokféle vason fut, és nem érzem, hogy sok gond lenne vele, pláne nem, hogy több, mint bármelyik másik inittel. Tanulni kellett kicsit hozzá, mert más, mert új, kukázni kellett a megszokott megoldásokat, ez bizonyára nem mindenkinek esik jól. De vessetek meg nyugodtan, én pl a hozadékai közül a journalt kifejezetten kedvelem.

Félreértés ne essék, nem szeretném, ha a systemd lenne az egyetlen, jól van ez így, hogy létezik több init, mint ahogy a systemd előtt is jó volt. Eltekintve az olyan helyzetektől amikor munka közben át kellett venni egy gentoo-s servert üzemeltetésre, és addig nem láttál a sysviniten túl :D

Nem játszom semmivel, a "többiekhez képest" az pontosan azt jelenti, hogy az összes többihez képest. Aki tud szöveget értelmezni az azt is tudja értelmezni, amit mondtam. Aki nem, annak marad a belemagyarázás. Jó kis szalmabáb sose rossz, igaz?

> hát ebben se vagyok biztos, HUP-on bárhol felmerül a téma lelkes ekézésbe kezd a közönség a hszekben.

Mind a 353 ember, aki ellene szavazott? Mert szerintem ugyanaz a 10-15 ember szokta szidni. És kb. ugyanannyi védeni.

Aki szavaz valamire, az a többi ellen szavaz és ennek megfelelően aki nem szavaz valamire, az ellene szavaz. (Ez alól kivételt képeznek természetesen a tartózkodók, de ők a szavazásban csak akkor jelennek meg, ha van "tartózkodom" opció, itt pedig nem volt.) Ez nem systemd-specifikus, ez generikus logika, ami mindenféle szavazásra igaz. Ennyit a szalmabábokról; megint csak gondolkodni nem sikerült.

A másikra csak annyit tudok mondani, hogy szerintem ezen a portálon én voltam az, aki a legtöbb műszaki érvet felsorakoztatta a systemd ellen, úgyhogy ezt nagyon rossz embernek mondod.
Az meg nem az én hibám, hogy a systemd pártiaknál az "ellenérvelés" többnyire kimerül a személyeskedésben és a szalmabábok püfölésében (ld. még: "Nem sikerült megtanulni?", "Persze, mert ami új az rossz, ugye...", "De ezt egy systemd-hater írta!!!4", "Mert a SysVInit az olyan jó, mi?!" és még sorolhatnám). És az sem az én hibám, hogy a systemd pártiak többségénél a systemd kritizálása és ekézése közé tripla egyenlőségjel van téve. Ezek ugyanis vallásos hozzáállást tükröznek, ami a legkevésbé engem minősít.

Szavazás:
Melyik a kedvenced az alábbiak közül:
-Mákostészta
-Lekváros tészta
-Diós tészta
-Sajtos tészta
-Káposztás tészta porcukorral
-Káposztás tészta borssal

Szerinted tehát az, aki a fenti hat közül például a sajtos tésztára szavaz, az utálja és rossznak tartja a többi ötöt (a lekváros tésztát pláne...), sőt a döntő többségüknek hasmenése és heveny lábrázása lett a lekváros tésztának még az említésétől is?

 

Mindkettőtöknek: ti keveritek az "ellene szavaz"-t az "ellene van"-nal (azaz azzal, hogy utálja). Ha szavazol a saját választottadra, akkor azt akarod, hogy az győzzön és nem a többi, tehát a többi ellen szavazol, hiszen nem akarod, hogy győzzenek, de ez nem azt jelenti, hogy utálod a többit. Az egész posztom arról szólt, hogy aki csendben van, annak a véleményét nem tudhatjuk. A systemd 8%-os többséget szerzett, de nem szidja a másik 42% egésze, aki nem a systemd-re szavazott, csak egy része. Nem lehet tudni, hogy pontosan mi volt a szavazatuk oka, ebben benne van az is, hogy simán mást favorizálnak, meg az is, hogy bajuk volt a systemd-vel, de nem adtak neki hangot. A lényeg az volt, hogy aki csöndben van, annak a véleménye nem ismert.

Mivel nincs preferencia megadva a szavazásnál, így lehet a te értelmezésedben is valami, de én a "másik irányból" közelítem meg a dolgot: valami _mellett_ az nem azt jelenti, hogy az összes többi _ellen_. Nekem pl. a jól használt(!) sysvinit-tel nincs igazán bajom - viszont látva a korlátait és a hibáit mondom azt, hogy ugyan az n+1 féle (disztribúciónként és azon belül főverziónként is) eltérő toldozása-foltozása lehetne jó is, de célszerűbb volt az egészet újragondolni, újratervezni, és más elvek mentén felépíteni.

Nem. Attól, hogy azt mondom, hogy a kedvencem a lekváros tészta, még közel ugyanúgy szeretem a káposztásat (szigorúan csak borssal - sok-sok borssal) is meg a sajtosat is - csak épp ha egyet és csak egyet kell kiemelni, akkor az a lekváros lesz. Tehát nem a káposztás _ellen_ sőt egyik tészta ellen sem szavazok (mert nem az a kérdés!), hanem a lekváros mellett. Te lehet, hogy "minden ellen, kivéve a ..." módon szavazol, azonban ezzel nem a feltett kérdésre (meliyket kedveled leginkább) válaszolsz. Mert  pl. abból, hogy "behúzod" a sysvinit-et, még nem következik, hogy a BSD-stílusút utálod-e jobban, vagy a systemd-t, vagy épp valamelyik egzotikus init-rendszert, hanem csak és kizárólag az következik belőle, hogy a leginkább a sysvinit-et kedveled, semmi több, hiába képzelsz oda bármi mást is.

Hogy került már megint az utálat a képbe? Ezt ti látjátok bele folyamatosan, pedig itt csak arról van szó, hogy ha választottál valamit és az mellett voksolsz, akkor az automatice a többi ellen egy szavazat. Ha leülsz megnézni egy meccset, akkor is, ha az egyiknek drukkolsz, akkor a másik ellen drukkolsz, de ez nem azt jelenti, hogy utálod a másikat. Ezt ti látjátok bele folyamatosan.

Akkor mondjuk a fizikában az ellenerő azt jelenti, hogy utálja az egyik erőt és nem azt, hogy szemben áll az egyik erővel? Ami pedig a magyar nyelvet illeti: https://www.arcanum.hu/hu/online-kiadvanyok/Lexikonok-magyar-etimologiai-szotar-F14D3/e-e-F1E41/ellen-F1ECD/

‘‹valakivel, valamivel› szemközt; ellentétes irányban; ‹valakinek› ártalmára’; ‘‹főnévként› ellenség’. Származékai: ellenség, ellenséges, ellenségeskedik, ellenébe, ellenkedik, ellenez, ellenző, ellenkezik, ellenkező, ellenkezés, ellenkezőleg, -ellenes, ellenzék, ellenzéki, ellenzékieskedik.
Alighanem az elő főnév el-, illetve ele- tövéből jött létre -n locativusi raggal; a szó tövének l-je utólag nyúlt meg intervokális helyzetében. Eredeti jelentése tehát ‘előtte’, majd ‘vele szemben’ (pl. átellenben); később ‘feléje’, végül ‘támadólag valaki felé’ irányban fejlődött névutóként. Főnévként nyelvújítási elvonás, talán az ellenség, ellenkezik származékokból; ebben az értelmében régies, irodalmi szó. Összetett szavak előtagjaként, illetve igekötői szerepben is sok szó eleme, többnyire latin (contra-) és német (gegen-) előtagú összetett szavak mintájára: ellenáll, ellenvetés, ellenszél, ellenfél, ellenméreg, ellenőriz, ellenérzés, ellenvélemény stb. Lásd még ellenszenv.

Micsoda? Az, hogy az ellenszavazat ellenérzetet vagy ellenségeskedést jelent? Hol? Amit beidéztem, az az ellen szó jelentése volt, amiben világosan leírták (mindjárt az első szóban), hogy ez elsősorban azt jelenti, hogy valamivel szemben, átellenben, csak lehet használni úgy is, ahogy ti teszitek, de az még mindig a szótő (ellen) és nem pedig az ellenszavazat.

Ha választottad X-et, akkor azt akartad, hogy X győzzön, tehát nem akarod, hogy a többi győzzön, tehát a többi ellen szavaztál, de ez nem jelenti, hogy utálod őket. Mit nem lehet ezen érteni?

"eredeti jelentése ... később fejlődött..." Világosan leírták, hogy miből fejlődött ki a jelenlegi jelentése, de tényleg nem egy magyar nyelvet beszélünk :)

> Ha választottad X-et, akkor azt akartad, hogy X győzzön, tehát nem akarod, hogy a többi győzzön, tehát a többi ellen szavaztál, de ez nem jelenti, hogy utálod őket. Mit nem lehet ezen érteni?

Engedd el az utálatot, mint konkrét szót. "tehát nem akarod, hogy a többi győzzön, tehát a többi ellen szavaztál". Ez egy negatív értékítélet. Azt mondtad, ilyet az ellen nem jelent.

Nem, ez nem a jelenlegi jelentése, hanem jelenleg lehet így is értelmezni, a szótövet, de ettől az ellen szónak a jelentése az azt jelenti, hogy valamivel szemben. Szerinted az ellenszél pl. mit jelent? Nem szembeszelet? Az ellenpólus? Az ellenhatás? És még sorolhatnám. Ezek melyike hordoz negatív érzelmi töltetet?

Ez nem negatív értékítélet, ennyi erővel ellenfél == ellenség, holott nem. Ez egyszerűen versengés, ebben az esetben a szavazatokért. Az ellen pedig nem hordoz semmilyen negatív érzelmi töltetet.

Az lehet, hogy marginális hobbiproject, de sokat beszélek rajta, így nekem fontos. És rögzítsük, nem a kliens rossz. Olyannyira, hogy kínomban megnéztem a forráskódját. Pipewire-rel szép a hangja.

Poetteringnek vannak jó meglátásai, csak nem tud programozni. Inkább nevezném elméleti szakembernek, mint mérnöknek. Amikor a pulse nagyon bugzott az elején, bebizonyította, hogy egy rakás alsa driver bugos, vagy nincsenek implementálva olyan függvények, amelyeket a pulse használ, így ujjal mutogatott az alsa fejlesztőire, miközben alkalmazhatott volna workarond-ot. De nem, mert nyilván rétegek fölött átnyúlás. Inkább legyen sz.r, de elvileg legalább tökéletes, szépen hozza az OSI-modellt. Szóval idegesítő a fazonnak az idealizmusa, amiből akkor sem tudod kibillenteni, ha emiatt nem működik valami, noha javítható volna. Ha rajta múlna, nem volna DirectX sem, meg olyan huncutságok, hogy néha megkerülik az X szervert, hogy gyors legyen.

A másik, hogy szerintem a pulseaudio-ban van elvi bug. Nincs belekalkulálva, hogy nem realtime a kernel, s bizonyos esetekben a kliens és a szerver egymásra várnak, talán egymás callback függvényeit hívva azok nem térnek vissza, amíg át nem tudnak adni vagy venni egy buffert, így mind a kliens, mind a szerver futásidő igénye az egekbe szökik. Ez persze csak sejtés, sohasem néztem a forrását. Ez az, amit viszont a pipewire szépen megoldott.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Az lehet, hogy marginális hobbiproject, de sokat beszélek rajta, így nekem fontos. És rögzítsük, nem a kliens rossz. Olyannyira, hogy kínomban megnéztem a forráskódját. Pipewire-rel szép a hangja.

Természetesen lelked rajta, nem bántani akartam én, fogalmam sincs, hogy egyébként jó vagy rossz, és teljesen reális, ha ez neked megfelel, és a pipwireel jól megy, akkor csinálod az early adoptert. Egyszerűen csak arra akartam utalni, hogy ez egy kvázi ismeretlen valami, az ismertekkel a legtöbben tudnak voipozni úgy, hogy nem recseg nekik elviselhetetlenül, mint neked. Aztán hogy ez azért van, mert mégiscsak a siren nem olyan jó szoftver, vagy azért, mert a többiek körbekerülgették, hogy egyébként szar a pulseaudio, az passz. Bár élnék a gyanúperrel, hogy nem fog minden ismertebb cucc csak a pa hülyeségeivel megküzdeni, tehát vagy a siren szar, vagy a paval együtt az összes audiobackend "szar", és ki kell kerülgetni a használó appnak. Akkor viszont ennek jó eséllyel oka van, nem egyszerre béna mindenki ugyanúgy.

> Poetteringnek vannak jó meglátásai, csak nem tud programozni. Inkább nevezném elméleti szakembernek, mint mérnöknek

Minden tiszteletem mellett, de az a HUPos megnyilvánulásaidból teljesen egyértelmű, hogy neked esélyed sincs megállapítani valakiről, hogy ő tud-e programozni, mert fogalmad nincs a területről. Még ha legalább a hardware közeli programozásról beszéltél volna, ott esetleg. De az, amit itt összehordtál mérnökségről az jézusom. FYI, sokkal inkább az a mérnök, aki a helyén próbálja meg korrigáltatni a dolgokat (ugyanis a probléma forrása az volt, hogy egy rakás ALSA driver ezek szerint egy félkész trágyadomb volt), mint az, aki jön, és kifújja az összes lukat purhabbal, az ugyanis a kőműves. És megint tisztán látszik, hogy fogalmad sincs, hogy egy szoftver projektben miért kiemelten fontos, hogy ne purhabozzunk. A fal ugyanis jó eséllyel úgy marad, a sw viszont bizony feljesztjük tovább, és pontosan az ilyen megworkaroundoltamoktól esik szét hosszú távon a francba. (Arról már nem is beszélve, hogy opensource projekten workaroundolgoassa más szarját, aki akarja, elvárni kissé naivitás)

Mást értünk a fogalmakon. A programozó-matematikus nem mérnök, viszont egy villamosmérnök, vagy akár gépész az. Legalább is az én felfogásomban. Az nem mérnöki hozzáállás, amikor valaki implementál egy szabályozót, csak éppen fogalma sincs a korlátairól, a problémáról. Sohasem vallottam magam programozónak. Akkor programozó volnék, nem pedig mérnök. :) Mindamellett igen, alacsony szinten assembly-ben és C-ben szoktam programozni mikrokontrollerekre, de mindig látom magam előtt a hardware-t, a limitációkat.

Egyébként azt, hogy Lennart mennyire tud programozni, igazolja a gyakorlat. A pulseaudio majdnem 14 főverziót megélt, s a mai napig nem működőképes, ez az időzítési probléma nincs megoldva. A pipewire tart 0.3.15-nél, és szépen szól. Igaz, nem Lennart írta, hanem Wim.

A programozás egyébként nem azonos a magas szintű nyelveken történő programozással, és tudom, hogy egyesek szerint a C++ az assembly picivel közérthetőbb formája. :)

A pulseaudio működése erősen függ attól, milyen alsa driver-t használ az alsó rétegben. A gépteljesítménytől is függ, a választott resampling algoritmustól is. Mert ez a VoIP kliens fix 48 kHz-en dolgozik, a hangkártya meg sok esetben 44.1 kHz-en.

A pulse csak bizonyos konfigurációk esetén lesz használhatatlanul rossz. Nem mindig az. De a hardware-től ez döntően függ.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Mást értünk a fogalmakon. A programozó-matematikus nem mérnök, viszont egy villamosmérnök, vagy akár gépész az.

Ja, hogy elitistázkodnunk. Rossz hírem van, az én papíromban pl az van, hogy mérnök informatikus, szóval sajnos mérnök lesz az. (És egyébként a szobatársam, akinek az lett a papírjában, hogy villamosmérnök,  nagyjából ugynazt tanították neki, más hangsúlyokkal, meg néhány más szaktárgyi ismerettel, szóval nem nagyon látom be, hogy mitől lenne egy informatikus kevésbé az)

> Az nem mérnöki hozzáállás, amikor valaki implementál egy szabályozót, csak éppen fogalma sincs a korlátairól, a problémáról. 

Jaja, én pedig azt próbálom neked elmagyarázni, hogy neked fogalmad sincs, hogy pulseaudio méretű projektben mik a valódi konkrét problémák és korlátok, amiket egy szoftvermérnök megold, ezért a saját magad fele hajló békanézetből megállapítod, hogy ...

> Egyébként azt, hogy Lennart mennyire tud programozni, igazolja a gyakorlat. A pulseaudio majdnem 14 főverziót megélt, s a mai napig nem működőképes, ez az időzítési probléma nincs megoldva

... hogy nem tud programozni, mert valahol van benne egy bug vagy egy rosszul implementált darab valahol egy levélen*, ami egyébként különösen vicces egy olyan ember szájából, akinek saját bevallása szerint sincs fogalma arról, amit az elmúlt 20-30 évben megtanultunk arról, hogy hogyan lehet jól szoftvert tesztelni.

Ezzel szemben a gyakorlat az igazolja, a pulse audio a világ linux desktopjainak igen jelentékeny részén kielégítően teszi a dolgát.

Abban egyébként igazad van, hogy ezt többnyire már nem is programozónak szokás hívni, hanem szoftvermérnöknek :)

Szóval TLDR: mérnökölni alapvetően ugyan úgy kell áramot vezető dolgokon, betonnal kiöntött vas dolgokon, és absztrakt szofver komponenseket összekötögető dolgokon, nagyrészt a domain ismeretek különböznek, illetve a domainek sajátosságai miatt más módszereket használunk és mások a hangsúlyok --  pl mert míg ha egyszer valami bele van öntve a betonba, akkor azzal már nem nagyon lesz semmi, meg (ahogy ezt ti állítottátok) ha egyszer valami microcontrolleres dolog készen van, ahhoz többet hozzá nem nyúl senki, ellenben egy szoftverrel, -- de a megközelítés az ugyanaz.

 

*illetve ne menjünk el amellett, hogy most ugyan irányt váltottál, mert látszik, hogy az előzővel nem értél célba, de az előbb még azért nem volt mérnök, mert nem volt hajlandó körbetaknyolni a bugos ALSA drivereket.

Ha  jó a pulseaudio, akkor

- miért eszik egy rakás futásidőt a pipewire-rel szemben?
- miért recseg-ropog a hangja, miközben a pipewire hangja jó?

Mindez ugyanazon a hardware-en, ugyanazon az operációs rendszeren vizsgálva. Mindez úgy, hogy a pipewire API-nak van egy pulseaudio kompatibilis interface-e. Továbbá biztos, hogy kizárólag az új feature-ök adják a pipewire létjogosultságát?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A recsegéssel kapcsolatban meg sem próbáltad értelmezi a mondottakat, a cpu idő meg egyrészt max a saját kiragadott szempontodból fontos, másrészt pedig az, hogy a pipwirenek sikerül kevesebb cpu időből megoldani saját bevallásod szerint is egy kis részhalmazát a pulsenak, az kb semmit nem jelent.

Harmadrészt meg nagyon cuki vagy, hogy amikor te mész össze vissza, akkor természetesen el lehet térni a témától, bezzeg ilyenkor visszaérünk oda, hogy te egészen konkrétan mit állítottál

(ráadásul nem azt állítottad, hogy a pulse szar, hanem azt, hogy pötyi nem jó programozó)

Ja, ha nem számít a futásidő, nem számít a hangminőség, akkor jó a pulseaudio. Télen különössképp, mert így legalább fűteni lehet általa a CPU-val a lakást. Az meg a másik, hogy gondolom, attól jó egy programozó, hogy jó programokat ír, és attól rossz, hogy rossz programokat ír.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csak ismételni tudom magam, próbált értelmezni amit írtam, addig addig meg légy oly mérnök, és ne fektess görbét egy pontra.

Továbbá ne sarkíts. Nem azt mondtam, hogy nem számít a futásidő, hanem azt, hogy az egyetlen paraméter a sok közül egy szoftverben, és egyáltalán nem biztos, hogy a legfontosabb. De köszönöm, hogy megerősíted, hogy mivel a többiről lövésed sincs, ezért ezen rugózol.

Igen, árnyaltabban fogalmaztál, mely szerint nem ez a legfontosabb. Mi a fészkes fene lehet fontosabb egy hangszerver esetében, mint az, hogy folyamatosan szóljon a hang, valamint ne vigye el a CPU futásidejét, amikor - mint kiderül -, ez nem elengedhetetlenül szükséges a helyes működéshez?

De, agyon csapnám az összes programozót, aki terjengősen kódol, mondván, RAM és futásidő van számolatlanul.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

+1 Egyetértek locsemegével, hogy egy ilyen program esetén, ami kb minden desktop Linuxon fut, igenis számít hogy hatékonyan használja a CPU-t! Az meg, hogy jól működjön az pláne számít! (Bevallom nekem működött a Pulse mióta feladtam az ellenállást, de elvben egyetértek, hogyha nem működik az baj.)

> Egyetértek locsemegével, hogy egy ilyen program esetén, ami kb minden desktop Linuxon fut, igenis számít hogy hatékonyan használja a CPU-t!

Mennyire? Számít, hogy egy alsó középkategóriás gépen egy audiostream 10%? Hogy 1? Hogy fél? Hogy egy tized? Meddig számít? Mennyi plusz cpu fér bele, hogy valamit lehessen generikusan kezelni, és ne kelljen emiatt egy rakás eszközhöz kb ugyanazt leimplementálni kicsit másképp? Mennyi CPU fér bele, hogy kevesebb setupban legyen recsegő hang? Mennyi CPU fér bele, hogy emulálhass featureöket, amiket adott esetben nem támogat valami hardware, és egyébként nem lenne? Meddig éri meg a CPU spórolás miatt miatt sokkal nagyobb, nehezebben karbantartható, olvashatatlanabb, nehezebben portolható, potenciálisan bugosabb, potenciálisan mindenféle hardweren változó minőségű kódot csinálni?

> Az meg, hogy jól működjön az pláne számít! (Bevallom nekem működött a Pulse mióta feladtam az ellenállást, de elvben egyetértek, hogyha nem működik az baj.)

Persze hogy számít. Csak it is az a kérdés, hogy meddig? Szar lesz a PA, mert locsemege pont talált egy olyan setupot, ahol épp recseg? Annak ellenére, hogy pl nálad -- meg még egy nagy nagy rakás -- embernél nem recseg? Hány hiányosan megírt ALSA drivernél éri meg beleszarni az architectúrába (képzeld ide az összes következményt fentről)? Biztos, hogy az a jó, ha ezeket elkezdik workaroundolni, ezzel jó eséllyel bebetonozva a status quot, hogy azok az örök életre ott maradjanak, és sose javuljnak, potenciálisan új driverekből is hiányozzanak, meg szép lassan szaporodjanak? Biztos nem jobb hosszú távon azt mondani, hogy javítsátok meg a szart ott, ahol van, addig akinek peche van, recsegni fog, meg nem fog szólni?

És ezek csak azok a minimális kérdések, amiket az ember a domain ismerete nélkül a gépelés sebességével fel tud tenni.

Na, ebből lát lócsemege annyit, hogy pötyi nem jó programozó mert nála recseg, és egyébként is eszi a CPUt, és mivel ő olyan területen dolgozik, ahol a resourceok hatékony használata kiemelten fontos, ezért békanézetből megszokta, hogy ütné, aki nem baszakszik ezzel a végletekig, miközben nem gondol bele, hogy mások a keretek, és rohadtul más a cél, ha az ember nem egy konkrét hwre ír dolgokat, hanem egy olyan szoftveren dolgozik, aminek lehetőség szerint a világ összes audio hw-vel kéne menni.

> Mennyire? Számít, hogy egy alsó középkategóriás gépen egy audiostream 10%? Hogy 1? Hogy fél? Hogy egy tized? Meddig számít? Mennyi plusz cpu fér bele, hogy valamit lehessen generikusan kezelni, és ne kelljen emiatt egy rakás eszközhöz kb ugyanazt leimplementálni kicsit másképp? Mennyi CPU fér bele, hogy kevesebb setupban legyen recsegő hang? Mennyi CPU fér bele, hogy emulálhass featureöket, amiket adott esetben nem támogat valami hardware, és egyébként nem lenne? Meddig éri meg a CPU spórolás miatt miatt sokkal nagyobb, nehezebben karbantartható, olvashatatlanabb, nehezebben portolható, potenciálisan bugosabb, potenciálisan mindenféle hardweren változó minőségű kódot csinálni?

Itt vegyük elő a Hajbazer énünket! Relatíve nem nagy a Linux penetrációja, de összesen mégis nagyon sok gépen fut. Mennyi áramot fogyaszt, menyni CO2 kibocsátással jár egy 5%->10% növekedés? Mennyivel csökken a notebookok üzemideje akksiról? Mivel az a pár százalék CPU is összesen nagyon sok, ezért igenishogy indokolt a spórolás. Ráadásul locsemege infója szerint nem arról van szó, hogy 10-20%-ot lehetne faragni, hanem hogy többszörös a CPU használata, mint muszáj volna.

Ez a karbantarthatóság, portolhatóság gyenge kifogás, mert a jó megoldás sokszor egyáltalán nem bonyolultabb, vagy nehezebben karbantartható. (Ez saját tapasztalat a munkáimból, amikor valamit újraterveztünk eredetileg teljesítmény okokból, akkor sokszor még egyszerűbb is lett a megoldás. De tény, hogy létezik mikor teljesítmény miatt komplexebb lesz a megoldás, ilyenkor mérlegelni kell.) Persze nem néztem a Pipewire implementációját, de gondolom nem kézzel optimalizált X86 assembly az sem, hanem hordozható C. Ugyanis az ilyesmi nagyságrendileg nem mikoroptimalizáláson múlik, hanem architekturális kérdéseken. Abból, hogy egy ember ilyen rövid idő alatt működő programot állított elő, arra következtetek, hogy éppenséggel inkább egyszerű ez a program, mint bonyolult. A mikrooptimalizációnak is létezik még tere, de döntően nem ilyenekről van szó.

A programok teljesítménye fontos, és egy programozó aki ad magára, az számol vele. Nyilván sokmindentől függ, hogy mit mennyire érdemes optimalizálni, de a hangszerver már pont az a kategória amit kellene. A programozó által kiadott program teljesítménye felhasználható a programozó értékelésére. Hiába működik egy program, ha többszörös az erőforráshasználata, mint muszáj lenne, akkor az szar, és az a programozó hibája. Tapasztalatom az, hogy egy 10-100-1000-szeres lassulást simán hanyagságból bele lehet tenni egy programba úgy, hogy még nem is skálázódási a probléma, csak sima lineáris elbaszás. Prototípusnál még belefér, de egy elvileg kész programban ne maradjon ilyen!

> A programok teljesítménye fontos, és egy programozó aki ad magára, az számol vele. Nyilván sokmindentől függ, hogy mit mennyire érdemes optimalizálni, de a hangszerver már pont az a kategória amit kellene.

Természetesen. Vegyük észre, hogy én sem mondtam mást. Csak lócsemege előadta, hogy szar, mert nála recseg, és a pipwire sokkal jobb, mert kevesebb cput eszik. Egy pontból extrapolálva, majd teljesen kisarkítva olyan baromságokkal, hogy azt mondom, hogy nem számít a felhasználó. Úgy, hogy a sok mindentől függöt egyáltalán nem ismeri, fogalma sincs arról, hogy milyen szempontok szoktak még egy nagy szoftveben lenni, Meg azt sem, hogy a pipwire most még csodálatosan gyors implementációja hogyan fog kinézni, ha majd "nem csak az alap dolgok működnek".

A hajbazer énem meg majd kielégítem egy peccsel, hogy akkor se lehet emberi hangnál hangosabbra venni egy kimenetet, ha egyébként kilówattos hangfal van :P

"Mennyire? Számít, hogy egy alsó középkategóriás gépen egy audiostream 10%? Hogy 1? Hogy fél? Hogy egy tized? Meddig számít?"

Amint nem egy pc-n, hanem teszem azt egy arm-es board-on szeretnéd használni, vagy bármi máson, igenis sokat. Vagy amikor a laptopon azt látod, hogy a PulseAudio miatt a cpu nem megy alvó állapotba, hanem 3 GHz-en pörög, neked meg az akkuidő éppen fontos lenne, olyankor. És igenis, addig kéne baszakodni vele, amíg annyira jól nem működik, hogy el is felejted hogy a gépen ott van.

Hat-hét éve szereztem egy HP t5720 vékonykliens gépet, amiben egy 1GHz AMD Geode NX 1500 CPU, 512Mb DDR SODIMM RAM és 1 Gb IDE Flash háttértár volt. Erre akkor fel tudtam telepíteni egy aktuális Debian-t Xfce4-el, és használható volt, filmnézésre, alap böngészésre. Egy ilyen gépre ma kb SEMMILYEN desktop disztribuciót nem tudnék feltelepíteni, mert az összes egy túlhízott, összecsapott, bloat vacak.

Egy ilyesmi gépen igenis számít a szoftver optimalizáltsága.

De egy most piacon lévő  laptopon, amiben valami ultramobil cpu van is lehet ám csodákat látni, mert a gyufásdoboznyi alaplapról minden le van spórolva, amit csak lehet, olyan akadások tudnak ám létrejönni, mert a pci/pci-express sávok a végletekig le vannak korlátozva, és mindent a cpu számol, hogy nagyon meglepődnél ám. Mentettem kijelzőhalott Lenovo Ideapadról le hanganyagot live linux-al, ahol bele kellett hallgatni, hogy mit mentek le, és baromira sistergett, meg recsegett. A végén alsaplayer-t tettem a live rendszerre és a pulseaudio-t megkerülve sikerült lejátszani a hangfájlokat. Igen, tudom, hardvert venni tudni kell, csak hát akkor szoftvert írni is tudni kéne, nemdebár?

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Mondjuk van egy olyan opció is, hogy nem használunk olyan ritkán használt, bár az alsa API-ban definiált függvényeket, amelyeket egyes driver-ekben hiányosan, vagy hibásan implementáltak. Csak azért, mert kényelmesebb lenne használatával az életünk, még nem muszáj használni. Lehet úgy tekinteni, mintha nem is lenne. Teszem azt, nincs kedvünk kiszámítani a hw pointer helyét, mert azt vissza is kérdezhetjük az API-n. Igen, de ha van olyan driver, amelyik nem, vagy nem jól adja vissza, akkor inkább mérjük az időt, s a mintavételi frekvenciából számoljuk ki, hol tart. Megoldható? Igen. Bár, aki nem akarja megoldani, annak ez nem fog menni.

Példa volt, bár emlékeim szerint tényleg valami ilyen nyűgje volt a pulse-nak egyes driverekkel.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igy van.

Ha kesz lesz, jobb lesz, es atter ra minden program (vagy kompatibilis, hogy eszre se veszem), akkor mehet felolem.

A szemetelest utalom. Sajnos felkell aldozzak ra egy orat, hogy kitakaritsam a sok hulladekot, amit felgyujtott magara a Debian. Semmi kedvem rendszergazdat jatszani. 10+ eve nem szorakoztat.

fixme, de az apt nem frissit olyan csomagot, ami valami ujat akarna felrakni. ezeket szepen felsorolja a keepback listaban, es kesz. ahhoz user beleegyezes/kikenyszerites kell, hogy valami ujat felrakjon. szal az illetonek csak ugy nem ment fel, hacsak nem nyomott ra valami "nemerdekel, frissits mindent" gombra 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Valamit nem teljesen értek. Van ez a patch, amelyhez fűzött a szerző némi megjegyzést:

Don't build by default, update the README
With pulse-server we are more flexible and compatible and we don't
have to (badly) reimplement libpulse anymore.

Most az egy dolog, hogy azóta nem tudtam lefordítani, de addig masszíroztam a pipewire.spec file-t, amíg ez sikerült. Ahogy ezt sejteni lehetett, a pulseaudio-t indította a pulse kliensekhez. No, de az egész pipewire project számomra azért érdekes, hogy megváljak végre a szutyok pulseaudio-tól.

Egyelőre nem frissítek, az utolsó valóban pipewire implementációt használom, nálam működik. Tény, hogy például a pulseeffects kliens nem megy vele. Remélem, hogy ez csak a fejlesztés egy közbenső stációja, amikor is inkább az eredeti pulseaudio intézi a hangot, amíg bolygatják az egész pipewire pulse interface-ét.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azt gondolom erről, hogy ez ideiglenes, amíg kikalapálják a pipewire pulse interface-ét. De nem győzöm hangsúlyozni, ezt gondolom azok alapján, hogy nekem úgy tűnik, egy rakás commit pulse related, de ezt teljes bizonyossággal nem jelentem ki, mert én csak sejtek, következtetek, aki ezt tudja, az Wim Taymans.  Most még ilyen vicces elírások is vannak benne, amikor egy struktúra címének nullaságát vizsgálták tévedésből, nem egy tagjának nullaságát:

	pw_log_info("destroy %s", p->sample->name);
	spa_hook_remove(&p->listener);
	p->stream = NULL;
-	if (--p->sample == 0)
+	if (--p->sample->ref == 0)
		sample_free(p->sample);
	p->sample = NULL;
}

De legalább már ez is kijavult. :) Szóval átmenetileg a pulseaudio-ra húzott réteg lett, de azóta nem csinálok belőle build-et magamnak. :P

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én tartok tőle, hogy rosszabb a helyzet:

pw-pulse is part of pipewire-pulseaudio (the PA compatible library), which is just deprecated and no longer enabled by default since 346e35ee.

forrás: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/375

Psszt, elárulom az IP-címemet: 192.168.0.14

Dehát így az egész dolog értelmét veszti... Mi a francnak tegyen föl bárki egy olyan extra audiolayert az ALSA/OSS fölé, amit a saját interface-ével nem használnak a szoftverek? Azért, hogy feltegyük azt a hulladék library-t, amit kiváltani hivatott és annak a tetején ücsörögjön, feleslegesen, pluszban, amikor ennyi erővel az eredeti hulladékot is hívogathatnák a szoftverek?

Ha így lenne, csalódott lennék. Bár a pipewire-nek akkor is lenne létjogosultsága, hiszen általános multimédia sharing szerver, de épp akkor van értelme, ha azt, amit láttam belőle, audio terén meg is fogja valósítani. Nevezetesen a kis erőforrásigény, pulse, alsa, jack interface-ek, jó minőségű hang.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Miféle létjogosultsága van valaminek, amit nem használ semmi? Ha ki tudja szolgálni a más hasonszőrű layerekre támaszkodó szoftvereket, akkor van, amennyiben jobban csinálja, mint azok, amiket imitál (és speciel a PA-t elég nehéz lenne alulmúlni). Nyilván, ha majd lesz, ami ezt natívan használja, akkor már más lesz a helyzet, de itt pont az lett volna a lényeg, hogy addig is lehet használni N féle másik helyett, ráadásul, ha jobban működik, mint azok, akkor az emberek rászoknak arra, hogy inkább ezt az egyet tegyék fel a többi helyett és akkor az még ahhoz is lendületet adhat, hogy a saját interface-ét is elkezdjék használni. PW PA helyett: jóra cserélni a fost, az jöhet; PW a PA tetején: a felesleges ül a foson, az a felállás kell a francnak...

Egyetértek veled, ezért is a jelen csalódottságom. Azért vagyok mégis bizakodó, mert noha - szigorúan szerintem! - átmenetileg deprecated (itt majdnem azt írtam, hogy decrapeted, de akkor már jönne is értem a TEK, szóval nem jó, ha az ember nem tud angolul, mint én) lett a pulse közvetlen reimplementációja, továbbra, tehát azóta is létezik például ilyen patch. Vagy például ez.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hát ja, de optimista vagyok, mert pulse specifikus fejlesztéseket továbbra is tolnak bele. Lehet, hogy csak sok nyitott bug volt, s nem akarja Wim ezek elszaporodását, miközben tudja, hogy a pulse csak részlegesen van implementálva. Mindez feltételezés részemről.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszönöm: ami eddig kiderült, az alapján még jó ideig maradok az ALSA-nál apulse-al kiegészítve.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Az apulse oldaláról:

Not implemented functions, application crashes

Large portion of PulseAudio API is not implemented. There are functions that do nothing and return some arbitraty values. Often, if application tries to call something not implemented, it crashes while trying to dereference a NULL pointer. By default, tracing level is set to 0, which means no messages are printed to standard output. It's possible to increase that value to 1, which shows unimplemented function calls, or to 2, which shows all function calls.

Már bocs, de ennél szerintem a pipewire natív pulse interface-e most sokkal jobb és egyszerre tudja a a jack, alsa, pulse felületet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt a kérdést körül kell járni, egyelőre nem látok tisztán. Most nincs időm, dolgoznom kell. Ha valakiben van annyi lelkesedés, kurázsi, megkérdezhetné ezt Wim-től. Már csak azért is, mert amennyire én angolul tudok, simán lefejezést írok az elavulttá tett kód helyett. ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Annyira aranyos vagy, mikor láthatólag azt se érted, mit csinálsz, de fasza :)

Szóval, volt az a pipwire-pulseaudio, ami a pulse kliensek fele biztosította azt, hogy a pulse interfacen keresztül (libpulse ugye) tudjanak megszólalni. Na, a commit arról szól, hogy megpróbált implementálni egy alternatívot, de szar volt, ezért inkább ezentúl wrappelni fogja a libpulse-t a module-protocol-pulse nevű saját modulban.

A depracated meg azt jelenti, hogy ez nem átmeneti, hanem faja programozó barátod így gondolja ezt hosszú távon.

Nem a barátom, csak tetszik a project. Ami a többit illeti, írtam is, hogy nem látok világosan a kérdésben, és ha így van, ahogy írod, akkor a végletekig el vagyok keseredve. Egyet azért nem értek: ezen patch után miért van még egy rakás pulse related commit?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ne haragudj, ennyire nem néztem meg, de ha tippelnem kellene, akkor a libpulse wrapperését csinálja?

Igazából nem nagyon látom, hogy miért olyan rettenetes tragédia, ami történik? Mármint ha jól értem (és ez pár perc nézelődés után simán lehet faszság) a libpulse gyakorlatilag csak a publikus api, magát a hangszerver részét nem fogja használni, szóval ha tippelnem kellene, akkor azokat a részeket amiket ti nem szerettek (hogy állítólag nincs hangja, miközben zabálja az erőforrást) ez nem hozza magával. Az apiból meg miért olyan rossz ötlet használni a pulse által adottat, ami definíció szerint az igazság arról az interfaceről. Egyrészt sokkal könnyebb nem elcseszni valamit a klienseknek, másrészt sokkal hamarabb észrevenni a változásokat, amiket le kell követni az illesztésnél.

Ezen én is gondolkodtam, és ezzel így nincs is bajom, ez a lépés üdvözlendő számomra. Magát az interface-t valóban felesleges újraírni. Annyira nem ismerem a pulseaudio-t, hogy tudjam, a klienstől milyen függvényeken át jut el a buffer tartalma a szerverig, illetve a szerver mit hív vissza a kliensből, s ez az egész hogyan működik, hol lehet az interface-t elvágni a szervertől. Bár van valami pulseaudio socket, de mondom, ebben nem mélyedtem el.

Szerk.: igazából az érdekel, hogy lehessen native pipewire-t használni audio alkalmazásoknak pulseaudio interface-en keresztül.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Úgy néz ki, fején találtad a szöget, és ez bizony igen jó hír! :) Csináltam egy build-et a 573e2afd commit-ig, már azt is beleértve. Most azt tegyük félre, hogy hogyan csomagoltam be lustaság okán. A hivatalosan megszüntetni vágyott pipewire-libpulse csomagba hánytam be minden új file-t, s dobtam ki belőle, ami megszűnt. :) Szóval ezt ne firtassuk, de semmi jelentősége, kutyafüle is lehetne a csomag neve akár. Felfrissítettem az új csomagokra, majd

systemctl --user daemon-reload

Maszkoltam a pulseaudio socketet, hogy eszébe ne jusson elindulni:

systemctl --user mask --now pulseaudio.socket

Itt lehet, hogy a --now a mask elé írandó, de azt hiszem, mindkét formát megeszi. Utána leállítottam a pipewire-t, engedélyeztem a pipewire-pulse socketet és elindítottam a pipewire-t:

systemctl --user stop pipewire.socket
systemctl --user enable --now pipewire-pulse.socket
systemctl --user start pipewire.socket

Persze minden lépésem eredményességét status olvasással ellenőriztem, ezt itt most nem írtam le. Aztán működik jól. :)

A futásidő felhasználása kicsit romlott, mert a pipewire-pulse szerver megeszik kb. 1.7 % futásidőt, de ezzel még együtt tudok élni. Ez csak egy audacious kliens esetén, nyilván sok kliens ronthat ezen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A Manjaro-s gépemen megjelent a Pipewire. 0.3.15-1 lesz a 0.3.14-1-ből, ha rákattintok, hogy oké. Rákattintok. Ha nem jövök többet, akkor rossz ötlet volt.

A 0.3.15-ben eredetileg még nem a libpulse használatát vezették be, hanem a saját pipewire implementáció van benne. Az működik egy adott szintig, de szerintem Wim rájött, hogy bonyolultabb dolgok megvalósítására rossz a koncepció, s később dobta csak a saját kivitelezésű interface-t. Ebben a későbbiekben tért csak át az eredeti pulseaudio interface-éhez, ugyanakkor a szerver továbbra is saját megvalósítás marad, így tehát szerencsére a pipewire nem egy újabb vékony réteg lesz a pulseaudio fölé, hanem valóban saját implementáció. Egyedül az interface marad a pulseaudioból. De mindez téged csak a 0.3.16-ban érint majd, hacsak nem fordítasz forrásból, mint én. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A mai build tanulságai: működik továbbra is, a bloetooth engedélyezéséhez nem kell a forrást patch-elni, elég a /etc/pipewire/pipewire.conf file vége felé ez:

exec /usr/bin/pipewire-media-session -e bluez5

Annyi viszont van, hogy szól a bluetooth fülesen a zene, kikapcsoltam a bluetooth fülest, s azt vártam, hogy az audio stream átdobódik az USB-s mikro hifire. Ehelyett elvesztette az összes be- és kimeneti device-t. Egy

systemctl --user restart pipewire-pulse.socket pipewire.socket

parancs helyrehozta a lelkét.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Sokat fejlődött, egyre jobb. Van már 0.3.17-es változat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt egyszer már megtették a Pulse-val, akkor is milyen jól sült el. A pipewire sokkal jobban van összerakva ugyan, de attól még nem kéne elsietni ezt szerintem, inkább szállítsanak kicsit később egy stabil rendszert, mint korábban egy félkészet.

Psszt, elárulom az IP-címemet: 192.168.0.14

Ez így van, csak ugye ezt írtad:

pont ott kell minel bugosabbnak lennie

Nem kell minél bugosabbnak lennie a kódnak Fedorán. Itt is minél hibátlanabbnak kell lennie, csak nem túl nagy baj, ha már itt kibuknak és javításra kerülnek a hibák, mielőtt széles körben el lenne terjesztve az adott megoldás.

Ha a minél bugosabb állapot lenne a cél, akkor szándékosan kellene bele bugokat írni. De nem ez a cél.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Értem, meg látom a Fedora szerepét az ökoszisztémában, továbbá a Pipewire nem a default multumédia szerver Fedorán, ennek ellenére jegyzem meg, a Fedora stabilitásával nincs baj, jól használható napi munkában. Mindhárom gépemen Fedora van, ebből az egyiket csak munkára használom minden nehézség nélkül. Apróbb nyűgök vannak, de az sokszor nem a Fedora sara. Például az, hogy az 5.9-es kernelsorozatban hazavágták a nouveau driver-t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

De nem erről volt szó, senki sem szidta itt a Fedorát, nem ez volt a lényeg. nullptr annyit mondott, hogy inkább várjanak vele, mintsem szállítsák le bugosan, golgota meg erre mondta, hogy a Fedora pont arra való, hogy bugosan is kijöhetnek vele, mert a Fedora egy testing site; inkább ott legyen bugos. Ez nem azt jelenti, hogy legyen csak bugos, és azt sem jelenti, hogy szükségszerűen bugos lesz, csak azt, hogy ha az, akkor ott legyen bugos és ne a longterm disztrókban. Kár ebbe többet belelátni, főleg rosszindulatot.

pontosan....nem hittem volna hogy ennyire nem voltam ertheto.

Azt akartam mondani, hogy minel bugosabba  afedoraban annal jobb lesz, mert ott szet fogjak javitani. Minel bugosabb ott, annal jobb lesz a vegen, mert rebgeteget fognak rajta dolgozni ogy ne legyen az. Es ezaltal meg jobb lesz. Ezt akartam mondani. Szoval igenis legyen minel tobb bug megtalalva benne, azaz legyen tizsta bug az egesz. Hogy a vegen szuperjo legyen.

Noha értem, amit mondasz, a megfogalmazás még mindig kellemetlenül zavaró, sőt, szerintem pontatlan is. Ne legyen tiszta bug az egész, a fejlesztők törekedjenek arra, hogy elsőre minél kevesebb hibával írják meg a kódot! Én is arra törekszem a munkámban, hogy minél kevesebb hiba legyen benne már első gyártatásra, ha hardware. Ha meg firmware, akkor első futtatásra.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Ne legyen tiszta bug az egész, a fejlesztők törekedjenek arra, hogy elsőre minél kevesebb hibával írják meg a kódot!

Ez nem azt jelentette, hogy szándékosan pakoljanak bele bugokat, hogy legyen mit kijavítani... :)
Csak az számít bugosnak, amiben meg is találják a bugokat, mert amíg nem fut bele valaki, az olyan, mint ha ott sem lenne. (Nyilván ott van és bugos a cucc, de ismert hiba nincs, tehát a szoftver jelenleg nem minősül bugosnak.) Magyarán értsd: találjanak meg benne minél több bugot. Erre való egy játszótér disztró. (Ez most külön, kötőjel, vagy egybe...?)

Attól még, hogy nem volt benne rosszindulat, marhaság.

https://fedoraproject.org/wiki/Fedora_myths?rd=FedoraMyths#MYTH_-_Fedor…

Nem az a különbség a Fedora és a RHEL között, hogy a fedora nem lenne stabil és nyugodtan bele lehet tenni bugos dolgokat, hanem hogy gyorsan lehet rajta változtatni, bele lehet rakni mindenből a legfrissebbet, nem probléma ha valami nem kompatibilis visszafelé teljesen és nem kell rá évekig supportot adni, ezáltal régi kódot karbantartani.

Ettől még erősen tesztelve van és nem adnak ki olyan dolgokat benne amiben nem biztosak, hogy stabilan működik. Tehát biztos lehetsz benne, hogy addig nem lesz a pipewire a default audio server amíg nem biztosak benne, hogy működik, ugyanúgy, ahogy a waylandre sem álltak át addig, amíg nem teljesítette a feltételeket, és nem a userekkel teszteltették le.

> Ettől még erősen tesztelve van és nem adnak ki olyan dolgokat benne amiben nem biztosak, hogy stabilan működik. Tehát biztos lehetsz benne, hogy addig nem lesz a pipewire a default audio server amíg nem biztosak benne, hogy működik, ugyanúgy, ahogy a waylandre sem álltak át addig, amíg nem teljesítette a feltételeket, és nem a userekkel teszteltették le.

Akkor csak a systemd-re sikerült idő előtt átállniuk? :P

Nem, a systemd működött kezdettől fogva. A pulseaudio volt az, ami valami elképesztő mértékben bugos volt, durván recsegett-ropogott a hang, néha 100 % CPU-t megevett és egyúttal szétfagyott. Azt a szörnyet - ami a mai napig nem jó - valóban így rakták a Fedorába.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Nem, a systemd működött kezdettől fogva.

Hibás szórend; helyesen: a systemd kezdettől fogva nem működött. Kiegészítés: most se.

> A pulseaudio volt az

Is.

> ami valami elképesztő mértékben bugos volt, durván recsegett-ropogott a hang, néha 100 % CPU-t megevett és egyúttal szétfagyott

Nem érzem indokoltnak a múlt időt.

Nem érzem indokoltnak a múlt időt.

Ezt még a 14-es Pulseaudio is csinálja? Remek.

Kiegészítés: most se.

Ez érdekesebb. Az ellenszenven túl vannak olyan dolgai, amelyek valóban nem a dokumentáció szerint működnek? Természetesen a legfrisseb változat érdekes, mert korábbinak a bugjait a friss javíthatta.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> vannak olyan dolgai, amelyek valóban nem a dokumentáció szerint működnek?

Hát, mintegy ezerháromszáz darabnyi (csak ma hat új darab)...plusz még húsz darab sérülékenység; bár ki tudja, lehet, hogy azok a dokumentáció szerint működnek.

> Természetesen a legfrisseb változat érdekes, mert korábbinak a bugjait a friss javíthatta.

Ez annál is frissebb, ez az upstream repository.

> ~1300 issue azért nem ugyanennyi sérülékenység.

He? Ki mondta, hogy 1300 sérülékenység van benne? locsemege azt kérdezte, hogy vannak-e olyan dolgai, amelyek valóban nem a dokumentáció szerint működnek és erre írtam, hogy mintegy ezerháromszáz darab, lévén a bug azt jelenti, hogy nem a doksi szerint működik. Plusz még húsz darab sérülékenység. Nem ezerháromszáz plusz húsz sérülékenység, hanem ezerháromszáz bug plusz húsz sérülékenység. Legközelebb figyelmesebben olvass.

> Ennyi idős és ekkora projektben lazán van bárhol ennyi issue.

Ennyi nyitott, azaz javítatlan? Mert ezen felül még van több, mint ötezer lezárt...ami viszont nem ekvivalens a javítottal, lévén egy jó része WONTFIX-szel került lezárásra.

Aha, bízzál benne, hogy más sem nézi meg, hogy igazat beszélsz-e? 1300 nyitott issue, és mind-mind javítatlan, azaz BUG! :D

És nem, nem állítom, hogy ez egy tutijól megírt cucc, csak nem értem mit kell itt (is) vergődni ezen, ráadásul egy olyan topicban, ami a PipeWire-ről szól.

> Aha, bízzál benne, hogy más sem nézi meg, hogy igazat beszélsz-e? 1300 nyitott issue, és mind-mind javítatlan, azaz BUG! :D

Micsoda? Nézd már meg jobban: ennyi nyitott issue van. Abban ugyan igazad van, hogy ez nyilván nem mind bug, de vajon hány lehet ebből feature-request? 100? 200? Változtat ez az eredményen? Nem, már csak azért sem, mert elegánsan figyelmen kívül hagytad, hogy a lezárt hibajegyek se mind javítottak, hiszen Pötyi bátyó tucatjával zár le hibajegyeket WONTFIX-szel... Felhívnám még arra is a figyelmedet, hogy ugyan még csak dél van, de már ma is két bugot reportoltak, valamint arra is, hogy százával hemzsegnek az olyan ticketek, amiket évek óta nem javítanak (csak 2015-ös ticketből 65 db van).

> És nem, nem állítom, hogy ez egy tutijól megírt cucc, csak nem értem mit kell itt (is) vergődni ezen, ráadásul egy olyan topicban, ami a PipeWire-ről szól.

Szóbakerült, mert related, már csak azért is, lévén a PW támogatja a systemd-t, szerencsére a jelek szerint opcionális a dolog. Itt konkrétan úgy jött képbe, hogy mivel a PipeWire a PulseAudio-t hivatott leváltani és ebben a szálban az volt a téma, hogy a Fedorában is tervezik a váltást és a Fedora játszótér mivolta kapcsán szóbajött, hogy mi mindent tett defaultá a Fedora idő előtt, többek között a PulseAudio-t is és a systemd-t is.

Nem eszik olyan forrón a kását. A kernelben hány bug is van? Aztán mégis használja a világ. A systemd bugtrackerében is van olyan bug, amely mellé oda van biggyesztve, hogy voltaképpen az kernel bug.

A pipewire csak arra használja a systemd-t, hogy elindítsa a user session indulásakor a user jogaival. Nagyjából, illetve van függőség kezelés, a pipewire.socket triggereli a pipewire.service-t, valamint a pipewire-pulse.socket triggereli a pipewire-pulse.service-t. De ezt kb. egy kutya közönséges shell scriptben is megírod mondjuk az SysVinit keretein belül néhány sorban. Bár attól függ, mennyire akarod általánosra, minden hibát lekezelősre csinálni, mert ezekre a systemd fel van készítve. Ha jól emlékszem, van valami OnFailure vagy valami efféle benne.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> A kernelben hány bug is van?

Kb. 9000, de nem baj, hogy alma-körte? A kernel több nagyságrenddel bonyolultabb, mert több nagyságrenddel több dolgot kell tudnia, mert annyival több feladata van. Hol kell a pl. systemd-nek hatvannyolcezer féle hardware-t kezelnie? Csak érzékeltetésképpen (tömörítetlen TAR fájlban) a méretek:

-rw-r--r-- 1 root root 1011333120 nov   28 14:12 linux-5.9.11.tar
-rw-r--r-- 1 root root   58449920 nov   28 14:13 systemd-247.tar

A Linux kernel kódbázisa 17x akkora, mint a systemd-é, ehhez képest kevesebb, mint 7x annyi bug van benne. Ha megnézzük, hogy hány bug jut egy MB-ra a két projektben, akkor 9.45 bug/MB a Linux kernelnek és 24.13 bug/MB a systemd-nek. Ez azt jelenti, hogy arányaiban a systemd 2.5x olyan bugos. És mondom: mindezt úgy, hogy a kernelben található bugok egy nagyon jelentős része a hardwarekezeléssel kapcsolatos (ott a lista, lehet csekkolni) és asszem pont neked nem kell ecsetelnem, hogy mennyi olyan van, hogy a hardware maga is bugos, vagy csak dokumentálatlan, vagy épp máshogy működik, mint a doksi leírja...szerinted fair ilyen jellegű kernelbugokat pariba állítani azzal a taknyolással, ami a systemd-ben folyik?

> A systemd bugtrackerében is van olyan bug, amely mellé oda van biggyesztve, hogy voltaképpen az kernel bug.

Persze, a rm -rf /foo/.* meg "UNIX pitfall"... Pötyi bátyó előszeretettel hárítja másra a saját sarát.

> Nem related, de szóba hoztad, és még mindig lovagolsz rajta.

De related és nem is én hoztam szóba először.

> Hogy neked mennyi felesleges időd van!

Hétvége van.

> Esetleg javíthatnál systemd bugokat!:D

1. A systemd koncepcionálisan törött, azt nem lehet javítani.
2. Ne akard beosztani az időmet, vagy megszabni, hogy mivel foglalkozzak.

Hát ha neked elég, hogy kb említésre került a neve, akkor legyen related.

A systemd koncepcionálisan törött, azt nem lehet javítani.

Azt elfelejtetted odaírni, hogy: szerinted.

Szerintem meg a hibáival meg bugjaival együtt is sokkal inkább előremutató stuff, mint a klasszikus initek. És úgy tűnik, hogy ezzel a véleményemmel mintha nem lennék teljesen egyedül, szép lassan a mainstream disztrók bevezették, használják. Persze lehet, hogy mindenki hülye azoknál is. De majd az idő eldönti. Én mindenesetre szívesen látnék egy mondjuk a solaris SMF-re hajazó megoldást systemd helyett, nem pedig scriptekből összetákolt megoldásokat, amiket jelenleg fel szoktak sorolni alternatívaként.

2. Ne akard beosztani az időmet, vagy megszabni, hogy mivel foglalkozzak.

Kicsit figyelj már oda, mielőtt vagdalkozni kezdesz, ott a szmájli a végén. Egyébiránt meg ki vagy te hogy ezt megszabd nekem, majd én azt eldöntöm, hogy kinek mondok véleményt, és kinek nem! :D

> Azt elfelejtetted odaírni, hogy: szerinted.

Mert nem csak szerintem. Én sem vagyok egyedül ezzel a véleménnyel.

> Szerintem meg a hibáival meg bugjaival együtt is sokkal inkább előremutató stuff, mint a klasszikus initek.

És? Más újkori SCS nincs a systemd-n kívül? Még mindig csak a SysVInitre sikerül mutogatni?

> szép lassan a mainstream disztrók bevezették, használják.

A popularitás nem érv. Ha az lenne, a winfostíz lenne a legjobb desktop oprendszer a világon.

> Persze lehet, hogy mindenki hülye azoknál is.

Nem csak hülyeség lehet a háttérben.

> Én mindenesetre szívesen látnék egy mondjuk a solaris SMF-re hajazó megoldást systemd helyett

Ebben egyetértünk, de már vannak hasonlóak.

> nem pedig scriptekből összetákolt megoldásokat, amiket jelenleg fel szoktak sorolni alternatívaként.

Te miről beszélsz? Az s6 vagy a nosh mióta van scriptekből összetákolva?

> Kicsit figyelj már oda, mielőtt vagdalkozni kezdesz, ott a szmájli a végén.

És? Azt nem csak a komolytalanság jelzésre lehet használni, hanem kárörvendésre vagy hasonlókra is.

> Egyébiránt meg ki vagy te hogy ezt megszabd nekem, majd én azt eldöntöm, hogy kinek mondok véleményt, és kinek nem! :D

Nem szabtam meg semmit, főleg nem azt, hogy kinek mondhatsz véleményt. Azt mondtam, hogy te ne akard megszabni, hogy mit csináljak.

Te miről beszélsz? Az s6 vagy a nosh mióta van scriptekből összetákolva?

Nos, ezek nincsenek összetákolva, csak még igen messze vannak a széles körben használhatótól. Persze ha valakinek elég sok ideje van init rendszerekkel kísérletezni VM-en pl, akkor tuti jó móka lehet.

A nosh egy tök jó ötlet, de kb one-man project, annak minden velejárójával. Kipróbáltam volna archon pl, de a 2018-as leírásokkal már nem igazán lehet egy az egyben haladni. Plusz elég érdekes, hogy van forráscsomag, de sehol egy git, issue tracker, etc... 

De legalább jó "UNIX-os" megjelenésű mindkét stuff honlapja, imádom a talpas betűket monitoron. :D

> Nos, ezek nincsenek összetákolva, csak még igen messze vannak a széles körben használhatótól.

Miért is? Mi hibádzik belőlük, amiért ne lehetne őket "széles körben" használni?

> Persze ha valakinek elég sok ideje van init rendszerekkel kísérletezni VM-en pl, akkor tuti jó móka lehet.

Ezek nem init rendszerek, ezek SCS-ek, ahogy a systemd is.

> A nosh egy tök jó ötlet, de kb one-man project, annak minden velejárójával.

A legtöbb opensource projekt kis létszámmal. A systemd-t is Poettering meg Sievers kezdték el csinálgatni.

> Plusz elég érdekes, hogy van forráscsomag, de sehol egy git, issue tracker, etc...

Hogyhogy sehol? Fent van githubon a nosh. Az s6 is.

Honnan tudod, hogy egyetlen ember commitol? A git csak egy mirror. Kérdezd meg az írót, hogy mennyire aktív a tábor.
Ez a szakértőzés meg nagyon beakadt neked valamiért; az eszedbe sem jut, hogy minden ami nem mainstream, az egyre inkább a perifériára szorul? Ld. golgota válaszát egyel lejjebb.

apro es talan lenyegtelen megjegyzesem a temahoz:

* nem egy program minosege dont arrol hogy tartalmazni fogja egy disztro hanem mondjuk a penzugyek. Marpedig a systemd-t karbantartani sokkal egyszerubb a disztro-kat kiadoknak, mint szamos kulon-kulon projektet.

Ez nem jelenti azt, hogy a systemd jol csinalna amit csinal, hanem hogy penzugyileg jobban megeri, mert kevesebb emberorat igenyel a cegeknek, azaz kevesebb penzbe kerul. (bar en ezt is ketlem a bughalmaz miatt, de hat ki vagyok en, hogy ezt megmondjam?) :D 

Na, de ha tegyük fel, hogy Wim hamarabb elkezdte a munkát, akkor ez a folyamat az IBM nélkül is végbe megy. Egyébként az IBM szerintem elsősorban a szerver piacra és a cloud-ra fókuszál, nem hiszem, hogy a desktop és azon belül a multimédia lenne az érdeklődése homlokterében.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Na, de ha tegyük fel, hogy Wim hamarabb elkezdte a munkát, akkor ez a folyamat az IBM nélkül is végbe megy.

A munka hamarább elkezdése irreleváns, mert én nem azt állítottam, hogy az IBM mondta neki, hogy fejlesszen PA alternatívát, hanem azt kérdeztem, hogy vajon lehet-e, hogy az IBM adta ki az ukázt, hogy a PA-t cseréljék le rá, ha már kifejlesztette. Lehet, hogy nem, mert tényleg mindenképpen lecserélték volna, de az is lehet, hogy az IBM takarítani kezdett. Az első felállás is jó hír lenne, mert akkor fejlődőképesek.

> Egyébként az IBM szerintem elsősorban a szerver piacra és a cloud-ra fókuszál, nem hiszem, hogy a desktop és azon belül a multimédia lenne az érdeklődése homlokterében.

Lehet. De az RHEL világ nem csak szerver, hanem desktop felhasználásra is jó. Lehet úgy gondolták, hogy ha már megvették és hirtelen lett ilyenjük, akkor nem ártana, ha a legnagyobb hulladékokat kiszórnák belőle. De ez persze szigorúan csak feltételezés.

Egyébként a systemd-t szerintem nem fogják, mert túl sokan használják a képességeit. A pipewire ebből a szempontból más. A pulse API nem olyan rossz, abban az esetben a pulseaudio implementáció az, ami fájdalmasan borzalmas. Tehát meg lehetett csinálni, hogy az alkalmazások felé megtartják a libpulse API-t, s csak a szervert írják teljesen újra és illesztik a pipewire-hez. Ez olyannyira így van, hogy a libpulse nem is lett újraírva - bár erre történt kísérlet az elején -, hanem az eredeti pulseaudio féle libpulse az, amit használnak.

A systemd-vel viszont nem implementációs bajok vannak, hanem koncepcionálisok. Az a baj vele, hogy szakít a Unix filozófiával, azzal, hogy egy jól definiált feladatot egy alkalmazás valósítson meg, de azt nagyon flexibilisen, jól. A systemd ezzel megy szembe, nem csak init rendszer, de session manager is, meg ntp kliens is, meg hálózati manager is, meg minden is. Ezen a koncepción viszont nem segít a reimplementálás, megválni viszont nem lehet tőle, mert vannak előnyei is, s ezeket az előnyöket aktívan használják az operációs rendszerek és a fejlesztők.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Sok igazság van abban, amit mondasz, de olyan nincs, hogy valamit nem lehet. Ha van kizárólagos előnye a systemd-nek (azaz olyan feature-je, amit más SCS-ek nem tudnak), az nem átemelhetetlen, hiszen a plusz tudásának zéró százaléka származik abból, hogy mindent egybeöntöttek. Egyszerűen csak sokan dolgoztak rajta és sok feature-t implementáltak. Ki lehet bökni valamelyik hasonlóan nagy tudású SCS-t, mondjuk az s6-ot, vagy a nosh-t és el lehet kezdeni felmérni, hogy mi hibádzik belőlük és mennyi munka lenne átemelni. (És zárójelben mondom, hogy ezeknek is megvannak a maguk előnyei, amit meg a systemd nem tud.) Vagy, fel lehet mérni teljesen, hogy mit tud a systemd, hogyan tudja, mi az ami koncepcionálisan törött benne, mi az, ami amúgy használható koncepció és nulláról újraírni, ezúttal nem a PID1-be beleöntve az egészet. (És Poetteringet és Sieverset minél távolabb tartani a projekttől.)

BTW, a systemd-vel implementációs bajok is vannak, nem csak koncepcionálisak; picit feljebb linkeltem be, hogy mennyi bugja van.

Szervezz magad köré egy csapatot, akikel forkoljátok azokat a csomagokat a Fedora-ból, amiknek systemd függésük van, és pucoljátok ki a systemd-s függést mindegyikből, cseréljétek le a systmed-t tchinit-re :-P csináljatok saját repót ezeknek a csomagoknak, telepítőkészletet, usw. Meg lehet csinálni? Igen. Lehet hozzá erőforrást gyűjteni? Ha tényleg annyi hozzáértőnek nem tetszik, akkor lehet, csak valakinek fel kell vállalnia a szervezést. Akarsz valaki lenni? :-D

Azt arra írtam (csak neked úgy tűnik, nehezen esnek le a dolgok), hogy _valakinek_ fel kell vállalnia egy ilyen systemd-mentes csomaghalmaz forkolását és a karbantartásához szükséges erőforrások összeterelését. Erre írtam, hogy akarsz-e (ez a) valaki lenni? (direkt mindkét "valaki"-t kiemeltem dőlt betűkkel...)

Tekintve, az eddigi diskurzusaink lefolyását és a kiemelt részek áthallásos jellegét, lehet jobb lett volna, ha kiírod, hogy "ez a valaki", mert így nagyon is úgy nézett ki, hogy megint csak szurkálódni akartál. (Ld. még ezt a "leesős" kitételt is.)
A csomaghalmaz forkolására amúgy nincs szükség, mert ezt már több projekt is meglépte, számos systemd-mentes package repository van, elég csak a systemd-mentes Linuxokat megnézni. Itt igazából egy olyan systemd alternatíva kifejlesztése volt a kérdés - márhogy bejátssza-e ezt az IBM - ami tudja azokat a feature-öket, amik miatt a systemd-re esküszők a systemd-re esküsznek. Hogy ezt az s6, a nosh, vagy valamelyik hasonszőrű SCS forkolásával, vagy a NIH elve mentén from scratch oldják meg, az igazából mindegy.

Ami működik, azt nem kell megjavítani. A RHEL7/8 vonalon pedig működik... Mivel a RHEL8-ban systemd van, amit főverzión belül biztosan nem fognak lecserélni másra (2029Q2 végéig, ha jól tudom), így legfeljebb az évek múlva várható RHEL9 hozhatna újat - de ahhoz nagyon sok melót kéne kukába dobni, amit meg pláne nem fognak. Szerintem...

Csak az a baj, hogy RHEL vonalon sem működik, ők is szívtak/szívnak vele. Egyébként senki nem mondta, hogy holnapra - vagy akár az RHEL9 érkezésére - kell lecserélni; ha az új SCS-t lóhalálában hányják össze, akkor ott vagyunk, ahol a part szakad. A gyors váltás meg a systemd minden bugja ellenére több kárt, mint hasznot hozna a keletkező káosz miatt. Meglátjuk, hogy egyáltalán egy induló tendenciával állunk-e szemben, vagy csak a PA-t dobják el.

Lehet, hogy ez a ticket konkrétan 2018-as, de az utolsó kommentek ideiek, többen is reklamáltak még mindig a probléma miatt. Az utolsó kettő ugyan a fixálásról szólt, de:

fixed by https://access.redhat.com/solutions/3900301 works like charm after applying it

https://access.redhat.com/solutions/3900301 involves rebooting the server like a cheap PC.

És ha megnézzük a hivatkozott ticketet:

  • Since updating to RHEL 7.6, users need 25 seconds to login and messages such as the one shown below are seen in the journal:
  • [...] dbus[xxx]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
    [...] systemd-logind[xxx]: Failed to enable subscription: Failed to activate service 'org.freedesktop.systemd1': timed out
    [...] systemd-logind[xxx]: Failed to fully start up daemon: Connection timed out
    [...] systemd[1]: systemd-logind.service: main process exited, code=exited, status=1/FAILURE
    [...] systemd[1]: Failed to start Login Service.
  • RHEL 7.6 periodically doesn't boot properly because polkit.service and tuned.service fail to start. This happens about 1 in 10 to 20 boots.
  • Tehát a probléma még csak nem is egyértelműen reprodukálható, mert stochasztikusan 10-20 bootonként egyszer jelentkezik.

    javistsunk ki mindent a vilagban, hogy a systemd jol mukodjon es kesz. :D

    Emlekszem egy ticketre, amikor a systemd-resolved megette az 53-as portot es kesz. Egyik sajat fejlesztoje csinalt is ra egy bugot. Pottering azt irta erre, hogy javistak ki a dns szervereket!!! A fejleszto szepen elmagyarazta neki, mint a reszeges apukanak, aki belepisalt az eloszobaszekrenybe, hogy mi is a baj. Szerencsere kepes volt felfogni. A srac javitotta, de par DNS szerver akkor sem ment, Pottering valasza: javistak ki a DNS szervereket!!! 

    Hat persze...muhahahaha

    Van egy (itt kettő) szolgáltatás, ami vagy elindul jól, vagy nem. Nomostan ha létfontosságú a szolgáltatás, akkor kezelje már le rendesen, hogy nem indult el, és legyen fallback, ha nem működik - például a PolicyKit... De ugyanez pepitában a NIS-es dolog is, aminél az rpcbind unit fájlt kellett megmókolni, hogy jó legyen.
    ha egy initscript sz@rul van megírva, vagy az abból indított motyó hibnásan indul el, akkor a scriptet futtató parancsértelmező a hibás?

    Ha a unit fájl van szarul megírva, vagy maga a szolgáltatás bugos, akkor az nem a systemd hibája.
    Viszont ha a unit fájl rosszul van megírva, az mindig rossz működést eredményezne, hiszen szarul paraméterezik fel a szolgáltatást, tehát stochasztikus start-fail esetében a unit-errort kizárhatjuk.
    A szolgáltatás pedig el sem indul, tehát ami bugja nem a startup részében van, az nem is játszhat közre, ami bugja meg esetleg a startup részében van, az meg mindig crasht eredményezne, ha azonos paraméterekkel indítod.
    Ennek megfelelően itt a hiba forrása kívülről jön. Lehet, hogy egy nem várt - és le nem kezelt - külső esemény miatt nem tudja elindítani őket a systemd. Ez azonban nem az el sem indult szolgáltatások hibája. A rendszer indulási mizériáinak reboottal történő javítása pedig nem lehet megoldás egy szerveren.

    (Kivételt képez az, ha valami hardwarehiba van a háttérben, vagy, ha egy harmadik software belekontárkodik a folyamatba. Ilyenkor sem a systemd, sem a szolgáltatás hibája. De ez lokális jellegű probléma, nem jelentkezhet egyszerre N helyen...)

    Tudom. De a párhuzamos indítás pláne kívül esik a szolgáltatások szkópján, mert azt maga a systemd intézi, tehát ha ott race-fail lenne, az csakis a systemd sara lehetne. De ha függőségi probléma miatt nem tudna elindulni a szolgáltatás, akkor a systemd ezt jelentené. Vagy legalábbis gondolom, hogy jelentené...

    Nem. En itt nem rossz unitfuleokrol beszelek. Hanem arrol, hogy Pottering szerint a DNS szervereket (pl. bind) meg kell fixalni hogy a megfeleloen mukodjenek, hogy ne utkozzenek a systemd-resolvd (akkori) faszsagaival. Most nincs kedvem megkeresni a ticketet, de gyonyoruen elmond mindent Potteringrol, ahogy eloszor kezelte a problemat. A systemd-s dev srac tok normalis volt es javitotta a systemd-resolvd fasz mukodeset, de Pottering eloszor be sem akarta fogadni, mondvan hogy won't fix. 

    Szoval itt nem is asystemd-resolvd a gaz, hanem ahogy ez kezelve volt a nagy Pottering altal. Azota is van par DNS szerver amit jobb ha nem futtatsz ott, ahol bekapcsoltad a systemd-resolvd-t a szervereden. :D

    Erdemes neha beleolvasni egy-egy ticketbe hogy az ember sirva rohogjon.

    Tisztelt Egybegyűltek! Ez a topic a PipeWire multimédia sharing szerverről szól, nem pedig a systemd előnyeinek és hátrányainak megvitatására szolgáló hely.

    tr '[:lower:]' '[:upper:]' <<<locsemege
    LOCSEMEGE

    Mármint a systemd-vel nem volt szétoffolva. Mert ha szigorúan vesszük, a pulse is off, mert ugyan lehet, hogy azt váltja és az még csak-csak related, hogy miben jobb a PW, de az már off, hogy a pulse-nak milyen önálló gyíkjai vannak...és a pulse fikázását biza te inicializáltad. ;) (Na, nem mintha nem értett volna benne egyet a fél közönség. :] )

    Bármiről lehet beszélni egy fórumon. A pulse abszolút related, hiszen a pipewire részint pulse API-t használ, illetve a pulse szervert implementálták újra. Szóba kerülhet a systemd is, hiszen ez indítja - vagy indíthatja - a pipewire-t. Az zavart, hogy szenvedélyes vita kezdődött a pipewire multimédia sharing szerverről szóló topicban arról, hogy miér nem jó a systemd, ha jó, akkor miben jó, Poettering meg bekaphatja, stb. Ez már elviszi a fókuszt, köze nincs a pipewire-hez, annak működéséhez.

    tr '[:lower:]' '[:upper:]' <<<locsemege
    LOCSEMEGE

    Ubuntun már próbálta valaki? Bluetooth hogy áll? Itt is használhatlan videóhívásra a BT füles a hangminőség miatt, mint Pulseaudion?