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

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.

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