PipeWire - mi ez?

Multimédia

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!

A téma folytatása a PipeWire #2 topikban található!

( dap | 2019. 10. 19., szo – 14:55 )

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

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

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

A pulseaudio olyan mint az abszolút nulla fok a termodinamikában. Nem lehet alul múlni. :) 

Eredetileg "pulsevideo"-ként indult, volt valami vita névvel mert mert volt olyan. Majd audio résszel is kiegészült. Hasonló szerver stream elven működik ez is. Sandboxolt programokhoz hasznos ha kell gui. Tudtommal pulseaudio felett is tud működni. Szóval nem kizárólag _vagy_ kapcsolat van a két hangrendszer között, illetve ez nem csak hangszerver. Reményteli dolog, hogy Lennart Poettering nincs a fejlesztői között. 

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.

( batyu v | 2019. 10. 19., szo – 16:21 )

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.

( Sas66 | 2020. 03. 27., p – 10:57 )

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

( st3v3 v | 2020. 03. 27., p – 11:45 )

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 :)

( Szenti v | 2020. 03. 27., p – 15:11 )

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

(nem ide, törölhető)

( locsemege v | 2020. 09. 09., sze – 00:29 )

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.

( locsemege v | 2020. 09. 09., sze – 22:24 )

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

( locsemege v | 2020. 09. 09., sze – 23:41 )

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

( locsemege v | 2020. 09. 10., cs – 14:05 )

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

( locsemege v | 2020. 09. 12., szo – 10:29 )

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

( locsemege v | 2020. 09. 18., p – 14:02 )

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

( nullptr | 2020. 09. 20., v – 21:33 )

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

( locsemege v | 2020. 09. 28., h – 23:35 )

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

( locsemege v | 2020. 10. 06., k – 22:17 )

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

( locsemege v | 2020. 10. 08., cs – 21:30 )

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.

Oldschool Computer - http://oscomp.hu

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

( locsemege v | 2020. 10. 09., p – 18:47 )

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

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?

Oldschool Computer - http://oscomp.hu

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.

A Ctr + W kombó az előző whitespace-ig töröl, nem kell annyiszor backspace-et nyomni. (Ez tudtommal minden shellben megy.)
Egynémelyik shell pedig tud a Ctrl + B és Ctrl + F vagy a Ctrl + Left és Ctrl + Right kombókkal a szavak közt ugrálni.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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

( locsemege v | 2020. 10. 19., h – 23:28 )

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 ;)

( locsemege v | 2020. 10. 21., sze – 22:54 )

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

( locsemege v | 2020. 10. 23., p – 10:37 )

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

Oldschool Computer - http://oscomp.hu

( locsemege v | 2020. 10. 23., p – 18:11 )

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

( locsemege v | 2020. 10. 23., p – 19:12 )

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

( locsemege v | 2020. 10. 31., szo – 10:50 )

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

( locsemege v | 2020. 11. 04., sze – 18:12 )

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

( kubi | 2020. 11. 05., cs – 08:39 )

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

Oldschool Computer - http://oscomp.hu

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 :)

> és egyébként is pötterix

locsemege pont nem tartozik azok közé, akik utálják Pötyi bátyót; jópár vitában védte már eddig a systemd-t. Szóval, ha még ő is azt mondja a PA-ra, hogy good riddance to bad rubbish, akkor ott már komoly baj kell, hogy legyen a PA-val.

Oldschool Computer - http://oscomp.hu

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

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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?

Oldschool Computer - http://oscomp.hu

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

Oldschool Computer - http://oscomp.hu

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.

"Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

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!

( locsemege v | 2020. 11. 14., szo – 00:34 )

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?

Oldschool Computer - http://oscomp.hu

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

Oldschool Computer - http://oscomp.hu

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

( Dwokfur v | 2020. 11. 14., szo – 16:00 )

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

( asch v | 2020. 11. 17., k – 21:45 )

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

( locsemege v | 2020. 11. 17., k – 22:06 )

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

( locsemege v | 2020. 11. 26., cs – 20:58 )

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.

Oldschool Computer - http://oscomp.hu

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

Oldschool Computer - http://oscomp.hu

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

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

Oldschool Computer - http://oscomp.hu

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.

    Oldschool Computer - http://oscomp.hu

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

    Oldschool Computer - http://oscomp.hu

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

    Oldschool Computer - http://oscomp.hu

    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.

    ( locsemege v | 2020. 11. 30., h – 17:41 )

    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. :] )

    Oldschool Computer - http://oscomp.hu

    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

    ( ricsipontaz | 2020. 12. 03., cs – 20:40 )

    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?

    ( locsemege v | 2020. 12. 19., szo – 00:17 )

    Majd' elfelejtettem. Van már 0.3.18, illetve azóta egy csúnya memleak is javításra került.

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

    ( Alucard | 2020. 12. 21., h – 14:43 )

    Raspberry Pi Arch alatt vannak mar tapasztalatok?

    Arch Linux [Sway WM]

    Most van egy kis idom szoval elvileg mukodik, gyakrlatilag meg nincsen hang :D pedig:

    $ > pactl info
    Server String: /run/user/1001/pulse/native
    Library Protocol Version: 34
    Server Protocol Version: 34
    Is Local: yes
    Client Index: 56
    Tile Size: 65496
    User Name: alucard
    Host Name: rpi4
    Server Name: PulseAudio (on PipeWire 0.3.21)
    Server Version: 14.0.0
    Default Sample Specification: float32le 2ch 48000Hz
    Default Channel Map: front-left,front-right
    Default Sink: alsa_output.platform-fef05700.hdmi.iec958-stereo
    Default Source: alsa_output.platform-fef05700.hdmi.iec958-stereo.monitor
    Cookie: d769:1a3b

    A vas egy RPI4 fedélzetén egy Arch Sway WM-el. WIKI szerint kell neki a xdg-desktop-portal-wlr csomag aminek a telepitese megtortent, illetve az XDG_CURRENT_DESKTOP-ot betoltam az /etc/environment-be.

    Egyelőre itt tartok :)

    Arch Linux [Sway WM]

    alsa_output.platform-fef05700.hdmi.iec958-stereo

    Valóban ezen a lyukon várod a hangot? A beállításokban a pavucontrol lesz a segítségedre, jó eszköz még a pasystray. Ha esetleg forrásból fordítanád, tedd fel az SDL2-devel csomagot is hozzá. Ha systemd-t használsz, egy új verzió telepítése után az adott grafikus session-ön belül - tehát nem ssh-n - az alábbit érdemes tenni:

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

systemctl --user status pipewire-pulse.socket pipewire.socket
systemctl --user status pipewire-pulse pipewire

    Az utóbbi két sor inkább ellenőrzés. Nézhetsz várakozási időket, foglaltságot a pw-top paranccsal. Restartnál a daemonokat nem kell újraindítani, mert a socketek újraindítása egyben triggereli a daemonok újraindulását is.

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

    Noh, megint akadt egy kis időm foglalkozni a témával. Szóval ha indítok egy mpv-t ott teljesen jó a hang :) hurrá! :) ebből arra következtetek, hogy a böngészőkkel van valami baja őkelmének.

    Terminálból indítva Chromium elég szűkszavú:

    [7208:7208:0218/161151.830753:ERROR:pulse_util.cc(343)] pa_operation is nullptr.

    Kicsit googlizok, aztán ha nincs solution akkor még lehet jövök :D

    Arch Linux [Sway WM]

    Nekem Arch és Artix alatt van vele rövid távú tapasztalat, már ha lehet azt annak nevezni, hogy fent van a rendszeren, kernelmodulok be vannak hozzá töttve, de konkrétan nem használja nálam semmi, minden pulseaudio-val megy. Így persze bugot se tapasztalok. Csak úgy fent van a rendszeren, megjött a frissítésekkel és új kernellel. Azzal még nem játszottam, hogy ténylegesen is használatba vegyem és kikényszerítsem, hogy valami is használja.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    ( locsemege v | 2021. 01. 05., k – 22:57 )

    Szerkesztve: 2021. 01. 20., sze – 17:23

    0.3.19

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

    ( BehringerZoltan | 2021. 01. 18., h – 00:00 )

    Próbálgattam ma a zongorás gépen. A célom az lett volna, hogy Pulse Audiot eltávolíthatóvá tegyem, de mehessen egyszerre a zongi [Jack] és a YT browserből. Ugye ezt idáig a PA oldotta meg. Annyi működött most, h ment a hang a Yt-ról a böngészőből a PA nélkül. Azonban Jack-et nem engedte egyidejűleg hozzáférni a kártyához, csak h az eredeti jacklibek helyett a PipeWireos Jack libeket használta. Viszont akkor azokkal a beállításokkal indítja el amit a PIPEWIRE_LATENCY változóban állítok be, és nem azokkal amik a qjackctl-ben vannak beállítva. Lényegében nekem külön beállítások kellenének a latencyt illetően a zongihoz és a YT-hoz. További gond volt h jackdbus nincs implementálva és emiatt a session kezelők Claudia; Gladish el sem indulnak. Forrásból tettem fel Ubuntura, és máshova pakolta a dolgokat, mint a doksi írta. Kellet kissé nyomozni, h mi hol van. Végül most leszedtem, de majd próbálgatom még. 

    "antiegalitarian, antiliberal, antidemocratic, and antipopular"

    ( hajbazer v | 2021. 01. 18., h – 01:58 )

    Szerkesztve: 2021. 01. 18., h – 01:58

    Újrafeltalált kerék, kitől mástól, mint a Red Hat-tól.

    Akinek enterprise Linux vendorként semmi más dolga nem lenne, mint a jelenleg elérhető szoftvereket stabilan összeboronálni és karbantartani. Csak épp ezek pont nem az erősségei.

    Ez is ugyanazokkal az ígéretekkel indul, mint a PulseAudio és előreláthatólag ugyanazzal az igénytelenséggel lesz lefejlesztve, több évig bennmaradó bugokkal, feature ágas felhasználókon való bétateszteléssel és egyéb arrogáns módszerekkel megfűszerezve.

    Én bizakodóbb vagyok, pont azért, mert egyszer már próbálkoztak, így (remélhetőleg) ismerik már, hogy milyen hibákat kell elkerülniük. A fejlesztője sem Poettering-szemléletű.
    Újrafeltalált keréknek sem mondanám, tekintve, hogy ilyen célú ÉS architekturálisan nem elrontott szoftver nincs jelenleg ezen kívül.

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

    Nem Poettering az egyetlen szélsőségesen idealista feljesztő a Red Hat-nál, csak arroganciája és a Linux-világ felforgatása révén ő a legismertebb.

    Vannak még jónéhányan.

    Peter Hutterer, a csotrogánnyá butított, újrafeltaláltkerék libinput fejlesztője, aki nem a (már deprecated) synaptics driverrel tökéletesen működő circular scroll-os laptopok használhatatlansága miatt aggódik, hanem amiatt, hogy mennyit kellene a libinputon módosítani, hogy beleférjen egy circular scroll, és ehhez mennyi tesztet kéne írnia. Egy olyan dolog, ami a leváltott synaptics-ban alap volt, és még mindig készülnek ilyen laptopok. Magyarul a saját lustasága, kényelmeskedése miatt aggódik, illetve hogy kurvára elfelejtette feature-paritással újrafeltalálni a kerekét és erre utólag, a felhasználók kell felhívják a figyelmet. [1]

    Matthias Clasen, GTK3-lead fejlesztőcske, akinek többnyire a minor verziók közti API-törések tömkelegét és a GTK3-témák utánhúzogatása által felemésztett többezer elpocsékolt munkaórát köszönhetjük világszerte.

    Emmanuele Bassi, akinek többek között köszönhető a GTK3 File Chooser rekurzív keresésének (korábban Alt-S) kötelezővé tétele, ami egyrészt felesleges I/O bloat, másrészt súlyos privacy-t érintő kockázat (osztott képernyőnél, előadásnál), harmadrészt nem lokális (vagy lassabb, HDD-s) fájlrendszereknél használhatatlan, negyedrészt a felhasználói szabadság lábbal tiprása, a kikapcsolhatatlansága miatt. Természetsen, hallani sem akar a kikapcsolhatóvá tételéről, a merge requesteket ignorálja, szélsőségesen idealista, lépjtovább, feljődésmániás indoklással. [2]

    we don't want typeahead. It's dead. It's pining for the fjords. It's an ex parrot.

    Ha ennyire hülyének tartod őket, és ennyivel okosabbnak magadat, miért nem pályázol hozzájuk, jól megmondani, hogy hogyan kell tervezni fejleszteni? Amilyen nagy szakmai tudásról és tapasztalatról meg kompromisszumkészségről tettél eddig itt tanubizonyságot, simán felvennének fejlesztési főatyaistennek.

    Mert soha nem volt vágyam egy arrogáns multinál dolgozni.

    Mert fejétől bűzlik a hal és az, hogy ezek ott lead fejlesztők lehetnek, egyvalamit jelent: olyannak kell lennem, ami én zsigerből nem vagyok (szélsőségesen idealista, fősodratú, elitista mérnök úr).

    Ha ennyire hülyének tartod őket, és ennyivel okosabbnak magadat

    https://a.te.ervelesi.hibad.hu/szalmabab

    Nem tartom magam okosabbnak és nem is mondam ilyet, csak te akarod rámolvasni, hogy könnyebben beleköthess a véleményembe. Csak véleményeztem a munkáikat, amik megannyi bosszúságot okoznak a Linux-világnak és ezért semmilyen szempontból nem tekinthetőek jó minőségű munkának. Ez nem feltétlenül a hülyeségüknek, inkább a rossz döntéseik sorozatának köszönhető.

    "Mert soha nem volt vágyam egy arrogáns multinál dolgozni." - pedig a habitusoddal beleillenél egy tetszőleges arrogáns társaságba... Sőt. te lennél a vezérökör. (csak véleményeztem a hup-os minkásságodat)

    "Nem tartom magam okosabbnak és nem is mondam ilyet," - Mindenkiről, aki nem te vagy, olyan lesújtó véleményt alkotsz, hogy tisztán következik belőle, hogy magadat mindenkinél okosabbnak és nagyobb tudásúnak tartod.
     

    pedig a habitusoddal beleillenél egy tetszőleges arrogáns társaságba

    Bagoly mondja, user error huszár multimosdatókám. Bagoly mondja.

    Mindenkiről, aki nem te vagy, olyan lesújtó véleményt alkotsz, hogy tisztán következik belőle

    Ezt te így következteted ki, tévesen, a szélsőségesen idealista, szűklátókörű skatulyalogikáddal. Ettől persze még nem igaz.

    > Akinek enterprise Linux vendorként semmi más dolga nem lenne, mint a jelenleg elérhető szoftvereket stabilan összeboronálni és karbantartani.

    Már miért lenne csak ez a dolga? Most lendüljünk már túl azon, hogy még mindig nem a te tiszted megmondani, hogy kinek mit kellene csinálni, de az opensource nagy részét bizony olyan cégek csinálják, mint pl az RH, nem random gyerekek apa pincéjében. És az RHnak általában egész jól megy, hogy valóban opensource szellemben csináljon dolgokat.

    > Csak épp ezek pont nem az erősségei.

    Hát pedig de, ez pont kifejezetten jól megy az RHnak

    >  feature ágas felhasználókon való bétateszteléssel

    1. A feature ág pontosan ezt jelenti: kapod a friss fejlesztést, korán gyorsan

    2. Mi is az open source mantra? Ja, igen. Release early, release often.

    Már miért lenne csak ez a dolga?

    Mert egy enterprise-disztróért elsősorban a stabilitásért és a kiszámíthatóságért fizetek. Nem azért, hogy kísérleti nyúl legyek. Ha a Red Hat semmi mást nem csinálna, mint meglévő open-source projekteket simítana össze, sokkal jobb Linux-világot élnénk, systemd, pluseaudio, gtk3, libinput, avahi-daemon stb. nélkül.

    Hát pedig de, ez pont kifejezetten jól megy az RHnak

    Ja, azért kellett szarrátörni mindent a systemd-vel, a pulseaudioval, a gtk3-mal 2-3 éven keresztül, még a saját API-jukat is.

    Release early, release often.

    Ez eredetileg a Linux-kernelfejlesztők mantrája, nem a teljes open-source közösségé. Később az agilis módszertant alkalmazó multik babzsákfejlesztői járatták csúcsra, csakhogy ők a mai napig nem rendelkeznek sem azzal a kompetenciával, sem azzal a mögöttes szemléletmóddal, amivel a Linux-kernelfejlesztők.

    > Mert egy enterprise-disztróért elsősorban a stabilitásért és a kiszámíthatóságért fizetek.

    Először is, szögezzük le, hogy ha kicsit is önazonos vagy, akkor ezért se fizettél sose egy fityinget, csak a partvonalról pofázol. Szóval fogalmad sincs arról, hogy tulajdonképpen miért fizet egy enterprise distro vevője. És bár ezek fontos pontok, a kérdés messze nem ennyire egyszerű. Pl egész sokat nyom a latban, hogy az enterpise bajaimra legyenek benne megoldások, szóval nem egy olyan elrugaszkodott gondolat, hogy a hiányzó lukakat a vendor megpróbálja betömni. Egyébként pedig:

    >  Nem azért, hogy kísérleti nyúl legyek

    Ja kérem, ha hajlandó lennél fizetni, akkor tudnád, hogy ilyen major izéket nem hoznak főverziók között. Azt is tudnád, hogy pl a systemdre átállásra még most is van időd 2024ig, addig lehet ugyanis extended supportal RHEL6ot csinálni. Ha esetleg nem lett volna elég időd kiszámítani az elmúlt ~10 évben, amióta a fedorában (tudod, a valódi kisérleti nyulaknál) default, vagy az elmúlt ~7-ben, amióta a firssebb RHEL már azzal jön. Mire a 2024 eljön, egy systemdvel szálított főverziót (7) már biztosan kihagyhatsz, és mivel egyrészt historikusan látszik, hogy 4-5 évente van release, másrészt jelenleg a 8 full support dátumának vége szintén 2024, csak kicsit korábban, mint a fenti, ezért jó esélyed van rá, hogy akár azt is kihagyhasd, és egyből a 9esre menj, szóval 2 releaseben lehettek mások a kísérleti nyulak. Ja, az RH nem kiszámítható.

    >  sokkal jobb Linux-világot élnénk, systemd, pluseaudio, gtk3, libinput, avahi-daemon stb. nélkül.

    Maradjunk abban, hogy szerinted.

    > Ez eredetileg a Linux-kernelfejlesztők mantrája, nem a teljes open-source közösségé. Később az agilis módszertant alkalmazó multik babzsákfejlesztői járatták csúcsra

    Hát, az igazi opensource projektek nem nagyon tudnak agilis módszertanok mentén fejlődni. Mármint azok, amik a "közösségé" és nem igazából valamelyik cég adományai. Pl mert nincs nekik főnökük, össze vissza ülnek, meg foglalkoznak vele, illetve mert nem igazán van okuk, hogy igyekezzenek az üzleti igényeket kielégíteni. Ezzel együtt, bár a mantra a kernel fejlesztőké, in practice így működött ez azokban a régi szép napokban a legtöbb dologgal :)

    Ezt az álláspontod kivételesen megint osztom. A Red Hatnak nem kéne ilyesmikkel előhozakodnia, már így is elég kárt okozott a Linuxnak a systemd-vel meg a pulseaudio-val. De pont azért, mert nagy cég, nem akar csak egy közönséges, n+1. összerakó vendor lenni, hanem aktívan bele akarnak szólni a linuxos inftrastruktúra fejlesztésébe, fejlődésébe, hogy ne őnekik kelljen igazodni a többiekhez, hanem a többiek igazodjanak hozzájuk, pont ezért dolgozik be a kernelbe a MS is, meg egy csomó más nagy cég, nem szívjóságból, meg piárból. Ennek mentén meg igyekeznek mindenből újra feltalálni a kereket. Próbálnak belőle egyfajta alternatív Windowst vagy alternatív MacOS-t gyúrni, amit nagyon nem kéne. A Linux addig volt jó, amíg magánhobbisták reszelgették maguknak, és igyekeztek a rendszer erőforrásait és átláthatóságát szem előtt tartani, az egyszerűséggel és a Unix-filozófiával egyetemben, igaz sokkal kevesebb dolgot is támogatott, de azt normálisabb minőségben. És nem csak a Red Hat, hanem a Canonical is ilyen, ők is rendre fel akarták találni a kereket, sysvinit helyett upstart, X.org és Wayland helyett Mir, Gnome2 helyett Unity (ami bukta lett), most jelenleg a Snap-bloatjaikat erőltetik bele a rendszerbe, hogy minden Snap legyen, ne natív .deb csomag, korábban meg az amazonos spylinkeket, ami a keresési eredményeket küldte az Amazon felé. Jobb lenne, ha ezeket a törekvéseket feladnák a multik, nem kell a Linuxból Windowst meg MacOS-t csinálni, arra már ott van ez a kettő, aki olyan szutykokat akar, az használhatta őket eddig is.

    És a systemd-vel meg a pulseaudio-val nem is az a baj, hogy van, meg hogy miilyen feature-ókkel és minőségben van implementálva, mert akinek erre van igénye, az használja felőlem, egyel több alternatíva. De ehelyett nem alternatívának van kezelve, hanem minden rájuk dependel, és ezzel rá vannak kényszerítve mindenkire, igaz ez nem a systemd, pulseaudio, Poettering meg a Red Hat hibája, hanem a sok szűk látókörű fejlesztőké, akik kényelemből rádependelik ezekre a szoftvereiket, holott senki nem kötelezi őket rá. Itt van a legnagyobb gond ezekkel az újrafeltalált innovációkkal, a multik csak elkezdik, de ha a fejlesztők nem harapnának rá, elhalnának ezek a corporate bloatosíási kísérletek.

    Ugyanez van az okostelefonoknál is. A Google az Androiddal az iOS-t másolja, az Apple nem enged SD kártyát, meg cserélhető akkut, a többi gyártó se engedi, az Apple elhagyja az audiojacket és bevezeti a notcht, a többi gyártó is azonnal másolja, nem ad töltőt a teló mellé, nem ad a többi se. Ilyen egy hülye a kútba ugrik, a többi ész nélkül ugrik utána, mert az a sikk. Vagy a laptopgyártók, akik szintén mindenben az Apple Macbookját utánozzák, vékonyságban, csatik szegényítésében, minden odaforrasztva, nem cserélhető, nem upgrade-elhető, stb.. Közben meg nem az Apple-t kéne utánozni, hanem egyedi alternatív innovációkkal jönni, és ezen nem a hajlítható meg összhajtható kijelzős baromságot értem, hanem hasznos feature-öket.

    És még mielőtt valaki azzal jönne, hogy sánta párhuzamokat írok, mert a Linux meg a Red Hat nem Apple, csak úgy mondom, hogy a systemd-t és a pulseaudio-t pont hogy a MacOS-ből leste el Red Hat és Poettering, azokat próbálták lekoppintani. Tehát a lejtőn a dolgokat itt is az Apple indította el igazából, szerintem a legkárosabb IT cég ever, pedig ezért a címért erős versenyben vannak még a MS, Google, Oracle, stb. is. De említhetném a Gnome-ot is, ami szintén a MacOS-t próbálja utánozni, vagy a flat dizájnosítást, tabletesítést, amit megint a MacOS-ből, meg iOS-ből próbáltak áthozni, az iPad és iPhone-ok sikerén felbuzdulva, erre a hájpvonatra még a MS is felszállt a Win8 Metro/ModernUI-jal, Surface-termékvonallal, meg egyfelé felület minden eszközre, mobilra és desktopra is, ami még a Win10-ben is érezteti a hatását. A MS szintén a MacOS-t utánozza, hogy egyféle OS főverzió legyen (ala Win10), de az félrolling alapon frissítve.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    " De ehelyett nem alternatívának van kezelve, hanem minden rájuk dependel," - Talán mert látják az előnyeit...? Erre még nem gondoltál? Ha és amennyiben tényleg annyira sz@r lenne, nem hiszem, hogy értelmes, nálam és nálad is vélhetően jobban képben lévő fejlesztők/architect-ek nem ebbe az irányba mennének. Igen, tudom, a prutymutyix disztró nem systemd és nem pulseaudio, sőt a mutyitrutyix sem, meg... Melyik nagy mainstream sorolható még ide?

    Erre még nem gondoltál? Ha és amennyiben tényleg annyira sz@r lenne, [...] irányba mennének. 

     

    Lehetene erre azt mondani, hogy 10 milliárd légy, de én is azt gondolom, hogy ha tényleg annyira szar lenne, akkor az "extraprofit maximalizálás" miatt rég ki lett volna már dobva, legkésőbb RHEL8-ra.

    Ha ennek az előnyei kellenek, használj MacOS-t. Abban már eleve egy olyan initrendszer és audio-alrendszer van, amiről a systemd-t és pulseaudio-t koppintották, épp ugyanazokat az előnyöket fogod élvezni. Ezt nem kell még egyszer kitalálni, meg a Linuxra kötelezően rátolni, akinek erre van igénye, az használ Mac-et, eddig is tudott már évtizedek óta. Épp így, akinek DRM-re, meg registryre, meg 4 vírusirtóra, 5 tűzfalra, mindenféle bloat absztrakcióra van igénye, az eddig is tudta használni Windows alatt, nem kell újra feltalálni Linux alatt, hogy abból is Windowst csináljanak. Arra már ott a Windows, azt kell feltenni, bárhol kapható, akár 5 dollárért is az eBayen lehet hozzá venni egy használható kulcsot, és lehet nyomatni, széleskörű driver és szoftvertámogatása van, határozatlan idejű support van rá, stb..

    A systemd-mentes disztrókkal meg az a baj, hogy hiába nem systemd az initrendszer bennük, épp úgy fut alattuk az elogind, libszutyokd, poetteringd, (esetleg apulse), mivel a csomagok meg rá vannak dependelve, és futtathatóak kell maradjanak, így lényegében a systemd egyes alrendszerei továbbra is futnak a háttérben, és a user csak saját magát hülyíti, hogy nem systemd-t, meg nem pulseaudiót használ, közben meg dehogynem.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    "a Linuxra kötelezően rátolni," - Nem kötelező, lehet saját, ezek nélküli forkot csinálni. Mainstream nem lesz belőle, az igaz, de ennyi.

    "épp úgy fut alattuk az elogind, libszutyokd, poetteringd, (esetleg apulse), mivel a csomagok meg rá vannak dependelve" - Jaaa, hogy sok-sok munka lenne midnent is átírni saját kedv és igény szerint... Ha megfelelő nagyságú fejlesztői és felhazsnálói bázist szedsz össze, menni fog. Nem azonnal, de mit számít 4-5-10 vagy több év, ha azzal a világot is megváltod...

    épp úgy fut alattuk az elogind, libszutyokd, poetteringd

    Azért ne essünk át a ló túlsó oldalára sem: attól még, hogy valamire ránézett Poettering, még nem válik rögtön patás ördöggé. A systemd-vel az a probléma, hogy a) egy hatalmas, monolitikus rendszer, b) PID 1-ként fut, tehát össze tudja dönteni az egész rendszert. Ezek egyike sem igaz az elogind-re.

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

    Itt a környéken zeller kollégával értek egyet. Azért dependálnak rá a software-ek, mert egy jó API lett kitalálva. Az más kérdés, hogy a Pulseaudio implementáció vacak. Viszont a PipeWire egyik API-ja teljes egészében pulseaudio API. Olyannyira, hogy a kliens library-t nem is írták újra, az marad a pulseaudioé.

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

    Az más kérdés, hogy a Pulseaudio implementáció vacak.

    Tehát ha odaszarok a tányérra, tortát formálok belőle és ráírom, hogy ehető, akkor megeszed.

    A vacak implementáció, az instabil működés, a seregnyi bug, aminek egy része mai napig javítatlan, a sok tízezer debugolással, konfigolással töltött munkaóra mind-mind önmagában is egy nyomós érv a pulseaudio ellen. Ha ezt nem a Red Hat erőltette volna az ipari befolyásával, akkor már rég a süllyesztőben lenne - ahová való.

    Ugye, nem erősséged a programozás, csak szeretsz írni hülyeségeket? Elég szorosan követem a projectet, segítek a fejlesztőknek, egészen mást gondolok erről, mint te. Ettől persze még bátran írhatsz sületlenségeket, elvégre alanyi jogod. :)

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

    Pedig én örülnék a legjobban, ha nem lenne igazam.

    Elég szorosan követem a projectet, segítek a fejlesztőknek

    Akkor tietek a pálya! Cáfoljatok meg!

    Ne mondhassák 5 év múlva, mikor multiék már beleerőltették ezt is minden disztróba, hogy "hajbinak igaza volt".

    Nem erőltette a pulseaudio-t sem senki, viszont annak örülni fogok, ha minden Linux disztribúció multimédia sharing szervere - tehát a hangszervere is - a PipeWire lesz. Nem kényszerből, hanem mert jó.

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

    Egyrészt, ez önmagában épp elég baj vele.

    Másrészt, olvasgasd: http://web.archive.org/web/20140909093139/http://boycottsystemd.org/

    Vannak itt azért bőven szakmai érvek. Más kérdés, ha téged ezek nem érdekelnek, de ettől még corporate erővel lett torkokon lenyomva a systemd és továbbra is biztos vagyok benne, hogy ha Poetteringnek ez egy házi barkácsprojektje lett volna úgy, hogy nem a Red Hat-nál dolgozik, akkor most nem lenne systemd.

    ( mogorva v | 2021. 01. 18., h – 09:35 )

     De ehelyett nem alternatívának van kezelve, hanem minden rájuk dependel, és ezzel rá vannak kényszerítve

     

    Hát nem tudom, tarts te karban és supportálj gazdaságosan 2-3-4 féle init rendszert.

     

    az Apple nem enged SD kártyát, meg cserélhető akkut, a többi gyártó se engedi,

     

    Ez pontosan hogyan történik? A Xiaomi nagyon szerette volna, de az Apple odament és kést szorított a torkához? Ezt látva a Samsung meg inkább csöndben megette a kapcsolási rajzokat, amik a saját cserélhető SD kártyás megoldásához kellettek volna? 

    Nem lehet, hogy ez megint csak arról szól, hogy spórolnak 50 centet, de akkora tételben már számít és ha másoknál benyelték a felhasználók, akkor nekik nem kell erőlködni?

    Nem kell nekem 3-4 féle initrendszert fenntartani és támogatni. Azt megteszi minden initrendszerrel a saját fejlesztőgárdája. A lényeg, hogy nem kell a szoftvereket a systemd-re dependelni, és egyből szabadon cserélgethető lesz az initrendszer alatta, nem kell semmilyen extra támogatás semmihez. Ahogy pl. most X.org szerveren bármilyen WM-et le tudsz cserélni bármi másikra, épp úgy futnak az X-es programok, meg még Wayland protokollt használó WM/kompzitor alatt is XWayland emulációval, ilyen rugalmasnak kéne lennie az initrendszernek is. Hangrendszernek nem különben, ha minden sima ALSA-t használna, akkor mindegy lenne, hogy ALSA fut, vagy Pulsaudio is fölötte, vagy PipeWire.

    Az SD kártya, akku csak egy példa volt. Pont ezt írom én is, hogy senki nem tart kést senki torkához, egy hülye multi (tipikusan Apple) elkezdi a baromságot, a többi meg önszántából megy utána, mert kényelmes, meg az a cool, az a jövő. Közben meg egy nagy lila-kék-eres bránerség, de hájpolni kell, mert Apple. Ahogy pl. Poettering se kényszerít senkit, hogy a systemd-t vagy a pulseaudio-t használja, mégis rá dependelnek minden szutykot.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    ha minden sima ALSA-t használna, akkor mindegy lenne, hogy ALSA fut, vagy Pulsaudio is fölötte, vagy PipeWire.

    Ami csak azért nincs így, mert a pulse API lényegesen többet tud, mint az alsa API. Az egy dolog, hogy van a pulseaudionak és a pipewire-nek is alsa interface-e, de ez a fallback, ha úgy tetszik, csökkentett mód. Ráadásul éppen azért, mert van a pipewire-nek - és a pulse-nek is - alsa interface-e, kívánságod teljesült. Azt meg hadd döntse el az alkalmazás írója, hogy beleteszi az alsa és a pulse illesztést is, mint pl. az audacious-ban, vagy csak pulse interface-re illeszt, mert jó, kényelmes, egyszerű.

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

    pont irni akartam, hogy nalam jobban csak kevesek utaljak a systemd-t szivbol, de annyira azert nem vagyok hulye hogy ne ertsem meg, hogy miert terjedhetett el, akarcsak a pestis a kozepkorban. :D

    A disztributoroknak nem millio kis szart kell supportolni hanem csak egy nagy osszehanyt valamit

    A fejlesztoknek eleg egy valamire dependalniuk es nem kell millio programhoz illeszteniuk a termekuket, hogy mukodjon soundA-val meg soundB-vel meg loginA-val es loginC-vel, hiszen ott a systemD, ami mindent is tud, megha esetleg szarul is. Majd azt javitjak, de a sajat programmal nem lesz  gond. Ha csak a systemd nem tor el valamit, de az akkor is csak egy lehetseges tores es nem sok kis termek permutacioja :D

    Ettol meg nem fogom szeretni :D Szeresse az akinek penze van belole, hogy emiatt 20%-al kevesebb fejleszto beret kell kifizetnie :D  

    A disztributoroknak nem millio kis szart kell supportolni hanem csak egy nagy osszehanyt valamit

    Ezt sose értettem. Egy adott disztró választott (presystemd időkben) valamilyen init-rendszert, és ahhoz az egyhez gyártotta a az indítófájlokat. Miért kellene milliót szupportálni?

    fejlesztoknek eleg egy valamire dependalniuk

    Ez is szerintem így működött a premindenegységesésnagyonjó időkben. Minden program készítője kiválasztotta, hogy milyen hang- és grafikus rendszert, konfigfeldolgozó rutint, buildrendszert, stb. használ, és azt alkalmazta. Ha valamelyik disztró ezt a programot érdemesnek találta, készített hozzá és a (hiányzó) függőségeihez csomagot.
    Nyilván minél egyformábbak a programok igényei, annál kevesebb csomagot kell karbantartani - cserébe a választás és a változatosság lehetősége veszik el.

    Annyi elég lenne a legtöbb asztali felhasználónak, amit az ALSA tud. Egyébként a Linuxnak ez a hangrendszer gyenge oldala volt mindig is, már az OSS-es időszakban is, most már egyszerre 3 interface-t kevernek, ALSA, PA, Jack, egy baromi nagy káosz az egész, az volt mindig is, erre most jött ez a 4. PW. Egy API kéne, azt nem bloat, nem Mac-mintára, normálisan megcsinálni. Nem Poetteringnek, nem a Red Hatnek, hanem a közösségnek, egy koncepcionálisan normálisan lefektetett API-val. A legközelebb még az ALSA volt egy normális implementációhoz, de félkészen hagyták.

    Azt meg el kéne felejteni az egész iparágank, hogy mit csinál az Apple, mi van épp MacOS-n. Egy rétegrendszer, nem kéne vele foglalkozni, nem lenne szabad, hogy bármit is meghatározon. Akinek tetszik, az használja, vegyen Mac-et, ha nem a legfrissebb generációt veszik újonnan, megfizethető. Akinek viszont nincs Mac-je, mint nekem vagy neked, az nem véletlen, nem azért, mert nem volt pénz Apple-cuccra.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Amióta a multik invazív módon eltérítették a Linux disztrókat, azóta ugyanaz a menő, ami a multik berkein belül előtte is az volt: majmolni egy másik multit.

    A közösség veteránjai pedig vagy "odavesztek" a jóval nagyobb apparátussal, több tech-evangelistával és közösségi influenszerrel rendelkező multik ellen folytatott szakmai-ideológiai harcban és átálltak nem mainstream projektek mögé, mint a Devuan, vagy átköltöztek a BSD nevű bolygóra, vagy behódoltak.

    Furcsa mód, kezdem azt hinni, hogy a korábban szabad Linux-világ multik általi invázióját valójában a GPL virális licencelésének köszönhetjük. Annak a kitételnek, hogy kötelező visszaadni a közösségnek a forráskódot. A közösség pedig egyre inkább csak hírnevet, menőséget, átlagnál 4x magasabb fizetést akaró, a konzumerizmus által meghülyített fejlesztőkből áll, akik egyre kevesebb kompetenciával kerülnek oda a multikhoz. Ahogy Chain-Q veteránunk idézte egyszer, egy ugyanezen témájú threadben.

    When in doubt, follow the money.

    A folyamat pedig egyre erősodik, ahogy az egyetemi képzések és vele együtt a szürkeállomány is silányodik és veszik át a helyüket a Facebook-Instagram-Tiktok szentháromságon szocializálódott újgenerációs babzsákfejlesztők.

    A stallmani, a multik proprietary-kódokban megnyilvánuló arroganciája elleni lázadáson alapuló ideológia végül önmaga ellen fordul és felfalja a közösséget, a szabad közösségi fejlesztés koncepciójával és minden értékével együtt. Melyet jelenleg szintén multik teljesítenek be. Amellett, hogy egyébként a nap mint nap használt termékek és szolgáltatásuk továbbra is zárt forrásúak (webes JS-szutykok, okostelefon bloatware-ek).

    Annyi elég lenne a legtöbb asztali felhasználónak, amit az ALSA tud.

    Nem lenne elég. Ugyan nem vagyok képzett alsa-ból, de szerintem nem tud resampling-et. Azt sem tudja, hogy online zenét hallgatok audacios-zal  bluetooth-on mikro hifi hangfalán, majd ugyanezen a gépen megnézek és meghallgatok ezzel egyidőben egy youtube videót a gép saját hangszóróin hallgatva, mert abban például szöveg van. Teljesen átlagos felhasználó vagyok. Van két input stream-em, meg két sink-em, szeretném eldönteni, melyik hova menjen, s milyen hangerővel, s mindezt tegye egyszerre. Az alsa ezzel szemben egy minimális réteg userspace-ben, ami illeszt a kernel API-hoz.

    Amúgy jól látod, van eddig alsa, pulse, jack API. A pipewire audio terén az, amit hiányolsz. Mindhárom API-t megvalósítja, így nem kell az alkalmazásokat újraírni. Ráadásul eddig jól valósítja meg, nem óriási erőforrások felemésztésével, nem figyelmen kívül hagyva azt, hogy nem realtime a kernel, és így tovább.

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

    szerintem nem tud resampling-et

    De tud (rate plugin).

    Azt sem tudja, hogy online zenét hallgatok audacios-zal  bluetooth-on mikro hifi hangfalán, majd ugyanezen a gépen megnézek és meghallgatok ezzel egyidőben egy youtube videót

    De igen, ezt is tudja, egy jól megírt asound.conf, bár JACK-kel talán kényelmesebb.

    Teljesen átlagos felhasználó vagyok.

    Nem vagy az, de az igényeid sem a PipeWire-nek, sem a PulseAudio-nak nem adnak létjogosultságot. JACK-kel megvalósítható.

    Van két input stream-em, meg két sink-em, szeretném eldönteni, melyik hova menjen, s milyen hangerővel, s mindezt tegye egyszerre.

    Amit a JACK is tudott már ALSA előtt, OSS-sel.

    Ráadásul eddig jól valósítja meg, nem óriási erőforrások felemésztésével

    Még nem. Minden újrafeltalált kerék így indul a 0.X.Y verziójával. Aztán amikor kikerül a nagyvilágba, jönnek a meglepetések, a bugok, a crash-ek, meg a kényelmeskedőnél kényelmeskedőbb "teljesen átlagos felhasználó vagyok" igények, és vele együtt a bloat, meg a GTK4-es user interface, ami 4x annyi erőforrást fog zabálni, mintha GTK2-ben írták volna meg, csakhogy pixelpazarló retinasznobék élvezkedhessenek a 4K-monitorjuk előtt, milyen szépen skálázódik a UI, meg Tapicskoló Tamás soha meg nem született, Linux-felhasználó ivadéka is örüljön, hogy végre nagyképernyősített okostelefon előtt ücsöröghet a kényelmes seggén.

    nincs GUI-ja

    Még nincs. Aztán kikerül a nullapont-verziós stádiumból és gányolnak hozzá egyet. Abban te már valószínűleg nem fogsz részt venni.

    Pipewire-nél nem kell semmit megírni, intézi az egészet automatikusan, dinamikusan.

    Cserébe magát a Pipewire-t kell megírni. Vagyis még egy, mindent is tudó ígérő újrafeltalált kereket.

    A tengelycsonkodon ott van a kerék is, csak olyan szűk látókörben szemlélődsz, hogy nem látod a tengelycsonktól a kereket, mert nem vetted a fáradságot, hogy megismerd (lásd rate pluginos felsülésed).

    A megnyilvánulásaidból egyértelműen lejön, hogy fogalmad nincs az ALSA haladó funkcióiról, de még arról sem, mit adhat neked akár egyégsugarú felhasználóként. A PipeWire projekt belengetett céljából és (vélt) értelméből ítélve pedig ez ugyanúgy igaz a Red Hat babzsákfejlesztőire is, akikkel jelenleg együtt dolgozol.

    Milyen felsülésem? Odaírtam, hogy szerintem, mivel nem néztem utána. Az megy amúgy az alsa-nak, hogy különböző mintavételi frekvenciájú audio stream-eket játszik le egyszerre? Nem tudom, lehet, hogy igen. És persze nem úgy, hogy előbb felkonfigolod az alsa-t, hogy akkor most játsszuk le ezt a két hanganyagot, mert 1 perc elteltével más hanganyag jön majd.

    Aztán mi van azzal, amikor egy hangkártya sok kimenetét splitelni kell, mintha több hangkártya lenne, vagy több hangkártyát mergelni, mintha egy lenne? Ezekre biztosan az alsa a legalkalmasabb eszköz?

    Még mindig műszeriparban dolgozom, hardware fejlesztő vagyok, semmi közöm a Red Hat-hez, legfeljebb szabadidőmben segítek nekik.

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

    nem néztem utána

    Nem tudom, lehet, hogy igen.

    Igen, erről beszéltem. Hogy fogalmatlanul találjátok fel újra a kereket. Mindeközben elmondjátok minden szarnak, idejétmúltnak, elavultnak, nehézkesnek, alkalmatlannak az ALSÁ-t. Úgy, hogy nem is ismeritek.

    És persze nem úgy, hogy előbb felkonfigolod az alsa-t

    Akkor ennyi erővel: "nem úgy, hogy előbb megírod a PipeWire-t" ... a PipeWire már rég túlhaladta azt az effortot és kódmennyiséget (kb. 180 000 sor), mint amennyi asound.conf-ot a Linux felhasználók valaha is írtak, mert írniuk kellett.

    Ezekre biztosan az alsa a legalkalmasabb eszköz?

    Alkalmas rá, mint low-level eszköz. Amihez akár command-line akár GUI-s segédprogramot össze lehet rittyenteni, ha akarsz, ami a felhasználóval való high-level interakciók után megvalósítja.

    semmi közöm a Red Hat-hez, legfeljebb szabadidőmben segítek nekik

    Ha neked az megéri, hogy milliárdos multiknak ingyen dolgozz valamin, amit majd a soron következő scrum master és/vagy termékmenedzser váltásnál deprekálnak egy újabb trendi idealizmusért cserébe, hát te tudod.

    A kerékújrafeltalálás erőltetése és a high-level API-kon való kényelmeskedés csúcsra járatása a babzsákfejlesztés, meg úgy általában az, ami a Red Hatnál "fejlesztés" címszó alatt zajlik.

    Igen, egy GUI-s alkalmazást is lehet hatékonyra, nem bloat-ra írni. Keveseknek sikerült eddig.

    "úgy általában az, ami a Red Hatnál "fejlesztés" címszó alatt zajlik." - Szerintem van felvétel, Chief Architect pozit pályázz meg náluk, aztán mutasd meg, hogy hogyan kell csinálni - merthogy te biztos okosabb vagy, és szélesebb látókörrel rendelkezel mindenkinél _is_. Ha már itt nem mutattál semmit, ami alapján leszűrhető, hogy értessz-e hozzá, vagy csak szájtépésben vagy profi, akkor ott mutasd meg legalább.

    Akkor ennyi erővel: "nem úgy, hogy előbb megírod a PipeWire-t" ... a PipeWire már rég túlhaladta azt az effortot és kódmennyiséget (kb. 180 000 sor), mint amennyi asound.conf-ot a Linux felhasználók valaha is írtak, mert írniuk kellett.

    A egy általános futtatható kód, meg az egyedileg írandó konfigurációs állomány nagyon más. Azt hiszem, tényleg nem érted, mire való a pipewire. Azért van egy jó hírem a számodra: használhatod az alsa-t továbbra is. Már, ha találsz hozzá alkalmazásokat. :)

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

    Tudom, hogy más. A ráfordított erőfeszítések síkján hasonlítottam össze. Mert bármennyire más, a kódot is be kell gépelni, sőt jóval komplexebb egy ilyet összerakni, mint néhány ALSA konfigot azoknak, akiknek a default nem elég.

    Már, ha találsz hozzá alkalmazásokat. :)

    Nyilván Red Haték majd elintézik, hogy ne találjak. Ahogy eddig is ezt a fajta önkényeskedést tolták.

    Szerintem nem érted. Az alsa configot minden felhasználónak, aki nem ért és nem is akar hozzá érteni, annak is magának kellene a saját rendszeréhez megírnia. A pipewire viszont alkalmazkodik a hardware és software környezethez, a felhasználónak meg kell nyomni valahol egy play gombot, és szól. Ezért megéri a beletolt munka, energia, mert egyszer kell megírni olyanoknak, akik értenek hozzá. Szerintem nem mentek hozzád a Red Hat lovagjai, hogy elvegyék a terményeidet, s azt Wim Taymansnak adják, hogy megírja a PipeWire-t. :)

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

    Nem tudom, mennyire a kerék feltalálásáról van szó, valaki tesztelt ilyen körülmények között, majd bugreportolt:

    Just tested Pipewire for the first time in 6 months for stability, and I ran into two issues with my largest Ardour project (54 ins, 104 outs and tons of effects) [...]

    Bár lehet, hogy mindent az Ardour csinál, s a végén egyetlen mixelt stream-et ad át, de erről nem vagyok meggyőződve.

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

    Elvileg tud mixelni, de csak azonos ratet-tel, továbbá tudsz virtuális hangkártyát is létrehozni vele. Vannak mindenféle pluginek is: https://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html

    "antiegalitarian, antiliberal, antidemocratic, and antipopular"

    Valószínűleg minden mixelés úgy működik, hogy előbb egyforma rate-re konvertálják a különböző jeleket. Ezt meg itt is meg lehet csinálni! Tény, h borzasztóak ezek a konfig fájlok, de lehet h meg lehet szokni! Mondjuk ez nyilvánvalóan nem felhasználói szint. 

    "antiegalitarian, antiliberal, antidemocratic, and antipopular"

    Na jó, írok egy konfig file-t, lejátszom az egy perces hanganyagomat. Utána le szeretnék játszani valami mást, de előbb azért írok egy másik konfig file-t fél órán át doksikat olvasva. Ergonomikus. Nem inkább az a jó megoldás, hogy megnyomom az alkalmazáson a play gombot és szól?

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

    Gyakorlatban csak néhány use case lehet kritikus, ahol kerülni kell a PA-t. Azokra meg le lehet gyártani a megfelelő ALSA konfigokat! 

    De amúgy igazad van! Annál nincs jobb, h minden működik és semmit nem kell csinálni :) 

    "antiegalitarian, antiliberal, antidemocratic, and antipopular"

    Valószínűleg jóval több van az ALSAban mint gondoljuk! Csak nagyon eldugták. Hiányoznak a szájbarágós tutoriálok a bülbül formanyelvű konfigurálásához! Míg a JACK professzionálisabb felhasználást is intuitívabban biztosít.  

    Az igényekről is nehéz képet alkotni! Milyen programokat/eszközöket használnak az egyszerű felhasználók, hifisták, ipari környezetben telekommunikáció vagy épp az amatőr/profi zenészek? Őszintén szólva felhasználói oldalról nem igazán látom a PW előnyét! Mit érdekli az a felhasználót, h milyen APIn keresztül működik bármi? Mit ad PW egyébként amit korábbi szentháromság ne tudna megoldani? 

    "antiegalitarian, antiliberal, antidemocratic, and antipopular"

    Mit ad PW egyébként amit korábbi szentháromság ne tudna megoldani?

    Egyrészt a pipewire multimédia sharing szerver, így például egy videotelefon alkalmazásnak odaadhatod egy vlc video képét a kamera helyett. Ami a hangot illeti, ott olyasmi, mint a pulseaudio+jack, csak jól implementálva. A pulseaudionak a világ összes CPU ideje sem elég, pedig csak egy vacak hangról beszélünk. Ráadásul a pulseaudio hangja a mai napig használhatatlanul recseg-ropog bizonyos felhasználásokban. A pipewire pointereket ad át, nem másol feleslegesen egy rakás buffert. Az alsa-t azért nem írtam bele, mert a pulseaudio azt tudja.

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

    ( locsemege v | 2021. 01. 31., v – 16:34 )

    Rakás javítás került bele, a fontosabb fájdalmaim is megoldódtak. Ez egyfelől alsa rétegben volt, másfelől bluetooth probléma.

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

    ( locsemege v | 2021. 02. 19., p – 00:04 )

    Szerkesztve: 2021. 02. 19., p – 00:05

    0.3.22

    Benne ilyennel például:

    Implement per-client config files. Each pipewire client will now read a config file that you can use to configure the context of the client.

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

    ( locsemege v | 2021. 03. 18., cs – 17:14 )

    De elhanyagoltam ezt a blogot. Volt már 0.3.23, de azóta lett 0.3.24 is. Nagyjából január óta kínlódás volt a bluetooth-szal, de ebben a 0.3.24-ben végre megjavult. Legalább is az én konfigurációmban. Ebből nem következik, hogy bármilyen bluetooth eszközzel jó már, de mindenképp jobb, mint volt korábban, akár csak néhány napja.

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

    Szóval ennél az újrafeltalált keréknél is felemás lesz a bluetooth support, mint az előzőnél és egy Python-ban (!) megírt GUI appban kell majd összeszarakodni 2 crash között 100% CPU-val, vagy még ennél is gányabb megoldást enterprise-kodnak majd össze a Red Hat-nál az ingyenmunkátok fölé?

    Tanulj meg C-ben programozni! A forráskódját itt találod, debugold szorgalmasan, s ha hibát találsz benne, javítsd ki, majd a patch-et küldd el Wim Taymansnak. Szerintem örülni fog neki. Vagy legalább annyit tegyél meg, amit én megtettem, hogy időt, fáradságot nem kímélve debugoltam, logokat küldtem, s ezáltal a fejlesztők ki tudták javítani. A kerítés mögül csaholni sokkal egyszerűbb, kényelmesebb, nem olyan fárasztó és még látványos is. ;)

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

    Te ingyen dolgozol egy arrogáns, profithajhász multinak, amely nem képes a saját fejlesztői által egy valamirevaló szoftvert összerakni bugtenger, koncepcionális hibák, inkompatíbilitás, túltervezés és bloat nélkül (systemd, pulseaudio, gtk3, gnome3, wayland), cserébe a talpnyalóin keresztül erőlteti és lenyomja mindenki torkán. Nekem ennél drágább az időm és az elveimmel is ellenkezik.

    Neked sok sikert!

    És te mit tettél már le a közösség asztalára a szakamilag nulla tudásról árulkodó agyatlan fröcsögéseiden túl? Mert eddig ezen túlmenően semmi hasznodat nem láttuk errefelé. És máshol sem.
    Ha annyira drága az időd, akormiért foglalkozol a témával? menj, és inkább mással töltsd azt az időt, ameddig nem látnak az ápolók...

    "És te mit tettél már le a közösség asztalára a szakamilag nulla tudásról árulkodó agyatlan fröcsögéseiden túl?" - Nos? van válasz, vagy maradjunk annyiban, hogy egy szakmai és minden egyéb tudás nélküli troll vagy? (mert ahhoz is tudás kell, hogy (f)elismerd, hogy valamihez hülye vagy...)

    És ingyen használja annak az arrogáns profithajhász multinak a termékét és szolgáltatásait, igen. És ezért úgy gondolja, hogy amellett, hogy magának is jót tesz azzal, ha segít a hibák mielőbbi megtalálásában, hasznos, ha a közösségnek is ad vissza valamit... nem úgy, mint te, akinek a szakmai tudásáról csak annyi ismeretünk van, amennyit az idehányt böfögéseidből látunk - az meg... Szóval nem igazán fest rólad pozitív képet... Sőt.

    Sohasem értettem ezt az irigy hozzáállást. Dolgozom pénzért is, tervezek analóg és digitális hardware-t, írok firmware-t C-ben vagy assembly-ben. Ugyanakkor van, ami belefér a hobbyba. Mivel nekem gond volt a pulseaudio koncepcionálisan rossz mivolta - mindamellett vannak benne jó ötletek, csak rosszul implementálták -, s recsegett-ropogott a hang - nem zenehallgatás közben, csak VoIP használata esetén -, kidebugoltam, s igazolást nyert, hogy nem hálózati probléma, hanem pulseaudio buffer underrun, így figyelmem a pipewire felé fordult.

    Wim Taymans egy blogja alapján próbáltam ki, megtetszett, azóta sokat fejlődött, bár tény, hogy volt rengeteg regresszió is, viszont ezeket javítják folyamatosan. Különösképp, ha kapnak segítséget. Azért kell a segítség, mert nyilván a saját konfigján hibátlanul működik, de hardware és gép összeállítás annyi van, mint csillag az égen, tehát a legnyakatekertebb eseteket a fejlesztőknek nem áll módjukban kipróbálni. Marad az, hogy logokat kérnek azoktól, akiknél valami nem működik, s abból megvilágosodnak a fejlesztők.

    Nekem nem fáj, ha segítem a fejlesztést, mert van, ami nálam volt kellemetlen bug, de finoman szólva kivertem a fejlesztőkből a javítást, hogy végre használhassam. Meg, ahogy zeller is írta, ingyen használom a munkájukat. Ha úgy tetszik, én ezzel a segítséggel fizetek érte.

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

    s recsegett-ropogott a hang - nem zenehallgatás közben, csak VoIP használata esetén -, kidebugoltam, s igazolást nyert, hogy nem hálózati probléma, hanem pulseaudio buffer underrun, így figyelmem a pipewire felé fordult.

    Ahelyett, hogy esetleg kijavítottad volna a pulseaudio-ban, amit már sikeresen ráerőltettek többmillió emberre, akinél mindnél recseg most az audiokonferencia.

    Tovább gondolva, 8 év múlva, miután az eredeti kezdeti, nullapontverziós lelkesedésed már lelankadt, lesz majd egy másik locsemege, akinél a Chromium 1365 verziójára épülő, natívnak hazudott huszonötezredik audiokonferenciaszoftver nem képes egy olyan alapfeladatra, amit egy Windows 95-ös NetMeeting vagy Speak Freely is meg tudott csinálni a 30 évvel ezelőtt legyártott 16-bit-es ISÁ-s hangkártyán. Aztán, mivel a pipewire akkor már elavult™, jön majd az új locsemege és beszáll egy új projektbe ugyanazzal a nullapontverziós lelkesedéssel, mint most te. Egyik évtizedben a mikrofon recseg majd, másik évtizedben a hangszóró, harmadik évtizedben 1 mag 100%-on kihajtva meg telemetria kell majd ahhoz, hogy a hangkártya működhessen.

    A probléma továbbra sem veled van, hogy örömödet leled abban, hogy belefejlesztesz. A probléma azzal van, ahogy a Red Hat-os projektek működnek. Egy ponton megakad a fejlesztés és ott marad egy bétaverziós katyvasz bughalmaz, ami távolról sem production-ready, a Red Hat mégis beveti a multitalpnyaló és FOSS-influencer armadáját, hogy lenyomja mindenki torkán. Ez után pedig egyre kevésbé engednek majd be patcheket. Hiába írsz kifogástalan commitokból merge request-eket, jön majd egy enterprise-idealista Matthias Clasen, aki csakazért se fogja merge-elni a javításod, mert túl™ nagy™ munka lenne nekik, vagy épp az idealista architektúrájukba és a clean code konvencióikba nem illik bele teljes mértékben. A felhasználók meg szopjanak, nem csak Red Haton, hiszen az influenszerhálózat már lenyomta a torkokon.

    Meg, ahogy zeller is írta, ingyen használom a munkájukat. Ha úgy tetszik, én ezzel a segítséggel fizetek érte.

    Az, hogy Zeller Mérnök Úr így gondolkodik, azon nem csodálkozom. Azon, hogy te is, már egy kicsit jobban. Ez a fősodratú profitprotektor hozzáállás ott van elbaszva, hogy ha az open-source ingyenmunkák sokasága, ami a Linuxot megalapozta nem lenne, akkor Red Hat sem lenne. Ami miatt tényleg szomorú vagyok, hogy erre szívesebben láttam volna válaszként tőled egy "segítem a közösséget" közhelyet is, mintsem azt, hogy már te is átkozott üzleti logikával közelítesz meg egy ilyen kérdést: fizetni valamiért, cserébe, amit multik ingyenmunkára alapozva építettek fel, ráadásul etikátlanul, a közösséget párévente szembeköpve és felforgatva.

    Nézd, a hozzáállásodban az zavar, hogy sohasem akarsz a dolgok mögé nézni, mindig csak a felszínt kapargatod. Éppen úgy, mint a kocsmákban politizálók, akik nem értik, miért nem lehet örök élet, ingyen sör, meg pénzt is milyen egyszerű lenne nyomtatni, aztán csak szét kellene osztani az emberek között, és mindenki boldog. A sok hülye politikus meg közgazdász erre meg valahogy nem jött még rá.

    A hangkezeléssel az az egyik igen nagy probléma, hogy lényegében csak adott valószínűséggel biztosítható, hogy jó lesz a hang, nem fog akadozni. Ugyanis az operációs rendszer általános, minden processzt és minden igényt igyekszik kiszolgálni. Jó, emeljük meg a prioritást. És? Mi van, ha más processzek is magasabb prioritást követelnek? Mi van egy fork() bombánál? Mi van out of memory-nál? Mi történik, ha megszakítások és DMA kérések viszik el a futásidőt, illetve foglalják a buszt? A hang az közben fix sebességgel emészti a buffert, s hamarosan kiürül, de közben az oprendszernek lett egy 200-as loadja. :)

    Remélem, érted, hogy önmagában a platform általánossága adja a valós idejű folyamatok problémáit. Egy DDoS támadásnál sem tudja megmondani a szerver, melyik kérés valódi, s melyik rosszindulatú, de ha tudja, akkor is foglalkozni kell a szűrésével, ami idő. Meg sávszélesség, hogy bejön a rosszindulatú kérés.

    Ezt az egészet csak elég jól lehet csinálni, nem pedig tökéletesen.

    meg tudott csinálni a 30 évvel ezelőtt legyártott 16-bit-es ISÁ-s hangkártyán

    Bluetooth-on is? Még fel sem találták. Úgy is, hogy több hangkártyából egy virtuális legyen, vagy egy fizikai több virtuálisra van splitelve? Az is ment régen, hogy ugyanarról a gépről zenét hallgatsz bluetooth eszköz felé, miközben a saját hangkártyájára megy a böngésző hangja, de keveri egy harmadik alkalmazáséval, ahonnan eltérő mintavételi frekvenciával jön a hang, és individuálisan állíthatók a hangerők? Mert a pipewire ezeket tudja - egyébként a pulseaudio is.

    Addig nem túl bonyolult, amíg pontosan egyetlen alkalmazásból közvetlenül eteted hanggal a hardware-t, de itt nem ez a feladat.

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

    > Az is ment régen, hogy ugyanarról a gépről zenét hallgatsz bluetooth eszköz felé, miközben a saját hangkártyájára megy a böngésző hangja, de keveri egy harmadik alkalmazáséval, ahonnan eltérő mintavételi frekvenciával jön a hang, és individuálisan állíthatók a hangerők?

    A per-task volume level-t leszámítva (bár hákolással-tákolással az is megoldható) ezt az ALSA is tudja. Igen a BT-t is.

    > Mert a pipewire ezeket tudja - egyébként a pulseaudio is.

    Csak utóbbi rosszul csinálja.

    Oldschool Computer - http://oscomp.hu

    Csak tájékoztattam, hogy azért nem kell leírni az ALSA-t. Vannak gyíkjai és hiányosságai, de a pulse csak bajnak jött a nyakunkra. Viszont a PipeWire fejlesztőjénél egyelőre nem tapasztalom a poetteringi (RHEL/FreeDesktop) mentalitást; a cucc működik, a pulse is kiváltható vele és ami a legfontosabb, ez egyelőre opcionális.

    Oldschool Computer - http://oscomp.hu

    Engem pedig az zavar a hozzáállásodban, hogy azt gondolod, hogy minden desktop felhasználó egy okosotthonban élő, minden szart is 25 féle bluetooth-eszközön hallgató-felvevő és a lítium-ion akkumulátorok vezetéknélküli leányálmában élvezkedő, extrém igényű Linux audio enthusiast. Miközben meg semmi mást nem szeretne a normális felhasználók 99%, minthogy ha már a reklámok lehazudták a legkényelmesebb™ HD-audioeszközt, meg HD-audiokonferenciaszoftvert is az égről, akkor hadd legyen már egy kicsit HiFi minőségű és akadásmentes egy audiokonferencia 2021-ben. Mire a magadfajták válasza az lesz, hogy nem lehet, mert mi van, ha DoS-olnak, meg mi van, ha OOM, meg mi van, ha jön egy forkbomb, meg amúgy is lesz, hogy kiürül a puffer, nem lehet garantálni az akadásmentességet. Na meg, amúgy is hogyan támogatnánk több hangkártyát úgy, hogy egy virtuális legyen, meg egy fizikai több virtuálisra splitelve.

    Képzelem, hány felhasználó fogja majd 5 felé splitelni a streamjeit, pláne, hogy nem lesz ehhez sem normális grafikus konfigurátor, mint ahogy semmihez nem volt eddig, amihez a Red Hat hozzányúlt, a parancssorban meg továbbra is csak a magadfajták fognak konfigolgatni.

    Miközben azt várod, hogy más nézzen a dolgok mögé, valójában neked kéne egy kicsit kijönni a dolgok mögül és a valóságot, meg a valós felhasználási módokat is meglátnod, figyelembe venned, mert a most tanúsított hozzáállásod és a bluetooth, meg szanaszét split-elt audio-stream-es érveléseddel egyelőre ennek a mémnek a klinikai esete vagy: https://xkcd.com/619/

    Az a legszebb az egészben, hogy semmi akadálya annak, hogy alsa-t használj. Kicsit feature-szegény, de legalább faék egyszerűségű és rugalmatlan. Statikusan konfigurálhatod, s ha változik a hardware-ed, módosíthatod a config file-t. Azon meg ne bánkódj, hogy az alkalmazásoknak már alig van alsa interface-ük. Nyílt a forrásuk, írd bele. Vagy használj mégis csak pipewire-t.

    Amúgy konkrétan mi a fene bajod van ezzel a projecttel? Ha nem tetszik, ne végy róla tudomást, ne használd!

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

    > Kicsit feature-szegény, de legalább faék egyszerűségű és rugalmatlan.

    Azért ez elég erős túlzás.

    > Statikusan konfigurálhatod, s ha változik a hardware-ed, módosíthatod a config file-t.

    Ez meg nem igaz. Ha kicseréled a hangkáryát, akkor sem kell semmiféle konfigot túrni.

    Oldschool Computer - http://oscomp.hu

    Ismerősen cseng a mondat, csak nem emlékszem, honnan. Meg, hogy miért írtad. Mondjuk az tény, hogy az egy béna dolog, hogy ha van egy 32 csatornás DAC-od, akkor az alsa láttat 32 csatornát, így ennyi hangerőszabályozód lesz majd.

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

    Igen, ezt megtaláltam én is. Emlékszem, hogy egy időben rendszeresen feljött ez az írás első kommentként, de mostanra csak ezt a példányt találja meg a kereső. És ez stb.-vel végződik, ami gondolom azt jelenti, hogy valahol folytatódik is.

     

    És hogy jön a mindent átható felügyelet, az MTA WIGNER és a Persecutor Kft. össze.

     

    Ez a valaki, aki ezt folyton beposztolta át akart adni nekünk valami üzenetet, de egyszerűen nem értettük meg :-)

    Mindent tud, ami egyes embereknek kell (pl. nekem). A PW létjogosultsága, hogy az ALSA nem tudja azt, ami más embereknek kell (pl. neked, bár eddig amit felsoroltál igényként, azt mind tudta az ALSA, ha kompromisszumokkal is). A PA létjogosultága ugyanez lett volna, csak éppen a csapnivaló megvalósítás miatt több kár volt, mint haszon.
    A fő az, hogy attól, hogy valami többet tud, még nem biztos, hogy mindenkinek szüksége van rá, tehát csak addig extra, amíg opcionális, utána már kényszer. Namármost, ha ez mellett legalább jól van megcsinálva, akkor az ember maximum azért reklamálhat, hogy neki nincs rá szüksége, de a PA még szar is. Nagyon.

    Oldschool Computer - http://oscomp.hu

    Igen, azzal egyetértek, hogy a PA vacak. Tényleg nagyon. A PW viszont nagyon ígéretes project, noha nincs kész. Nagyjából napi szinten csinálok build-et belőle, meg rpm csomagokat, s teszem fel a gépemre. :)

    De ahogy írtam, nem csak a felhasználó számít, hanem a fejlesztő ideje is, tehát ha a PA kliens interface jól kitalált, kényelmes, akkor legyen az, s szerencsére a PW nem hozott létre egy n+1. interface-t, hanem audio-ra ott a pulse, jack, alsa neki. Bár van natív PW interface, de gyanítom, inkább a video miatt. Hangban elterjeszteni rizikós, mert akkor a PW-re fog dependálni az adott alkalmazás.

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

    A PW-vel nekem nincs bajom. Ez akinek kell, jó, akinek meg nem kell, nem kötelező. A PA-ra ez nem igaz, az akinek kellett is, annak is szar, akinek meg, annak meg ráadásul kényszer is.

    Őszintén szólva, ha már az alkalmazás mindenképpen dependálni fog vagy a PA-ra, vagy a PW-re, akkor inkább tegye ezt az utóbbira. A drótozás nem jó, de a PA még szarabb. :P

    Oldschool Computer - http://oscomp.hu

    Az a legszebb az egészben, hogy semmi akadálya annak, hogy alsa-t használj.

    De igen, amikor a nem faék egyszerűségű és rugalmatlan projektek babzsákfejlesztői önkényesen kidobják a supportját, aztán buildelgethetsz magadnak órákig minden verziót, a soron következő frissítéskor (Firefox). Nem beszélve a proprietary szutykokról (pl. audiokonferencia-alkalmazások), amik bármikor egy tollvonással kidobják az ALSA támogatást, mert az valamelyik idealista projektmenedzser szerint elavult™ és nem™ éri™ meg™ tovább támogatni azokból a milliárdokból, amikből a 12. generációs, 8 magos CPU-s, 1 TB SSD-s, 64 GB RAM-os fejlesztői™ munkaállomások által megtestesített bloat-gyártósorra futotta. Ezeknél esélyed nincs arra, hogy tényleg natívan ALSÁ-t használjanak.

    Amúgy konkrétan mi a fene bajod van ezzel a projecttel?

    Mint minden másik Red Hat projekttel. Előző hozzászólásokban már bőven leírtam.

    Arra még nem gondoltál, hogy a fejlesztőknek is lehetnek jogos igényeik, nem csak a felhasználóknak? Hiába működik jól az alsa, ha nehézkes az API-ja, ha a programozónak szívás vele dolgozni, ha a pulse és így vele kompatibilisen a pipewire API-ja viszont kényelmes.

    önkényesen kidobják a supportját, aztán buildelgethetsz magadnak órákig minden verziót, a soron következő frissítéskor

    Tehát akkor valójában mégis csak szükséged van a pipewire-re. Használd egészséggel!

    Valamiről amúgy nyilván lemaradtam, de amikor még alsa volt a pulseaudio előtti időkben, nem tudtam megcsinálni, hogy élő, online stream-et átdobtam egyik kimenetről a másikra, és viszont, s ezt vegyesen bármilyen mintavételi frekvenciájú stream-mel, hangerő megjegyzéssel, és most már ugyanez kép átvitellel is. Mert a pipewire nem egy pulseaudio replacement, lényegesen több annál.

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

    A PW egy dolog, de sajnos nem az a kváziszabvány linuxos audio-middle-layer, hanem a szutyok PA, ami sokkal több problémát kreált, mint amennyit az ALSA hiányosságai okoztak, arról nem is beszélve, hogy azért az ALSA is fejlődik, a hiányosságok egy része már a múlté.

    Oldschool Computer - http://oscomp.hu

    Az attól függ, hogy mit értünk "interface" alatt: magát az API-t, vagy a libpulse-ot? Az API-t nem tudom milyen, mert fejleszteni sose fejlesztettem pulse-ra, de emlékeim szerint az API-t nem is minősítettem. A libpulse viszont ugyanúgy szoftver, mint maga a szerver és annak is van minden baja; pl. a függőségekkel való kínlódás.

    Oldschool Computer - http://oscomp.hu

    Azért aki látott _jól_ használt sysvinit-et, meg látta azt, hogy Linux alattmivé lett, nos... Az ugyan publikusan nem biztos, hogy tett fel kérdéseket, de hogy magában megfogalmazódtak benne nem minden esetben szalonképes kérdések, az biztos... És ez ugye csak egy szelete annak, amit a systemd csinál.

    Nem, nem olyan. A sysvinit-et lehetne jól használni, de nem így van sajnos: jellemző, hogy 345scriptben legalább 234-féle módon megírják ugyanazt a funkciót, és minimum 123 scriptben bedrótozott paramétereket használnak, az inittab-ot, illetve a futási szinteket gyakorlatilag nem használják...

    Persze, aki az egyik szerszámot nem tanulja meg rendesen használni, az a másikat sem fogja- de legalább csökönyösen rahaszkodik ahhoz, amit bár használ, de nagyjából a "part menti hajózás" szintű vitorlás ismeretekkel...

    Arra még nem gondoltál, hogy a fejlesztőknek is lehetnek jogos igényeik, nem csak a felhasználóknak?

    Folyamatosan tapasztalom, a szoftverek elsilányodását, az instabilitást, a bloat-ot a fejlesztők nagy kényelmeskedései által. Számos példakód, implementáció létezik már az ALSÁ-ra, mivel jó két évtizede velünk van. Az, hogy valaki hozzád hasonlóan [1] "nem néztem utána", "nem tudom, lehet, hogy igen" alapon lusta megtanulni, utána nézni, beleásni magát, alkalmazkodni hozzá, egy dolog, de nem kéne, hogy okot adjon a Linux-világ felforgatására, amit a Red Hat 5 évente leművel az újrafeltalált kerekeivel.

    Tehát akkor valójában mégis csak szükséged van a pipewire-re. Használd egészséggel!

    Nem, nincs. Mivel a Firefox ALSÁ-val is jól tud működni, csak itt a Mozilla babzsákfejlesztői annyira nem™ akartak™ szívni™ és annyira kényelmesek™ voltak, hogy inkább kivették a már meglévő támogatást, csakhogy ne kelljen vele foglalkozniuk. Tehát, itt még csak nem is arról van szó, hogy babzsákfejlesztőék szerettek volna valamit jobban csinálni, ami egyben kényelmesebb is. Itt szerettek volna valamit nem csinálni, amivel sokaknak keresztbe tettek. Ez nem több, mint szimpla lustaság és kényelmeskedés és arrogancia.

    Sétálsz az irodaházban, ahol dolgozol, arra jövök, eladni neked az új fejlesztésű, kényelmes, WiFi-s, bluetooth-os, cloud-integrált okoskerekesszékem. Neked nem kell, mert tudsz két lábon járni, pedig hidd el, a kifejlesztése is azért ment jobban™, sikeresebben™, gördülékenyebben™, mert a mérnökök is az előző termékcsaládot használták. Neked továbbra sem kell. Ekkor én fogom a kapcsolataimat és elérem, hogy az irodaházban csökkentsék a belmagasságot másfél méterre. Onnantól közlekedés vagy négykézláb, vagy a szuperkényelmes okoskerekesszékemmel. Hogy tudtam, hogy szükségetek™ van rá. Használjátok™ egészséggel™!

    ^ Ezt művelitek most éppen.

    A világ az ember kényelmessége miatt fejlődik. Inkább feltaláljuk a kombájnt, csak ne kelljen kaszával aratni nyáron a földeken. Szóval önmagában azt számonkérni a programozón, hogy miért nem szereti sz.patni magát, amikor kevesebb munkával, egyszerűbben is elérheti a célt, szerintem felesleges.

    Én sem szeretem azt, ha valaki silányul, igénytelenül programozik, de van ennek egy gazdasági oldala is. Gyorsan kell sokat és jól csinálni. Egészen más, ha otthon polírozol magadnak hobbyból tükrösre egy vasgolyót hónapokig, meg az is más, amikor a kapitalista versenyben kell csinálnod nagyon sok elég jó minőségű vasgolyót, amit a vevő nem visz vissza garanciális javításra, de egyetlen felesleges percet sem töltesz az elkészítésével. Nem tudom, te mivel foglalkozol, miből élsz, de az a fajta naiv önmegvalósítás akkor működik, ha jó helyre születtél, sokat örököltél, vagy nyertél a lottón.

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

    > Inkább feltaláljuk a kombájnt, csak ne kelljen kaszával aratni nyáron a földeken.

    Csak pl. a PA esetében nem a kombájnt találtuk fel, hanem egy hernyótalpas vízikecskét, ami nem elég, hogy felzabálja a termést, de még irányítani sem lehet, hogy merre menjen.

    > van ennek egy gazdasági oldala is. Gyorsan kell sokat és jól csinálni.

    Pontosabban: "van ennek egy gazdasági oldala is. Gyorsan kell sokat és jól csinálni."

    És pontosan ez a "gazdasági" oldal, ami miatta szoftverek egyre rosszabbak lesznek.

    Oldschool Computer - http://oscomp.hu

    A világ az ember kényelmessége miatt fejlődik.

    Ez alapvetően egy közhely és jobban megnézve baromság. Különbséget kell tenni kényelem és lehetőség között. A telefon és később a mobiltelefon nem a kényelem, hanem a lehetőség miatt tudott elterjedni, hogy akkor is tudsz beszélni valakivel, amikor nem vagytok egy helyen. Lehet olyat játszani, hogy felhívom a szomszéd szobában lévő családtagom, haverom, hogy ne kelljen magam szopatni™ azzal, hogy felemelem a kényelmes seggem és pár lépéssel átmegyek hozzá, de az már alapvetően nem a világ fejlődését kiváltó nemes igény, hanem egy, a lustaságom által motivált pazarlás.

    Két folyamat létezik jelenleg. Az egyik, amikor a mesterségesen csúcsra járatott fogyasztói vadkapitalizmus pszichológiai manipulációval (értsd: reklámokkal) a kényelmesebb (értsd: fogyasztóibb, pazarlóbb) életvitelre buzdít, a profit érdekében, beállítva azt sikeresebbnek, a nem fogyasztói életviteleket pedig sikertelenebbnek, lúzerebbnek, népszerűtlenebbnek. A másik, amikor egy alapvetően intellektuális, széleskörű ismereteket és magas szintű tanulékonyságot igénylő szakma felhígul és bekerülnek a körbe olyan alapvetően szűklátókörű és rendkívül kényelmes egyedek, akik önző módon inkább másokat szopatnak, csakhogy őnekik kényelmesebb legyen.

    Ha a PulseAudio minden szempontból hatékonyabb és kényelmesebb lenne, mint az ALSA, akkor szerinted mondanánk rá bármi rosszat? Itt egyszerűen arról van szó, hogy a fejlesztők a saját maguk szopatása helyett (ami nem is lenne olyan nagy szopás, ha tehetségesebbek és lelkesebbek lennének az egységsugarú koffein-kód konverter babzsákfejlesztői szintnél) a felhasználókat szopatják. Ha meg ezt bárki kifogásolja, akkor a szokásos "ingyen van, kussolj", "ha nem tetszik, ne vedd meg" típusú arrogancia a válasz és ez ellen kelek ki, nem a világ fejlődése ellen - ami egy olyan világban kissé értelmezhetetlen is, amelyben milliárdok élnek az európai, fejlett™ komfort-, technológiai szint és létminimum alatt.

    A gazdaságosság pedig erre nem kifogás, mert ezzel kárt okozol a felhasználóidnak, egyúttal a gazdaságnak is. Egy kényelmeskedő, arrogáns Poetteringre jut több millió Linux-felhasználó, akik nem egy percet, hanem órákat fognak elvesztegetni azzal, hogy lekerekítsék a vasgolyónak hazudott, törékeny műanyagból készült kockát, és még akkor sem lesz vasgolyó. Mindeközben nem termel GDP-t, csak más szarát lapátolja el.

    Alapvetően egyetértek ezzel a hozzászólásoddal. Talán azzal a különbséggel, hogy nem látom ezt a kérdést ennyire sarkosan, s kicsit megengedőbb vagyok a fejlesztőkkel. Én is igyekszem jó munkát kiadni a kezemből, csak a főnököm túl gyakran érdeklődik, hogy mikor lesz kész, illetve a megbeszéléseken eleve határidőket vár a feladathoz. Reális határidőnél az a kérdés, minek arra annyi idő, ha bevállalod úgy, hogy tudod, úgysem készül el addigra, akkor meg miért nem vagy kész vele.

    A PA vacak, ezt mondom én is, de most a PW-ről beszélünk, ami még nincs kész, de már most jobb, mint a PA. A bluetooth kezelésben vannak egyelőre nagyon kellemetlen meglepetések.

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

    ( locsemege v | 2021. 03. 19., p – 00:51 )

    Kipróbáltam, fordítottam késő este egyet forrásból eddig: db85339f. Már csatlakozik akkor is, ha nem szedem ki a codec-ek közül az AAC-t, viszont kb. random szemét megy át hang helyett. Ellenben, ha kiszedem a konfigból az AAC codec-et, SBC-vel szól szépen, s a csatlakozással sincsenek már nehézségei. :)

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

    ( doc | 2021. 03. 19., p – 08:03 )

    Az utobbi hetekben tobbszor hisztiztem, hogy a Linux audiokezelese latszolag semmit nem fejlodott 20 ev alatt...

    Mindenfele idiota problemai vannak, van hogy egy youtube-video 5-6 reload utan indul csak el (audio hibara panaszkodva), van hogy akkor sem, katasztrofa.

    Nem tudom hogy egy meg ujabb reteg bevezetese, ami az amugy is recsego-ropogo felepitmeny tetejere kerul, hogyan fog ezen segiteni :(

    Érdekes... Nekem a böngészős dolgok, a Zoom, a sima médialejátszás normálisan megy - oké, nincs 3 hangkártya meg blútyúk meg kutyapöcse a gépben, de ezzel (alaplapi hangkártya, külső USB-s hangkártya, bluetooth füles) még a Windows-nak is meggyűlik néhanapján a baja - tapasztalatból tudom...

    >Mindenfele idiota problemai vannak, van hogy egy youtube-video 5-6 reload utan indul csak el (audio hibara panaszkodva), van hogy akkor sem, katasztrofa.

    Még csak hasonló problémáim se voltak soha. Valami nálad nagyon el lehet tekerve akkor, nem lehet hardveres hiba?

    Igazából meglepően nem volt semmi bajom Linux alatt hanggal évek óta. (Arch + Gnome + Pulse) Alaplapi nyekergőt használom változatos felállásokban, kimenet jacken, BT-n, HDMI-n, bemenet jacken, USB-n. Megy minden bármi extra lépés nélkül patentul a Gnome vezérlőpultjából, szemben pl. a Windows-zal, ahol a BT audióval vastagon szopni kellett, meg furcsa hangerő problémák vannak (ugyan azon a vason).

    " Valami nálad nagyon el lehet tekerve akkor, nem lehet hardveres hiba?"

    Lehet, de valoszinutlen, mert amugy minden mukodik (amikor mukodik), neha csinal ilyet (mikor pl. a Spotifyt megallitom, es neznek gyorsan egy Youtube videot). Maga a youtube lejatszo ablak kozepen irja, van hogy nehany reload utan jo, van hogy hiaba pufolom az F5/-ot, nem megy. Nem letfontossagu, de duhito, es arra emlekeztet mikor 2 evtizede meg ALSA pluginokat kellett configolni hogy egyszerre ket hang is tudjon jonni a hangkartyan...

    Windowshoz nem tudok hozzaszolni, Macen tokeletesen mukodik mindig minden, mindenhogy, van egy kis ikon fent, azon azonnal le tudom pausalni vagy resume-olni (csak szep magyarosan, ugye :D) barmelyik hangot kiado appot, szoval lehet hogy csak ahhoz kepest frusztral ez a Linuxos problema :D

    ujabb reteg bevezetese, ami az amugy is recsego-ropogo felepitmeny tetejere kerul

    Ezt rosszul gondolod. A pipewire nem a pulseaudio vagy a jack fölé kerül, hanem natívan a kernel alsa driver-ei fölé. Ugye a pipewire userspace-ben fut, nincsenek kernel moduljai, tehát a hardware-t az alsa driver-eken keresztül tudja elérni, de itt van mozgástér. Valamelyik commitban láttam arra utalást, hogy néha tiltják a megszakítást, s másképp - gondolom, a buffer pointere alapján - kezelik a hangkártyát, szóval elég alacsony szintig le lehet menni.

    Az más kérdés, hogy a pipewire képes jack vagy pulseaudio kliens is lenni, de efféle butaságot valamiféle nyakatekert teszten túl miért tennénk?

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

    Ezt nem értem. A pipewire-nek van pulse interface-e. A pulseaudio-ból csak a kliens oldali library kell, mert az jó a pulse-ban, nem implementálták újra. A szerver lett újra csinálva, az nagyon másképp működik, mint a pulseaudio szerver.

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

    De, ez így van. Azért mindenképpen pontosítom ezt, mert két síkon tudunk elbeszélni egymás mellett.

    1) Natív pipewire esetén a pipewire a kernel által biztosított alsa driver-ekhez csatlakozik. A node-okat, szükség esetén - és csak akkor - a resampling-et, a jelutak tulajdonságainak tárolását, mint például kliensenként a hangerő, a pipewire biztosítja. A szerver oldal teljesen natív pulse, jack, alsa emuláció a pipewire részéről. Ugyanakkor kell a pulseaudio-libs, mert azok a függvények, amelyeket a kliens oldali programok hívnak, nem lettek újraírva. Ezek érzésem szerint semmi egyebet nem csinálnak, mint átadnak struktúrákat a szervernek, amelyben tulajdonságok vannak, meg pointerek, amelyek adat bufferekre mutatnak. A pulseaudio szervert viszont nem kell telepíteni.

    2) Képes ő maga is akár jack, akár pulse kliensként működni. Ekkor becsatlakozik például egy pulseaudio szerverre, le lehet tiltani az ő pulse interface-ét, vagy lehet akár engedélyezni egy másik socketen. Így használható pulseaudiohoz jack szervernek. Vagy, ha jack kliens, akkor ahhoz pulse interface-t tud biztosítani. Értelme nem sok van, s ez az az eset, amikor egymásra halmozzuk a rétegeket, zabáljuk a futásidőt, s velünk marad a pulseaudio minden hátrányos tulajdonsága. Szóval én nem teszem ezt. Nálam natívan fut a pipewire, nem használok pulseaudio-t.

    pgrep -l 'pulse|pipe|jack'

2245 pipewire-pulse
2281 pipewire
2307 pipewire-media-

    Az ott a végén pipewire-media-session akar lenni, de a kernel csak röviden tárolja a nevet.

    Egyébként teszteltem, működik pipewire-rel a linuxos teams kliens is.

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

    Pulseaudio-ban van valami koncepcionális hiba. Fiatal korában volt olyan, hogy 100 % CPU terheléssel megdöglött, s ennek az állapotnak a létrejötte annál valószínűbb volt, minél nagyobb volt a CPU terhelése általa. Ez hellyel-közzel javítva lett, de szerintem nem generikusan, diszkutálva, mi is történik pontosan, hanem kis optimalizálgatásokkal. Most is képes arra, hogy 4 magvas, 3.2 GHz-es CPU egy magját 25 %-ig terheli, s közben recseg-ropog a hang annyira, hogy érthetetlen a beszédátvitel.

    A pipewire ezt az akadályt minimális CPU terheléssel megugorja, miközben nem recseg a hang sem.

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

    Tuti, hogy csak egy magot terhel 25%-ra és nem mind a 4 magot, azaz egy magot továbbra is 100%-on pörget? Ez a mai napig előfordul, amióta a Slackware-ben is van, azóta a Slackware userek is megtapasztalták a gyönyöreit. :P

    Oldschool Computer - http://oscomp.hu

    Igen. Értem a kérdésed annál is inkább, mert a 25 % épp 1/4, de ezúttal határozottan emlékszem, hogy egy mag 25 %-a volt. Valami olyasmi lehet a probléma, hogy a kernel ütemezője nem ad merev időzítést, hiszen egy rakás más processznek is futnia kell, viszont itt például hang lejátszásakor a kliens feltölti a buffert, a szerver átveszi, de ha még nem vette át a szerver, a kliensnek várnia kell, hogy végre átadhassa az adatot, ha meg a szerver másodjára venné át, míg a kliens egyszer sem adta, akkor underrun. Megfigyeltem, hogy ha szétcsúszott az ütemezés, a kliens és a pulse szerver futásidő igénye is megnőtt, mert vélhetően egymásra vártak. Gondolom, ez inkább kétirányú kommunikációnál van így, mint amilyen egy VoIP kliens, ahol van sink és source is.

    Mindez érzés, sose néztem meg a pulseaudio kódját. Ezektől a kínoktól a pipewire nem szenved.

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

    Késő van és lehet, hogy csak nem esik le a tantusz, de ha a kliens és a szerver tudhatja, hogy várnia kell, akkor itt van valamiféle handshake, nem? Viszont akkor, ha handshake van, akkor hogy próbálhatja meg a szerver kétszer átvenni, ha egyszer tudja, hogy már átvette? Mondjuk bele én se néztem a PA kódjába, a működése is elég meggyőző volt, hogy kerüljem el jó messzire, így nem tudom milyen módon cserél adatot a kliense és a szervere.

    Oldschool Computer - http://oscomp.hu

    Azt értem, hogy meg lehet ezt jól is csinálni, de szemlátomást rosszul van implementálva. Egyébként rendesen be lehet menni az erdőbe, magam is implementáltam különféle állapotautomatákat, és a baj akkor kezdődik, ha valamelyik oldalon hiba keletkezik, szétcsúsznak egymáshoz képest, mást gondol a kommunikáló felek közül az egyik arról, hogy hol tart a másik, esetleg ekkor hibát kezelünk, de a másik oldal is, így aztán elkezdenek az állapotaik egymás elől bujkálni, akár végtelen ciklusban kergetve egymást. Szóval csak azt akarom mondani, nem triviális önálló rendszerek közötti kommunikációt hibatűrőre megcsinálni.

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

    Nem triviális, de nem is lehetetlen, én is írtam már jópár kommunikációs kódot, sorosat, párhuzamosat, TCP/IP-set, GPRS-eset, "tessék itt van két szál drót"-osat; azért nem egy ördöglakat. A PA-nak ezek szerint ez sem sikerült, ráadásul itt az esetek többségében itt a sender és a receiver is a localhoston belül van, az átviteli közeg a memória, ahol azért messze nincs annyi hibalehetőség, mint egy valamilyen hálózati csatornán keresztül.

    Oldschool Computer - http://oscomp.hu

    Nem egy ördöglakat, de amit el lehet rontani, azt el is rontják. Itt az ütemező tud kellemetlen lenni, az, hogy lényegében aszinkron futhat a szerver és a kliens, akár eltérő CPU magon egyszerre. Nyilván lehet és kell is állapotokat jelölni, szemaforozni.

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

    Hát ez az, hogy ha itt a kliens és a szerver várnak egymásra, akkor itt kell, hogy legyen valami szemaforkezelés, handshake és a többi; akkor meg hogy a bánatba tud előállni olyan, hogy úgy próbál olvasni a szerver, hogy a buffer ready flag szerint nem olvashat, vagy hogy a bánatba mutathatja a flag azt, hogy olvashat, ha a kliens nem töltötte fel a buffert? A bufferen végrehajtandó műveletek végrehajtása után a szerver a jelzőflag-et azonnal át kell, hogy kapcsolja, a kliens meg addig nem kapcsolhatja vissza, amíg a buffert nem töltötte fel újból és mindenki csak akkor nyúlhat a bufferhez, ha a szemafor engedi, tehát bármelyik oldalon is következik be crash, a double read nem lehetséges, feltéve ha a szemafort mindenki átváltja a munkája befejeztével és utána vár addig, amíg megint át nem áll. Azért ez tényleg nem egy ördöglakat, főleg ugyanazon a gépen belül.

    Oldschool Computer - http://oscomp.hu

    Nem ismerem az implementációt, de arra emlékszem, hogy Lennart szerint van benne valami nem nyilvánvalónak nevezett algoritmus. Szerintem sikerült elbonyolítani valamit. Az meg a másik, hogy a pipewire changelogjában volt egyszer arra utalás, hogy valamilyen adatstruktúrát feltöltöttek a megfelelő adatokkal, ami a pulseaudioban a mai napig hiányos.

    Ja, megvan.

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

    Nem az van, amit locsemege feljebb is írt, hogy akkora aszinkronitás van (nem RTOS, eltérő magokon futhat a szerver meg a kliens, dinamikusan változik az egyéb processzek száma), hogy hiába állítgatják a szemafort, elképzelhető, hogy a kliens már feltöltötte a buffert, beállította a flag-et, de a szerver még nem kapott CPU-t, hogy elkezdje feldolgozni? Okés, hogy milisec-ekről beszélünk, de lehet, hogy az audio feldolgozás erre már pont érzékeny (nem értek hozzá), mert annak teljesen seamless-nek kellene lennie a megfelelő élmény érdekében, más program esetében meg nem tűnik fel a dolog.

    > Nem az van, amit locsemege feljebb is írt, hogy akkora aszinkronitás van (nem RTOS, eltérő magokon futhat a szerver meg a kliens, dinamikusan változik az egyéb processzek száma), hogy hiába állítgatják a szemafort, elképzelhető, hogy a kliens már feltöltötte a buffert, beállította a flag-et, de a szerver még nem kapott CPU-t, hogy elkezdje feldolgozni?

    Ha a szerver egyáltalán nem kapott még időt, akkor hogyan olvashatta ki kétszer, hogy buffer underrun legyen belőle? Akkor maximum egyszer sem olvassa ki és lagzani kezd a hang.

    > Okés, hogy milisec-ekről beszélünk, de lehet, hogy az audio feldolgozás erre már pont érzékeny (nem értek hozzá), mert annak teljesen seamless-nek kellene lennie a megfelelő élmény érdekében, más program esetében meg nem tűnik fel a dolog.

    De itt most nem az volt a kérdés, hogy az aszinkronitás miatt lehet-e jitter, hanem, hogy hogy a búbánatban tud a szerver buffer underrunt produkálni, ha a szemaforkezelés helyesen van implementálva?

    Oldschool Computer - http://oscomp.hu

    Ezt debugoltam, csak nem fejtettem ki. A VoIP kliens kapta meg újra a vezérlést, meghívta az alsa valamelyik függvényét, de ez a pulseaudio alsa emulációs rétegében végződött. Ezzel a hívással audio buffert kért a kliens, de nem kapott. Már önmagában ez is szörnyű, de ami rosszab, pulse szerver oldalról ilyenkor broken pipe lesz, mintha a kliens nem is érdeklődött volna adatért, s a pulse lezárja az egész kapcsolatot, a kliens eltűnik a nyilvántartásából. A pavucontrol felületéről is. Utána a kliens újra próbálja építeni a kapcsolatot, ez sikerül neki, de a szünet több 10 ms volt közben. Néhány 10 esetleg 100 ms-on át megint van hang. A pavucontrol felületén a kliens ott vibrál, hol megjelenik, hol eltűnik, a hang recseg-ropog, sorozatosak a broken pipe-ok, a closed, majd reconnect állapotok.

    Szerk.: már eleve az helytelen, hogy buffer alulcsordulásnál lezárják a kapcsolatot, az egy rakás idő.

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

    Oké, én most vesztettem el végleg a fonalat. A PA működésképtelen az ALSA vagy az OSS nélkül. Te Linuxot használsz, ott ALSA a hangrendszer. Ha egy program közvetlenül az ALSA-t akarta hívni (kernelhívás AFAIK), akkor hogy a búbánatban érhetett az véget a PA egy emulációs rétegében? Egyáltalán mi a túrónak emulálja a PA az ALSA-t, amikor ott van alatta az igazi? (Mármint Linuxon.) Ezt így hogy? Itt többszintű masszív és komplex elkúrást sejtek a PA részéről, ha egy ilyen felállás előfordulhatott...mondjuk meglepni nem lep meg túlságosan. :P

    A másik felét sem értem túlságosan. ALSA hívás, bufferkérés, a PA válaszol rá, de az emulációs rétege nem adott buffert. A kapcsolat eltrashelődik, broken pipe. Idáig értem, ez tényleg szörnyű. Viszont. Egy törött csőből mi a túrónak akart olvasni a PA, pláne kétszer?

    Vagy én nem értem mit mondasz, vagy te nem érted mit kérdeztem, vagy mindkettő.

    Oldschool Computer - http://oscomp.hu

    Tudtommal egy linuxos rendszeren a pulseaudio rátelepszik az alsa kernel interface-ére, és az alkalmazások használhatják a natív pulseaudio API-t, vagy a pulseaudio alsa emulációs API-ját. Tehát, ha fut a pulseaudio, az alsa kliensek is azon keresztül csatlakoznak, nem pedig közvetlenül. Ezzel egyébként semmi baj, az alsa-t tekinthetjül egy low level audio interface-nek, ami nem ergonomikus az alkalmazások számára.

    A többit nem írom le újra. Az a lényeg, hogy kiszaladt a bufferből az adat, mert az ütemező későn hívta meg a klienst. Hülye PA erre lezárta az egész kapcsolatot, jöhetett elölről a felépítése.

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

    A PA szerver az egy opcionális daemon, a kernelen kívül. Ha én a kernelben lévő függvényeket hívogatom, azt hogy téríti el a PA? Arról nem is beszélve, hogy a driverek esetében röhej lenne, ha az ALSA driverek nélkül nem működő PA-t hívogatnák az ALSA driverek. Szóval itt valami nem stimmel. Próbáltam keresni, de semmi olyasmit nem találtam, hogy a PA-nak ALSA emulációs rétege lenne (nem is lenne értelme). Nem kevered te az ALSA PA emulációs rétegével?

    Csak én még mindig nem értem, hogy rendes szemaforkezeléssel hogy fordulhat ilyesmi elő.

    Oldschool Computer - http://oscomp.hu

    Szerintem az ALSA-t a programok egy liben keresztül használják (többnyire), nem a kernelt hívják direktben. Ezen libet ki lehet cserélni egy olyanra, ami a hívásokat Pulse Audio hívásokra fordítja, és akkor az a Puse feletti ALSA emuláció. Úgy tudom, hogy így van megcsinálva.

    Szerk.: ja, nem, Wikipédián ezt írják: "In a typical installation scenario under Linux, the user configures ALSA to use a virtual device provided by PulseAudio." Eszerint tehát létrejön egy virtuális ALSA device, ami a Pulse-ban végződik, és ez van defaultnak beállítva. Utána kellene autentikusabb helyeken olvasni, hogy hogy működik pontosan. Az alsamixer nálam például csak a HW kimenethez mutat mixert, virtuális Pulse kártyát nem mutat. (De lehet, hogy azt direkt leszűrni hogy ne zavarjon össze?)

    Hogy ez mire jó? Arra, hogy így az ALSA API-t használó programok is részesülnek a Pulse minden előnyéből. (Aminek egy része szerintem valóban feature.) Például, hogy:

     * Senki nem foglalja el a hangkártyát kizárólagosan

     * alkalmazásonként tudod állítani a hangerőt egyetlen közös helyről

     * Rá tudod kötni dinamikusan az alkalmazást bármilyen kimenetre leállás nélkül

     * Ugyanet bemenettel is, a bemenetre bekapcsolhatsz filtereket leállás nélkül (pl visszhang-elnyomás)

     

    Az egy más kérdés, hogy mindezek hogyan működnek, a mondanivalóm az, hogy elvileg erre jó ez a trükk.

    Szóval nem emulációról beszélünk, hanem az ALSA eszközök között megjelenik egy olyan elem, amit a PA rakott oda. Thx. Ez mondjuk még mindig nem magyarázza a buffer underrunt, hogy mégis mit lehetett annyira elkefélni egy flag beállításában, hogy double read legyen belőle... (A lib-replacement egyébként is kizárt lett volna, abból aztán végképp akkora botrány lett volna, ha a PA lecseréli az ALSA libeket, arról nem is beszélve, hogy csomagütközést is eredményezett volna, abból pedig a PA jött volna ki rosszul, mert neki függősége az ALSA, tehát ha ütközik vele, akkor őt nem lehet felrakni.)

    Oldschool Computer - http://oscomp.hu

    A buffer underrun akkor is bekövetkezhet, ha megpróbálod jól kezelni. Azzal nem tudsz mit kezdeni, ha egy csomó ideig nem kapja meg a vezérlést a kliens, a szerver meg közben éhen hal adat nélkül. :) A baj azzal van, ami ezt követően jön: lezárja a kapcsolatot, pedig nem kellene. Persze mással is baj van, mert ugyanaz az ütemező, ugyanaz a kernel fut a pipewire esetében is, aztán az meg képes szépen szólni.

    Tegyük hozzá - s ebben hajbazernek igaza van -, Lennart Poettering egy szélsőségesen idealista, elméleti szakember. Amikor egyes alsa driverekben nem volt implementálva valami, amit addig szinte senki sem használt, de a PA-nak kellett - talán a hardware pointer visszaolvasása az adott pillanatban -, akkor ahelyett, hogy workaroundot írt volna a PA-ba, kicsapta a hisztit, hogy ez alsa bug, ennek elfedése nem az ő dolga, az OSI-modellben nem ahhoz a réteghez tartozik, amelyet a PA megvalósít, javítsa meg az alsa fejlesztői csapata.

    Az eredmény az lett, hogy a hang sokáig használhatatlan volt Linuxon, s közben ezt Lennart simán meg tudta volna oldani. Ilyenkor érzem azt, hogy legszívesebben felrúgtam volna az égig, illetve nagyon semmi keresnivalója a Red Hat egyik vezető fejlesztői pozíciójában ezzel a szemlélettel.

    Wim Taymans nem ilyen beképzelt, sokkal gyakorlatiasabb. Ő a feladatot látja. A Commodore 64 időktől kezdve foglalkozik audio driver-ekkel, ezzel a témakörrel, s működő dolgot akar csinálni, nem pedig olyat, ami ugyan nem működik, de meg tudja magyarázni, hogy valaki más miatt nem működik. Láttam is a PW commitok között workaround-ot, ami Lennartnak egészen biztos derogált volna.

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

    > A buffer underrun akkor is bekövetkezhet, ha megpróbálod jól kezelni. Azzal nem tudsz mit kezdeni, ha egy csomó ideig nem kapja meg a vezérlést a kliens, a szerver meg közben éhen hal adat nélkül. :)

    Nem, ettől nem következhet be buffer underrun, csak akkor, ha a szerver a szemafor tiltó állapota ellenére is olvasni próbál. Ha van egy egyértelmű jelződ, ami azt mondja, hogy nincs adat, azt nem lehet letojni. Ha a pulse ezt letojta, akkor Poettering még annál is elmeháborodottabb, mint amit eddig hittünk róla...

    > A baj azzal van, ami ezt követően jön: lezárja a kapcsolatot, pedig nem kellene. Persze mással is baj van, mert ugyanaz az ütemező, ugyanaz a kernel fut a pipewire esetében is, aztán az meg képes szépen szólni.

    De a lezárt kapcsolat önmagában nem eredményezhet buffer underrunt. Ez az amit nem értek, nem azt, hogy a PA feleslegesen eltöri a csövet, csak mert szerinte túl régen nem jött már adat...

    > Tegyük hozzá - s ebben hajbazernek igaza van -, Lennart Poettering egy szélsőségesen idealista, elméleti szakember.

    Ebben egyetértünk. (Bár lehet, hogy direkt csinálja, mert ezért fizetik. Vagy mert pusztítani akar.)

    > Amikor egyes alsa driverekben nem volt implementálva valami, amit addig szinte senki sem használt, de a PA-nak kellett - talán a hardware pointer visszaolvasása az adott pillanatban -, akkor ahelyett, hogy workaroundot írt volna a PA-ba, kicsapta a hisztit, hogy ez alsa bug, ennek elfedése nem az ő dolga, az OSI-modellben nem ahhoz a réteghez tartozik, amelyet a PA megvalósít, javítsa meg az alsa fejlesztői csapata.

    Távol álljon tőlem Pötyi bátyó bárminemű védelme, de egy csak a driverspace-ben elérhető pointer kiolvasását miféle mágikus workarounddal oldotta volna meg a userspace-ben? Nem kevered valamivel? Vagy csak a hardware pointer alatt értünk mást? (Nálam az vagy a hardware címtartományára mutató pointer, vagy egy indexregiszter a hardware-ben.)

    > Az eredmény az lett, hogy a hang sokáig használhatatlan volt Linuxon, s közben ezt Lennart simán meg tudta volna oldani. Ilyenkor érzem azt, hogy legszívesebben felrúgtam volna az égig, illetve nagyon semmi keresnivalója a Red Hat egyik vezető fejlesztői pozíciójában ezzel a szemlélettel.

    Hát ezt megértem, de miért nem törölted le a francba a PA-t és akkor megint használható lett volna a hang? :)

    > Wim Taymans nem ilyen beképzelt, sokkal gyakorlatiasabb. Ő a feladatot látja. A Commodore 64 időktől kezdve foglalkozik audio driver-ekkel, ezzel a témakörrel, s működő dolgot akar csinálni, nem pedig olyat, ami ugyan nem működik, de meg tudja magyarázni, hogy valaki más miatt nem működik. Láttam is a PW commitok között workaround-ot, ami Lennartnak egészen biztos derogált volna.

    Elhiszem, Wimet én nem is minősítettem, sem a munkáját. Pötyi bátyóval van tele a joystickom, meg a munkáltatóival.
    BTW, C64, Wim 10 éve még aktív volt. :)

    Oldschool Computer - http://oscomp.hu

     

    ettől nem következhet be buffer underrun

    A klienst eteti a szervert. A szervernek merev ütemezéssel kell adat, mert ha az elfogy, akkor vagy ismételgetjük az utolsó buffert, ami elég sz.rul hangzik, vagy elhallgatunk. Tehát, ha van 200 ms buffered, s a vezérlés 350 ms múlva kerül a kliensre, akkor a 150 ms csendet nincs az a szemafor, ami zenével vagy beszéddel töltené fel. :)

    Nem a lezárt kapcsolat okoz alulcsordulást, hanem az alulcsordulás miatt zárja le a pulse a kapcsolatot, csak az újbóli felépítés sokkal több idővel, költséggel jár.

    Mivel mindenféle időt nyilvántart Lennart, tudja, mennyi adat van a bufferben, tudja vagy tudhatja, mikor adta azt át, tudja a mintavételi sebességet, egész jól ki tudja számolni, hol tart vélhetően a hangkártya a lejátszásban. Eleve az az interrupt nélküli buffer kezelés is az idők számolgatásán alapul.

    Igazából zene lejátszásnál nem volt gond, bár kicsit sok CPU-t evett. Baj a VoIP-nál volt, de ha jól sejtem, a Firefoxnak meg alsa interface-e nincs már, szóval a PA-free élet nem volt opció. Most, hogy van PW, már az.

    Elhiszem, Wimet én nem is minősítettem, sem a munkáját. Pötyi bátyóval van tele a joystickom, meg a munkáltatóival.

    Lennart nekem sem a kedvencem, a Red Hat-et nem ismerem, mint szervezetet, de érzelmileg elfogult vagyok Fedora használóként.

    Az igen, C64-re kiadni játékot 2011-ben, szép! Kell hozzá eltökéltség. Ahogy nézem, írt C64-re jócskán kódot.

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

    De még mindig elbeszélünk egymás mellett: a kérdés az, hogy mi a túróért olvas a szerver bele egy bufferbe, ha látja, hogy nincs benne adat? Ez a kérdés. Az, hogy elfogyott az adat és nem jött újabb már N idő óta, az maximum timeout, de miért próbál beleolvasni a szerver a bufferbe, ha egyszer tudja, hogy üres, mert látja a szemaforból, hogy nem szabad? Nem az a kérdés, hogy ha nem jön adat időben, akkor miért lesz csend, hanem, hogy miért próbál meg ennek ellenére a szerver beleolvasni, ha nem jött? Mire számít, mi jön vissza egy üres bufferből? Én ezt nem értem.

    > Lennart nekem sem a kedvencem, a Red Hat-et nem ismerem, mint szervezetet, de érzelmileg elfogult vagyok Fedora használóként.

    A RedHat és a Freedesktop iszonyatos mértékű károkat okozott a UNIX világnak a shitware-eikkel, amiket a világra szabadítottak.

    > Az igen, C64-re kiadni játékot 2011-ben, szép! Kell hozzá eltökéltség. Ahogy nézem, írt C64-re jócskán kódot.

    A C64 scene a mai napig virágzik, még ma is adnak ki játékokat rá.

    Oldschool Computer - http://oscomp.hu

    Abban nem vagyok biztos, hogy bele is olvas a bufferbe. Attól még buffer alulcsordulás van, ha ott állsz letolt gatyával, mert olvasnád a buffert, de az olvasó pointer utolérte az írót, s nem tudsz mit kiolvasni. Ne a szavakon lovagoljunk, hogy akkor lenne buffer underrun, ha a read pointer át is lépné a write pointert, ebből aszempontból csak annyi a lényeg, hogy elfogyott, nincs többé, nem tudunk hangot adni, s akkor reccs van.

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

    Akkor itt beszéltünk el egymás mellett; nekem a buffer underrun a tényleges buffer underrun és az jött le, hogy ez a hulladék PA bele is olvas a feltöltetlen bufferbe, te pedig a buffer underrun lenne, ha beleolvasna állapotot is buffer underrun-ként kezelted, nálam az meg inkább buffer timeout, vagy empty buffer, vagy mittudomén.

    Oldschool Computer - http://oscomp.hu

    ( mogorva v | 2021. 03. 19., p – 09:25 )

    Szerkesztve: 2021. 03. 19., p – 12:12

    -- del --

    ( locsemege v | 2021. 04. 07., sze – 11:35 )

    0.3.25

    Nagyon sokat fejlődött az előző kiadás óta, ideértve a bluetooth képességeket is. Tetszik. :)

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

    Majd ha eljön a linuxdesktopéve, akkor minden szép és jó lesz... Egyébként meg hajrá, nyugodtan beszállhatsz ötletekkel, javaslatokkal, patch-ekkel, vagy egy komplett saját audio alrendszer összerakásával - ha jók az alapok, jó az elképzelés, akkor a te tudásoddal, kapcsolatrendszereddel, szakami elismertségeddel simán össze tudsz hozni egy ütőképest fejlesztői csapatot, akikkel pikk-pakk megoldjátok mindazt, amit a RH általad idiótának tartott emberei nem voltak képesek.

    Én már várom a hajbiaudio-t Linuxra :-P

    Nem ugyanaz a kettő, de erről aligha foglak meggyőzni. Nem te panaszkodtál, hogy a Firefoxnak nincs alsa interface-e? Azt is megnézem, amikor egy jack kliens csatlakozik alsa szerverre, vagy egy pulse kliens, vagy ezek mindegyike egyszerre, külön hangerő állítással, bluetooth-on hallgatod a zenét, lokális hangszórón a rövid youtube videót, és a mintavételi frenkvencia is más. De erről beszéltünk, nem akarod érteni, ott tartasz, hogy van egy darab hangforrásod, egy darab hardware-ed, s az előbbiből az utóbbiba kell DMA-zni a hangmintákat. A pipewire nem ezt csinálja.

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

    Nem ugyanaz a kettő, de erről aligha foglak meggyőzni.

    Nem kell meggyőzni, mert szerintem sem.

    Nem te panaszkodtál, hogy a Firefoxnak nincs alsa interface-e?

    Van neki, csak babzsákfejlesztőék arrogáns módon kivették a hivatalos build-ből. Ez innentől nem egy valódi igény arra, hogy ne ALSÁ-t kelljen használni, hanem a már ismertetett felforgatás és mesterséges igénygenerálás.

    Sétálsz az irodaházban, ahol dolgozol, arra jövök, eladni neked az új fejlesztésű, kényelmes, WiFi-s, bluetooth-os, cloud-integrált okoskerekesszékem. Neked nem kell, mert tudsz két lábon járni, pedig hidd el, a kifejlesztése is azért ment jobban™, sikeresebben™, gördülékenyebben™, mert a mérnökök is az előző termékcsaládot használták. Neked továbbra sem kell. Ekkor én fogom a kapcsolataimat és elérem, hogy az irodaházban csökkentsék a belmagasságot másfél méterre. Onnantól közlekedés vagy négykézláb, vagy a szuperkényelmes okoskerekesszékemmel. Hogy tudtam, hogy szükségetek™ van rá. Használjátok™ egészséggel™!

    Volt idő, amikor kedveltem a hozzászólásaidat, mert a kritikákban sok igazság volt. Az utóbbi időben viszont az az érzésem, hogy indokolatlanul vagdalkozol. Megnézted a kódot? Értesz hozzá? Küldtél be patch-et? Amúgy elárulom a hatalmas titkot: bluetooth-ra is rengeteg féle codec van, nem is azonos ezek célja. Telefonbeszélgetéshez a beszédátvitelhez alkalmas, kis sávszélességűt használják, míg zenehallgatáshoz nagy sávszélességű, hifi átvitelre alkalmasat. Hogy értsd, hiába élünk a XXI. században, telefonos átvitelhez a szolgáltatók a dróton ma is 8 kHz mintavétellel biztosítják a 300 Hz - 3.4 kHz frekvenciasáv átvitelét, ráadásul veszteséges tömörítéssel, 8 bit/sample. A CCITT G711 A law és µ law kódolásokról beszélek. Nem, nem azért, hogy az "sz" és "f" hangok között ne tudj különbséget tenni, hanem azért, hogy egy 2.048 Mb/s-os trunk-ön el tudjanak vinni 30 csatornányi beszédet kiegészítő infókkal együtt.

    Persze erre is lehet mondani, hogy milyen vacak már, nem hifi, semmi magas hang benne. Ne zavarjon, hogy ez tervezett tulajdonság, és nem hiba.

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

    Amúgy elárulom a hatalmas titkot: bluetooth-ra is rengeteg féle codec van, nem is azonos ezek célja.

    Lesz rá lehetőség, hogy mindenféle hákolás és low level scriptelgetés nélkül, UI-ról beállítsam, hogy az adott bluetooth eszközömre milyen kodekkel legyen leküldve a hang? Esetleg, hogy a hangeszköz által támogatottakat lekérdezzem? Például, ha én MP3-ból szeretnék zenét hallgatni, ne kódolja újra OPUS-szal, AAC-vel, hanem tolja rá az MP3-at stream szerűen, ha már képes dekódolni?

    Hogy értsd, hiába élünk a XXI. században, telefonos átvitelhez a szolgáltatók a dróton ma is 8 kHz mintavétellel biztosítják a 300 Hz - 3.4 kHz frekvenciasáv átvitelét, ráadásul veszteséges tömörítéssel, 8 bit/sample.

    Észrevettem. Ezzel semmi baj nem is lenne, ha nem hazudnák XXI. századinak, meg HD audiónak.

    Nem, nem azért, hogy az "sz" és "f" hangok között ne tudj különbséget tenni, hanem azért, hogy egy 2.048 Mb/s-os trunk-ön el tudjanak vinni 30 csatornányi beszédet kiegészítő infókkal együtt.

    Mindeközben gigabiten száguldanak a lájkok, a tiktok videók és a feleslegesebbnél feleslegesebb sallangok.

    Ne zavarjon, hogy ez tervezett tulajdonság, és nem hiba.

    A felhasználói szabadság lábbal tiprása zavar. Amikor a szoftver nem teszi lehetővé, hogy kihasználjam a hardver adta lehetőségeket. Például, ha nem tetszik, hogy a Skype beszélgetést még egyszer szarrátömöríti valami, mielőtt eljut a bluetooth-eszközre, ahelyett, hogy direktben úgy tolná ki rá, ahogy a netről jön.

    Erre csak azt tudom mondani, hogy nincs rossz hangja a Teams-nek, kollégámmal épp ma beszéltem Linuxról Teams-en és 0.3.25-ös pipewire-en keresztül. :) Mert a Teams amúgy a Skype-ból lett. A másik dolog, hogy a sávszélesség nem végtelen. Az egy történet, hogy a szolgáltató ad neket néhány száz Mb/s-os csövet, de ha ezt összeadod felhasználónként, az sokkal több, mint amit a gerinc elbír. Ezt tekintsd úgy, hogy nincs korlátozva a sávszélesség közted és a szolgáltató között, de nem tudod kihasználni, ha az általad elérni kívánt gépig az útvonalon szúk a keresztmetszet. Lehet szűk a 10 Gb/s is, ha ott sokan sokat forgalmaznak. Majd valamikor összefésülődik a te UDP csomagod is a többiekével, illetve a többiekéi közé.

    Amúgy meg nem muszáj Skype-ot használni, vannak más megoldások. Lehet, hogy nem népszerűek, lehet, hogy kell portot nyitni hozzá a router-en, ha nem akarsz STUN szerver megoldást, de át tudod tolni a hangot saját magad által konfigurálható tömörítési rátával kellemes minőségben. Az meg egy dolog, hogy nincs grafikus user interface-e. Minek is kell az hangátvitelhez? Mivel ad többet egy terminálnál? Ja, hogy semmivel? Akkor van ilyen alkalmazás.

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

    Tudod mit? maradj a DOS mellett - azzal biztosan nincs bajod... Vagy a CP/M, meg a 8"-os hajlékonylemez - az a tuti. (Tudod attól, hogy nem bírod felfogni, hogy mi a jó az újabbnál újabb dolgokban, még lehet, hogy nem az egész világ megy szemben az autópályán - hanem te...)

    >Lesz rá lehetőség, hogy mindenféle hákolás és low level scriptelgetés nélkül, UI-ról beállítsam, hogy az adott bluetooth eszközömre milyen kodekkel legyen leküldve a hang? Esetleg, hogy a hangeszköz által támogatottakat lekérdezzem?

    Az ALSA tud ilyet? :^)

    >Például, ha én MP3-ból szeretnék zenét hallgatni, ne kódolja újra OPUS-szal, AAC-vel, hanem tolja rá az MP3-at stream szerűen, ha már képes dekódolni?

    Ezt csinálja egyáltalán valaki az iparban? Ellenőrizetlen forrásból érkező tömörített streameket kihajtanak érintetlenül ezekre a gagyi vackokra?

    Hajbinak mikor volt értelmes szakmai hozzászólása? Hogydesose. Ez a srác már többször bebizonyította, hogy fogja sincs de tényleg semmiről. Elképzelései vannak, amik meg köszönő viszonyban sincsenek a valósággal. Aztán ha egy hozzáértő elkezdi megvilágítani neki a dolgokat, jön a durci meg a terelés. Életében nem hallgatott meg egy érvet nemhogy felfogni megpróbálta volna.

    De mi ilyen szerencsétlen idiótának szeretjük. :)

    Attól még, hogy a HUP ügyeletes mitugrászának a valóság egyenlő az aktuális technológiai trendekkel és a fősodratú gondolkodásmóddal, nem leszek kevésbé hozzáértő.

    A durci meg most pont nem amiatt van, mert valaki megvilágította a dolgokat. Alapvetően örülök neki, hogy locsemege eloszlatja a kételyeket a pipewire-ral kapcsolatban. Legalább is, megpróbálja.

    Aminek kevésbé, hogy amint kilép a nullapontverziós stádiumból ez a projekt, úgy megy át a fejlesztés értelmes léptékűből arrogáns divatléptékűvé és lesz mindenki torkán lenyomva, meg elkészítve hozzá a lebutítottnál is lebutítottabb tapicskoló felhasználói felület és az erőforráspazarló bloat körbehákolások.

    "nem leszek kevésbé hozzáértő" - valóban, mert a hozzáértés esetében a nulla a minimum, annál kevésbé nem lehet... Még neked sem. Bár néha nagyon igyekszel, hogy bebizonyítsd ennek az ellenkezőjét...

    "elkészítve hozzá a lebutítottnál is lebutítottabb tapicskoló felhasználói felület"

    kontra:

    "Lesz rá lehetőség, hogy mindenféle hákolás és low level scriptelgetés nélkül, UI-ról beállítsam, hogy az adott bluetooth eszközömre milyen kodekkel legyen leküldve a hang? Esetleg, hogy a hangeszköz által támogatottakat lekérdezzem?"
     

    Hmmm... Egyébként meg szabad a pálya, donj össze valamely általad kedvelt eszközzel egy olyan felhasználói felületet, amiben minden, számodra fontos dolog ott van. De legyen ám áttekinthető, kényelmes, könnyen kezelhető, portábilis a külöböző rendszerek között, és a többi, és a többi... Mivel te nagyon nagy tudással rendelkezel mindenben _is_, így ez is menni fog. Úgyhogy jöhet a hajbiaudio után/mellett a habiUI for PipeWire&Pulse&ALSA megalkotása is... Mert ugye te okosabbnak tartod magad midnenkinél, úgyhogy mutasd meg, hogy tényleg az vagy...

    Ja, és persze ne legyen erőforráspazarló bloat meg körbehákolása mindennek _is_ :-P

    Még neked sem. Bár néha nagyon igyekszel, hogy bebizonyítsd ennek az ellenkezőjét...

    https://a.te.ervelesi.hibad.hu/szemelyeskedes

    Még ha így is lenne, akkor sem változtatna azon, hogy a Red Hat arrogáns módon forgatja fel a Linux-világot.

    kontra:

    Bocs, az egy kérdés volt, amire locsemege udvariasan elhallgatta a választ.

    Úgyhogy jöhet a hajbiaudio után/mellett a habiUI for PipeWire&Pulse&ALSA megalkotása is...

    Nem jön a hajbiaudio, mert hajbi nagyon jól elvan Windows XP-n, amit hosszú távú, stabil használatra terveztek, nem arra, hogy 8 évente újraírja valaki a teljes audio backendet. Ha szükségem van az átlagfelhasználóknál nulla valószínűséggel előforduló, többeszközös bűvészkedésre, arra ott a Virtual Audio Cable, amivel nagyszerűen össze lehet kattintgatni minden hasonló konfigurációt. Ja és már vagy 15 éve.

    Azért hallgattam el a választ, mert lusta voltam frissíteni a kis gépemet, pedig van már 5.11.12-es kernel is Fedorára, meg 0.3.25-ös pipewire, új samba, tudja fene, mi még. Aztán, ha ez megvan, ki tudom próbálni. Amúgy emlékeim szerint igen, a pavucontrol engedi a bluetooth profilt állítani közvetlenül, nem kell semmit sem scriptelgetni. Bár bevallom, engem az sem zavarna túlzottan.

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

    https://a.te.ervelesi.hibad.hu/nem-igazi-skot

    Mert nyilván attól fogok elismerten érteni™ hozzá, hogy nem 15 éve jól bevált, stabil technológiákat használok, hanem újrafeltalált kerekekért kapkodok, nullapontverziós fétissel, csakmert az most hűde 2021™.

    Ahhoz hogy erdemben tudd hasznalni az uj technologiakat elengedhetetlen hogy jol ismert a 15 evvel ezelotti technikakat termeszetesen. Azonban csak a 15 eves technologiak ismeretevel nem fogsz tudni a versenyszferaban munkat talalni.

    De hat ez mind lenyegtelen is, mert te csak hiszed magadrol hogy ismered akar a 15 eves technologiakat is :D

    Nem, az XP nem technologia, hanem egy operendszer neve :D

    off

    A telemetriát ne keverd ide, mert az messzire vezet, mondhatnám, már-már politika. Szimplán műszaki szempontok alapján sem jó a Windows XP. Csapnivaló az USB kezelése - nem plug and play, hanem plug and pray -, emlékeim szerint nem dugdoshatsz bármit bármelyik USB aljzatba, ha egyszer megjegyezte az adott eszközt az egyik porton, ott várja legközelebb is, a hálózati biztonsága hagy némi kívánnivalót maga után. Aztán természetesen újabb software-ek alá már nem jó.

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

    Pontosan ugyanezt csinálja egy Windows 8 és egy Windows 10 is.

    A csapnivaló USB drivereket, meg úgy általában a csapnivaló drivereket ne keverjük ide, mert az messzire vezet.

    Igen, Windows XP-re is igaz az, hogy tudni kell alá hardvert venni. Mint minden operációs rendszerre.

    Semmi köze a hardware-nek ahhoz, hogy a registry-ben megjegyzi, hova dugtál be egy USB-s midi billentyűzetet. Ezen a téren egyébként tapasztalatom szerint a Win 10 már jól teljesít, a Linuxot meg abszolút nem érdekli, mit hova dugsz, akár bekapcsolt állapotban is, az jól fog működni. Win 8-ról nincs infóm, de az is elavult, felesleges hivatkozni rá. Win 10-en saját fejlesztésű műszert, amelynek éppen most írom, javítgatom az USB midlayer-ét, szintén oda dugok, ahova akarok, működik. Windows 7-en ez egyáltalán nem így volt, ott sokat szentségeltek kollégák.

    Arról meg már sokszor volt vita, hogy hibátlan software nincs, így egyetlen lehetőség, hogy ha kiderül egy sebezhetőség, azt mielőbb foltozni kell. Az XP már nem támogatott, elengedte a gyártó, ennélfogva lyukas, mint a sajt.

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

    "Pontosan ugyanezt csinálja egy Windows 8 és egy Windows 10 is." - Vagyis pont nem, de sebaj. Persze ha te a 64 bites, XP-nek maszkírozott w2k3-ról beszélsz, akkor az árnyalja a képet, igen. Ha viszont nem erről, akkor a "tudni kell alá hardvert venni" szép baleset manapság - egyre kevesebb olyan új eszköz van, amihez kapsz XP-s drivert - de felhasználói sw-ből is egyre több az olyan, ami minimum Windows7 vagy épp minimum Windows 10-et igényel (és tényleg kell neki, mert olyan OS szolgáltatás/dll függőségei vannak, amik korábbi OS-ekben nem voltak).
    Persze akinek elég egy külön tákolt böngésző (amibe bele van reszelve a TLS1.x x>0), meg elég a 4GiB RAM, annak ezek nem jelentenek problémát...

    Jaj, tényleg, az XP 32 bites architektúra még, s ott a 4 GiB-os cím korlát. Nekem most böngésző, levelező, fejlesztői környezet, Teams van benn, s 4.09 GiB a RAM használat. Biztos jól menne XP-n. Fedora 34-en fut egyébként.

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

    Aha, mert az Electronos szutykok, mint a Teams nem™ áldozzák™ be™ a™ sebességet™. Nevetséges.

    Szerintem továbbra is kuporgasd inkább az idődet, az sokkal fontosabb™, mint a környezeted szétbaszása az újravásárolt gépekkel, meg a szoftverek erőforráspocsékolásával.

    Én alaphelyzetben egy minimális erőforrást használó terminálos VoIP alkalmazást használok, de a főnökömet és kollégáimat nem hiszem, hogy le tudom nevelni a Teams-ről. Van az a helyzet, amikor alkalmazkodnod kell, mert például dolgozol.

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

    Van az a helyzet, amikor alkalmazkodnod kell, mert például dolgozol.

    Szerencsére vagyok olyan pozícióban, hogy meghatározhatom, min keresztül beszélgetünk a munkatársakkal. A Teams nem tartozik a lehetőségek közé. Saját SIP servert és PBX-et tartunk fenn, erre a célra, amire telefonvonalról és tetszőleges VoIP klienssel (még a te terminálosoddal is) be lehet csatlakozni. Én MicroSIP-et használok.

    Sajnálom a céget, ahol te vagy "olyan pozícióban, hogy...". Komolyan. Már egyébként azon is csodálkozom, hogy VoIP-et használtok beszélgetésre, merthogy a kurblis telefon is tökéletesen működik ilyen célra...
    Csak tudod nem midnenütt és minden esetben elég a beszédátvitel, és bizony ott a hajadra kenheted a konzolos vackaidat, meg a 64 bites xp-nek nevezett OS-edet.

    Persze ha te a 64 bites, XP-nek maszkírozott w2k3-ról beszélsz, akkor az árnyalja a képet, igen.

    Igen, Windows XP x64 Edition-ről beszélek, de továbbra sem világos, hogy a kötekedésmániádon kívül miért kell ezt mindig megjegyezni. Ugyanúgy EOL rendszerről van szó. Ráadásul ugyanakkor járt le a támogatásuk. Az elnevezést beszéld meg a Microsofttal. Nem én találtam ki.

    egyre kevesebb olyan új eszköz van, amihez kapsz XP-s drivert

    Viszont, ha leveszed a szélsőségesen idealista, fősodratú, fejlődésmániás, veddmegdobdki szemellenződ, akkor egyre több van, ugyanis használtat is vehetsz.

    de felhasználói sw-ből is egyre több az olyan, ami minimum Windows7 vagy épp minimum Windows 10-et igényel

    És egyre kevesebb értelme van használni őket a "mindent böngészőből" világrend miatt, csak úgy, mint az új, modern szoftverek felhasználói felületének lebutítása, tabletesítése, elsilányítása, a bloated framework-ökben való babzsákfejlesztői kényelmeskedés okozta bloat miatt.

    Persze akinek elég egy külön tákolt böngésző

    Mikor írsz az egyes Linuxok Firefox-maintainereinek, hogy ha nem upstream forrásból dolgoznak, hanem backportolnak javításokat, esetleg disztribúció-specifikus patcheket is írnak bele, attól tákolt böngészőjük lesz? Vagy csak akkor érzed magad feljogosítva a kötekedésre, ha valaki nem a birkaárral fősodródik?

    meg elég a 4GiB RAM

    Úgy érted, 128 GB RAM (x64)? Egyébként 32-biten sem állja meg a helyét a maszlagod, mert rRamDisk akármennyi RAM-ot be tud húzni 3,2 GB fölött és virtuális meghajtóként kezelni. Oda meg kipakolhatod a page file-t.

    Ne haragudj, de annyira fájóan nem látod a piac működését. Igen, számít egy termék megjelenése is. Van standalone műszer valóban touch screen felülettel, de lehet kijelző nélkül, hálózatról, központi vezérléssel.

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

    Írd meg ugyanannyi idő alatt, ugyanannyi ráfordítással kisebb erőforrásigényűre. Egyébként meg a 64 bites XP-d is bloat, hiszen mondjuk a QNX a Photon-nal erőforrásigényben, sebességben, meg úgy mindenben agyonveri a Windows-okat - igaz, hogy egyrészt drágább maga a környezet, másrészt fejleszteni is többe kerül rá, harmadrészt meg átlagos felhasználói igényeket kielégítő szoftverek nem nagyon vannak rá. De itt a nagy lehetőség előtted...

    "Igen, Windows XP x64 Edition-ről beszélek" - Csak nem ezt írtad.  Nem mindegy, hogy Kovács Zoltánról vagy Kovács II. Zoltánról beszélünk...

    Perifériából "használtat is vehetsz" - Hogy is énekelte Zalatnay cini? "Ha kimegyek, az ócskapiacra..." - similis simili gaudet - avagy jelen esetre lefordítva ócskaság az ócskaságnak örül...

    "Úgy érted, 128 GB RAM (x64)? Egyébként 32-biten sem állja meg a helyét a maszlagod, mert rRamDisk akármennyi RAM-ot be tud húzni 3,2 GB fölött és virtuális meghajtóként kezelni. Oda meg kipakolhatod a page file-t." - Windows XP-t írtál, az alapesetben egy 32 bites OS, amiről te beszélsz, azt úgy hívták, hogy Windows XP x64 Edition, ami Windows 2003 volt belül, és csak a felülete volt XP-re maszkírozva. Ilyen alapon a DOS, meg a 3.1-es Windows is tud kezelni sok megabájtnyi memóriát, hiszen ramdiszk-re ott is kipakolható volt sokminden... Amire céloztam, meg amit mindenki ért azon, hogy memóriakorlát, az a címtér mérete, és az bizony 32 bites XP esetén 4GiB.
     

    Ne parázz, ennek nincs GUI-ja. Van pulse, alsa, meg jack interface-e. Tehát tudod piszkálni azzal a pavucontrol nevű csodával, meg a system tray-en lévő pulseaudio-hoz való bigyóval, meg tudod például Carla-val jack interface-en például keresztbe kötni a bal és jobb oldalt, mindezt real time és akár egyidejűleg ezekkel a grafikus programokkal.

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

    Általában akkor kell valamit kivezetni és újrafeltalálni, amikor már kifejlődött.

    Nem. A pulseaudio egy sikertelen project. Ugyan szögelték annyit, hogy a legtöbb felhasználónál úgy általában elég jól menjen, de a mai napig visszaköszönnek azok a gyermekbetegségei, amelyek Fedora 10-ben használhatatlanná tették a hangot 2008-ban, ha jól emlékszem az évszámra. Az elfogadhatatlan, hogy egy 4 magos, 3.2 GHz-es CPU-val szerelt gépen szétesik egy terminálos VoIP alkalmazás hangja annyira, hogy érthetetlen a beszéd miatta, miközben egy mag futásidejét 20..25 %-ban viszi el. Pipewire esetén jóval kisebb a futásidő igény, illetve folyamatosan szól a hang ropogás nélkül.

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

    A Red Hat többnyire két szabály szerint dolgozik.

    Ami kezdetben szar, azt lenyomjuk a Linux-közzösség torkán, majd toldozgatjuk-foltozgatjuk, hogy ne legyen olyan szar.

    Ami kezdetben jó, azt lenyomjuk a Linux-közösség torkán, majd elszarjuk.

    Nincsenek kétségeim afelől, hogy a PipeWire is hasonló sorsra jut, amint kilépett a nullapontverziós gyermekáldásából és a döntéshozatal átkerül néhány szélsőségesen idealista, arrogáns sztárfejlesztőhöz és babzsáktermékgazdához, a mostani, technológia iránt lelkes, hozzáértők helyett.

    Nem tudom, mi az elvárásod. Ha van egy high-end stúdiód otthon, akkor lehet, hogy arra sohasem lesz alkalmas a bluetooth átvitel. Sima hifi-ként jól szól. Azért nekem továbbra is az a gyanúm, hogy sikerült valami nem a2dp profilon keresztül megszólaltatni.

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

    Nem is vártam, hogy studió minőségben zengjen a füles, de azt igen, hogy normális hangminőségben, egyébként semmi bajom pipewire-rel. A bluez-monitor.conf-ban mind az 5 általad felsorolt kodek be volt állítva, akkor sem volt ok. Nekem ehhez nincs most türelmem/kedvem, hogy kinyomozzam mi lehet a hiba. Ne vedd támadásnak, nem leszólni jöttem ide. Arch alatt nekem még nem ok, persze, nincs kizárva, hogy valamit én néztem be, de ez majd már csak az 1.0 verzónál fog kiderülni.

    0.3.25-tel próbáltad? Én csak valamiért rákattantam, de nem vagyok a fejlesztője. Használom, tetszik, segítem olykor a fejlesztését, de nem írok a kódba.

    Tapasztalatom egyébként az, hogy a bluetooth egy szövevényes bonyodalom, erősen függ a működés a linuxos hardware-től is, de attól az eszköztől, amelyik bluetooth-on keresztül kapcsolódik a Linuxhoz.

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

    Igen, azzal próbáltam tegnap, de ma megint neki ugrottam és átírtam a megfelelő részt mert alapértelmezett beállításokkal ugyan olyan volt, viszont most ok, aptx_hd kodekkel. Szóval valószínű, hogy tegnap én mókoltam el valamit.

    Na, jól van, megnyugodtam. Ezek is annak kapcsán lettek konfigurálhatók, hogy sokat hisztiztem azon, hogy AAC codec-et akart használni, de nem sikerült neki, SBC-vel utána már hiába próbálta, a bluetooth eszközöm állapotautomatája, amihez csatlakozott volna, már olyan állapotba került, hogy azzal sem sikerült. Azaz buktam a bluetooth-t. Ekkoriban tették konfigurálhatóvá ezt, ki lehet zárni egyes codec-eket. Bár nem néztem még, de lehet, hogy már megy AAC-vel is, mert rengeteg bluetooth patch van ebben a release-ben. Hiába fordítottam forrásból napi szinten, azzal nem vacakoltam, hogy mindig visszaállítsam a config file-t. Jó nekem az SBC is. :)

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

    Nyugodtan fejlesszenek, csak ne forgassák fel vele a meglévő hangrendszereket és szoftver-dependenciákat és ne erőltessék nagyvállalati erővel, arroganciával mindenre és mindenkire.

    Windows-on is ki tudott külön fejlődni az ASIO, professzionális és stúdió célokra. Nem kellett miatta lecserélni az összes másik nemprofesszionális, audió alrendszert használó szoftver backendjét és más library-kra dependáltatni.

    Senki sem tiltja, hogy a neked bevált komponenseket, a hozzád hasonlóan gondokodókkal együtt, közös munkával életben tartsátok, "kipachheljétek" az általatok kiválasztott mainstream disztróból ami nem tetszik, és belerakjátok az általatok megfelelőnek tartott legacy dolgokat. Igen, ez munkával - nem kevéssel- jár.

    Ja, még én lapátoljam a szart, hogy aztán egy mindenki által leköpködött, lehugyozott platformot életben tartsunk.

    Nézd meg, pl. a ReactOS-re, Devuan-ra stb. alternatív 100% közösségi és multikkal közösséget nem vállaló platformok announcement topikjaira milyen megalázó kommentek érkeznek, mikor kijön egy újabb verziója, mert nem értik, hogyan léteznek emberek, akik ebbe időt és energiát ölnek, ahelyett, hogy sodrodnának a fősodratú, multibuzi áramlattal. Ami azért necces, mert a lakájmédia hasábjait is fősodratú bértollnokok firkásszák, így ott is ez fog megjelenni. Bezzeg a multik szoftverei, operációs rendszerei a végletekig vannak istenítve, még ha szarok is.

    "Ja, még én lapátoljam a szart, hogy aztán egy mindenki által leköpködött, lehugyozott platformot életben tartsunk." - Ha neked hiányzik nagyon, akkor lapátold. A régi sz@rt, vissza a lóba, merthogy sok esetben az eredeti fejlesztő is hagyta a fenébe, mert látta, hogy nem igazán jó az irány. De elég lenne az általad emlegetett terjesztések fejlesztésében tevőlegesen részt vállalnod - gondolom, ha megtetted volna, akkor be is mutatnád, hogy mit és hogyan toltad ezeknek a közösségeknek, ezeknek a "nemfősodratú, nem multibizi" változatoknak a szekerét.
     

    ( jimmy399 v | 2021. 04. 10., szo – 11:43 )

    Gondoltam kipróbálom a pipewire-t, leszedtem kompletten az pulseaudio-t, feltettem helyette. Egy napig nem sikerült használni, vissza kellett tenni a pulse-t.

    Elindul a yt videó, leállítom, elmegyek a géptől, visszajövök, folytatnám, nincs hang. Ok, újraindítom a pipewire-t, van hang, leállítom, megint nincs. Más médiát lejátszó alkalmazásban sincsen... A Wikit túrva semmi nincs ilyen hibáról, ami segítene. 

    Milyen oprendszeren, melyik verziójú pipewire? Mi volt a hardware konfiguráció? Érdekel, mert a stabilitásával sohasem volt bajom, használom keresztbe-kasul, ráadásul úgy is, hogy van alkalmazás, aminek a hangja USB-n megy ki, másiké bluetooth-on, és jól működik. Ebből nem következik, hogy ne lehetne baj más környezetben. Volt, aki arról riportolt hibát, hogy 64 audio csatornát használva nem indult el a pavucontrol. Erre Wim limitálta a csatornák számát 32-ben, mert a pulseaudio is annyit tud, és a kliensek erre vannak felkészítve. :)

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

    Arch Linux-on, legutolsó stabil verzióval:

    extra gst-plugin-pipewire 1:0.3.25-1
    extra libpipewire02 0.2.7-1
    extra pipewire 1:0.3.25-1
    extra pipewire-alsa 1:0.3.25-1
    extra pipewire-media-session 1:0.3.25-1
    extra pipewire-pulse 1:0.3.25-1

    A gép:

    Amd A8-5600K 12 GB RAM, Samsung 480-as SSD, hangkártya: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (rev 01)

    5.11.11-es visszatartott kernellel, mert a VGA kártyával gondok voltak: https://hup.hu/node/173360
     

    HP EliteBook 8570p

    Intel(R) Core(TM) i5-3340M CPU

    8 Gb ram, Micron 128 Gb SSD.

    Kernel: 5.11.12-arch1-1

    Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)

    Arch linux

    extra/gst-plugin-pipewire 1:0.3.25-1
    extra/libpipewire02 0.2.7-1
    extra/pipewire 1:0.3.25-1
    extra/pipewire-alsa 1:0.3.25-1
    extra/pipewire-jack 1:0.3.25-1
    extra/pipewire-media-session 1:0.3.25-1
    extra/pipewire-pulse 1:0.3.25-1

    Video/zene lejátszás megy, mvp és gstreamer-es lejátszóval is. Viber működik. Youtube 3 böngészőben kipróbálva, működik. Bedugott usb hangkártyás fejhalgatóval is.

    Tetszik.

    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.

    "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

    ( volo v | 2021. 04. 16., p – 09:16 )

    Szerkesztve: 2021. 04. 16., p – 09:17

    Esetleg valaki nem tud egy tippet arra, hogy laptopon ha be dugom a külső hangfalat (jack) akkor automatikusan váltson át rá? Rohadt idegesítő állandóan átkapcsolgatni.

    Machine:   Type: Laptop System: Dell product: G5 5587

    Audio:     Device-1: Intel Cannon Lake PCH cAVS driver: snd_hda_intel 
               Device-2: NVIDIA GP106 High Definition Audio driver: snd_hda_intel 
               Sound Server-1: ALSA v: k5.11.13-zen1-1-zen running: yes 
               Sound Server-2: PipeWire v: 0.3.25 running: yes 

    Ez így igaz, de pulseaudioval alapértelmezetten működik. Kérdés, hogy vajon miért?

    A pactl info kimenete:

    rver String: /run/user/1000/pulse/native
    Library Protocol Version: 34
    Server Protocol Version: 35
    Is Local: yes
    Client Index: 63
    Tile Size: 65472
    User Name: volo
    Host Name: Aporka
    Server Name: PulseAudio (on PipeWire 0.3.25)
    Server Version: 14.0.0
    Default Sample Specification: float32le 2ch 48000Hz
    Default Channel Map: front-left,front-right
    Default Sink: alsa_output.pci-0000_00_1f.3.analog-stereo
    Default Source: alsa_input.pci-0000_00_1f.3.analog-stereo
    Cookie: e0a3:29ef
     

    Ez az alapértelmezett beállítás, nem piszkálom még gentoo-n sem kellett eddig hozzányúlni flottul működött (pulse). Ha megpróbálom eltávolítani az alsa-t viszi a fél rendszert. A configba mint már mondtam nem turkálok ha nem muszáj. Pulseval meg vidáman működött eddig minden, csak a pipewire-el nincs összhangban még.

    Nem kell eltávolítani az alsa-t, hiszen a driver rétegben ő van, ha úgy tetszik, miután a pipewire megrágta, resampling, hangerő, mix, minden megvolt, akkor az alsa-nak adja a hangot. Itt ez az aszimmetrikus config furcsa nekem, szerintem mindkét hangkártyát a pipewire-nek kellene kezelnie. Ez meg véleményem szerint azon múlik, mi van a /etc/alsa környékén.

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

    Jaja.

    1. Felhasználó ellehetetlenítése, választási lehetőségektől való megfosztása. Felhasználói szabadság lábbal tiprása.
    2. Felhasználóval való kompenzáltatás, az open-source idealizmusra hivatkozva.
    3. Végül az elkészülő merge request-ek elutasítása idealista érveléssel.

    Láttuk már.

    Lehet, neked nem szóltak még erről, ezt nem Lennart Poettering fejleszti. Wim Taymans egészen más habitusú ember. Ő olyan, hogy megköszöni, ha időt, munkát áldozol, segítesz, s nem valami nagyképű szöveggel ráz le. Tapasztalatból mondom.

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

    Lehet, hogy neked még nem szóltak, hogy nem Lenart Poettering az egyetlen arrogáns elem a Red Hatnál. Tény, hogy a többi nem olyan híres.

    Ő olyan, hogy megköszöni, ha időt, munkát áldozol, segítesz, s nem valami nagyképű szöveggel ráz le.

    Nem garantált, hogy mindig nála lesz nála a projekt és az sem, hogy mindig ilyen marad, pl. akkor is, amikor már bőven túl vagytok a nullapontverziós fázison.

    https://a.te.ervelesi.hibad.hu/hamis-okozat

    Üzleti vonalról is jópáran panaszkodtak a rekurzív keresés kötelezővé tételére. Abból a rengeteg időből, amit a Red Hat babzsákfejlesztői bérkommenteléssel és az elégedetlen felhasználók megalázásával töltöttek, simán belefért volna egy opció a kikapcsolására, vagy legalább valamelyik elkészült patch set, merge request befogadása.

    A rekurzív keresést fájlkiválasztó ablakban az ég világon semmi nem indokolja, sem szakmai, sem UX szempontból. Semelyik másik ablakkezelőben, semelyik másik platformon, operációs rendszerben (Windows, Mac OS X, Android, iOS stb.) nincs ilyen. Ezzel lényeges, kikapcsolhatatlan inkonzisztenciát teremtettek számos alkalmazásban és ablakkezelőben, ami GTK3-ra dependál. Megannyi álmatlan éjszakát és frusztrációt a felhasználóknak.

    https://gitlab.gnome.org/GNOME/nautilus/issues/244
    https://gitlab.gnome.org/GNOME/nautilus/issues/1157
    https://gitlab.gnome.org/GNOME/gtk/-/issues/627
    https://gitlab.gnome.org/GNOME/gtk/-/issues/839
    https://github.com/telegramdesktop/tdesktop/issues/2411
    http://archive.is/wip/ayEa7
    http://archive.is/wip/WHjXK
    http://archive.is/wip/HNkJG

    Mielőtt üzleti világozol, meg kvázisztenderdezel (amit mondjuk én se vitattam, de mindegy), inkább vedd le kicsit a szemellenződ és olvasgasd a fentieket, mert sajnos még mindig képtelen vagy megérteni, hogy én a Red Hat fejlesztők arrogáns viselkedését és a beteg fejlesztési irányokat, UX-trendeket kiritzálom, amit követnek, nem feltétlenül a szakértelmüket, bár a GTK3 API folyamatos, főverzión belüli eltörögetése minimum igénytelenségre vall, ha nem inkompetenciára.

    Visszatérve az arroganciára, ahogy Emmanuele Bassi, szélsőségesen idealista, GTK Core developer mondotta:

    Free software development is not a democracy, and does not get driven by polls. Features and bugs are introduced by those who show up, within a community that works towards a shared goal.

    Onnantól pedig, hogy a merge requesteket rendre elutasították, gyakorlatilag érvénytelenedik az általad és locsemege által is oly sokat hangoztatott "csatlakozz a projekthez és tedd jobbá" című idealizmus is.

    A Red Hat egy velejéig arrogáns multi, az IBM felvásárlás után különösképpen (lásd stabil CentOS 8 kinyírása). Ezen pedig az sem változtat, ha a PipeWire nullapontverziós változata ígéretes. Csak a szerencsének köszönhetjük, ha a PipeWire megmarad olyannak, amilyennek locsemege a piedesztálon látja és nem cseszi szét valami szélsőségesen idealista, antipatternbuzi, arrogáns babzsákfelesztő, akihez egyszer átkerül majd.

    Azon túl, hogy szidod a fejlesztőket, mit tettél hozzá ezekhez a projectekhez? Ha te lennél az egyik meghatározó fejlesztő, ezzel a mentalitással, amit itt előadsz, nekem úgy tűnik, szintén egy önző irányvonal valósulna meg, csak az épp a tiéd volna, ezért fel sem tűnne. Neked jó lenne, meg azoknak, akik épp hozzád hasonlóan gondolkodnak ezekről, a többieknek meg ígyjárás.

    Egyébként nem túl nagy baj, ha valaki képes visszanyúlni a Unix filozófiához, eszközökhöz. Én erről a rekurzív, nem rekurzív keresés hisztiről nem is tudtam. Saját forráskódomban így szokta keresgélni:

    grep -anF 'valami' *

grep -anRF 'valami' *

grep -anE 'regexp' *

grep -anRE 'regexp' *

    És hidd el, megtalálom, amit keresek, mi több, azt is, az adott függvényt, változót melyik file-okban hívom, használom, azok hanyadik sorában, illetve hol van deklarálva. Nem hisztizni kellene, hanem használni az oprendszer képességeit nyafogás helyett!

    Ebben ott az adott szinten keresés, meg az alkönyvtárakba lemenős rekurzív forma is. Nekem is van, hogy az egyik, van hogy a másik jobb, de nem szégyellem azt az 'R' betűt, ha épp az kell.

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

    Saját forráskódomban így szokta keresgélni

    Rendben. Továbbra is lehet MS-DOS szinten használni a modern™ operációs rendszeredet és dicsekedni, hogy nálad nem jönnek ki a mainstream GUI-s hibák, meg hisztinek degradálni egy valós kritikát egy, a Red Hat által szándékosan elbaszott feature-rel szemben.

    És hidd el, megtalálom, amit keresek

    Elhiszem. Én is megtalálom, mivel nem használok sem Linuxot, sem GTK3-at.

    Most, hogy ezeket tisztáztuk, esetleg akkor hajlandó vagy megérteni a tárgyalt problémát is? Merthogy nem fájlokban való tartalomkeresésről volt szó, az biztos. Arról volt szó, hogy ha bármilyen GTK3-ra dependáló alkalmazásból megnyitnál egy fájlt, ott a file dialog rekurzívan fog keresni és neked esélyed nincs ezt kikapcsolni. Legalább olvasnád el a belinkelt bugreportokat.

    Mit értünk itt keresés alatt? Gondolom, az elég rossz megoldás volna, ha az adott szinten kilistázná a file-okat, alkönyvtárakat, de az alkönyvtárba nem mehetnél be, mintha nem lenne jogosultságod. Vagy ki se listázná az alkönyvtárakat, mintha az ott sem lenne. Ha jól értelek, ez az a dialógus ablak, amelyben egy file-t lehet kiválasztani, hogy az alkalmazás azzal kezdjen valamit. Windows-ban ilyen helyzetben emlékeim szerint a hálózati megosztásokat is látom, onnan is lehet file-okat megnyitni, vagy oda is lehet menteni.

    Ezzel a feature-rel mi a baj? Lassú? Mert elég akkor listázni az alkönyvtár tartalmát, amikor abba belemegyünk. Van valami keresés, de sosem értettem, hogyan működik, nem is érdekelt, így nem használtam. El kell mesélni a gépnek, systemd timer vagy cron, hogy csináljon néha updatedb-t, s akkor ott a locate, gyors lesz, mert cache-ből dolgozik. Igaz, nem lesz pontos, mert ami nincs még az adatbázisban, arról nem fog tudni.

    MS-DOS szinten használni

    vs. coreutils, grep, awk, calc, miegymás. Ne nevettess, kérlek! Van némi különbség.

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

    Röviden: Bármelyik könyvtárban van, onnan indulva rekurzívan keres, nagyságrendekkel több erőforrást elpocsékolva és I/O-t elhasználva a szükségesnél. Emellett, képtelen vagy a fájlok-mappák néhány első karakterét beírva, szimplán az aktuális könyvtárból választani (typeahead). Öröm lehet ez egy hálózati fájlrendszeren, vagy egy osztott képernyőn, amikor megjelenik olyan, alkönyvtárban lévő fájl is, amit nem szívesen mutatnál meg, hogy a /home könyvtáradban van (és most nem csak az NSFW tartalmakra gondolok).

    Régen ezt a funkciót az Alt+S kombóval lehetett előhozni, ami jó is volt így, alapértelmezés volt a typeahead, ahogy egyébként minden más fájlkiválasztó is működik. A typeahead kikerült, a rekurzív keresés kötelező lett. Kikapcsolhatatlanul. A beállítási lehetőség berakását elutasították, a szokásos, milliárdos multik fillérbaszó érvelésével. [1]

    Options have a cost, especially those which are not enabled by default and do not get tested

    Ami már ott megbukik, hogy régen évekig igaz volt ez a rekurzív keresésre, hiszen GTK2-től benn volt mindkét funkcionalitás. Tehát, konkrétan kevesebb munka és költség lett volna nekik, ha hozzá se nyúlnak. A merge requesteket rendre elutasították, arrogánsabbnál arrogánsabb, szélsőségesebbnél szélsőségesebb idealista közhelyekkel.

    Sajnálom, hogy lusta voltál elolvasni a linkelt bugreportokat. Pedig jócskán kapnál egy képet arról, hogy a Red Hat-nál milyen lead fejlesztői kultúra uralkodik. Bár, lassan már kezdek hozzászokni, hogy szándékosan a szőnyeg alá söpröd, eljelentékteleníted a Red Hat okozta bosszúságokat, ha mással nem megy, az érintetlenségeddel önigazolva.

    Leírok pár dolgot bár hiába, mert annyi ész szorult beléd, mint az állott macskahányásba.

    Nem a RedHat fejleszti a gnome-ot. És van más filemanager, ha nem tetszik a DE-ben lévő. Sőt van más DE is.

    A kislányos kis picsogásod egy ideig szórakoztató, mert lehet rajtad nevetni, de aztán már csak kurva fárasztó nézni a vergődést arról, hogy egy idióta okosnak hiszi magát. 

    Egyértelmű, hogy nem értesz de tényleg semmihez. Nincs is ezzel baj, ha nem lennél erőszakos hülye. :)

    Nem a RedHat fejleszti a gnome-ot.

    De igen, a GNOME és a GTK3 lead fejlesztői mind a Red Hat-nál dolgoznak. Az, hogy bedolgoztatnak ingyenmunkásokat, egy dolog. A Chromium is csak a marketingasztalon open-source™ közösségi™ projekt. Ott van mögötte a Google.

    És van más filemanager, ha nem tetszik a DE-ben lévő.

    Akkor kérlek, sorold fel, ha már beléd olyan kurvasok ész szorult, hogy milyen filemanagert file dialogot (tehát ami megnyitásnál és mentésnél megjelenik) használhatok GTK3-as alkalmzásokhoz a GTK3-ason kívül, és hogyan?

    Egyértelmű, hogy nem értesz de tényleg semmihez. Nincs is ezzel baj, ha nem lennél erőszakos hülye. :)

    Én legalább el tudom mondani a problémát és alá tudom támasztani el tudom mondani, miért probléma. Te csak személyeskedni és minősíteni tudsz.

    Várom a technikai javaslataid, a kötelezővé erőltetett, rekurzív keresés kikapcsolására anélkül, hogy a fél világot újra kéne forgatnom és saját csomagot kéne karbantartanom a gtk3-ból. Ha ebben felsülsz, akkor várom a technikai javaslataid, hogyan lehet tetszőleges file dialogot használni bármilyen alkalmazáshoz, hogy az open/save dialog feldobásakor az induljon el. Könnyítés: Nekem az is elegendő lenne, ha a GTK2-es jelenne meg a GTK3-as alkalmazásokból, fájl megnyitásakor/mentésekor. Ha ebben is felsülsz, akkor még mindig várom a személyeskedést nélkülöző indoklásod, hogy ennek tükrében miért nem állja meg a helyét az az állítás, hogy a Red Hat folyamatosan lehetetleníti el a választási lehetőségeket és tiporja lábbal a felhasználói szabadságot.

    Tehát tartsak karban saját GTK2-es Firefox-ot, Chromium-ot, Libreoffice-t és minden valamire való grafikus alkalmazást, ami egy kicsiny halvány értelmet ad a Linux desktop használatának. Hát persze. Ez aztán a választási™ lehetőség™!

    Más kérdés, hogy olvasni nem tudsz, mert tisztán és világosan leírtam, hogy "anélkül, hogy a fél világot újra kéne forgatnom".

    Netán esetleg van valami módszer, vagy környezeti változó, amit megadva GTK2 File Choosert fog használni minden GTK3-as alkalmazás, esetleg a rekurzív keresés letiltható? Ja hogy nincs, csak fogalmatlanul okoskodsz.

    Az opensource világ így működik - a topic témájával kapcsolatban is javasoltuk már neked, hogy forkold le a neked tetsző állapotot a Linuxos hangrendszerből, csinálj belőle hajbiaudio-t, gyűjts köré közösséget, fejlesztőket, és kész.
    Vagy "B" tervként használd a csilliómegegy éve EOL-os, XP-bőrbe bújtatott W2k3-at, és azt, ami azon elérhető. Mert nem egyszer kijelentetted, hogy az tökéletesen elég minden feladatra, úgyhogy marhára nem értem, mit sírsz, mint a fürdős..., hogy így rossz irányba megy a RedHat és az egész Linux világ, meg úgy idióta elkényelmesedett "babzsákfoteles" fejlesztők... Tedd oda magad, a tudásodat, a munkádat, hogy neked is megfelelő eszközök készüljenek. Forkold, tartsd karban, igen. Ha jó lesz, amit csinálsz, akkor idővel lesznek olyanok, akik beszállnak a fejlesztésbe - ha nem, akkor kiderül, egyedül maradtál, és az egyedi igényeidet bizony magadnak kell megoldanod...

    De biza' így működik: van egy szoftver, amit x fejlesztői csapat y irányba haladva fejleszt. Ha neked a z irány lenne jó, az tetszene, akkor nyugodtan megteheted, hogy fogsz egy még elfogadható állapotot, megcsinálod belőle a saját forkodat, és viszed tovább egy másik csapattal. Persze a te hozzáállásoddal nehezen képzelhető el fejlesztői csapat, de ez más kérdés.

    Egyébként meg visszakérdezek: szerinted hogyan működik?

    Szerintem úgy működik, hogy egy core dependenciaként funkcionáló projekt (pl. GTK3) lead fejlesztői nem dolgoznak semmilyen multinak, ahol autokráciában vezetett szélsőségesen idealista termékmenedzserek és túlfizetett, arrogáns babzsákfejlesztők határozzák meg a kijelölt irányt, míg a külsősök által felvetetteket semmibe veszik. Itt már csúfosan megbukik az open-source eredeti, közösségi koncepciója. Szóval kár ezt lobogtatni.

    A lehetőség természetesen adott a forkolásra, de ettől még a Red Hat egy velejéig arrogáns multi marad, amelyik pont annyira leszarja a felhasználóit, mint azokat a fejlesztőket, akik nem náluk dolgoznak. Előbbieket fejőstehénnek (ha ügyfelek) vagy ingyentesztelőnek (ha nem ügyfelek) tekinti, utóbbiakat ingyenmunkásoknak.

    Gondolom a következő kérdésed az lesz, hogy miért nincsenek forkolt projektek a GTK3-ból... Egyrészt, vannak. Másrészt, a teljes FOSS tech-közvéleményt, beleértve ezt a fórumot is megfertőzte már az a trend, hogy ha valaki saját OS-t szeretne csinálni (merthogy a Red Hat összes felforgatását ellensúlyozni minimum egy saját Linux-disztróba kerülne), akkor segítséget aligha kap, csupán kinevetést, megalázást, megvetést amellett, hogy folyamatosan éreztetik vele, mennyire felesleges, amit csinál. Ez a multik (élen a Red Hat-tal) Linux-világ feletti hatalomátvételének köszönhető és azon marketing-idealizmus lakájmédia, tech-divatcikkek és tech-influenszerblogok általi elterjesztésének, hogy valami csak akkor lehet jó™, stabil™, hiteles™, kelendő™, ha minimum egy multi mögötte áll.

    Nézd végig például, hogy a systemd-szkeptikusok, a Devuan felhasználók, a ReactOS-t fejlesztők-próbálgatók milyen destruktív nyomásnak vannak kitéve, akár ezen a fórumon, akár másutt. Szóval, az open-source eredeti, közösségi koncepciója, meg a "forkold le és csinálj jobbat" akkor fog működni, amikor a fősodor ezt komolyan is gondolja és nem lemaradott™, sértődött™ senkiháziaknak fogja bélyegezni azokat, akik elkezdenék a forkot, de mondjuk segítséget kérnek benne, mert nincs mögöttük egy dollármilliárdos IBM.

    "core dependenciaként funkcionáló projekt (pl. GTK3) lead fejlesztői nem dolgoznak semmilyen multinak" - És miből élnek? Mert egy ilyen központi szerepet játszó komponenst otthoni/munk amelletti hobbiprojektként csinálni nem biztos, hogy jó dolog - sőt. Hobbiprojektre alapozni bármit is senkinek sem életbiztosítás.

    "Gondolom a következő kérdésed az lesz, hogy miért nincsenek forkolt projektek a GTK3-ból" - rosszul gondolod. A kérdésem az, hogy miért nem azok közül használod a neked szimpatikusat?

    "a systemd-szkeptikusok, a Devuan felhasználók, a ReactOS-t fejlesztők-próbálgatók milyen destruktív nyomásnak vannak kitéve" - Szerinted. Szerintem meg nem. Egyszerűen megmaradtak egy adott irány mellett, és ennyi. Az, hogy fejlesztési erőforrásuk mennyi van (visszautalnék a hozzászólásom elejére: központi szerepet játszó komponens fejlesztése hobbiprojektként, munka mellett problémája), az nem a "destruktív nyomás"-nak, hanem annak köszönhető, hogy arra, amit csinálnak az igény khm. korlátozottabb.
    Aki "hobbiból" csatlakozna fejlesztésekhez, aki adni akar az erőforrásaiból a közösségnek, az eldönti, hogy hova adakozzon: oda, amit többeknek haszbos, vagy oda, ami kevesebbeknek.

    Más jellegű közösségi projektnél is tisztán látszik, hogy az, aki a "közösbe" akar adni, az jellemzően mérlegeli annak a hasznosságát, és oda tesz erőforrást, ahol többen élvezhetik a munkája gyümölcsét.

    És miből élnek?

    Amiből akarnak. Senki nem mondta amúgy, hogy egy ember hobbiprojektjének kéne legyen. Igazából pont itt ütközik ki az a hozzáállásod, amivel a legnagyobb baj van, nem csak nálad, hanem úgy általában a fősodratú mérnök uraknál, hogy elképzelhetetlennek tartod, hogy valaki legalább olyan komolyan vegye a hobbiprojektjét, mintha pénzt kapna érte egy multitól.

    A kérdésem az, hogy miért nem azok közül használod a neked szimpatikusat?

    Mert nincs nekem szimpatikus. Vannak tákolt csomagok. Hivatalosan Red Hat mentesített disztró nincs. Ubuntu Bionic az egyetlen, ahol kipatchelték a kötelező rekurzív keresést, de Focaltól már visszatették.

    nem a "destruktív nyomás"-nak, hanem annak köszönhető

    Attól még ott van a destruktív nyomás, ami messzemenőkig hátráltatja az értelmes diskurzust és munkát az ilyen projekteknél. Ez kiválóan alkalmas arra, hogy elvegye a projekttel kezdetben szimpatizáló fejlesztők kedvét a becsatlakozástól. Így tényleg csak az a fanatikus kisebbség marad, akiknek az alternatíva megteremtése van a központi fókuszban.

    ellemzően mérlegeli annak a hasznosságát, és oda tesz erőforrást, ahol többen élvezhetik a munkája gyümölcsét

    Más kérdés, hogy ha multik által vezetett projektekbe adakozik ingyenmunkázik, akkor azt csak félig teszi a közösségért, félig pedig egy olyan nagyvállalat profitjáért, amelyik őt ingyen dolgoztatja és kész kisiklatni a projektet a saját önző profitérdekében olyan irányokba, amit rövidtávon jövedelmezőbbnek gondol.

    Ha mindenki ilyen logika alapján gondolkodott volna, akkor mindenki az open-source szoftverét Windows-ra készítette volna el, mert ott "többen élvezhetik a munkája hasznosságát", hiszen jóval többen használják. Az eredeti és a Linuxot is felépítő open-source filozófia rendkívül távol áll ettől a korporatizált maszlagtól, csak számodra nem létezik már más út.

    "Senki nem mondta amúgy, hogy egy ember hobbiprojektjének kéne legyen." - akkor több ember miből éljen?

    "valaki legalább olyan komolyan vegye a hobbiprojektjét, mintha pénzt kapna érte egy multitól" - Leet komolyan venni, valóban, csak akkor esélyes, hogy alkalom adtán lesz fontosabb, és "vigye, aki akarja" projekt lesz belőle - ami pont egy központi szerepet játszó komponensnél nem vállalható kockázat azoknak, akik arra építenek.
    A másik, hogyha komolyan veszi az adott szoftvert, akkor szerinted napi hány órát kell ráfordítani, hogy vezető fejlesztőként foglalkozzon vele? 1-2 esetleg 3 órát? Vagy tán többet? Család meg lesz@rva?

    "Mert nincs nekem szimpatikus. Vannak tákolt csomagok." - Akkor csinálj olyat, ami neked szimpatikus, csinálj nem tákolt csomagokat. Amilyen nagy tudásúnak próbálod beállítani magad, biztosan sikerülne... Meg csapatot építeni is... (Ja, nem...)

     

    akkor több ember miből éljen?

    Ki kéne szakadni végre ebből a korporatokrata csapdából, szerintem.

    Actually, many people will program with absolutely no monetary incentive. Programming has an irresistible fascination for some people, usually the people who are best at it. There is no shortage of professional musicians who keep at it even though they have no hope of making a living that way. But really this question, though commonly asked, is not appropriate to the situation. Pay for programmers will not disappear, only become less. So the right question is, will anyone program with a reduced monetary incentive? My experience shows that they will. For more than ten years, many of the world's best programmers worked at the Artificial Intelligence Lab for far less money than they could have had anywhere else. They got many kinds of nonmonetary rewards: fame and appreciation, for example. And creativity is also fun, a reward in itself. Then most of them left when offered a chance to do the same interesting work for a lot of money.

    - GNU Manifesto

    Kérdezd meg a NewPipe, a uBlock Origin, az ffmpeg, az mplayer, a youtube-dl stb. fejlesztőit, hogy miből élnek. Nyilván nem a híd alól commitolnak, ez mégse kerül abba, hogy egy multi irányítsa és tegye napról napra használhatatlanabbá az általa főállásba felvett lead fejlesztőkön keresztül. Az ilyen közhelyes kérdéseket azért teszed fel, mert a te értékrended és munkamorálod teljes egészében pénzért megvásárolható, vagy legalább pénzre váltható. Hasonlóképpen, ahogy a Red Hat fejlesztőinek. Ez inkább szegénységi bizonyítvány, mintsem erény. Továbbá, nem is feltételezi azt, hogy mindenki így működik. Bár megszokhattuk már, hogy azért, mert te kihasználod az okostelefonod képességeit, céltalan tapicskolás helyett, azért éljünk inkább hatmillió okostelefon országában és a másik ötmillió-kilencszázkilencvenkilencezer-kilencszázkilencvenkilencnek is legyen, mert csak így lehet fejlődni™. Próbálj meg nem mindig magadból kiindulni.

    Leet komolyan venni, valóban, csak akkor esélyes, hogy alkalom adtán lesz fontosabb, és "vigye, aki akarja" projekt lesz belőle - ami pont egy központi szerepet játszó komponensnél nem vállalható kockázat azoknak, akik arra építenek.

    Megint csak két szélsőségben tudsz gondolkodni, és az átkozott befektetőlogikád sem vagy képes félretenni. Szerintem sokkal nagyobb kockázat az, hogy főverzión belül negyedévente eltörik az API-t, mint ahogy tették a GTK3-nál, minthogy az egyik lead átmeneti kiszállása vagy családi okai miatt a másik lead viszi tovább a projektet ugyanabba az irányba. Itt már meg is bukott a főállású projektgazda képzelt felsőbbrendűsége a hobbi projektgazda fölött. A valódi kockázatokról és mellékhatásokról meg érdeklődj azoknál a fejlesztőknél, akiknek többször keresztbe tett a Red Hat az instabil szarkupacaival és elegük lett a faszerdőben szaladgálásból, multiék kedvéért. Jó példa az Audacious GTK3-ról GTK2-re visszaállása, majd Qt-re portolása.

    Család meg lesz@rva?

    Egyrészt, nem mindenkinek kell család. Másrészt, embere válogatja, mennyire szarja le a családját, nem a hobbija.

    Még jó, hogy engem piszkáltál, hogy ingyen segítettem Wimnek a pipewire fejlesztésében, most meg egyenesen elvárásként fogalmazod meg ezt a viselkedést. :) Egy ilyen project nagyon sok idő, az úgy nem fog menni, hogy valaki dolgozik a munkahelyén, aztán a közösségi projectjén, és még magánélete is legyen. Márpedig legyen, mert mindenkinek egy élete van.

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

    Még jó, hogy engem piszkáltál, hogy ingyen segítettem Wimnek a pipewire fejlesztésében, most meg egyenesen elvárásként fogalmazod meg ezt a viselkedést. :)

    Nem én fogalmaztam meg, hanem Richard Stallman. És nem azt fogalmazta meg, hogy multiknak segíts csatlósként ingyenmunkával. A többi nyálat nála verheted.

    Egy ilyen project nagyon sok idő, az úgy nem fog menni, hogy valaki dolgozik a munkahelyén, aztán a közösségi projectjén, és még magánélete is legyen.

    Nem azt mondtam, hogy ne dolgozzon a munkahelyén. Azt mondtam, hogy a munkahelye ne pofázzon bele közvetlenül, merre viszi a projektet. Ehhez nyilván az kell, hogy a projekt hobbiprojekt legyen és a cégnek ne fűződjön hozzá érdeke. Másrészt, ha több idő kell másra, a "sok" munkát is véges időtartamon belül be lehet fejezni a hobbiprojekt oldalon. Vagy befejezheti egy másik fejlesztő is. Nem hiszem, hogy baj, ha később lesz kész. Lásd a főállású Red Hat szörnyszülött Wayland, ami 10+ év után sincs használható állapotban, mégis elkezdték erőltetni. Harmadrészt, valakinek a magánéletet nem a család jelenti, mert nincs neki. Nem is kell, hogy mindenkinek legyen.

    Ugyanakkor baromság a reklámfilmből ellesett életérzésekkel érvelni a komolyabb szintű hobbiprogramozás ellen. Ha valaki törődik a családjával, szeretteivel, akkor nem rendeli alá őket a hobbijának, sőt akár olyat is lehet, hogy bevonja a gyereket is, aki legalább megtanul programozni, céltalan Facebook-ozgatás, Netflix-ezgetés, Instagramozgatás helyett.

    ééés hajbi ismét bebizonyította, hogy csak az unokatestverenek a huganak a szobatarsanak a tengerimalacatol hallott arrol, hogyan lehet sajat projektet vinni cegen belul sot egyaltalan milyen egy nagy cegnel dolgozni, vagy egyaltalan az IT-ban dolgozni :D

    aranyos vagy...ki dob neki banant? :D

    OK, hogy ez az egész hobbyként indult, de lettek cégek, amelyek láttak ebben fantáziát - vagy erre jöttek létre -, ebből élnek, így a fejlesztő teljes munkaidejében tud ezzel foglalkozni, sőt, még fizetést is kap érte. Szerintem win-win szituáció. Attól, hogy valami hobby project marad, ugyanazokat a nyűgöket cipelheti magával. Ha egy Lennart Poettering mentalitású fazon hobby project-ként csinálná a PulseAudio-t, akkor hirtelen befogadóbb lenne a külsős patch-ekkel, illetve ott, ahol módja lett volna, hirtelenjében alkalmazott volna workaround-okat, ahelyett, hogy beszólogat az ALSA fejlesztőinek? Aligha. Nem hinném, hogy Lennart attól hülyült meg, mert Red Hat alkalmazott. Ő akkor is egy beképzelt agresszív barom maradna, ha nem lenne Red Hat alkalmazott. Bár tény, hogy a Red Hat egyik vezető fejlesztőjének lenni olyan státusz, amely kiemeli a rossz emberi tulajdonságokat az erre hajlamosak esetében.

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

    Szerintem win-win szituáció.

    Onnantól nem win-win, hogy a cég megnyomja az arrogancia-gázpedált és rendre siklatja a ki a projekteket, szembe köpve azt a filozófiát, amire felépítették a céget. Emlékeztetnélek, hogy a Red Hat sem volt mindig arrogáns. A Poettering-érával kezdődött az arrogáns ámokfutásuk és a Linux-világ korporatokrata gyarmatosításuk. Azóta a visszafogottabb, kevésbé ellenséges fejlesztők is sokkal több arroganciát engedtek meg maguknak, mivel látták, hogy sikeresen túszul ejtették a közösségi Linux-fejlesztést az által, hogy a Debian is adoptálta a szutykukat. Gyakorlatilag kevés vesztenivalójuk van, így még több arroganciát hajlandóak maguknak megengedni, gyakorlatilag a Microsoft mögé beállva a sorba.

    Ha egy Lennart Poettering mentalitású fazon hobby project-ként csinálná a PulseAudio-t, akkor hirtelen befogadóbb lenne a külsős patch-ekkel, illetve ott, ahol módja lett volna, hirtelenjében alkalmazott volna workaround-okat, ahelyett, hogy beszólogat az ALSA fejlesztőinek? Aligha.

    Itt az első nagy tévedésed. Egyrészt, de igen, simán lehet, mivel nem áll mögötte egy egész multi apparátusa, pénzzel és erőforrásokkal. Ez taníthatta volna alázatra. Másrészt, ha nem ezt tette volna, akkor senki nem adoptálta volna a PulseAudio-t, maradt volna egy éretlen hobbiprojekt, amilyen most is, csak ezt mindenki elfelejti, mert rajta van egy Red Hat copyright notice, meg a másik disztrók adoptálták a Red Hat megkerülhetetlensége és befolyása miatt.

    Nem hinném, hogy Lennart attól hülyült meg, mert Red Hat alkalmazott.

    Nem valószínű, hogy teljes egészében ettől hülyült meg, de az arroganciájához biztosan hozzátett.

    Ő akkor is egy beképzelt agresszív barom maradna, ha nem lenne Red Hat alkalmazott.

    Csak akkor sokkal kevesebb eséllyel tudná sikeresen felforgatni a Linux-világot.

    A szavak amiket keresel a mime, meg az "inode/directory=" meg ilyen egyszerű dolgok. Az hogy nem értesz az alap dolgokhoz sem nem az én problémám. Az sem hogy hatalmas a pofád ennek ellenére. És még kibaszott agresszív is vagy. Ez szerencsétlen anyádék és a kollégáid problémája. Meg az embereknek, akik kénytelenek egy ekkora faszkalapot elviselni. :)

    write-only kis bogaram: "hogyan lehet tetszőleges file dialogot használni bármilyen alkalmazáshoz, hogy az open/save dialog feldobásakor az induljon el. Könnyítés: Nekem az is elegendő lenne, ha a GTK2-es jelenne meg a GTK3-as alkalmazásokból, fájl megnyitásakor/mentésekor. " - fent leirtam a megodlast :D

    Felsultel te szerencsetlen hulye! :D

    Szogezzuk le hogy tenyleg nem ertesz semmihez sem. Az olvasas sem a baratod, de akar csak a sima gondolkodas is oriasi kihivas lehet neked. :D

    Nyilvan nem komoly hogy azt hittem van agyad egylatalan :D

    Semmilyen megoldást nem írtál le a GTK3 fájlkiválasztó rekurzív keresésének kikapcsolására. Sem arra, hogy GTK3-as alkalmazásokból a GTK3 fájlkiválasztó helyett más nyíljon meg.

    Ez azért lehet, mert továbbra is képtelen vagy felfogni, hogy nem default file manager-ről (pl. Nautilus), hanem open/save dialogról beszélünk (GTK2/GTK3 File Chooser, File Dialog).

    Felsultel te szerencsetlen hulye! :D

    Jelen pillanatban te vagy a felsült szerencsétlen hülye, mert alapdolgokat és köztük lévő különbségeket is képtelen vagy megérteni.

    További kellemes mitugrászkodást kívánok.

    hat ha nem tudod mi a mime, hol lehet allitani, es mi az az "inode/directory" amit be kell allitani, akkor tenyleg nemtudok segiteni.

    A fenti megoldana a problemadat. Ilyen egyszeruen. Szoval de, megmondtam a megoldast. Mondjuk mivel nincs agyad nem ertetted, meg. Ez nem lenne baj, ha egy szerencsetlen chatbot ertelmevel rendelkeznel es leglabb a neten megnezned, mirol is irtam.

    De nem. :D

    Vannak a chatbotok, vannak az amobak. Te valahol alattuk helyezkedsz el, ha az ertelmi szinvonalat probaljuk ertelmezni nalad, bar ez a te esetedben csak filozofiai kerdes,mert egyszeruen ertelmezhetetlen az ertelem fogalma veled szemben. :D

    Introduction

    KGtk is a quick-n-dirty HACK to allow some Gtk2, and Gtk3, applications to use KDE Frameworks 5 file dialogs.

    KGtk is composed of the following pieces:

    1. An application called kdialogd5. This is the KDE app that will show the file selector.
    2. LD_PRELOAD libraries that are used to override the Gtk2 and Gtk3 file dialogs.

    https://github.com/sandsmark/kgtk

    Nem tudom, hogy sírjak-e vagy nevessek. Ez rosszabb, mint a gtk3-typeahead patch és rebuild.

    Tehát, neked sincs, a framework által támogatott megoldásod, ezzel burkoltan elismerted, hogy a Red Hat arrogáns módon, önkényesen tiporja lábbal a felhasználói szabadságot.

    Szabadon forkolhatod a régit, és építhetsz belőle saját buildet. Azt meg, hogy a GTK3 merre megy, azt szerencsére nem a hozzád hasonló "nem kell fejleszteni csak támogatni örökké" szakmailag totálisan inkompetens alakok mindják meg. Az, hogy te "kettőt hátrébb lépve" nem bírod átlátni a dolgokat, az összefüggéseket, azt, hogy mi miért van, mi miért úgy van, ahogy azt az adott projektben eldöntötték, és csinálják, az nem az adott fejlesztő, illetve fejlesztői kör hibája vagy hiányossága.

    Neked egyébként mit jelentene a szabadság ezen a téren? Mert eddig úgy tűnik, hogy az, ha te fújhatnád mindenütt _is_ a passzátszelet, merthogy szerinted mindenki más idióta és nem ért ahhoz, amit csinál.

    "nem kell fejleszteni csak támogatni örökké"

    Ha a "fejlesztés" nem hozná magával meglévő komponensek visszafejlesztését, a lebutítást és a felhasználói szabadság lábbal tiprását, akkor nekem se lenne bajom vele. A GTK3-ba újonnan belefejlesztett képességek (pl. HiDPI támogatás) nem indokolják ezeket. Sem azt, hogy tabletet csinálnak egy olyan desktop felületből, amit senki nem használ tableten, de még érintőképernyőn is max. az 1%.

    szakmailag totálisan inkompetens alakok

    Relatív, kit tekintünk annak. A Red Hat mérnökei UX szempontból biztosan inkompetensek, de az open-source közösséggel való együttműködésben is.

    Az, hogy te "kettőt hátrébb lépve" nem bírod átlátni a dolgokat, az összefüggéseket, azt, hogy mi miért van, mi miért úgy van

    Ahhoz, hogy átlássuk, előbb meg kell indokolni. A Red Hat nem adott értelmes indokot a rekurzív keresés kikapcsolhatatlanná tételére. Csak fillérbaszó, idealista közhelyeket. Én adtam szakmai érveket, miért problémás a rekurzív keresés kikapcsolhatatlansága. Ha nekem nem hiszel, megannyi érvet olvashatsz ellene a mellékelt bugreportokban.

    https://gitlab.gnome.org/GNOME/nautilus/issues/244
    https://gitlab.gnome.org/GNOME/nautilus/issues/1157
    https://gitlab.gnome.org/GNOME/gtk/-/issues/627
    https://gitlab.gnome.org/GNOME/gtk/-/issues/839
    https://github.com/telegramdesktop/tdesktop/issues/2411
    http://archive.is/wip/ayEa7
    http://archive.is/wip/WHjXK
    http://archive.is/wip/HNkJG

    Amiket érdekes módon struccpolitikával ignoráltál - mint általában mindent, ami a multikat kritizálni meri.

    Neked egyébként mit jelentene a szabadság ezen a téren?

    A rekurzív keresés kikapcsolhatóvá tétele - ha eddig nem jöttél volna rá.

    "A rekurzív keresés kikapcsolhatóvá tétele" - megcsinálod a patch-et, buildelsz saját verziót, és örülsz. Ugyanis szabadon megteheted. Vagy ha nem tudod, mert nem vagy megáldva ilyen szintű tudással, akkor keresel valakit, aki meg tudja csinálni, és meg is csinálja neked.

    Ez már nem felhasználói szabadság. Felhasználói skillekkel ezt nem tudod megcsináni.

    Mindig ott van a lehetőség, hogy multiék szarát te lapátold el, tízezrezredannyi erőforrással és lehetőséggel, mint amennyi egy millirádos nagyvállalatnak megadatik. Ezt én nem is vitattam.

    Azt állítottam, hogy amit művelnek a korábban hosszú évekig ott lévő és problémát nem okozó beállítási lehetőségek kiszedésével és egy antipattern kötelezővé tételével, az a felhasználói szabadság lábbal tiprása, a rendezett mappastruktúrákkal bíró felhasználók szándékos büntetése és a nagyvállalati arrogancia tankönyvi példája. Ezt pedig továbbra is így gondolom.

    Nem megoldást kerestél, hanem össze-stackexchange-eltél egy undorító, gányolt workaroundot a babzsákodról.

    A "picsogásom" pedig nem az undorító, gányolt workaroundod hiánya miatt volt, hanem a Red Hat arroganciája miatt. Ami az undorító, gányolt workaroundod ellenére sem változott semmit.

    Akkor fogod bazmeg a GTK2-es FileChooser dialógot és berakod az undorító GTK3 alá. Senki nem tart vissza! Egyébként meg ha KDE5-öt használsz és azon belül GTK-s alkalmazásokat akkor az egységes FileChooser nem az ördögtől való, tehát nem gányolt és undorító workaroundról beszélünk. Te nagyon művelt faszomöccse!

    haggyad bazmeg! ez tok hulye.

    Leirom neki hogy lehet akarmilyen, de tenyleg barmilyen save/open dialogra cserelni a rusnya gtk3-as hasznalhatatlant, de nem birja felfogni, ignoralja picsog tovabb, hogy de a rekurziv kereses..blahblahblah..rinyarinya...taknyosorr...rinya..blahblah...bruhuhuhuuu.

    Te adsz egy masikat, ami eppeg olyan jo, bar nem stadnard freedesktop megoldas...eeees jon a rinyataknyosorrpicsogpicsog :D

    Fentebb mar megallapitottam, hogy egy darab napon szaradt macskaszar jobban fel tudja fogni mit mondasz neki, mint ez a "kibaszottkiralyvagyokesmindenhezisertek" bohoz :D

    Ja, ha nem érted a felvetést, ha nem tudod megcsinálni azt, amit ott leírtak, akkor jössz a hajbi-féle buzzwordokkal - nagyjából semmit sem hozzátéve a dolgokhoz - de azt elvárod, hogy más valaki oldja meg úgy, ahogy neked tetszik, véletlenül se másképp, belekevered az opensource témát is - ami pont neked is lehetsőséget ad arra, hogy kijavtsd/kijavíttasd azt, ami neked problémát okoz. Igen, ehhez neked is bele kell tenni munkát, időt, meg ha úgy van, akár pénzt is.

    Ha f@szság a merge request, akkor el fogják utasítani, valóban. Viszont megfelelően érvelve, szakmai indokokkal alátámasztva át fog menni a módosítási javaslat - csak ugye -ahogy azt látjuk - neked ezek (megfelelő érvelés, szakamilag alátámasztani a véleményedet) nem mennek...

    És működni is fog - ha meg nem, akkor utánajárok, hol a hiba, bugreport, workaround miegyebek - ezek ugyanis számomra nem ismeretlen, nem ördögtől való dolgok - nem úgy, mint neked, aki mindent, ami nem az, amit te használsz, mindent, ami nem olyan, amit te elképzelsz elfogadhatatlannak és használhatatlannak tekintesz.

    a meg nem, akkor utánajárok, hol a hiba, bugreport, workaround miegyebek

    Majd jön Emmanuele Bassi, megindokolja neked a bugreportban, hogy nekik miért nem éri meg kijavítani, meg amúgy is ez az elvárt™ működés. Ott behúzod füled-farkad, agymosott, profitprotektor lelked szemei előtt megjelenik a "multiknak mindig igazuk van" kikapcsolhatatlan felirat és jönnek a ma is alkalmazott közhelyeid.

    • Efelé halad a világ™.
    • Nem tetszik? Csinálj jobbat!
    • Aki kritizálja, valójában csak elfelejtette™ megérteni™, a nagytudású™ Red Hat fejlesztők miért döntöttek úgy, ahogy.

    Mindezt az Idiocracy Fritojához hasonló lelkesedéssel, aki végül örül, hogy a rendőrök szétlőtték a saját kocsiját.

    ( kikadff v | 2021. 04. 20., k – 12:12 )

    Szerkesztve: 2021. 04. 20., k – 12:17

    Könyörgöm, hagyjátok már hajbazert. Teljesen szétoffoljátok a topicot, pedig érdekel locsemege pipewire blogja. Hajbazert úgyse tudjátok meggyőzni semmiről, el van a saját világában, hagyjátok figyelmen kívül. Magával úgyse fog commentelgetni. 

    Köszi. Én csak azért nem mertem szólni, mert az elején én is belementem ebbe a vitába és nem lettem volna következetes.

    Hogy ontopic legyek: manapság, 0.3.25 óta nem csinálok napi szinten build-et, mert életre tudom kelteni a bluetooth-t és olyan buffer hiba sincs, ami korábban zavart. Ugyanakkor belefutok még hibákba, furcsa viselkedésbe. Például tegnap bluetooth csatlakozáskor elhasalt a bluez daemon, magával rántotta a blueman klienst, majd automatikusan újraindultak, de a pipewire erről nem tudott, így a pipewire-t manuálisan, a systemctl paranccsal kellett újraindítani. Utána működött minden szépen.

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

    Arch-on ma lőttem be a bluetooth-os headsetet Blueman segítségével. Gyönyörűen hibátlanul működik, anno pulseaudio-val is próbáltam életre kelteni, érdekes módon anno nem sikerült.

    Nekem semmi bajom vele.

    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.

    "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

    Erősen függ attól, mi az az eszköz, amelyhez bluetooth-on csatlakozol, meg attól is, mi a pipewire-t és bluez-t futtató gépen a bluetooth interface. Sőt, különféle codecekkel is lehet kódolni a hangot, aztán abból is jön egy mátrix, melyik hardware és software komponens melyiket ismeri.

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

    A vicc, minden ugyan az, csak a pulseaudio lett pipewire-re cserélve. Eddig nem volt vele hang, most lett vele hang. Pipewire jó, megtartjuk.

    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.

    "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

    Tényleg nyithatnál új blogot a témának, mert érdekes. Itt már nagy a khmmm... zaj.

     

    Ja és köszi a múltkori válaszod, hogy hogyan nézki nálad az audio. A korábbi bejegyzéseid alapján bonyolultabbnak gondoltam (azt hittem, 1 gép és az összes lukába be van dugva valami erősítő, BT, hangszóró, mikrofonok, stb. és ezért örülsz most ennyire a PW-nak) :)

    Nem bonyolult a helyzet. Elég lenne a pulseaudio is, ha képes lenne megugrani azt, hogy nem produkál rendszeresen buffer underrun-t, majd emiatt nem zárná le a kapcsolatot, ami miatt nem szakadozna az érthetetlenségig a VoIP kliens hangja. Meg az sem volna baj, ha a pulseaudio nem vinne el számottevő CPU időt egy 4 magos 3.2 GHz-es processzorból. A pipewire ezeket megugorja, ezért is szerettem bele. Meg azért, mert mindenféle audio interface-e van. Jack, alsa, pulse.

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

    Elszabadult volna? Hajbazer elmondta a véleményét és a projekt egy lehetséges, ráadásul igen valószínű jövőjét a Red Hatnál, a nullapontverziós lelkesedési ciklus után. Amire fősodratú fejlődésmániás lépjtovábbok, multimosdatók, profitprotektorok és mindenjóahogyvanok reagáltak. Ezt követték viszontválaszok és ebből kialakultak viták.

    Én speciel azzal kezdtem, hogy hozzászóltam, a pipewire-höz, a projekt jövőbeni kilátásait ecsetelve. Az, hogy ezt a multibuzi szemellenződ és a nullapontverziós lelkesedésed mögül nem vagy képes látni, nem az én szegénységi bizonyítványom.

    Egyébként nem kell játszanod a kussoltatót, ha már korábban adtad a konformista, megalkuvó huput és nem mertél csitítani, mert féltél, hogy fősodratúék álszentnek néznek majd.

    Úgy gondolom, hogy itt egyedül Kikadff Mérnök Úr látja jól a dolgot. Amit akartam, elmondtam. Ha nem érkezik viszontválasz vagy további kötekedés fősodratúék részéről a kommentjeimre, én se fogok többet válaszolni.

    Senki sem nézi semmilyen fősodratú babzsákfotelnek az itt beszélgetőket. Egyetlen hülyegyerek van a vidéken, akinek mivel nincs agya, így felfogása sincs. Igazából te a legrosszabb típus vagy, a beképzelt tudatlan erőszakos idióta. Mondanám, hogy de mi így szeretünk, de nem igaz. Egy ideig lehetett rajtad röhögni, de most már csak fáj nézni a vergődésed közben előkapott hülyeségeket, amiket biztos a hűtődre ragasztottál. 

    És már rég szóltunk hogy nem vagyunk kíváncsiak arra, ahogy a híg fős ömlik az agyadból. De hát ezt sem fogtam föl. ;)

    Igen, és továbbra is úgy gondolom, ahogy ott leírtam. A kimaradás multiék spúrkodásának volt köszönhető, az extraprofit érdekében.

    úgy hogy senki nem reagált rád

    Elmondtam a véleményem, amihez pont annyi jogom van, mint a nyugatnyaló, multimosdató, profitprotektor sleppnek, aki mellett most felszólalsz. Utána viszont, hogy senki nem reagált, érdekesmód nem kezdtem el magammal kommentháborúzni és nem is írtam oda többet. Nem zörög a haraszt, ha nem fújja a szél.

    Nem álltam én senki mellé. Csupán annyit jegyeztem meg, hogy tök gáz. Amikor 2 lépésből fullba tolod a kretént.  Nem esett még le úgy látom. Hogy nem a véleményed gáz. Hanem az eszközkészlet, amivel kinyílvánítod.

    Markos-Nádas-Boncz jelenet meg van? Amikor Boncz Géza csak annyit szólt be periodikusan, hogy Imperializmus.

    Az mondjuk vicces volt, még most is az.

    Hogy neked nem tetszik az eszközkészlet, az egyéni szociális problémád.

    Nekem sem tetszik az eszközkészlet, ahogy a legtöbb multi próbálja rávenni a nagyérdeműt pazarlásra, túlfogyasztásra, vagy hogy mindenképpen az ő szutykát vásároljuk meg.

    Vagy beszélhetnénk a te eszközkészletedről is, hogy idejössz engem szánalmasozni, kreténezni, ahelyett, hogy engedelmeskednél a pipewire-fanok kérésének és lekopnál, mondjuk elsősorban rólam.

    a legtobb multinak es itt irogatonak messze nagyobba a szokincse mint neked. Es ez igaz a tudasukra es az intelligenciajukra is. Figyi mindenki szembe jon veled az autopalyan. :D

    Ertem en hogy messias szindromad van, de ez nem azt jelenti hogy te vagy a messias, hanem hogy csak egy tokkelutott idiota :D

    Es tenyleg bebizonyitottad, hogy annyi affinitasod van a technologiahoz (nem, nem csak az informatikahoz, hanem ugy alatlaban a technologiahoz), mint egy veszett borznak a zen buddhizmushoz. :D

    Ertem en hogy azt a keves tudast amivel rendelkezel es azt a szivoszalat amin keresztul a vilagot latod a teljes kepnek gondolod, de nem az. Es ezen az sem valtoztat, hogy eroszakos kreten vagy. Attol a vilag nem valtozik a szivoszal vegen. :D

    Figyi mindenki szembe jon veled az autopalyan. :D

    https://a.te.ervelesi.hibad.hu/kozvelekedesre-hivatkozas

    Egyébként meg nem jön velem mindenki szemben az autópályán. A Red Hat itt is taglalt bűnei még sokaknál kiverték a biztosítékot. Látszik, hogy fogalom nélkül igyekszel itt az ügyeletes megmondóembert játszani, aki majd jól beszól. Kár, hogy semmit nem ér.

    messias szindromad van, de ez nem azt jelenti hogy te vagy a messias

    Majd pont te leszel az, aki megmondja, hogy ki a messiás. Ha már bibliai hasonlatokat hozol, jelenleg egy utolsó szar farizeus, korlátolt, arrogáns bohócként viselkedsz.

    ezen az sem valtoztat, hogy eroszakos kreten vagy

    Azzal vagyok erőszakos kretén, aki megérdemli. Például a magadfajta, fogalmatlan beszólógépekkel, akik konkrétumok és érvek nélkül nélkül oltogatnak másokat, csakmert a fősodortól eltérő véleményük van és felhívták a figyelmet egy multik által kreált, sokakat érintő problémára.

    "még sokaknál kiverték a biztosítékot" - Mégtöbbek pedig a pénzükkel szavaztak/szavaznak.  Mondom: ha annyira sokan vagytok, akkor gondolom össze tudtok fogni, és csinálni egy systemd-gtk3-pipewire-mindenmiredhat mentes disztrót, alkalmazásokkal, supporttal, midnezt úgy, hogy mindenki hobbiprojektként kezeli az egészet, otthon, a konyhaasztal alatt duruzsoló tizensok éves 64 bites procit használó gépen fejlesztgetve...

    "Például a magadfajta, fogalmatlan beszólógépekkel" - Bagoly mondja...

    Nem a tapicskoló felületűre silányított Nautilusról, amiről te. Hanem a GTK3 fájlkiválasztó ablakról. Ahol továbbra sincs lehetőséged kikapcsolni a rekurzív keresést. Ezt a bugreportokban tisztán és világosan leírták. Elég szörnyű, hogy beálltál a fogalom nélkül multibuziskodó birkasorba.

    Hanem a GTK3 fájlkiválasztó ablakról.

    Arra gondolsz ami a fájlok mentésekor/megnyitáskor GTK-s alkalmazásokban megjelenik? Pl a firefoxban a CTRL+O? Az is ugyanazt a beállítást használja. (Vagy a nautilus a GTK-sat). Szóval de ott is átáll, arra is hatással van.

     

    Ezt a bugreportokban tisztán és világosan leírták.

    Csak annyit tudok mondani, hogy jelenleg működik ha kikapcsolod és mindkét helyen (a nautilusban és a GTK fájlválasztóban is) azonosan, a beállításnak megfelelően működik.

    Kiscsikó. Korlátolt arrogáns bunkóként te viselkedsz. :)

    Te milliószor bebizonyítottad, hogy semmihez sem értesz. De tényleg semmihez. Az alapokkal sem vagy tisztában. Süt rólad a tudatlanság. Ez nem lenne baj, ha érdeklődő és nyitott lennél, hogy befogadd a tudást, amire nagyon szükséged lenne.

    Böfögöd, hogy babzsák, fősodratú körbe-körbe. Lapozz már egyet a "buzzword-ök Idiótának" könyvefben bazmeg!!! :)

    Ecsém, te vagy fogalmatlan, nem én/mi. Write-only módban pörögsz és még azt is elhiszed érdekel valamit amit mondasz.

    Szánalmasék gyermeke, te. ;)

    Nyugodtan papagájkodhatsz tovább. Attól még, hogy te úgy gondolod, hogy nem értek semmihez, ez nem lesz igaz. Tisztán és világosan leírtam, alátámasztottam a Red Hat arroganciáját, példákon keresztül. Te ezeket kinevetted, elbagatellizáltad, lesöpörted az asztalról. Nyugodtan oltogathatsz tovább, de ugyanúgy te maradsz a szánalmas, igénytelen mitugrász.

    Muhhaaahaha. Se egy babzsák, se egy konzum? Akkor ez nem egy könyv csak egy cetli a hűtődön? 

    Te nem tényekkel támasztottad alá a fatazmagóriád, hanem a hagymázas baromságaiddal, amiktől azt hiszed tények, mert sajna semmit sem tudsz és értesz a világból.

    És nem oltogatlak, csak leírom milyen kis idióta vagy. :)

    Na látod, a fenti egy tény. :) 

    Ízlelgesd a különbséget. :)

    De igen, tényekkel támasztottam alá. [1] Sőt, linkeltem is nagyon sok más, tőlem független tapasztalatot és alátámasztást arra az esetre, ha fősodratúéknak esetleg a személyemmel lenne baja és felveszik a profitprotektor szemellenzőt, ha meglátják a nevemet.

    És nem oltogatlak, csak leírom milyen kis idióta vagy. :)

    Mondom, nyugodtan személyeskedhetsz és szitkozódhatsz tovább a szokásos szmájlizós mitugrász bohóc üzemmódodban. Ezzel egyrészt annyit mondasz el, hogy nem bírod elviselni, ha valaki felhívja a figyelmet multiék arroganciájára. Másrészt, hogy a velem kapcsolatos személyes sérelmeid csak feltűnési viszketegségtől megrészegülve, egy fórumon tudod kifejezni, bunkó, paraszt minősítgetések és beszólások formájában. Továbbra sem az én szegénységi bizonyítványom, hanem a tied.

    A pipewire jelenleg a Red Hat irányítása és ingyendolgoztatása alatt készül, így a Red Hat arroganciája erősen befolyásolja a jövőjét és azt, mennyire járul majd hozzá később a desktop Linux felforgatásához, elsilányításához, ahogy a PulseAudio annak idején.

    ahogy a kutyaszarra sem haragszom, ha belelépek

    Meg feltehetőleg nem is érzel kényszert arra, hogy beszélj hozzá.

    Ha nem lenne személyes sérelmed velem kapcsolatban, akkor nem mitugrászkodnál viszontválaszokban, hanem érdeklődnél a pipewire-ről. De téged nem érdekel a pipewire, még annyira sem, amennyire engem a Red Hat-nál belátható jövője. Te csak azért vagy itt, hogy a másként gondolkodóknak beszólogass. Na, ez az igazi fertőző haszontalanság.

    A siker- és pénzszagot fogott, odacsimpaszkodott, multibuzi helytartók vagy technológiai talpnyalók által irányított disztribúciók, projektek jövője érdekel, ami erősen függ a Red Hat-tól. A Red Hat jövőjét illetően, remélem, hogy hamarosan kivérezteti őket a Microsoft a Linux-os alkalmazások Windows-on futtatásával. Ízig-vérig megérdemlik.

    Én se haragszom, általában nem értek egyet azzal, amit írsz. De kivételesen ebben a Red Hat témában egyetértünk. Én is utálom őket, tipikus corporate multi, a profithajhászásával, bloatjaival, öltönyös-nyakkendős jogászkodással és menedzserséggel. De ugyanez a véleményem a többi multiról is, Oracle, Google, SUSE, stb.. Ezek marha sokat ártanak a Linuxnak, hogy tolják bele a szutykaikat, és Windowst csinálnak az egészből. A Linuxban pont az kéne, hogy jó legyen, hogy sok kicsi, független fejlesztő, próbálnak csak technológiai érdeklődésből, szakmai fejlődésvágyból, tisztán a kódolás-alkotás öröméért fejleszteni, a technológia határait előretolni, és nem a pénzért, profitabilitásért. Így nem érdekük, hogy mindenen jogi meg szutyok DRM védelmek legyen, nem érdekül a bloatosítás, hanem a tisztán technolgóiai fejlődés, hogy a rendszer átlátható, fenntartható legyen, minél kevesebb korláttól mentes. Így pont az lenne a lényeg, hogy egyéni fejlesztők szabadon lecserélhető komponenseit használjuk, és ne ilyen nagy multik egy-megoldás-mindenkinek bloatjait. Az már van Mac-en, Windowson, nem kell Linuxra is behozni.

    De az is igaz, hogy sok minden nem csak a multik hibája. Mert pl. Poettering hiába írja a systemd-jét, pulseaudioját, nem kötelező használni. Azok a fejlesztők, akik önként erre dependelik rá a szoftvereiket, és emiatt elkerülhetetlenek ezek mindenkinek. Pedig egy jó linuxos opensource szoftvernek megint annak kéne legyen a fő, hogy minél kevesebb függősége legyen, minél jobban lecserélhető komponens, és választási szabadságot adjon, hogy ki mit használ, milyen komponensekből építi fel a rendszerét. Sőt, a legjobbak arra is figyelnek, hogy a szoftverük teljesen szabadon portolható legyen, lefordítható legyen nem x86 platformokon is, BSD-n is működjön, semmi Gtk, Qt hegyekre, se systemd-re, se PA-ra, se Bash-ra, se semmi kifejezetten Linux-specifikus dologra ne dependeljen, ami gátja lenne a portolásnak, használhatóságnak. És ezt általában nem is nehéz elérni, nem nagy fejlesztési munka, általában csak némi bölcsesség és előrelátás kérdése. Így minél szélesebb réteg tudja használni a szoftvert, meg elfut régi, gyenge gépeken is, stb.. Így lesz igazán univerzális, ez adja az erejét az egyszerűsége mellett.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    ^ Summon Polesz. A baszogatásom meg a pszichiáterhez küldözgetésem helyett végre bevédheted kedvenc "vágyálmos" disztródat.

    Kb. ott tartana ma, ahol tíz évesen tartott.

    Klasszikus multibuzi, korporatokrata FUD és a közösségi projektek, fejlesztések lenézése, semmi több. Példának okáért, a közösségi alapon, nem vállalati kézivezérlés alatt elkészült GNU toolkitek rendkívül sokat tudtak fejlődni 10 év alatt is, meg azóta is.

    HURD-ot a szónoknak! Szeritned közösségi alapon, otthon, szigorúan a hokedlin és a konyhaasztal sarkán, a családtól kapott 1-2 órányi szabadidőben hobbiprojektezve meddig jutna egy-egy projekt? És mekkora lenne a _garantált_ válaszidő egy-egy hibajelentésre? Mekkora lenne a tesztelési kapacitás? mennyire lenne széleskörű a hardvertámogatás és annak a tesztelése? Kinek lenne otthon hobbiprojektben enterprise-grade eszköze? Mondjuk valami méretesebb tárolótömb, izmosabb FC adapterekkel, meg 2-4 vagy több node-dal a tömbre akasztva, de mondhatnék akár RAID vezérlőket vagy épp 10Gbit-es vagy gyorsabb hálózato adaptereket meg switcheket...

    Ja, és ugye valaki nagyon nyomja, hogy sw-t is csillió+1 évig kell támogatni... Egy sokéves hobbiprojektet ki fog támogatni? garantált válaszidőkkel? Sőt ki fog üzletileg kritikus funkciót rárakni olyan rendszerre, ami mögött hobbiprogramozók állnak _csak_ és kizárólag?

     

    https://a.te.ervelesi.hibad.hu/allito-kerdes
    https://a.te.ervelesi.hibad.hu/allito-kerdes
    https://a.te.ervelesi.hibad.hu/allito-kerdes
    (...meg még egy párszor..)

    Amíg ilyen szélsőségesen vélekedsz azokról a projektekről, amik mögött nincs kötelezően legalább egy multi egy márkanévvel és egy logóval, addig nincs értelme válaszolnom a kérdéseidre. Kicsit vegyél vissza a kisemberellenességedből, a pénzszaglászásból és a kizárólag két végletben való gondolkodásból.

    Jó ha tudod, viszont:

    • Attól még, hogy egy cég (akár egy multi) bedolgozik egy projektbe, az nem lesz általa kézivezérelt projekt. Kivéve, ha tudatosan és arrogáns módon törekszik erre. Ahogy a Red Hat ezt teszi már vagy 10 éve.
    • A Debian, közösségi disztró az, amelyik a legtöbb hardveren támogatott a népszerűbb Linux-ok közül.

    Senki nem beszélt pénz nélküli linuxos világról. Multik kézivezérlése nélküli Linux-világról beszéltem. Persze, nyugodtan multibuziskodj tovább. Az egyetlen út mindig Rómába a multikhoz vezet. Legalább is, az amerikai jólétet hazudó reklámok, divatblogok és tech-influenszerek álomvilágában, amik alaposan megbolondították a tudatod.

    Multik pénze nélkül nincs "linuxos" pénz.

    Nem a multik hibája, hogy a közösség hagyja dróton rángatni magát.

    Még nem multibuziskodtam, de annyiszor hallom újra és újra – mint valami kikapcsolhatatlan reklámot –, hogy kicsit kezdek kíváncsi lenni, milyen élmény lehet.

    A "linuxos" közösség "megveszi", amit a multik kínálnak neki. Nem az én véleményemen, világlátásomon múlik, hogy a "linuxos" közösség folytatja-e a kurvulást, így hiába bombázol engem az anti-multi "reklámjaiddal", csak pocsékolod az értékes erőforrásokat.

    :)

    Multik pénze nélkül nincs "linuxos" pénz.

    Egyrészt, de, van. Lásd open-source körökben népszerű adományozás. Másrérszt, nem azt mondtam, hogy a multiknak egy fillérrel sem kéne hozzájárulniuk semmilyen open-source projekthez. Azt mondtam, hogy nem kéne felforgatni, kisiklatni, vagy megpróbálni eltéríteni azokat. Lásd SuSE egyidős a Red Hattal, mindig is multi kezében volt és kibírta anélkül, hogy a saját megoldásait (pl. YaST) lenyomkodja a teljes Linux fejlesztő- és felhasználóközönség torkán. Lehet konstruktívan is hozzájárulni a közösségi projektekhez. Ez az, ami a Red Hatnak az utóbbi 10 évben (nagyjából RHEL 6 óta) egyre kevésbé sikerül.

    Nem a multik hibája, hogy a közösség hagyja dróton rángatni magát.

    Igen, gondoltam, hogy hamarosan az áldozathibáztatás is előkerül. Végül is, nem™ a te hibád, ha megzsarolnak és engedsz neki, nyilván nem™. A zsaroló csak a munkáját™ végzi.

    A "linuxos" közösség "megveszi", amit a multik kínálnak neki.

    Ezt abban a párhuzamos univerzumban veszem be, amiben egy közösség konszezussal, egyöntetűen jelenti ki, hogy systemd-vel, pluseaudio-val sokkal jobb, mint nélkülük. Mert ebben az univerzumban nem ez történt.

    Igen, gondoltam, hogy hamarosan az is előkerül™, hogy a multi csak fizessen és kussoljon, esetleg be is nyalhat (már ha a közösség képes eldönteni, melyik projektek segge nyalandó, és melyeké túl szaros), és ne nézze a saját érdekeit. Gondolom, hamarosan az is előkerül™, hogy ne a multi mondja meg, szerinte mi az érdeke, hanem majd a közösség eldönti (és a multi érezze kegynek, ha a közösség hajlandó felajánlani neki nyalandó seggeket).

    :)

    Nem nagyon tartana hátrébb, mint most. Nyilván, ha driverekről van szó, akkor kell a multik közreműködése, de nem a technikai szint miatt, hanem a hardverük ügye zárt, és csak ők tudnak drivert írni hozzá. Pl. ezen a szinten hasznos, ha csak valamihez ilyen konkrét drivert vagy megoldást nézünk, nem ilyen általános, Linux egészét átszövő megoldást. Meg pl. a Valve is sokat hozzátett a Linux gaminghez. De! Ennek ki kéne merüljön ebben. Ilyen systemd-re, pulseaudio-ra a lőtéri kutyának nem volt szüksége. Ilyen Electron-alapú szutykok se kellenének. Ilyesmikre gondoltam.

    Szerintem ez a Pipewire némileg pozitív lépés a Pulseadio után, de még mindig nem a legjobb, ami lehetne. Az az lett volna, ha az ALSA-t viszik tovább, és kibővítik annak a hiányosságait. Meg mint mondtam, egymagában még a corporate megoldások létezése se baj, ami baj van velük, hogy sok idióta fejlesztő ezekre dependeli a szutykait, azon a ponton bukik az egész. Mert ha a systemd, PA opcionális lenne teljesen, nem dependelne rá semmi, akkor teljesen önkéntes alapon menne a használata, akinek tetszik feltenné, akinek nem, az használna helyette mást. De így, hogy minden dependel ezekre, így mindenki az arcába kapja.

    Szóval igen, a multik tudnak előrelépést is jelenteni a Linuxnak, de ezzel mindig óriási hátránnyal is kell fizetni. A jobbik véglet az lenne, hogy tartson csak ott, ahol 10 éve tartott. Nem lenne jó, de talán jobb lenne egy kicsivel.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    "tartson csak ott, ahol 10 éve tartott. Nem lenne jó, de talán jobb lenne egy kicsivel" - Jó lenn eálmodozni arról, hogy komplett üzleti infrastruktúra Linuxon fut... Mert ugye ha "kivesszük a képből" a fejlesztésekbe pénzt és emberi erőforrást toló cégeket, hát... Nagyon kevés, moondhatni alacsony használati értékű csontváz maradna - jóval több, mint 10 évnyit visszavetve a Linux és köré/rá épülő szoftveres környezeteken. (Hint: nézz utána, hány mérnökévnyi fejlesztést tolt bele egy-egy nagyobb kontributor cég a Linuxba és a kapcsolódó szoftverekbe, és saccold meg, hogy hobbiprojektként, nem munkaköri feladatként mennyi idő kellene hozzá, hogy hasonló mennyiségű munkát valakik megcsináljanak - gyakorlatilag ingyen.)

    A céges forrás nem ahhoz (nem csak) kell, hogy xyz eszközhöz kernelmodul készüljön, hanem ahhoz (főleg ahhoz!), hogy azt kellő mértékben teszteljék, legyen tesztkörnyezet a hardverhez, és integrációs teszteket is megcsinálják valakik valahol - na ez már pont nem a drivert író céges fejlesztő és nem az otthoni hokedlis hobbiprogramozó szintje/feladata.
    De ahhoz is kell bőségesen céges erőforrás, hogy az adott szállító/fejlesztő cég termékeivel való kompatibilitás meglegyen, azt folyamatosan biztosítani lehessen - nem véletlen, hogy nagyobb céges szoftverei például Debian vagy Ubuntu környezetben "not supported" kategóriába tartoznak.

    Az "ALSA-t kellett volna..." - van az az állapot, amikor érdemes egy régi kódot tovább gyurmázni, és van, amikor célszerűbb a célokat áttekintve kvázi nulláról újraalkotni az adott feladatot megvalósító motyót. Ez részben szakmai, részben üzleti döntés (melyik kerül kevesebbe) - ilyen mélységig a feature-ökbe és a tervezett roadmap nézegetésébe nem mentem bele. Ahol próbáltam (egy tartalék tartalékjaként desktopra használt kölcsön nodebook, valamilyen Debian-nal), ott "szólt minden", nem mélyedtem bele jobban - amire nekem kell, arra első bilkkre jó, innentől nem érdekel a bit- és kódmaszírozás része - ha ez lesz a következő release-ben a default, akkor ez kerül fel, ha nem, akkor nem.
     

    A céges forrás nem ahhoz (nem csak) kell, hogy xyz eszközhöz kernelmodul készüljön, hanem ahhoz (főleg ahhoz!), hogy azt kellő mértékben teszteljék, legyen tesztkörnyezet a hardverhez, és integrációs teszteket is megcsinálják valakik valahol

    Vagy épp ne csinálják, mert ahhoz is túl milliárdosok.

    https://gitlab.freedesktop.org/libinput/libinput/-/issues/235

    Itt például a Red Hat szélsőségesen idealista, kivénhedt babzsákfejlesztő arroganciahuszára arról ír, hogy bár arra volt idő, hogy a synaptics helyett újrafeltalálják a kereket, hogy az input réteget is korporatokrata módon kisajátítsa magának a Red Hat (libinput), de arra már nincs, hogy minden korábban támogatott feature és hardver funkciója továbbra is támogatva legyen. Még akkor sem, ha továbbra is készülnek olyan új laptopok, amikre kéne.

    Elsőként jön a tesztesetekkel, amiből már sejthető a későbbi hozzáállása. [1]

    FTR, this would require a full implementation and test cases for all combinations.

    Később bedobja a fejlődésmániás, elavulásos lózungot, arra számítva, hogy ha 4-5 évesnél a laptop, azt már nem kell támogatni. [2] Érdemes inkább kidobatni és újat vetetni helyette, természetesen kizárólag a szoftveres hiányosságok miatt, amit ők teremtettek meg.

    Quick google shows the Panasonic CF-SX3 is 4-5 years old by now? Do we have any more recent examples for circular touchpads?

    Végül elismeri, hogy bár vannak bőven új laptopok, amiket körkörös scrollozásra tervezett érintőpaddal szereltek, de az újrafeltalált kerékkel (libinput) ezeket támogatni már senkinek™ nem™ lesz™ ideje™. [3]

    it's not related to HW age, @SF6 showed that there are recent laptops with circular touchpads. It's a matter of someone finding the time to implement this feature and driving to get it accepted upstream and in the various compositors. It's not something I have time for (or, to be perfectly honest, motivation).

    Újabb jó példa arra, hogyan silányodik, szegényedik el a szoftveres környezet a multik kézivezérlése alatt.

    A libinputtal nagy baj nem lenne, csak az, amit írsz, hogy a mai napig nem támogat sok olyan feature-t, ami laptopokra kell, és a Synaptics támogatta. És nem csak 4-5 évesnél régebbi laptopon, hanem teljesen újakon is, sőt, azokon igazán, mert azokról általában már le van hagyva a dedikált touchpad gombsor, így muszáj olyan gesture-ökre támaszkodni, mint több ujjas görgetés és kattintás, amit csak a Synaptics driver támogat normálisan, mert a Red Hóttnál a mai napig lusták beleintegrálni a kódba a régi nyílt forráskódos megoldást (amiben a kód már meg van írva, tehát nem is kéne a 0-ról kezdeni).

    Szóval ja, a Red Hetet utáljuk szívből. Csak sokra nem megyünk vele, mert pl. Pöttyering Nyomingerre is hiába esne rá egy zongora, 10 emelet magasból, a corporate vezetés azonnal dedikálna a hülyeségek fejlesztésére egy másik „babzsákfejlesztőt” (ezeket Luke Smith soydev-eknek csúfolja), aki semmiben nem lesz különb, csak máshogy fogják hívni, és minden menne tovább ugyanúgy. Pont ez a baja a multigépezetnek, végtelen erőforrás, megállathatatlanok, hülyeségben is.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    nem véletlen, hogy nagyobb céges szoftverei például Debian vagy Ubuntu környezetben "not supported" kategóriába tartoznak

    Nem véletlen, hanem szándékos spúrkodás a milliárdos multik erőforrásain. Vagy épp kartellezés egy másik multival, hogy csak az ő platformja legyen támogatott, ha népszerű alkalmazásról van szó.

    Milyen sérelmem lehetne egy retardálttól? :)

    Maximum szórakoztató, de súlytalan bohóc vagy és néha átmész erőszakos idiótába.

    A kétszavas szokincseddel, meg nehéz veled vitába szállni. Olyan lenne, mint a relativitáselméletet egy magát éppen a saját végtermékével kenegető majomnak magyarázni. :)

    Ahhoz, hogy bármilyen mértékben komolyabban foglalkozzam a böfögéseiddel, mint a kosszal az cipőmön, minimális értelemmel kellene rendelkezned és legalább egy óvodás szokincsével. :)

    Ez is mutatja, hogy többet képzelsz magadról, mint ami valójában vagy. :)

    Hát az értelmi színvonala egy növény alatt van valahol. :)

    Láttam már intelligensebb chatbot-ot, aminek nagyobb volt a szókincse és választékos abban beszélt. Ő az élő példa arra, hogy néha a minimál AI is túlnőhet az emberen. :)

    Bár az ő esetében, egy sima véletlen generátor által adott random zagyvaság is Shakespeare-i magasság lenne.

    ( locsemege v | 2021. 04. 22., cs – 12:37 )

    Szerkesztve: 2021. 04. 22., cs – 12:39

    0.3.26

    38 perce van a commit a repóban, én már használom. :)

    Fedorához.

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

    ( dragi v | 2021. 04. 22., cs – 21:17 )

    Felraktam én is a 0.3.25-t (gentoo). Működik jól. Kérdés, bluetooth codeceket ti mivel állítgatjátok?

    Én a 0.3.26-ot raktam fel Arch-ra, ezúttal már Pulseaudio helyett. Semmi bugot nem vettem észre, eddig ugyanúgy működik minden. RAM fogyasztás nem változott, de a CPU terhelés kb. a felére esett vissza, ami eddig tetszik. Igaz még nem teszteltem eleget, és az én felhasználásom amúgy is elég minimalista, semmilyen streameket nem keverek, nem használok audio editor programokat, sem bluetooth-t, így négyzetesen kisebb is az esélye, hogy bármibe is belefuthatnék, de ki tudja. Ez csak hosszú távon dől el. Mindenesetre eddig tetszik, annak alapján, amit eddig tapasztaltam. Másnak is javaslom, hogy ha túl spéci felhasználása nincs, akkor nyugodtan meglépheti a váltást, nem kell tőle tartani.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    ( kikadff v | 2021. 04. 24., szo – 16:24 )

    Leiratkozás. Erre már nem vagyok kíváncsi.

    Locsemege, esetleg fontold meg, hogy ha van valami új, érdekesebb fejlemény a pipewire körül, akkor annak nyitsz egy új blogot. Ez már amúgyis nagyra nőtt, meg eléggé szét lett offolva.

    Ironikus, hogy először attól félsz, hogy álszentnek néznek, majd utána beleszállsz a vitákba, bevédve multiékat és a nekik való megalkuvásod, később kicsúszik a kezeid közül a saját topicod irányítása, aztán szól valaki, hogy hagyjanak engem békén, mert magammal úgyse fogok vitatkozni, amivel egyet is értek. Végül a fősodratú mitugrászaid képtelenek erre és csodálkoznak, ha jön a válasz a további multimosdatásra, profitprotektorkodásra, személyeskedésre, idiótázásra, lehülyézésre.

    Arra az esetre, ha a sorozatos töketlenkedésed után az apucinak árulkodás sem hozná az elvárt eredményt, megcsináltam a PipeWire-szkeptikus topikot.

    PipeWire - Még egy újrafeltalált kerék a Red Hattól

    Bármelyik hozzászólásomra érkezik válasz ezután ebbe a topikba, azt én már csak ide fogom megválaszolni. Az elvarratlan szálakat átirányítottam, ahol tudtam.

    Az, hogy hajbazer idejött, és szétbarmolta ezt a topicot, nagyon nincs rendjén. Az elején türelmesen válaszoltam, gondoltam, ki-ki elmondja a véleményét, és nyugvópontra kerül a dolog. Tévedtem, mert elkezdte a végtelenségig hajtogatni az offtopic sirámait, amelynek semmi köze a pipewire-hez, illetve akkor is érti mindenki, ha egyszer mondja el, de ő végtelen ciklusba került.

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

    Van egy lényeges különbség a te offolásod és máséi között. Más a jó ízlés határán belül tette ezt, néhány hozzászólás erejéig, ezzel szemben te képtelen vagy elhallgatni, ugyanazon pörögsz a végtelenségig. Teszed ezt annak tudatában, hogy talán sejted, egyikünk sem a Red Hat vezérigazgatója, de még vele sem itt kellene vitatkoznod.

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

    Más a jó ízlés határán belül tette ezt

    Aha, mert jó ízlés a szánalmasozás, a folyamatos lehülyézés, idiótázás és a folyamatos személyeskedés azért, mert más a véleményem egy arrogáns multiról, mint a fősodornak. [1] [2] [3] [4] [5] [6] [7] [8]

    ugyanazon pörögsz a végtelenségig

    Ahogy fősodratúék is a végtelenségig profitprotektorkodnak. Azzal érdekesmódon semmi bajod nincs, bármennyire is off vagy személyeskedő hozzászólások.

    Az elején türelmesen válaszoltam, gondoltam, ki-ki elmondja a véleményét,

     

    Na jó, de nála pontosan lehet tudni, hogy igazi troll, az tartja életben, ha valaki valamiért komolyan veszi. Nem szabad. Úgy kell kezelni, mint egy hisztis 3 évest. Verje magát nyugodtan a földhöz, aztán amikor rájön, hogy senkit nem érdekel, akkor majd abba hagyja és más szórakozás után néz. Tényleg nem értem, miért eteti itt még bárki is.

    Verje magát nyugodtan a földhöz, aztán amikor rájön, hogy senkit nem érdekel

    Nem verem magam a földhöz, ha senkit nem érdekel, mert nem vagyok hisztis hároméves, ellentétben néhány fősodratú elemmel itt. Ha senkit nem érdekel, amit írok, akkor esélyes, hogy nem írok többet. Ha valakit érdekel annyira, hogy válaszol, arra fogok reagálni. Erről szól egy fórum.

    Tényleg nem értem, miért eteti itt még bárki is.

    Valószínűleg azért, mert őket is érdekli a téma, vagy ők is látnak abban valamit, amit én a Red Hat-ról gondolok, csak túl szar lenne maguknak beismerni, hogy egy velejéig arrogáns multi gyarmatosította a Linux-világot, így inkább engem próbálnak elpusztítani, aki a kritikát megfogalmazta. Ez a tömegpszichózis egyik klasszikus esete, ráadásul kishazánkban igencsak népszerű, elég csak a viccre gondolni, amiben a magyarok visszarántják, aki megpróbál kimászni az üstből, így nem kell őrizni azt.

    Megtettem helyetted (legalább is, lehetőségeimhez mérten megpróbáltam), amit neked kellett volna: áttenni szépen ezt a topikot a Flame szekcióba, tekintettel arra, hogy a hozzászólasok 80%-a off, utána pedig nyitni egy újat.azoknak, akik csak a PipeWire nullapontverziós lépjtovábbkodásra, mindenjóahogyvankodásra, meg a bioRSSfeedelésedre kíváncsiak.

    Itt pedig láthatod, hogy a fősodratú majmaid ennek ellenére sem képesek leállni. Vagy lehet, hogy őket kellett volna elkussoltatnod először, nem engem. Persze, ahhoz nem voltál elég tökös.

    Maradjunk annyiban, hogy te jöttél ide rombolni. Ez a topic fénykorában szinte kizárólag a pipewire-ről szólt. Leírtam benne a tapasztalataimat, követtem a fejlődését, linkeltem az új release-eket. Nem a topikot kell a flame-be rakni azért, mert te felgyújtottad, hanem a gyújtogatót kell nagyon gyorsan kivágni a fenébe, tűzoltásként pedig a flame szálat törölni. Azzal semmi bajom, ha ezzel megy a levesbe az összes offtopic hozzászólás, így az enyémek is.

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

    Maradjunk annyiban, hogy te jöttél ide rombolni.

    Nem maradunk annyiban, mert ez hazugság.

    a gyújtogatót kell nagyon gyorsan kivágni a fenébe

    Csak a fősodratú majmaid után, akiket továbbra is mosdatsz, pedig szerves részei voltak a flame-nek. Sőt kezdetben te voltál az első szerves része a flame-nek.

    tűzoltásként pedig a flame szálat törölni

    És mi akadálya ennek? Én nem fogom újraindítani itt a flame-et a Red Hat-ról, ezt már egyszer megbeszéltük.

    Azzal semmi bajom, ha ezzel megy a levesbe az összes offtopic hozzászólás, így az enyémek is.

    Akkor hajrá!

    figyi writeonly huylegyerek soroloma tenyeket, amik szerencsere kovethetok a forumban:

    * amig nem jottel ide a topic a pipewire-rol szolt. IO folyamatosan updatelte azzol hol tart a project

    * idebaszott nekunk a joisten egy ilyen szarkupacot mint te es erre elkezdett omleni a fos a topicra

    * IO hibaja az volt hogy mar az elejen nem allitott le hogy huzz a verbe az agymeneseiddel

    * azok akik jobban ismerik a munkassagod (azaz hogy semmihez sem ertesz de tenyleg csak a pofad nagy, mint altalaban a magabiztos hulyeknek) megprobaltak leallitani, de IO meg mindig nem vette eszre magat, hogy veled nem lehet ertelmesen beszelni mert egy orvosi csoda vagy, agy nelkul is kepes vagy elni :D

    Tovabbi tenyek:

    * Senki sem kivancsi rad, de meg ezt sem veszed eszre

    * Nincs szokincsed, de nem evszed eszre

    * Mindeki hulyenek tart, de nem veszed eszre mert a legtobb ember kedves/sajnal....ezek az emberek meg mindig hisznek abban, hoyg az ilyen veglenyeket mint te meg lehet valtoztatni ha konstruktivan allnak hozzajuk. Pedig nem. A te fajtad ki kell baszni a budos picsaba mindenhonnan, mert mergezoek vagytok. Te pedig egy kulonosen haszontalan mergezo fajta irritalo idiota pocs vagy. :D

     

    Engem meg ne idezgess faszkalap agyra-fore, mert meg sem ertetetd miket irtam. :D

    Csak azt nem értem, hogy ha mindenkit zavar hajbazer vagy épp egyáltalán nem kiváncsi rá, akkor miért érez mindenki késztetést arra, hogy állandóan válaszoljon neki. Ebben a topikban is, ahol hozzászól, te is rövid időn belül megjelensz, és szinte minden egyes hozzászólására (egyre gázabb stílusban) válaszolgatsz. Próbálsz erkölcsileg, értelmileg, stb. magasabbnak látszani, de inkább csak mélyebbre kerülsz, mint ahol őt gondolod, hogy van.

    Nem láttam még olyat (bár nem követem minden egyes hozzászólását), hogy saját magának kezdett volna válaszolgatni - azaz ha ráhagynátok (vagy elmentek vele az általa nyitott flame-be), akkor itt nem írogatna tovább. Ez önmérséklet vagy önfegyelem kérdése lenne, de ennek híján vagytok.

    Ebben igazad van, de ugye az első off hozzászólások nekem még beleférnek, akkor még nem érzem, hogy ebből flame és topikrombolás lesz. Állít valami hülyeséget, leírom, hogy szerintem nem így van, amire ő nem áll le, és ez a baj. Ugyanazt a hülyeséget pörgeti. Nem minden alap nélkül egyébként, de ez itt akkor sem a sajnáljuk magunkat, de sz.r a kapitalizmus című topic, hanem a pipewire multimedia sharing szerverről szóló. Ráadásul akkor is értjük, mi a bánata, ha egyszer leírja, továbbá nem vagyok a Red Hat igazgatótanácsában tag, meg műszaki döntéshozó sem.

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

    Nem minden alap nélkül egyébként, de ez itt akkor sem a sajnáljuk magunkat, de sz.r a kapitalizmus című topic

    Nem a kapitalizmus volt kritizálva, hanem a Red Hat szükségtelenül arrogáns hozzáállása. Nagy különbség. Pláne, hogy vannak más szintén kapitalista cégek, akik tudnak tisztességes hozzáállást tanúsítani.

    Szóval nem kell lengetni az antikapitalista kártyát. Amúgy sem vagyok antikapitalista.

    Az assertive kommunikacio szep dolog, ha a befogado felnek megvan hozza az intelligenciaja. Szoval megprobalhatnek ugy kommunikalni vele, de teljesen ertelmetlen lenne. 

    Ez olyan, mintha azt mondnad, hogy egy hizot szepen kerjek meg hogy ne henteregjen a sajat szaraban. Mi nem igy szoktuk intezni, hanem arrebb tessekeljuk a szaros csizmankkal, ami tole lett szaros. Ha kell akkor racsapunk a vasvilla nyelevel is.

    Hajbi egy suket, szaros, veszett vaddiszno. Nem tudsz vele erdemben kommunikalni, csak azon a nyelven, amire erdemes. :D

    De akkor olvasd inkabb vegig a frumt. Normalisn megvalaszoltam a kerdeset erre le babzsakfotelszarozott, hogy nem ertem a kerdest se mert lyan fosodratu vagyok. Ezek utan ugy ereztem valthatok arra a kommunikaciora amit megerdemel. Es nem, nem jelenek meg ott, ahol Hajbi. De azert engedd meg nekem hogy en is olvashassak topicokat. Es igen van ahol ez az idiota szinten ott van es ott is elkezdi osztani az eszt. Ha tudok bokok rajta egyet a vasvillaval ilyenkor :D

    Az assertive kommunikacio szep dolog, ha a befogado felnek megvan hozza az intelligenciaja. Szoval megprobalhatnek ugy kommunikalni vele, de teljesen ertelmetlen lenne. 

    Ahogy az is totál értelmetlen, ahogy unintelligens ősbunkó módjára fröcsögsz és mindeközben azt képzeled, hogy menő vagy.

    Én legalább értelmesen leírtam, linkekkel, bugreportokkal stb. álatámasztottam az állításaim. Te meg végig csak fröcsögtél, az eredeti problémát meg természetesen szőnyeg alá söpörted.

    Oké, én pedig nem vagyok megalkuvó és örömömben tapsikoló a Red Hat újrafeltalált kerekeivel kapcsolatban, ezért elmondtam a véleményem. Amihez ugyanolyan jogom van, mint a fősodratú majmoknak. Azt pedig kikérem magamnak, hogy szétbarmoltam volna. Tartalmas hozzászólásokat írtam, érvekkel, linkekkel, alátámasztásokkal.

    Nincs több jogom, mint bárki másnak, bár talán az egész topicot egyben törölhetem. Ki kellene próbálni, mert lehet, hogy trey azért nem foglalkozik vele, mert lehet hozzászólásonként is. Nyitok is erre egy teszt topikot.

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

    Emlékeim szerint trey válasz nélküli hozzászólást tud/hajlandó törölni, vagy szálat.

    Sérelmez(t)ed, hogy az offolással el lett baszva a topik, mégsem hagytad és hagyod abba az offolást. Eddig úgy állítottad be, mintha fontos lenne a topik, most meg már talán törölni is hajlandó lennél. Fura...

    Én trey helyében semmit nem tennék, ha azt látnám, hogy az offolás miatt rendtételi-kérelmet benyújtó felhasználó offolás miatti panaszkodás közben tovább offol. :D

    :)

    Minjárt megsajnállak, tényleg.

    Csak azt elfelejted, hogy nem egy papírzsebkendőt dobtál el, hanem több tucatnyit. Azt is elfelejted, hogy előtte átitattad őket benzinnel.

    Az a különbség köztünk, hogy én komolyan vettem a kérésed és elvittem a flame szálakat egy másik topicba. Te pedig flame-eltél tovább itt. Ezek után nem világos, miért kéne bárkinek komolyanvennie a flame-szocproblémád.

    Nem gyújtottam fel. A fősodratú majmaid, a golgota-félék gyújtották fel. Leírtam a véleményem a Red Hat-ről, ami jelenleg a PipeWire-t fejleszti. Sajnálom, hogy az erre érkezett reakcióktól felgyulladt a topikod. Lehet, hogy jobban kéne tolerálni, ha valakinek más a véleménye.

    Igen, tudjuk, neked a szar (pláne, ha te szartad az asztal közepére) tökéletes. Similis simili gaudet.
    Nyavalyogni te jöttél ide, hogy "redhat, akkor fújszarköcsögmultimármegintcsináltvalamit"... Ezt a véleményedet ismerjük, tudjuk, hogy ilyen vagy, de attól még nem kell mindenhova odaokádnod, mert ezzel csak azt éred el, hogy egyre idiótább okádógépnek fog mindenki tekinteni.

    Amíg én leírom érvekkel, linkekkel, bugreportokkal alátámasztva a véleményemet a Red Hatról, addig te csak személyeskedsz és alpári, bunkó, kocsmatöltelék stílusban írod a hozzászólásaid. Ezek után azt mondani, hogy én baszom szét a topikot, na, az már tényleg nettó idiotizmus.

    Sajnálom, hogy a multikról, szoftvercégekről, fejlesztési irányokról másképp gondolkodókat idiótának tartod. Ez viszont nem az én szegénységi bizonyítványom, hanem a tied.

    szanalom gyermeke te! nem tudod en mit gondolok a multikrol. es azt sem tudod mit gondolok masokrol. csak azt tudod hogy ROLAD mit gondolok :D

    nem masokat tartok idiotanak, hanem TEGED. masokra egy rossz szot nem mondtam :D

    olyan huyle vagy, hogy azt sem erted: "et a topic a pipewire-rol szolt..valamikor meg" <-> "hajbi pfujj pfujj redhat hanyasa, rinya rinya kislanyos picsogas"

    Szogezzuk le ujbol. Eddigi tenykedesedbol latszik, hogy

    * nem ertesz a Linux OS-hez

    * nem ertesz a Linux userlandhoz

    * nem ertesz a WM/DE-hez, nem erted a layereket (freedesktop alap dolgokat)

    * nem ertesz a cloud-hoz, virtualizaciohoz, cointainer-ekhez, k8s-hez, bigdata-hoz

    * nem erted az IT business oldalat sem

    ennek ellenere nagyon hatarozottan allitod a faszsagaidat. majd elbujsz a tobbesszam moge. NEM, nincs tobbesszam. Te egyedulalloan idiota vagy. Kuriozum. :D

    nem tudod en mit gondolok a multikrol. es azt sem tudod mit gondolok masokrol.

    Nem tudom, mivel csak flame-elni és személyeskedni jöttél ide.

    nem ertesz a ...

    Szerintem meg igen. Sőt, ezért fizetnek és nem is rosszul.

    majd elbujsz a tobbesszam moge

    Aha, persze. "Senki sem kivancsi rad" [1] "akik jobban ismerik a munkassagod" [2] "Senki sem nézi semmilyen fősodratú babzsákfotelnek az itt beszélgetőket" [3]

    Szerintem inkább te vagy itt az, aki a többes számot erőlteted. Mindeközben vagy kb. te és Zeller Mérnök Úr, akik a személyem alapján ítélnek meg és ebből a kelepcéből nem is hajlandóak kivánszorogni. A többiek szimplán nem értenek egyet, ami egyébként jogukban áll. Van egy rossz hírem: többségi felhatalmazással és anélkül is csak egy ősparaszt mitugrász vagy, aki kizárólag flame-elni, személyeskedni és beszólogatni jön ide.

    Azt írtad valahol (2021. 04. 27., k – 23:45) hogy csináltál egy saját flémbe rakott topicot, és elkezdtél ott válaszolgatni - aztán ahogy látom, azt mégiscsak törölted (Megsértődtél a banánfürtös kép miatt?), és visszaevett ide a fene - merthogy itt több kattintást generálsz/többen reagálnak a megnyilatkozásaidra... Mintha perverz élvezetet jelentene neked az, ha direkt vagy indirekt módon lehülyéznek... Vagy egyszerűen csak kattintásgenerátor vagy a hup-nak?

    Nem töröltem. Továbbra is megvan.

    és visszaevett ide a fene

    Én megtettem, amit megtehettem, hogy a meglévő szálakat átvittem oda. Néhány fősodratú azonban továbbra is itt folytatta a velem való veszekedést. Én annyit ígértem, hogy a Red Hat-tal kapcsolatos további kritikáimat megtartom magamnak, vagy átviszem a flame topicba. Az, hogy én megcsináltam OP helyett, amit kellett volna neki, nem jelenti azt, hogy eltűröm és reakció nélkül hagyom a további lehülyézést, ócsárolást, idiótázást itt.

    Szóval nem nálam kell kopogtatnod ez ügyben. Esetleg állítsd le a HUP házi mitugrászát, Golgotát. Ő volt az, aki minősíthetetlen stílusban folytatta a flame-et. Őt követte OP a vádaskodásával.

    A belépőd ebbe a topicba, rövidítve...:

    ( hajbazer v | 2021. 01. 18., h – 01:58 )       Újrafeltalált kerék, kitől mástól, mint a Red Hat-tól., prekoncepció: ez is sz@r lesz

    ( hajbazer v | 2021. 01. 18., h – 12:56 )       Poettering és még mások is idióták.

    ( hajbazer v | 2021. 01. 18., h – 13:10 )       Ja, azért kellett szarrátörni mindent a systemd-vel,...  az agilis módszertant alkalmazó multik babzsákfejlesztői

    ( hajbazer v | 2021. 01. 18., h – 14:48 )       Mert fejétől bűzlik a hal és az, hogy ezek ott lead fejlesztők lehetnek...

    ( hajbazer v | 2021. 01. 18., h – 14:51 )       Ctrl-L csak workaround

    ( hajbazer v | 2021. 01. 18., h – 15:46 )       multimosdatókám, szélsőségesen idealista, szűklátókörű skatulyalogikád

    ( hajbazer v | 2021. 01. 18., h – 15:54 )       én lapátoljam el a szart millilárdos multik inkompetens fejlesztői után. Persze.

    ( hajbazer v | 2021. 01. 18., h – 17:05 )       mikor multiék már beleerőltették ezt is minden disztróba

    ( hajbazer v | 2021. 01. 18., h – 17:12 )       Tehát ha odaszarok a tányérra, tortát formálok belőle és ráírom, hogy ehető...

    ( hajbazer v | 2021. 01. 18., h – 17:13 )       Igen, persze, a systemd-t se™ erőltette™ senki™.  levelezőlistákon indított FUD-propagandával.

    ( hajbazer v | 2021. 01. 18., h – 17:41 )       A Red Hat elmúlt 10 éves felforgató munkássága a háborgásom tárgya.

    ( hajbazer v | 2021. 01. 18., h – 18:40 )       ettől még corporate erővel lett torkokon lenyomva a systemd

    És úgy kezdődött, hogy golgota visszaütött... Ééértem... A fenti lista még folytatható, de szerintem fölölsges... Egyébként meg okos enged... De te dafke visszajöttél, és nem hagyod magad...

    Egyrészt, szándékosan kiemelted azokat, amikbe beleköthetsz, hogy keményen fogalmaztam. Nem csak ezeket írtam.

    Másrészt, amivel kapcsolatban keményen fogalmaztam, azt alátámasztottam linkekkel, bugreportokkal, tényekkel.

    De te dafke visszajöttél, és nem hagyod magad...

    Amennyiben a személyemet éri továbbra is támadás, meg fogom védeni magam. Ha ezzel bajod van, akkor ne személyeskedj és erre figyelmeztesd kaptársaidat is.

    "Nem csak ezeket írtam." - Ezek voltak az első napi hozzászólásaidnak a kivonatai, tegnap este 132 darabnál hagytam abba a kivonatolást, úgyhogy való igaz, írtál mást is, durvábbat is, bunkóbbat is.

    "Amennyiben a személyemet éri továbbra is támadás, meg fogom védeni magam" Mondta mmár, hogy okosabb enged...?

    "( hajbazer v | 2021. 04. 28., sze – 17:15 )      nem vagyok hisztis hároméves, ellentétben néhány fősodratú elemmel itt, szar lenne maguknak beismerni, hogy egy velejéig arrogáns multi gyarmatosította a Linux-világot"

    De, nagyjából azt a szintet hozod...

    "( hajbazer v | 2021. 04. 28., sze – 00:15 )     (pipewire-höz) Nem akarok hozzátenni." - Akkor meg mi a szakadt lótüdőért vagy itt?

    Kérsz még kiemeléseket? Az a 132 sor az egyben olvasva igencsak durva, mondhatni nagyon nem pozitív képet fest rólad.

    Akkor meg mi a szakadt lótüdőért vagy itt?

    Reagáltam az újraindított flame-re, amivel a személyemet támadtátok.

    Megmondtam: ha felhagytok az ócsárolásommal, én többet nem írok ide. Ez még mindig nem sikerült, sem neked, sem a fősodartú mitugrász kollégádnak.

    Semmire nem kényszerített senkit, mindenki szabad akaratából volt hülye. Páran úgy tesznek, mintha kb. kizárólag hajbazer lenne felelős mindenért, nehogy szembe kelljen nézniük azzal, hogy a reagálásban olyan messzire jutottak el, hogy már nem csak reagálnak, hanem saját maguk alakítják az eseményeket. És azok az események nem azt tükrözik, ami szavaik szerint a céljuk lenne... Eljátsszák, hogy a világ megmentőiként hajbazert nézik hülyének, vagy talán hisznek is benne, hogy csakis hajbazer a hülye és ők a megmentők, de végül mind hülye hajbazerekké váltak (vagy rosszabbakká, hiszen kiválóbbnak állítják be magukat nála, mégis együtt fetrengenek vele a szarban). Nem tudom, hogy a többieket is hülyének nézik, vagy csak reménykednek abban, hogy a közösség hallgatása a hősi harcuk támogatását fejezi ki...?

    :)

    Nem is akartalak megalazni. Csak koszonotottelek itt nalunk, hogy borzalmasan szetoffold te is a topicot Az hogy megalazonak erzed hogy kozenk tartpzz csak megerositi azt hogy jobbnak gondolod magad, azaz belestel a sajat csapdadba hogy "itt midnenki jobbnak gondolja magat hajbitol vagy valakitol". :D

    Azert csak idetalaltal a vegere Te is. Es elvezed a "hangod" es hogy megmondhatod. :D

    Most hatnia kellene ram annak hogy valami ismeretlen ember azt mondja ram hogy nalam mindeki jobb? Komolyan? Gondoljuk at ezt megegyszer. :D

    Szerintem engedd el. Probald meg jolerezni magad a sarban (bar ugy latom megy ez). Fun! :D

    Nem is akartalak megalazni.

    Örömmel olvasom.

    Csak koszonotottelek itt nalunk, hogy borzalmasan szetoffold te is a topicot

    Ezt már nem lehet szétoffolni.

    Az hogy megalazonak erzed hogy kozenk tartpzz csak megerositi azt hogy jobbnak gondolod magad, azaz belestel a sajat csapdadba hogy "itt midnenki jobbnak gondolja magat hajbitol vagy valakitol".

    Az ember már csak olyan, hogy olykor beles az általa kirakott csapdákba...

    Persze nem volt semmilyen csapda, így bele sem leshettem és/vagy eshettem volna. Az, hogy ténylegesen beletartozom egy halmazba nem jelenti, hogy nem szégyellem, hogy beletartozom. El lehet fogadni valamit anélkül, hogy örülnék neki, szeretném, vagy büszke lennék rá.

    Azert csak idetalaltal a vegere Te is.

    A tetemre.

    Es elvezed a "hangod" es hogy megmondhatod.

    Azt élvezném, ha a "normális" emberek maguktól tudnák, mi a "normális". Mert azért az elég gáz, amikor már nekem "kell" megmondani, mi nem az.

    Most hatnia kellene ram annak hogy valami ismeretlen ember azt mondja ram hogy nalam mindeki jobb?

    Nem tudom. Válaszoltál.

    :)

    De hat en tenyleg meno vagyok! :D

    Nem irtal le semmit sem. Olyan volt az mint mikor visszajon a wc-bol a sok vizzel higitott fos. :D

    A problemadat meg megoldottam, csak hat te nem fogtad fel..."végig csak fröcsögtél...természetesen szőnyeg alá söpörted" :D

    Fussal ennek megint neki kiscsiko :D

    valthatok arra a kommunikaciora amit megerdemel

    ...

    Ha tudok bokok rajta egyet a vasvillaval ilyenkor

    Pont erről beszéltem:

    miért érez mindenki késztetést arra, hogy állandóan válaszoljon neki

    Nem értem, miért nem lett volna okosabb ráhagyni (ha szerinted te vagy az okosabb). Most, ahogy nekem (és nem neki) írtál, ugyanabban a stílusban beszélsz róla, sőt, ez a hozzászólásod egy jelentős része az ő "jellemzéséről" szól.

    Szóval nekem édesmindegy, csak gondoltam, jelzem, hogy én (kívülállóként) mit látok. További kellemes dagonyázást - úgy tűnik, mindannyian élvezitek.

    rahagytuk volna, de nem engedte :D

    Mar ne haragudj de ha oltari nagy faszsagokat beszel majd a segtsegre azt irja hogy babzsakfotelmultiberenchulyevagynemerted es visszabofogi ugyanazokat a keptelensegeket, akkor arra azert reagalok. De ezt barkinek megteszem.  

    Nem, nem gondolom hogy okosabb lennek. Ahogy nem hiszem hogy okosabb lennek egy darab szaraz galambszarnal sem. Hiszen az ertelem/okossag rajta nem ertelmezheto, nincs olyan kontextus amiben azt mondhatnak "nezd milyen okos ez a szaraz galambszar". :D

    Es igen, ahol lehet belerugok ebbe az idiotaba. Nem, nem azert mert szerencsetlen, hanem mert egy eroszakos faszkalap aki mindenkinel tobbre tartja magat. Ilyeneket eszek reggelire. :D

    Kozben meg szorakozast nyujtok a korulottem levoknek. :D

    Mi fontos egyáltalán az életben? Jobb lett volna, ha ez a szemét Red Hat befolyásolni merészeli a GNU/Linux fejlődési irányát téma kimaradt volna ebből a topicból. Nem erről szólt volna eredetileg.

    A pipewire valóban fejlődik, nekem új mondanivalóm egyre kevesebb van vele kapcsolatban, mert már használható, használom is. Nem hibátlan, de jól működik. Fedorához ma jött egy frissítés, amelyben a 0.3.26-hoz képest még néhány, Wim Taymans által fontosnak ítélt patch van.

    Nekem igazából már csak egy dolog hiányzik, az pedig az echo cancel. Ha az is meglesz, kereknek fogom érezni az egészet. Amúgy nem kizárt, hogy valamilyen gstreamer-es ügyeskedéssel már most meg lehet ezt oldani, de jobb szeretném, ha natívan tudná.

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

    ( locsemege v | 2021. 04. 27., k – 15:51 )

    Úgy látom, az általam nagyon hiányolt visszhangelnyomás is belekerült.

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

    ( salaud v | 2021. 04. 29., cs – 10:44 )

    Szerkesztve: 2021. 04. 29., cs – 10:44

    Ritkán szoktam ilyesmit írni, de most elszakadt a cérna.

     

    Hajbazer, te egy idegesítően nyüszítő, szánalmas, szemellenzős, Asperger-szindrómás, demagóg idióta vagy. Ahányszor meglátom, hogy beleböfögsz, vagy belehánysz egy normálisnak indult topicba, mindig az jut eszembe, na, ez is el lesz baszva innentől. Én még tőled hasznos, érdemi tartalmat, használható segítséget, bármit ami nem demagóg gyűlöletokádás, nem láttam. Nélküled a HUP nem lenne szegényebb semmivel.

    Egyszóval:

     

    TAKARODJ!

     

    Legyél szíves.

    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.

    "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

    Asperger ide vagy oda, az idegállapotod tekintve, nagyon úgy fest, hogy te szorulsz pszichiátriai segítségre.

    Én egyszer már eltakarodtam innen. Egy-két fősodratú majom azonban folytatta az ócsárolásomat, új szálakat is nyitott erre, amit nyilván nem fogok szó nélkül hagyni. Náluk panaszkodhatsz. Bár úgysem fogsz. A konformista fajtádnak az túl nagy kizökkenés lenne a megalkuvó komfortzónájából.

    Megmondtam: Ha nem érkezik több személyeskedés, ócsárlás, nem írok ide többet.

    A flame topicban nyugodtan lehet tovább Aspergerezni, meg kiscsikózni. Ha már a PipeWire multibuzi felhasználóközönségének nincs jobb dolga.

    ( Raynes | 2021. 05. 22., szo – 17:27 )

    Na, közben találtam a Pipewire-pulseaudio-nak egy bugját, Arch alatt. Inkább csak kisebb kényelmetlenség. Ha mpv-ben videólejátszás alatt elkezdek kurzormozgató billentyűkkel tekerni, akkor recseg a hang, és mikor elengedem, akkor is egy 1-2 mp.-ig még recseg, mire helyreáll normálba, alaplapi integrált hangchip, AMD-s laptopon, AMD HDMI Audio eszköz. Végül is nem a világ vége, meg a „sima” Pulseaudio sem tökéletes, úgyhogy ezért nem fogom még ekézni a Pipewire-t, gondolom javítani fogják.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    És valóban, észre se vettem, hogy javították. A hiba nem áll fent, Archon már a 0.3.29 van. Biztos vagyok benne, hogy uborkásoknak is eljön majd ez a pillanat, majd hipp-hopp, pár kiadás múlva, addig még kell egy párat aludni, meg kiadási partikra várni. Mindegy, ne legyünk gonoszok, lehet nekik nem lesz probléma, mert még a Pipewire-t se kapják meg jó pár kiadásig.

    Az is igaz, hogy mióta a pacman párhuzamosan frissíti a csomagokokat, olyan gyors lett a frissítés, hogy el sem tudom olvasni mi frissült. Mindegy, amúgy sem zavart annyira, nem volt nagy ügy, csak azért jeleztem eleve, hogy ne higgye senki, hogy tökéletes. Ennek ellenére nem volt még bajom a Pipewire-rel, minden ment eddig rajta probléma nélkül, médiaalkalmazás, játék, hangrögzítés, észre sem venni, hogy nem Pulseaudio fut, talán csak annyiban, hogy kisebb a CPU használata a hangszervernek. Nem hittem, hogy a PA-t egy nap ilyen simán leváltják. Főleg, hogy anno milyen rémálom volt a PA még a kezdeti időkben.

    Ehhez az is hozzátartozik továbbra is, hogy nem vagyok hangsznob, nem használok low latency és kreatív audióalkalmazásokat, mindenféle spéci audioeszközöket, így az esetleges hibák jó része eleve el is kerül. Tényleg csak alap böngészés, filmnézés, zenehallgatás, esetleg némi játék, teljesen átlag felhasználás, ennél fogva nem kicsit lenne ciki, ha sok hibával találkoznék.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Ubuntun vagyok és Pipewire-t használok. Nem kellett pár kiadást várnom, csak megcsináltam az a pár symlinket, és restartoltam sysctlben. Kicsit vacilláltam, hogy akarok-e mindig új PW bugokat, vagy kényelmesen megvárom, hogy Ubuntuék patcheljék, de végül frissítettem PPA-ból, így a pár nappal ezelőtti apt upgrade óta ez fut: PulseAudio (on PipeWire 0.3.29). Szóval nem tudom, miért kell az Ubuntut fikázni.

    ( locsemege v | 2021. 06. 09., sze – 19:55 )

    0.3.30

    This is a quick emergency release to fix some severe problems with the previous release.

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

    ( locsemege v | 2021. 08. 14., szo – 23:22 )

    Bocsánat, kicsit elhanyagoltam.

    0.3.33

    Fedora csomag.

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

    ( locsemege v | 2021. 08. 26., cs – 19:34 )

    0.3.34 rengeteg javítással, optimalizálással, gyorsabb fft-vel.

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

    ( locsemege v | 2021. 08. 29., v – 11:52 )

    Szerkesztve: 2021. 08. 29., v – 11:55

    Az utóbbi időben érdemi infót nem adtam ehhez a topic-hoz, csak az újabb verzió megjelenését jeleztem itt. Most azért van új infóm is. Az egyik, hogy míg korábban kizárólag SBC codec-kel volt hajlandó pipewire-ről működni a Panasonic mikro HiFi-m, addig most már megy az SBC-XQ és AAC is. Legutóbb, amikor néztem, az AAC összezagyválta a hangot, lényegében RAM-szemét ment a hangszórókra, de most már ez jó.

    Amúgy ezek a lehetőségek:

    bluez5.codecs = [ sbc sbc_xq aac ldac aptx aptx_hd aptx_ll aptx_ll_duplex faststream faststream_duplex ]

    Illetve:

    bluez5.headset-roles = [ hsp_hs hsp_ag hfp_hf hfp_ag ]

    A másik érdekesség - legalább is nekem -, hogy VoIP telefonáláshoz sikerült felizgatnom a visszhang elnyomását, amely már implementálásra került. Az én esetemben ez úgy néz ki, hogy a

    /etc/pipewire/media-session.d/media-session.conf

    file-om az alábbi:

    # Media session config file for PipeWire version "0.3.34" #
#
# Copy and edit this file in /etc/pipewire/media-session.d/
# for systemwide changes or in
# ~/.config/pipewire/media-session.d/ for local changes.

context.properties = {
    # Properties to configure the session and some
    # modules.
    #mem.mlock-all = false
    #support.dbus  = true
    #log.level     = 2
    #alsa.seq.name  = Midi-Bridge
}

context.spa-libs = {
    # Mapping from factory name to library.
    api.bluez5.*    = bluez5/libspa-bluez5
    api.alsa.*      = alsa/libspa-alsa
    api.v4l2.*      = v4l2/libspa-v4l2
    api.libcamera.* = libcamera/libspa-libcamera
}

context.modules = [
    #{   name = <module-name>
    #    [ args = { <key> = <value> ... } ]
    #    [ flags = [ [ ifexists ] [ nofail ] ]
    #}
    #
    # Loads a module with the given parameters.
    # If ifexists is given, the module is ignored when it is not found.
    # If nofail is given, module initialization failures are ignored.
    #
    # Uses RTKit to boost the data thread priority.
    {   name = libpipewire-module-rtkit
        args = {
            #nice.level   = -11
            #rt.prio      = 88
            #rt.time.soft = 2000000
            #rt.time.hard = 2000000
        }
        flags = [ ifexists nofail ]
    }

    # The native communication protocol.
    {   name = libpipewire-module-protocol-native }

    # Allows creating nodes that run in the context of the
    # client. Is used by all clients that want to provide
    # data to PipeWire.
    {   name = libpipewire-module-client-node }

    # Allows creating devices that run in the context of the
    # client. Is used by the session manager.
    {   name = libpipewire-module-client-device }

    # Makes a factory for wrapping nodes in an adapter with a
    # converter and resampler.
    {   name = libpipewire-module-adapter }

    # Allows applications to create metadata objects. It creates
    # a factory for Metadata objects.
    {   name = libpipewire-module-metadata }

    # Provides factories to make session manager objects.
    {   name = libpipewire-module-session-manager }

    {	name = libpipewire-module-echo-cancel
	args = {
	    # aec.method = webrtc
	    # node.latency = 1024/48000
	    source.props = {
		node.name = "Echo Cancellation Source"
	    }
	    sink.props = {
		node.name = "Echo Cancellation Sink"
	    }
	}
    }
]

session.modules = {
    # These are the modules that are enabled when a file with
    # the key name is found in the media-session.d config directory.
    # the default bundle is always enabled.

    default = [
        flatpak                 # manages flatpak access
        portal                  # manage portal permissions
        v4l2                    # video for linux udev detection
        #libcamera              # libcamera udev detection
        suspend-node            # suspend inactive nodes
        policy-node             # configure and link nodes
        #metadata               # export metadata API
        #default-nodes          # restore default nodes
        #default-profile        # restore default profiles
        #default-routes         # restore default route
        #streams-follow-default # move streams when default changes
        #alsa-seq               # alsa seq midi support
        #alsa-monitor           # alsa udev detection
        #bluez5                 # bluetooth support
        #bluez5-autoswitch      # automatic bluetooth HSP/HFP profile switch
        #restore-stream         # restore stream settings
        #logind                 # systemd-logind seat support
    ]
    with-audio = [
        metadata
        default-nodes
        default-profile
        default-routes
        alsa-seq
        alsa-monitor
    ]
    with-alsa = [
        with-audio
    ]
    with-jack = [
        with-audio
    ]
    with-pulseaudio = [
        with-audio
        bluez5
        bluez5-autoswitch
        logind
        restore-stream
        streams-follow-default
    ]
}

    A /etc-ben eredendően még pipewire alkönyvtár sincs. Nem baj, létre kell hozni, ahogyan a file elején ezt a comment javasolja. Eredetileg ez a file a /usr/share/pipewire/media-session.d alkönyvtárban található, de ne azt módosítsuk a frissítések miatt.

    Két kicsit kellemetlen, de nem nagyon rossz tapasztalatom van vele. Az egyik, hogy ekkor a pipewire-media-session process elég nagy CPU időt eszik, az én esetemben ez most épp 13.2 %. A másik, hogy nem jegyzi meg, hogy a VoIP kliens az echo canceller sink-jét illetve source-ét használja, valamint azt sem, hogy az echo canceller kimenete melyik sink-re csatlakozzon, ha több audio kimenetet használunk egyszerre. Ezt tehát a Carla klienssel kell behuzaloznom minden használat előtt egyelőre. Vélhetően ez a saját hibám, ugyanis az az igen erős sejtésem, hogy a node-ok autodetect felépülését, a pipewire sejtését, hogy szerinte nekem hogyan lesz jó, vélhetően config file-ból felül tudom bírálni, s el tudom neki mesélni, hogy a VoIP kliens a visszhang elnyomó modulhoz csatlakozzon mindig. Ehhez még dokumentációt kell olvasnom.

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

    Köszi ezekért az infókért, kifejezetten hasznosak most, felraktam egy manjaro-t amin váltottam Pipewire-ra.

    Lenne egy kérdésem itt, amire nem nyitnék külön threadet. Most először sikerült fájdalom nélkül használnom bluetooth fülest, out of box nagyon jó volt a minőség. Headset módban viszont nem a legjobb, van esetleg ötleted, melyik a legjobb mód headsethez? Ha jól láttam nekem 3 módot támogat csak, nálad a konfig fájlban 4-et látok. Valamint nem látok AptX-et nálam, ezt hol tudom megnézni, támogatja-e az a verzió ami nálam van? 3.34-es települt ha jól látom, de nem tudom milyen konfiggal fordítják. Köszi!

    A headset minősége elvi okok miatt rossz. Ahhoz hasonlítom, mint amikor az űrhajósok rádióznak, borzasztó a hangminőség. Nem azért, mert a technológiánk alkalmatlan valami jobbra, hanem a jobb minőséghez nagyobb sávszélesség kell, ami meg nem mindig van. Szóval telefon átvitelnél, headset módban többnyire csak a beszéd érthetőség a szempont. Ahogy írod is, tud az a füles A2DP-t, vagy mi fenének hívják, szóval meg lehet győzni minimum az SBC-ről, s akkor jó lesz a hang, csak persze nagyobb sávszélesség kell neki.

    Egyrészt javaslom a 0.3.35-ös használatát, másrészt, ha nem ijedsz meg saját árnyékodtól, s csináltál már ilyesmit - netán szoktál C-ben programozni -, akkor húzd ki git repóból a master-t, s fordíts magadnak egy legfrissebb változatot.

    Két említésre méltó patch-ről tudok 0.3.35 óta. Az egyiket media-session: only check passthrough when available néven, a másikat pulse-server: parse default.clock.rate from core info néven találod meg. Én is mindjárt fordítok virtuális gépben egyet.

    Codecek közül emlékeim szerint egyetlen egyre mondja a fordító, hogy az nincs, de nem emlékszem, melyikre. logokat nem néztem, a képernyőn meg gyorsan elszaladt.

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

    Valamint nem látok AptX-et nálam

    Most fordítok PipeWire-t, s láttam, hogy épp az aptX codec-re mondta, hogy nincs. Az is gyanús, hogy pulseaudiohoz is  csak az rpmfusion repóban van, tehát gondolom, van valami szabadalmi hercehurca az aptX codec körül. Gondolom, ezért nincs.

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

    Köszönöm szépen az infókat! Teljesen igazad van, hívás módban a samsung headset a samsung telefonommal (ahol gondolom nincsenek kodek stb problémák) is sokkal rosszabb ha zenét vagy podcastot kapcsolok, ami érthető mert feleződik (gondolom) a sávszélesség meg eleve nem use-case hogy hanghívás közben bárki zenét hallgatna vagy videót nézne. Csak kíváncsi voltam lehet-e javítani rajta, vagy a linux le tudja-e kommunikálni hogy kell-e mikrofon vagy nem (telón ugye ez megy és ha vége a hívásnak visszaáll magas minőségű kodekra).

    ( locsemege v | 2021. 09. 10., p – 00:19 )

    0.3.35

    Persze, mint minden kiadásról, erről is kiadást követően derült ki, hogy lett benne csúnya regresszió, így aztán kell hozzá ez a patch, hogy jó legyen. Fedorára már ezzel fordították. Na jó, mondjuk másodjára. :) Amúgy ellenkező híresztelések ellenére sajnos nem jegyzi meg az echo cancel sink és source, valamint az alkalmazás közötti link útvonalát. :(

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

    Hamarosan teszt nap, de "elakadtam" az első teszten: systemctl --user status wireplumber

    Started Multimedia Service Session Manager.
    wp_spa_pod_get_property: assertion 'key_val != NULL' failed
    (../modules/module-lua-scripting/pod.c:1055):push_luapod: runtime check faile>
     GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply)

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Aztán ez a wireplumber meg mi a lótüdő? Ezt írja az újság:

    WirePlumber is a modular session/policy manager for PipeWire and a GObject-based high-level library that wraps PipeWire's API, providing convenience for writing the daemon's modules as well as external tools for managing PipeWire.

    Ez megint valami, amitől csak nem fog működni az, ami eddig működött?

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

    Mondanám, hogy értem miért van rá szükség:)

    WirePlumber examples: https://pipewire.pages.freedesktop.org/wireplumber/testing.html#wireplu…

    wpctl status  # verify the default endpoints
    $ pw-record test.wav
    $ pw-play test.wav

    Using a non-default endpoint:

    $ pw-record --list-targets  # find the node id
    $ pw-record --target <node_id> test.wav
    $ pw-play --list-targets  # find the node id
    $ pw-play --target <node_id> test.wav
    or

    $ wpctl status  # find the capture & playback endpoint ids
    $ pw-record --target <endpoint_id> test.wav
    $ pw-play --target <endpoint_id> test.wav

     

    update

    És ...

    A PipeWire 0.3 egy példamenetkezelőt (pipewire-media-session) tartalmaz, amelyet le kell tiltania, és le kell cserélnie WirePlumber-re.

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Ez olyan ironikus „értem” volt. Elsősorban azt értem, hogy ezek szerint - remélem, csak átmenetileg - megint sikerült elrontani valamit, ami egyszer már működött.

    Tegyük hozzá, másfelől valóban értem ezt. Egy műszernek írom a programját C-ben mostanában, és egyszer már működött, de nem volt elég flexibilis. Nyilván, most, hogy szebben, elegánsabban valósítok meg benne dolgokat, általánosabban, rugalmasabban, adaptívabban, átmenetileg rosszabb lesz az egész, mert lesz benne egy rakás bug, nem működés, rosszul működés, amit mind meg kell keresni és ki kell javítani. Szóval értem, miért mennek így a dolgok, csak felhasználói oldalról szemlélve ez sokszor igen kellemetlen.

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

    Ezt én se értem, mert nálam Archon továbbra sincs probléma a PipeWire-rel. Csak pipewire-media-session van, ilyen wireplumber nincsen, mármint a tárolókban van, de a rendszerre nem került fel automatikusan. Pont ezért nem szeretem egyébként a nagyobb, mainstream disztrókat, meg DE-ket, mert rátolnak sok szutykot a userre, tipikusan 99%-ban olyat, amire nem biztosan lenne szüksége. Igazából sajnos Gtk-s szutykok nálam is behúzták a polkit, dbus, at-spi nyomorékságokat, még minimalista WM-nél is, és nem tudom kigyomlálni őket, mivel Firefoxnak, Steam-nek, redshift-nek, ennek-annak függősége sajnos.

    Amit így 5 hónapnyi PW-ezés után megfigyeltem, hogy a memóigénye nőtt egy kicsit, CPU igénye viszont mindig töredéke a PA-nak.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    ( locsemege v | 2021. 10. 23., szo – 09:48 )

    0.3.39

    Nagyon sok fontos javítást tartalmaz.

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

    Nem kell ehhez friss telepítés, csak át kell állítani, le kell szedni a pulseadio-t az összes függőségével, és fel kell tenni helyette a pipewire, pipewire-alsa, pipewire-pulsaudio csomagokat, ha kell valakinek, akkor a pipewire-jack csomagot is. Ezt a Wireplumber-t viszont még nem próbáltam, nem is egészen értem, hogy mi a lényege.

    Nekem egyébként a PipeWire továbbra is bejön, problémám nincs vele, kb. ugyanazt tudja, amit a Pulsaaudio, CPU terhelése is kb. akkora, memóriafogyasztása viszont majdnem csak fele, bár ez lehet változni fog idővel, ahogy kerülnek bele a javítások és új funkciót, tuti hízni fog. Az is igaz, hogy nekem Pulseaudio-val sem volt problémám, azon túl, hogy bloatnak tekintem. Ebben az is közrejátszik, hogy nem használok DAW progikat, nem dolgozok professzionális audio-val, nem OBS-ezek, nem használok Blutooth-t, stb., de ez mindenre igaz, nincs multimonitor setup, nem hibernálok, nem használok sleepet, nem gyúrok hosszú uptime-re, nem zárok mindent virtuális gépbe, meg dokkba, nem használok univerzális csomagformátumot (Snap és társai), nem használok DE-t (hanem minimalista WM-et, majdnem csak kizárólag terminálos CLI/TUI alkalmazásokkal), nem használok zárt drivert igénylő hardvert (NV GPU, túl egzotikus Wi-Fi, stb.), nincs swap, nincs zram, nincs túl spéci fájlrendszer (ZFS, btrfs, nincs RAID), csak natúr ext4, nem használok spéci kernelt,, spéci ütemezőt, nem használok GRUB-ot, stb.. Így egy csomó probléma és bug élből kikerül.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Hasonlóan vegetálgatok, annyi különbséggel, hogy nálam nincs (most) Xorg sem, és Pulse-bol is csak a pipewire-pulseaudio csomagot telepítettem fel (ez behúzza a pulseaudio-t viszont az alsa-t nem :D ) hozzáteszem eddig még nem sipákolt érte semmi . :)

    Arch Linux [Sway WM]

    CPU terhelése is kb. akkora

    Ezt erőst cáfolnám. Sokkal karcsúbb a pipewire CPU igénye. Már eleve a pointereket átadó koncepció miatt hiányzó memcpy()-k miatt.

    A wireplumber funkcionálisan a pipewire-media-session. Csak utóbbi valójában egy demo program, ami megmutatja, hogyan kell használni az API-t, így aztán olyan is. A wireplumber a valódi, teljes session manager. Nyilván, ha használod a wireplumber-t, nem használhatod a pipewire-media-session managert.

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

    De mi az előnye ennek a wireplumbernek? Telepíteni úgy kell, hogy felteszem a wireplumber csomagot és újraindítom a gépet, vagy kell hozzá konfigurálni valamit? Eleve azt se értem, hogy session kezelés minek a pipewire-be. Megy a hangszerver és kész, session az minek kell?

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Kösz a linket, elolvastam, meg ugyanennek a görög fejlesztőnek a videóját is néztem, ahol egy órát magokott róla, de mivel 15 perc után sem tudott a lényegre térni, így ráuntam, kinyomtam.

    Mindegy, felteszem a wireplumbert, ha ennyien ajánljátok, mert nem zárkózok el új dolgok kipróbálásától, de továbbra se értem, hogy miért kéne ez nekem. Már azt se értem, hogy a pipewire-session-manager minek kell (fent van, fut, függőségként kúszott fel) személy szerint nekem. Mert nem használok több audio eszközt, több streamet egymás mellett, nem használok JACK-et, DAW szoftvereket, OBS-t, stb.. Nekem ez így távolról kicsit olyasminek tűnik, mint mikor minden disztró GRUB-bal jön, mert az kell. Nem, nem kell, simán bootolok akármikor systemd UEFI boottal vagy EFI stub boottal önmagában. Pont ez a lényege az egész Linuxnak, hogy jól skálázódik mindenféle méretű eszközre, mindenféle felhasználási típusra, erősen moduláris, mindenki olyan rendszert legóz össze magának belőle, amilyet akar. Ez nem Windows, meg Mac, hogy bele van drótozva egy csomó komponens, ha kell, ha nem, azt kell szeretni, lenyelni.

    Szerk.: már fent is van pár perce. Simán pacman -S wireplumber kiadásával települt, lecserélte a pipewire-session-manager csomagot. Újraindítottam a rendszert, működik, semmilyen apt-os és systemctl-es varázslás nem kellett hozzá. Se mem, se CPU fogyasztás terén különbséget nem látok, bugba se futottam eddig bele, igaz nem is tudtam még alaposan tesztelni, csak pár alkalmazást pödörtem végig, ami problémás lehet, böngésző, videóstream, mpv-vel helyi fájlok lejátszása, ezekbe beletekerés, natív linuxos játék, wine-os és protononos játék. Hang egyikben sem pattog, nem akad, nem lagzik, nem duplázódik, nem torzul. Eddig.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Ja, jó, ezek egyikét se csinálom, mint egyszeri felhasználó. Mikor még Pulseaudio-t használtam, abban sem volt session manager, sőt, Gentoo-n próbálgattam alsa only telepítést apulse-szal, abban sem hiányzott ilyesmi. Amivel ez a bajom, hogy ha egyszer nem kell, akkor ne erőltessék bele, legyen opcionális függőség. Mindegy, fent van, legalább ezt is kipróbálom, de így kicsit a PipeWire értelme veszik oda nálam, mivel ennek pont az lenne a lényege, hogy soványabb, mint a PA, de ha minden ilyen session akármit beletesznek, akkor garantáltan nem lesz az, hanem csöbörből vödörbe esete.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    ezek egyikét se csinálom

    Csinálod, legfeljebb nem tudsz róla. Pipewire belül 48 kS/s-os, és gondolom, van egy rakás hanganyag, ami viszont 44.1 kS/s-mal jön, szóval resampling biztosan kell. A route-olás is, mert már az is annak minősül, ha a böngésződből a default sink-be megy a hang. (Fentebb az 'S' nem Siemens, hanem sample. :) )

    Nem vész oda a pipewire könnyűsége, csak szét vannak szedve a feladatok. Van egy olyan része, hogy ki kell találni, mikor hova menjen a hang, pl. át lehessen dobni belső hangszóróról bluetooth-ra, de ha a bluetooth-os eszközt kikapcsolod, jöjjön vissza a belső hangszóróra, melyik alkalmazásnak legyen visszhang-elnyomás, és effélék. Az ilyesmi a wireplumber dolga. Aztán van, ami falja be a buffereket, átadja a megfelelő pluginnak újramintavételezésre, keverésre, akármire, aztán tolja ki a kernel felé az alsa driver-be, ezt meg csinálja a pipewire-pulse illetve a pipewire, bár ez utóbbi képpel is, ha arra van igény.

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

    Fedorán ilyen kapcsolók vannak: oda / vissza váltás a szolgáltatások között, telepített csomagok keresése ....

    apt install pulseaudio --allowerasing
    apt install --allowerasing pipewire-pulseaudio

    systemctl --user status pipewire.*
    systemctl --user enable --now wireplumber
    systemctl --user start wireplumber.service
    systemctl --user enable wireplumber.service

    cat /proc/asound/card0/pcm0p/sub0/hw_params

    apt list installed *alsa*
    apt list pipewire\* --installed
    apt list installed *wireplumber*

    apt swap wireplumber pipewire-media-session
    apt swap pipewire-media-session wireplumber

    wpctl status
    wpctl set-default "ID"

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Az nagyon kemény, ha nálad Fedorán ilyen szapora apt-ozás van. Ezzel még Linus Sebastian is megirigyelne, mert ő is csak Manjaro-n próbálta használni az apt helyett az apt-get-et. Vagy lehet csak én nem vagyok képben, mert nem használom az Red Hat vonalát, de emlékeim szerint már rég maguk mögött hagyták a yum-ot, és már évek óta dnf megy, ezzel telepítenek .rpm csomagokat, már aki nem Flatpakk, meg Snap Matyi.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Hihi nagyon vicces, teszteltem Ubuntun is. Így átírtam neked, nem jól írtam? Már látom arch vagy változata:)

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Már nem tudod átírni, de mindegy, csak poénnak szántam. A lényeg, hogy amiket írtál, azoknak kb. egyike se kell. Egy natív csomagkezelős telepítés után egy egyszerű reboot kell neki, ezt nem is szokták elhinni az uptime és végtelenségig sleep/hibernálás mániások, hogy sokszor egy szem reboot többet megold, mint akárhánysoros mókolás, annak szerveren van inkább értelme. A minimalista disztró + SSD felállás mellett a reboot olyan villám gyors, 3-4 mp. körüli, hogy nem éri meg shellbe kisregényeket gépelgetni.

    Ezért szoktam keresztes hadjáratokat vezetni fórumokon, mikor próbálom a Linux = apt + Ubuntu + Snap, meg nem akarok újratelepíteni, nem akarok újraindítani mantra ellen, mert ezeket ma már sok felhasználó mániákusan tolja, és egyik se igaz. Nincs bajom az Ubuntu vonallal, főleg nem a közösségi, alternatív DE/WM-es kiadásaival, csak azt nem szeretem, mikor úgy tüntetik fel, hogy az „A” Linux. A legnépszerűbb disztróvonal, kétségtelen, de ez még nem teszi egyelővé magával a Linuxszal. Ráadásul ez az ész nélküli apt-ozás félrevezető a nooboknak, mert a neten megtalálják, és gondolkodás nélkül írják be a shellbe, lásd Linus Tech Tips esetét a Manjarón futtatott apt-get-tel.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Ezzel még Linus Sebastian is megirigyelne, mert ő is csak Manjaro-n próbálta használni az apt helyett az apt-get-et

    direkt trollkodik, mellesleg en mar a hangjatol is a falra maszom. (na jo a Brodie Robertson hangjatol is de o legalabb ertelmes dolgokrol beszel) :D

    bocs az Off-ert.

    Arch Linux [Sway WM]

    ( kubi | 2021. 11. 16., k – 09:54 )

    A desktopomon (Debian) megint felkuszott, amikor nem figyeltem egy pillanatra. Jott a pipewire es wireplumber is.

    Ezuttal, ellentetben a korabbiakkal, sikerult neki kiutnie a pulseaudiot, es betolakodni a helyere. A beallitasokat termeszetesen keptelen volt leutanozni. A bluetooth hangrendszer siman megdoglott. A blueman nem volt hajlando kapcsolodni a hangfalakhoz, mert csak. A HDMI hangrendszer eltunt (nincs csatlakoztatva az eszkoz, irja boldogan a HDMI monitoron).

    Ez nem feltetlenul/csak a pipewire hiabaja. A csomag karbantartoja is saros lehet. De ettol meg baromira bosszant.

    Egy apt purge nagyjabol visszahozta az eletbe a gepet. Kiveve, hogy az smplayer-bol mar nem tudok kimenetet valtani, csak a pavucontrol-bol.

    Sajnos, nem ez volt az elso esete, es gyanum szerint nem is az utolso. Szimplan nincs idom az ilyen hulyesegekkel foglalkozni egy alpha szinten levo programnal. Most kapott egy szep tiltast a csomag.

    Igy van. Eszembe se jut beallitani. Aztan majd ujra, amikor gondolnak egyet a fejlesztok. Majd szepen atallok ra, ha stabilizalodik. Vagy nem, ha eltunik a szinrol.

    Az smplayer frontend nem route-olasra valo. Azonban ki tudja (tudta, mielott ez a hulladek bekavart) valasztani a kimeneti eszkozoket, es ezt a kenyelmi funkciot surun hasznaltam.

    Nézd, nálam a seren VoIP kliens állandóan buffer underrun-t dobott pulseaudio használatával, mert Lennart Poettering-nek ezt a nem túl bonyolult kérdést - buffer kezelés, pointerek nyilvántartása - sem sikerült megugrania, így recsegett-ropogott a hang, a beszélgetés teljességgel érthetetlenné vált, miközben egy CPU mag 25 %-át elvitte egy 3.2 GHz-es AMD Phenom II X4-en.

    Ezzel szemben pipewire alig eszik CPU-t, működik a visszhang elnyomás, nem recseg a hang, nincs buffer underrun, ráadásul akkor, amikor még volt vele baj, Wim Taymans örömmel fogadta a bugreportot, azt komolyan vette, s kijavította a hibát, miközben én forrásból fordítgattam az újabb próbálkozásait, s küldtem vissza neki a logokat. Lennart hibajavítása ezzel szemben a másokra mutogatásban merül ki, amikor ugyan megoldhatná a problémát, ehelyett ideológiát gyárt hozzá, mondván, a bug az alsa layerben van, s ő nem hajlandó azt elfedni.

    A software-ek folyamatosan fejlődnek, nincs stabil állapotuk. Így nézve Linuxot sem lenne szabad használni, mert a kernelben is van bug, a systemd-ben is van, meg lényegében minden alrendszerben. A pipewire szerintem már igen jól használható, elérte azt az érettséget, hogy problémamentesen használható a legtöbb esetben. Mondjuk nem volna túl nagy baj, ha használnád a pavucontrol nevű találmányt, lehet, hamar megoldanád vele a problémát.

    Ugyanakkor folyamatosan fejlődik a pipewire. Ahogy nézem a commitokat, azt látom, mostanában kerül bele a RAOP.

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

    Ha visszatetted a pulseaudio-t, uninstalláltad a pipewire-t, akkor ez utóbbi hogyan tud bekeverni? Nem létező program nem fut. A konfig file-okat - nyilván, amikor nem fut a pulseaudio - tudod törölni, így azok újra inicializálásra kerülnek, aminek következtében semmiféle emléke nem lesz a gépednek a pipewire futásáról. Az más kérdés, ha csak a panaszkodás megy, a cselekvés nem, de akkor nem is igazán érint meg a probléma.

    A konfig file-ok helyett inkább állapotleíró, státusz file-okat kellett volna írnom, az pontosabban kifejezi, mire gondolok. Ahol tárolódik a route-olás, a hangerők, effélék.

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

    Bár nekem nem jöttek elő ezek a problémák, mikor Manjaro-n lecserélődött, szerintem ennél a forgatókönyvnél (már belakott rendszren cserélődik le) ezen én nem lépődök meg. Ha ugyan ezt a verziót tisztán felrakod, szerintem pöccre menne minden. Vagy marad az, hogy frissítés + debug. Vagy amit csináltál, a tiltás.

    ( Wooody | 2021. 11. 28., v – 13:34 )

    Szerkesztve: 2021. 11. 28., v – 13:41

    Beállításokkal esetlen foglakozott már valaki (client.conf, pipewire-pulse.conf, pipewire.conf) tapasztalatok?

    copy files /usr/share/pipewire/
    /etc/pipewire or ~/.config/pipewire

    pl: default.clock.rate          = 48000
    default.clock.allowed-rates = [ 44100,48000,96000 ]
    resample.quality = 15

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Ha találsz hasonló okos leírást dobj már meg vele:) ez pl még a régi rendszeren működött

    https://medium.com/@gamunu/enable-high-quality-audio-on-linux-6f16f3fe7e1f

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Most csak a visszhangelnyomással tudok hozzájárulni. Ha kell valakinek, pl. VoIP miatt, az alábbit lehet tenni. Nálam a /etc/wireplumber/wireplumber.conf file

    context.modules = [

    kezdetű szekciójába az alábbi írandó:

      # Echo cancellation module
  { name = libpipewire-module-echo-cancel }

    Én a szekció végére, a záró ']' megelőző sorokba írtam.

    Tegyük hozzá, ez gányolás, látszik ugyanis a config file-ból, hogy include-olja a pl. a main.lua komponenst, gyanítom, a main.lua.d-be kellene írni egy saját configot. Ugye a jelenlegi megoldásommal az a baj, hogy vagy csomagból nem fog frissülni a wireplumber.conf, vagy, ha igen, felülírja az echo cancel configomat. Ha majd lesz elegendő motivációm, kiírom külön file-ba.

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

    ( Wooody | 2021. 11. 29., h – 14:42 )

    Szerkesztve: 2021. 11. 29., h – 14:57

    Tehát asztali gépen nem lehet zavaró a magasabb minőség, valaki más is teszteli? Nem tudom szükséges-e a PCM source megváltoztatása. Ha igen, hogy tudom lekérni helyes-e az  (api.alsa.path = "hw:0") értéke, ez volt a gyári érték a fájlban. Audio/video üzenetkezelő alkalmazások használják a client-rt.conf fájlt? Párhuzamosan lehet mindkettőt használni más-más beállítással?

    /.config/pipewire/pipewire.conf

    ## Properties for the DSP configuration.
    default.clock.rate          = 48000
    default.clock.allowed-rates = [ 44100,48000,96000 ]

    # This creates a single PCM source device for the given
    # alsa device path hw:0. You can change source to sink
    # to make a sink in the same way.
    { factory = adapter
        args = {
            factory.name           = api.alsa.pcm.source
            node.name              = "alsa-source"
            node.description       = "PCM Source"
            media.class            = "Audio/Source"
            api.alsa.path          = "hw:0"
            api.alsa.period-size   = 1024
            api.alsa.headroom      = 0
            api.alsa.disable-mmap  = false
            api.alsa.disable-batch = false
    #       audio.format           = "S16LE"
            audio.format           = "float32le"
            audio.rate             = 48000
            audio.channels         = 2
            audio.position         = "FL,FR"
        }
    }

     

    /.config/pipewire/pipewire-pulse.conf

    stream.properties = {
    #node.latency          = 1024/48000
    #node.autoconnect      = true
    resample.quality	   = 15
    #channelmix.normalize  = false
    #channelmix.mix-lfe    = false
    #channelmix.upmix      = false
    #channelmix.lfe-cutoff = 0

     

    /.config/pipewire/client.conf

    stream.properties = {
    #node.latency          = 1024/48000
    #node.autoconnect      = true
    resample.quality	   = 15
    #channelmix.normalize  = false
    #channelmix.mix-lfe    = false
    #channelmix.upmix      = false
    #channelmix.lfe-cutoff = 0
}

     

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

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Nem egészen értem. Mi az, hogy nem lehet zavaró a magasabb minőség? A Shannon-törvény szerint 20 kHz átviteléhez legalább 40 kHz mintavételi frekvencia kell, tehát a 44.1 kHz és a 48 kHz is jó. Denevéreknek meg legyen 96 kHz. Dinamika szerintem érdekesebb, mert most 16 bit, de ez előjeles, így lényegében 15 bit lineáris. Tekintve, hogy logaritmikusan hallunk amplitúdóban, a nagyobb felbontás érdekes lehet, szóval 24 vagy még inkább 32 bit jótékony hatású lehet, csak az sem túl nagy baj, ha van megfelelő hanfforrás hozzá. Semmire nem mész azzal, ha egy jó átviteli csatornát rossz minőségű hanggal etetsz.

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

    Hát ma már nehezen, majd az összes online szolgáltató veszteségmentes HiFi formátumot használ. Rádiók is e felé mennek, pl  https://bdpstrock.hu/

    Újabban a kijött filmek között nem ritka a DTS-HD Master Audio 

    Netflix (Dolby Digital Plus, Dolby Atmos) , Tidal 24/96000, Apple Music (24/192000), Primephonic (24bit), Amazon Music Unlimited (HD and Ultra HD ), Qobuz (24/192000), 

    Aztán meg a kártyám is tudja a 24/32 bit 192.000 Hz-t és az említettek közül három szolgáltatást is használok. Így sajnos alul van méretezve, mert a linux + a firmware csak 48000 Hz-t tud.

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Hát akkor mit szólnál a 768KHz /32 bit PCM audióhoz, 2000 körül kiválasztottam a hangkártyámat, sajnos csak a boltban vettem észre hogy az ára 1.700e Ft nem voltam igazán boldog:)

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    azert az jelent "valamit", hogy:
    USB PCM: 16 /24 /32 bit, 32 / 44,1 / 48 / 88,2 / 96 / 176,4 / 192 / 358,2 / 384 kHz
    de: Frekvencia-átvitel: 5 Hz-80 kHz (+1 dB/-3 dB)
    es: THD: 0,0015 % (1 kHz, 20 Hz-20 kHz)
    ugy tunik a torzitast mar ok sem tudjak/merik/akarjak merni a teljes frekiatvitelen? :D
    biztos kurvajo a cucc egyebkent, de az ember hallasa kozeleben sincs a 20kHz-nek. es a hangkeltok atvitele sincs (a 20-22kHz is marketing bullshit, altalaban erost esik 15kHz korultol, nem veletlenul). ezzel vitatkozni lehet, csak nem erdemes :)
    es igen, en tudom, hogy a sample rate!=hangfreki, mielott ez trollkodas targya lenne :)

    Meg ugye x(t) = A * sin(ω * t), v(t) = dx(t) / dt = A * ω * cos(ω * t), valamint a(t) = dv(t) / dt = -A * ω ^ 2 * sin(ω * t), tehát a frekvencia négyzetével arányos a gyorsulás, s ezzel az az erő is, amellyel a membránt gyorsítani kell. Amúgy óriásiak ezek az erők, érdemes kiszámolni.

    THD-t elég nehéz mérni, így jellemzően THD+noise szokott lenni.

    Amúgy számít 20 kHz fölött a torzítás? Úgysem halljuk. Sőt, már 10 kHz fölött ultrahang az összes felharmonikus, így valójában 10 kHz fölött torzíthat. Akkor lehet gond, ha valamilyen nemlineáris fizikai folyamaton ezek a harmonikusok modulálódni képesek, pl. megjelenik a különbségi frekvencia, ami a hangfrekvenciás sávba eshet.

    Hallgasson a 20 kHz - 80 kHz-es sávban zenét az, akinek van erre ideje! :)

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

    Izgi téma két videót is találtam ezek szerint a 20Khz hallható (ha ezek a tesztek valósnak tekinthetőek) bár kicsit szaggat 19-20 között. Lehet csak vakítás a videó.

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Ugyanaz a véleményem róla, mint a csöves erősítőről meg az aranyozott hálózati konnektorról. Remélem, az MVM-et, meg az energiaszektort is meggyőzik az olyen emberek, hogy a paksi generátorokig az összes villamos kötés aranyozott legyen 400 kV-on is, meg a generátor 15.75 kV-os feszültségsintjén is, hogy szépen szóljon az erősítő.

    Szóval, ahogy írtam, az a véleményem róla, hogy semmi értelme, viszont mivel van rá fizetőképes kereslet, csinálnak ilyen eszközöket.

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

    Értelek, ezért 1% az 1% és maradjon is így. Ne is használja senki. Hifi kártya és hangfal esetén is cool a Sokol rádió minőség. 

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Nem ezt írtam. Legyen jó a minőség, de a jó minőségnek nem feltétele egy rossz hatásfokú A-osztályú végfok, benne egyébként egy nonlineáris alkatrésszel, ami a vasmag. Nem véletlenül írtam példaként az aranyozott 230 V-os hálózati csatlakozót, hiszen nem tudom, emberünk gondolt-e arra, hogy nem lesz Paksig minden csatlakozó aranyozva, továbbá ott az energia jön, lesz ott szűrés, egyenirányítás, transzformálás - előtte akár nagyfrekvenciás kapcsolgatás -, megint egyenirányítás, szabályozás, szűrés. Nem a hang megy ott, de tudom, a vallásos emberekre nem hatnak a tudományos érvek.

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

    Ja, ezen az aranyozott csatlakozós, meg jittermentes digitális audiofúl mantrákon én is nagyon szoktam röhögni, mindenből aranyozott, meg 5000 dolláros USB kábel, meg power contitioner. Meg hogy ők hallják a 44kHz-384kHz közötti, meg az 1440-3072 kbit, és a PCM és a DSD közötti különbséget. De csakis addig, amíg fülessel le nem ültetik őket egy 256 kbps-os aac-t játszó eszközre, ahol lenyomatnak velük egy ABX vaktesztet, ott megáll a tudomány, megy a találgatás 50-50%-os arányban, meg a kifogáskeresés, hogy izé, nem elég jó a lejátszóhardver, möhöhőő.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    "Meg hogy ők hallják a 44kHz-384kHz közötti, meg az 1440-3072 kbit, és a PCM és a DSD közötti különbséget. "

    Ezt félreértetted:) nézz utána ha tudsz. De az 100% hogy ha felteszem xy "lemezt" (ami eleve 24/192 lett rögzítve) bizony olyan hangok és hangszereket is lehet hallani amit egyébként nem.

    De van amiben igazad van egy fostaliga minőségű zene néha jobban szól a "buta" eszközön. Magam is jártam úgy hogy az alacsonyabb minőségű, nem audiofüles jobban tetszett. Valójában ez akkor fordult elő amikor a végső analóg anyagot rögzítették CD-re. De mint fent említettem, sok szolgáltató már komoly minőségben tolja, és nem fostalicska minőségben.

    DSD jobban szól teltebb a basszus, de ez nem jelenti hogy ha hasonlítgatnom kéne akkor megtudnám különböztetni. Biztos voltál már koncerten, ott is valamit produkálni kell, ezért a CD/DVD minőségétől sokkal jobb minőségben szólnak a cuccok. Anno egyszerűen master szalagot kértek. Ha otthon meghallgattad a lemezt akkor max. néztél mi ez a virsli és elmentél  a következő koncertre is.

    És az is biztató, hogy már majdnem olyan szól PC-s hifi mint anno a kazettás hifi metal szalaggal.:) De valószínű azt sosem fogjuk elérni. Kicsit olyan vita ez mint PC 32 vs 64bit.

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    A 24 bitben hiszek, mert logaritmikusan hallunk, s a 16 bit - ami lényegében 15 bit az előjel miatt - dinamikatartomány elég soványka. Ha csendben, halkan lenne egy szinuszos jel, az ilyen felbontással nagyjából négyszögjellé torzul a kvantálás miatt. Ha a +8 bittel 256-szor finomabb a felbontás, az úgy korrekt.

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

    a 16 bit - ami lényegében 15 bit az előjel miatt

    Bocs, hogy belevau, de nem. Egyrészt van unsigned 16-bites hang is, másrészt meg, ha signed is a 16-bites hang, az sem azt jelenti, hogy lefelezted a dinamikatartományt, csak annyit, hogy az aritmetikai ábrázolás történik -32768-tól 32767-ig és a nullpont ténylegesen a 0, míg jelöletlenül 0-tól 65535-ig és a nullpont 32768-nál található.

    Oldschool Computer - http://oscomp.hu

    Na jó, de a kettő ekvivalens. Arra gondoltam, hogy ha van egy szinuszod, akkor annak a pozitív félperiódusa is 15 bit, meg a negatív is ennyi, azaz 32768 lépcső. Most attól tekintsünk el, hogy a nulla ebben az értelemben pozitív szám, ezért eggyel több negatív értékünk van. Tehát, ha valaki odalép a lábdobra, akkor 15 bitnyi dinamikánk van, mert megjön annak a másik fele a visszalendülő membrán formájában.

    Amúgy valóban értelmezés kérdése, hogy Vp, vagy Vpp legyen a dinamikatartomány. Én a Vp-t értelmesebbnek érzem, de attól még kétszer akkora számábrázolás kell, hogy beleférjen a Vpp.

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

    Hát egy teljes szinuszjel félperiódusa valóban szükségszerűen maximum 15-bites felbontással bírhat, na, de képzelj el egy félszinusz jelet, aminek csak a pozitív vagy csak a negatív félperiódusa van meg és máris van egy szinuszos félperiódusod, ami 16-bites felbontású. Nem csak szinuszos jelek vannak, sőt, továbbmegyek: nem csak periodikus jelek vannak. A 16-bites dinamika az 16-bites és nem 15.

    Oldschool Computer - http://oscomp.hu

    Persze, csak azt nem teheted meg, hogy leülteted DC-ben -32768-ra, majd várod a hatalmas lábdobot 16 bit dinamikával, mert sajnos lesz negatív kilengésünk, illetve negatív irányban nulla lesz a vezérlési tartományunk. De jó, elfogadom, hogy az iparba sajnos beköltözött a marketingesek kényszeres nagyotmondó hazugsága, így aztán teljesítményben is a minél nagyobb számok kimondhatósága érdekében nem effektív teljesítményt mondanak, hanem pillanatértéknyi csúcsot, amely az effektív kétszerese, de eltérő időpillanathoz tartozóan ideveszik a negatív csúcsot, és hozzáadják, ami már a négyszeres, csak épp fizikai tartalom nincs mögötte.

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

    Már nem tudlak követni... Hogy jött ide a marketing? Ez matematika. Oké, lesz negatív kilengés, negatív irányba nem tudjuk vezérelni (a lefutó éllel amúgy nem ezt csináljuk?); na, de a pozitív kilengés hozni fogja a 65536 szintet? (És a negatív kilengés ekvivalens lesz a pozitívval?)

    Oldschool Computer - http://oscomp.hu

    OK, valójában csak annyit mondok, szimmetrikus range-re van szükségünk, s az én értelmezésemben a Vp lenne a dinamika, ami 16 bites számábrázolás esetében 15 bit. De el tudom fogadni, hiszen végső soron definíciós kérdés, hogy az iparban itt Vpp-vel számolják, ennélfogva a full range 20 * 16 * ln(2) / ln(10) = 96.33 dB-ről beszélnek, miközben a szívemhez a half range 20 * 15 * ln(2) / ln(10) = 90.31 dB értelmezés állna közelebb.

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

    Ha szimmetrikus range-re van szükség, akkor valóban minden tartományt automatikusan felezel, de nem csak szimmetrikus jelek vannak. A fizikai részhez nem értek, de annyi azért még nekem is lejön, hogy ez nem olyan egyszerű, hogy lefeleződik: matematikailag a 16-bites dinamika az annyi, amennyi, ha ennek fizikai korlátjai vannak, akkor arra inkább azt lehet mondani, hogy kevesebb, mint 16 - mert veszteség/csillapítás/kilengés/visszalengés/torzítás/mittudomén - de nem feleakkora...

    Oldschool Computer - http://oscomp.hu

    Azt akartam mondani, hogy a membrán középen áll, 15 bitnyi vezérlés után fog koppanni, nem pedig 16 bit után. Értem, hogy két koppanás között 16 bit utat tesz meg, ezért mondom, hogy definíciós kérdés, de hozzám az a szemlélet áll közelebb, hogy nyugalomból koppanásig mennyi mozgásterünk van.

    Lényegi vita egyébként szerintem nincs közöttünk. :)

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

    A membrán analóg módon viselkedik, ezt így nem lehet ráhúzni, hogy 15 bitnyi vezérlés után koppan; az akkor koppan, amikor a jelszint nem nő tovább. Az rendben van, hogy fizikailag a dinamikatartomány a nyugalomtól a koppanásig terjed, csakhogy a nyugalmat nem a nullás szint fogja eredményezni, hanem a nulla változás. Ha a jel végig a 3000-es szintből áll, akkor ugyanúgy csend lesz, mint ha végig 0, vagy végig -5000 lenne. Ennek megfelelően a koppanást sem a maximum szint fogja eredményezni, hanem a maximum változás. Egy 16-bites tartományban pedig a maximum változás az 65535 lesz és nem 32767. Ha a jeled nyugalmi szintje -32768 és te innen csinálsz egy - bármilyen felfutású - impulzust, ami eléri a +32767-et, akkor az bizony 16 bitnyi vezérlés után koppantja a membránt.

    Vagy rosszul gondolom?

    Oldschool Computer - http://oscomp.hu

    Hiba volt részemről ezt írni, elismerem, célszerűbb lett volna megmaradni az erősítő kimeneti feszültségénél. Egy lineáris egyenáramú villamosgép, ha úgy tetszik, lineáris motor, amelyik a membránt mozgatja, mozgásában egy ideális világban integrálja a feszültséget elmozdulássá. Ugye az indukált feszültség a sebességgel arányos, s ez tart egyensúlyt az erősítő feszültségével. Tehát nem a membrán pozíciója, hanem a membrán sebessége arányos a pillanatfeszültséggel, a pozíció pedig a sebesség idő szerinti integrálja. Már persze, ha nem lenne a tekercsnek és a hozzávezetésnek ellenállása. De van. Így aztán végső soron a membrán kitérő pozíciójában tartásához kell egy erő, amely az árammal arányos. Ha már nem mozog a membrán, az indukált feszültség nulla, az áram prdig a tekercset tápláló feszültség és a tekercs ellenállásának hányadosa.

    Továbbra is azt mondom, az definíció kérdése, hogy mit tekintünk dinamikának, hozzám közelebb áll a Vp értelmezés, de ha az audio szakmában mindenki a Vpp-t használja, én el tudom ezt is fogadni.

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

    Bocs, de ez a fizikai rész nekem nem teljesen tiszta. Egy -32768-as nyugalmi szintről +32767-ig felfutó impulzus, ami 16-biten ábrázolható változást okoz, az 16-bitnek megfelelő vezérlésként jelenik meg a membránon, vagy sem? Amikor kiadok egy -32768-akból álló jelet, akkor a membrán középen áll, nyugalmi állapotban?

    Oldschool Computer - http://oscomp.hu

    Összetett a dolog, mert nem szupravezető a tekercs, nem végtelen a membrán mozgásának úthossza. Az a lényeg, hogy elvileg a feszültséggel a membrán sebessége volna arányos, nem pedig a pillanatnyi helyzete. Ugyanakkor azért írtam mögé a kiegészítést, mert jön majd valaki, hogy kipróbálta, és azt tapasztalta, hogy 1.5 V DC-re kimozdul 0.5 cm-t, míg 4.5 V DC-re 1.5 cm-t, tehát nyilván hülyeséget beszélek, mert a tapasztalat nem hazudik.

    Igen, csak ekkor már a membrán nyugalomban van, és az áram arányos lesz a feszültséggel, az árammal meg az erő, s ha a kitérés függvényében lineárisan nő a visszatérítő erő, valóban ez lesz a tapasztalat. És ekkor van az, hogy egy ilyen szkeptikus embernek nem fogom tudni elmondani, hogy pedig de, inkább a sebességgel arányos a feszültség.

    Amúgy meg kicsit ez is, az is, mert nem hanyagolható el a tekercs ellenállása, a megmozgatott levegő mozgatásához szükséges erő, a membrán rögzítéséből fakadó visszatérítő erő.

    Mondom, ha rákötsz konstans 20-at, akkor megy a végtelenségig előre, kimegy a Naprendszerből. :) Ha 40-et mondasz neki, ugyanezt csinálja, csak kétszer gyorsabban. Csak ugye, nem végtelen hosszú az az út, ahol a membrán mozoghat, hanem néhány mm. Meg amiket fent még mondtam.

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

    Most vagy én vagyok túl hülye, hogy nem értem a válaszodat, vagy tényleg nem válaszoltál a kérdéseimre?
    Engem az érdekelne, hogy ha a membránra kiküldünk egy olyan lapos jelet, ami nem a nullszintből, hanem az abszolút mínuszból (-32768) áll, akkor a membrán nyugalomban lesz-e, vagy csinál valamit? És ha nyugalomban van, akkor, ha innen a jel felfut +32767-ig, akkor 16-bitnyi vezérlést kapott a membrán?

    Oldschool Computer - http://oscomp.hu

    Ha kiküldesz neki konstans -32768-at, akkor iszonyú gyorsan a végtelenségig hátrál a membrán, csak most a másik irányban hagyja el a Naprendszert. :) Ugye a sebesség lenne arányos a feszültséggel, nem a pozíció. Ugyanakkor valójában 1 - exp(-t / T) szerint be fog állni valójában valami megszeppent, beszívódott pozícióba, mert van ellenállása a tekercsnek, meg egyre nagyobb erőt kell kifejtenie, hiszen a rögzítés a széleken húzza vissza nullpozícióba.

    A második kérdésed nyilván arra utal, amiről a thread szól, igen, ez valóban a full range, azaz 16 bit. Viszont erre mondom, igaz, hogy 16 bit van két koppanás között, de a nulla bázishoz képest csak 15 bit van. Akár le, akár fel.

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

    Aha, na ez nem volt meg, hogy a membrán nem a jelszint változására reagál, hanem a maga a jelszint adja meg neki, hogy melyik irányba mekkora erővel lökődjön ki, tehát, ha 5000-re kiengedek egy 3000-et, akkor nem hátrafele fog kilökődni, hanem csak csökkenni fog az előre kilökődés mértéke. (Hiába, én nem vagyok fizikus.) Köszi.

    Innentől akkor tényleg definíciós vita, hogy a membrán dinamikatartományát a két koppanás, vagy a nyugalmi állapot és valamelyik koppanás közti tartomány jelenti. Viszont én kóder vagyok, én a teljes tartományt nézem, kopptól koppig, már csak azért is, mert mozogni mind a két irányba tud, ami azt jelenti, hogy a teljes mozgástér az 16-bittel vezérelhető, nem 15-tel, hiszen két irányba kell vezérelni.

    Oldschool Computer - http://oscomp.hu

    "15 bitnyi vezérlés után fog koppanni" - melyik irányban? Van a 0...X mV-os bemenő jeled, ezt kvantálod 16 biten, amely 16 bitet értelmezheted 0..65535 közötti diszkrét értékekként, de ugyanúgy -32768...32767 tartományra is leképezheted - egy egységnyi különbség ugyanakkora feszültségszint-beli eltérést fog adni mindkét esetben, mert a signed/unsigned csak a bitminta értelmezésére, nem pedig az értéktartomány nagyságára van hatással.

    Mindkét irányban. Tekintsünk el attól az egyetlen lépcsőnyi különbségtől. Így van, irreleváns, hogy kettes komplemens signed int16_t, vagy 0x8000 offsettel rendelkező unsigned uint16_t ábrázolást használsz. Jobban belegondolva csupán annyi a különbség, hogy az MSB épp a negáltja egymásnak a két ábrázolásban.

    Én mindvégig arról beszélek, hogy az én szubjektív világomban az a dinamika, ami a nyugalmi pozíciótól a falig van, nem pedig az, ami az alsó és felső koppanás között van, de el tudom fogadni azt is, ha az ipar szerint ez utóbbi. Számomra nem logikus, de olyan ez is, mint az 'ly' a nyelvünkben, együtt tudok élni vele. :)

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

    A 24 bit se valós előny. Ennek az az oka, hogy a valóságban az elektronika, a hangkeltők (hangszóró, fülhallgató, stb.) mechanikája és az emberi idegrendszer analóg módszerekkel elmossa a felbontásbeli egyenetlenségeket: lásd erről videó. A nagyobb bitmélység az a noise floort tudja lejjebb vinni, egy szinten túl csak nincs előnye, de legalább nem is káros, és a digitális helyfoglalást nem növeli számottevően. Viszont a high res (értds magas sample rate) káros, mert az ultraszónikus felharmonikusok interferenciát okoznak.

    Ennek a high res, high bit depth témának akkor van értelme, ha stúdiód van, és tovább vágod, mixeled a hanganyagot, és abban emiatt nagyobb tartalék van, amiből úgy tudsz még információt veszteni, hogy emberileg érzékelhetetlen lesz. De nem is emiatt hoztam fel, hanem ez is egy audiophil hülyítés, el tudnak adni sok idiótának extra pénzért kiadványokat, meg overkill hardvert, és pszichológiailag annyira hisz benne, hogy tényleg jobbnak is hallja (placebo-hatás), kivéve, mikor vaktesztre kerül a sor, mert ott kiderül, hogy nem hall szart se, csak tippelget, és statisztikai alapon 50-50% körüli találati aránya van.

    Ugyanaz a kategória, mint az aranyozott csatlakozók, meg a többi pénzlehúzós baromság.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    szep ahogy magad is elhiszed a bullshited, de javasolnam nezz utana ha tudsz, fentebbi xiph-es videokat, ugye!? megnezted mar?

    indulasnak segitek kicsit:

    https://www.youtube.com/watch?v=-jCwIsT0X8M
     

    kulcsszavak: kvantalas, dithering, aliasing, AD/DA konverzio, Nyquist

    csak mondom, hogy pl. a 48kHz-es mintavetelezes nem azert lett, mert a 44.1k keves lett volna a 20kHz+szurest lefedni, hanem mert kompatibilisnek kellett lenni az akkori videoformatumokkal. https://en.wikipedia.org/wiki/Sampling_(signal_processing)#Audio_sampli…

    a bitekkel is biztos hadilabon allsz, mert a nagyobb jobb... janem :D https://en.wikipedia.org/wiki/Direct_Stream_Digital

    a hiperaudiofil SACD is 1 bites

    csak mondom, hogy az SACD-ket annak idejen jellemzoen mas masterbol nyomtak, hogy legyen barmi kulonbseg az egyebkent CD-re is kiadott anyaghoz kepest. ha ugyanaz a forras, a ket formatum egyforma korulmenyek kozt lejatszva ugyanazt a vegeredmenyt adja.

    felreertes ne essek, mindenki abban hisz amiben akar, pont leszarom, de az teny, hogy zenesznek/audiofilnek mindent es barmit is el lehet adni (disclaimer: zenelek 30+ eve) :)

    a koncertelmeny otthoni reprodukcioja pedig nem a bitek miatt lehetetlen (nem, nincs akkora dinamikatartomany es jel/zaj arany ott sem), hanem mert nem fogsz tudni olyan hangnyomast/teret letrehozni. es a koncerttermet meg szinhazat sem tudod hazavinni. ez mar csak ilyen :)

    szerk: ertsd jol! ha egy hangmernokot megbizol azzal, hogy az ujrakiadott SACD jobban szoljon, a mernok penzert megcsinalja ra a jobban szolo mastert.

    Az Apple asztalin és a Windowson is működik, nem vagyok süket hallom a különbséget, a többi f@szságot meg pont le szarom. Aztán meg 2 különböző anyagnak hogy a tökömbe lehet azonos a forrása, na mindegy ezt is le... 1% a többi 99% meg bullshit hívő.

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    Na jó, de te most a különböző hangkártyákról beszélsz, amit valóban nehéz jól csinálni, mert egy digitális zajos környezetben kell kiszajú analóg jelet létrehozni, ami nem triviális. Amúgy simán el tudom képzelni, hogy a hangkártya túlmintavételezi a jelet, és két lépcső között interpolál, szóval van itt azért mozgástér, ha valamelyik gyártó nagyon nekifeszül. Ezzel persze látszólag ellentmondtam magamnak, de nem kell a resampling, ha igen meredek aluláteresztő szűrőt tudunk csinálni. A gond az, hogy ezt digitálisan lehet csak, de akkor meg mégis kell a resampling és nagyobb mintavételi frekvencia.

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

    "de ez nem jelenti hogy ha hasonlítgatnom kéne akkor megtudnám különböztetni." vs "nem vagyok süket hallom a különbséget," < onellentmondas lvl100 :D
    "Aztán meg 2 különböző anyagnak hogy a tökömbe lehet azonos a forrása" < ezt hivjak remasteringnek, a legnagyobb zeneipari "atveresek" egyike. egy lejatszott dalnak csak toredeke az eloado(k) mit/hogy/mivel jatszottak le es lett az felveve, aki azt osszemixeli, lekeveri, mastereli, annak a modern eraban sokkal nagyobb szerepe van, rajta mulik, hogy "jabbanszol", o rakja ossze a hangkepet, ad teret a hangszereknek azzal, hogy elhelyezi oket a mixben: volume, stereo panning, EQ, EFX. ez igaz az elo koncertekre is egyebkent.

    az agyad barmire kepes. az ember nem csak a fulevel hall (ami mar a CD felbontasanak is csak a toredeket kepes erzekelni, FYI)

    az a baj, hogy kevered a szezont a fazonnal, azok a magas mintavetelek amikrol szo van felvetelkor es reprodukciokor irrelevansak, a digitalis processzalaskor van (vagy nincs, ez attol fugg milyen digitalis effekteket hasznalsz) szerepuk. nincs olyan analog eszkoz ami akar kozelebe tudna erni ezen felbontasoknak sem dinamikatartomanyban, sem frekvenciatartomanyban, sem jel-zaj aranyban. ezek szimpla tenyek, ABX tesztekkel bizonyithatok. a "jabban szol a basszus" a bullshit, az AD/DA konverzio meg matek, az eloallitott waveform pedig scope-pal merheto.

    az ember agya pedig lazan elhiszi, hogy valami jobban szol mar csak a latvany alapjan is (ahogy a karma megbosszul, meg van szerencsed, meg az istenek is melletted allnak). ha neked egy dragabb termek azt az erzetet nyujtja, hogy faszabb a sound, akkor a marketing bullshit elerte a celjat, Te vagy a celkozonseg.

    mivel a matek/fizika/biologia es a labortesztek lathatoan nem erdekelnek, mert leszarod, kar is vitaznunk, hiszen tudod. ahogyan a "bolond" is _tudja_, hogy neki 3 karja van, akarhogyan is probalod neki elmagyarazni, hogy nem, csak 2 van. mert tudja :) engem mar meggyoztel.

    "a neked egy dragabb termek azt az erzetet nyujtja, hogy faszabb a sound, akkor a marketing bullshit elerte a celjat, Te vagy a celkozonseg."

    Azta remélem ezt el is hiszed:))))  Nem mellesleg, nekem nem kell elhinnem semmit, iTunes  - zene - váltogatás. A 32le/96000 olyan hangokat és hangszereket add vissza amit alatta nem is hallani.  Aztán mivel nem "szögletes a jel"  ha felhangosítod max hangerőn is kristálytisztán szól, míg alacsony értékek (pl 44.1 / 16bit) mellett 50%-on torz szarkása  és majd kiugrik a membrám. Szóval ennyi baromságot összehordani:))) 

    Már azt hogy ezt valaki megkérdőjelezi is szégyen!

    "ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

    és 100 éve még boszorkányt is égettek 

    ( locsemege v | 2021. 12. 13., h – 12:58 )

    0.3.41

    Hosszú idő után jelent meg és rossz! Lehet, hogy csak nálam, de nem valószínű, mert szabványos USB-s device felé nincs hangja. Vissza kellett tennem a 0.3.40-est, szóval lehetőleg kerüljétek még ezt a legfrissebb verziót.

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

    Pedig pont most...

    :: Synchronizing package databases...
 core is up to date
 extra                                         1585.1 KiB  5.27 MiB/s 00:00 [##########################################] 100%
 community                                        5.9 MiB  13.3 MiB/s 00:00 [##########################################] 100%
 multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (9) alsa-card-profiles-1:0.3.41-1  lilv-0.24.12-4  lv2-1.18.2-1  pipewire-1:0.3.41-1  pipewire-pulse-1:0.3.41-1
             serd-0.30.10-1  sord-0.16.8-1  sratom-0.6.8-3  wayland-1.20.0-1

Total Download Size:    2.41 MiB
Total Installed Size:  12.73 MiB
Net Upgrade Size:       4.01 MiB

:: Proceed with installation? [Y/n]

    ... :D

    Arch Linux [Sway WM]

    Hardware függő, a kis notebook-omon nekem is működik. USB-s mikro hifi cuccal nem megy. Miután visszatettem a 0.3.40-et, minden jó.

    Ha működik nálad, érdemes megtartani. Egyrészt, ha bugreportolsz, azt a friss verzióról tedd, másrészt nyilván egy rakás dolgot javítottak, meg lettek új feature-ök is.

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

    Valóban volt néhány bug ebben a változatban. Az a hiba, ami nálam előjött, egy automatikus visszhangelnyomással összefüggő bug, tehát csak azoknál jön elő, akik használják az echo cancellation-t. Miután erre rájöttem, szóltam Wim Taymans-nak, aki azonnal revertelte azt a commitot, amely a regressziót okozta. Akinek tehát kell az echo cancel, az vagy használja a 0.3.40-es pipewire-t, vagy húzza ki git repóból a legfrissebb forrást, ahogyan én is tettem, fordítsa le magának, majd telepítse fel a gépére, végül pedig a két releváns socket-re mondjon restart-ot.

    Talán emlékeztek, a pulseaudio recsegése-ropogása kapcsán Lennart Poettering nem volt hajlandó workaround-ra, inkább izomból leugatott mindenkit, hogy ez alsa bug a kernelben, ő nem hajlandó javítani. Ezzel szemben Wim Taymans:

    ALSA devices now keep track of the samplerate of the card and ensure that all PCM use the same rate. This is a workaround for a kernel bug that is fixed in 5.16.

    (forrás)

    Ez egy elég szignifikáns hozzáállásbeli különbség.

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

    OT

    no és hány verzió jött ki ugyanennyi idő alatt a PA-ból? Mert lám, javították a kernelben az ALSA-hibákat, most már a PA-felhasználóknak csak azt kell megvárniuk, hgy nekik is ilyen újabb kernelük legyen, és máris náluk se fog recsegni :-)

    /OT

    tl;dr
    Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

    De jó! :D A magam részéről PipeWire rajongó vagyok, mert régóta követem a project fejlődését, olykor hibajelentésekkel, infóval segítem a javítását. Meg aztán jók a tapasztalataim, nem falja fel a gépidőt, s nem esik szét a hang folyamatosan underrun-nal.

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

    ( locsemege v | 2021. 12. 16., cs – 11:15 )

    0.3.42

    This is a quick emergency release to fix some severe problems with the previous release.

    Highlights

    • Fixes a bug in pulse-server underrun handling that broke qemu and orca.
    • A fix was added to pulse-server to handle quantum changes gracefully.
    • Fix module-echo-cancel again.
    • Fix a bug where the bluetooth headset capture was producing noise.

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

    ( locsemege v | 2021. 12. 16., cs – 12:42 )

    Szerkesztve: 2021. 12. 16., cs – 22:38

    Ha már belejöttem a forrásból fordítgatásba, 15ce86af commitig bezárólag fordítottam le és telepítettem fel magamnak, működik is jól. :)

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

    ( locsemege v | 2022. 01. 27., cs – 12:28 )

    0.3.44

    Nagyon sok, nagyon szép javítást és fejlesztést tartalmaz. Szerintem ez egy jól sikerült kiadás, érdemes kipróbálni. Nem azért állítom, mert lett volna sok időm tesztelni, ahhoz túl friss. Az ezen változathoz vezető úton napi szinten build-eltem, amit aztán fel is telepítettem a gépemre, s ezáltal a mindenkori legfrissebbet használtam. Nem voltak komolyabb anomáliák, elrontások benne, legalább is, ami nálam előjött volna.

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

    Nálam már ez a verzió duruzsol.

    A lib32-pipewire csomag mennyire szükséges régi retro, Steam etc. játékokhoz? Mondjuk szerintem a pipewire-alsa -ra sincs szükségem.. :) fogalmam nincs ezeket miért telepítettem fel.

    Arch Linux [Sway WM]

    Fogalmam sincs, de igazából elég kicsi a kód ahhoz, hogy ne kelljen azon gondolkodni, mit telepítesz fel. Ez csak egy embedded rendszernél, például egy picike szappantartó routernél lenne érdekes, de jellemzően arra meg nem kell multimédia szerver. :)

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

    0.3.6-os pipewire? Azóta új létformák vannak a Földön, befejezték a piramisok építését, feltalálták a számítógépet, meg ilyesmi. :) Ez egy regresszió volt, a Zoom jól ment 0.3.43-as pipewire-rel, majd 0.3.44-ben elromlott, de azóta Wim betolt ezzel összefüggésben kb. három commit-ot, amelyek javítják a regressziót.

    Crackling sound in Zoom since 0.3.44

    Release-ben még nincs javítva, hiszen nem lett kiadva 0.3.45, viszont git repóból kihúzva, majd lefordítva a forrást, jó lesz.

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

    Egyelőre csak ha nagyon kell, akkor megyünk/mehetünk(!) be a munkahelyre, úgyhogy csak ezt kipróbálni nem igazán hiszem, hogy bemennék.
    Itthon Windows10(+wsl)-t használok (céges gép, így legalább nem nekem kell ezzel is foglalkoznom, hanem a desktop supportnak...) - azon meg yool megy a Zoom - ha meg bent kell zoomolni, akkor úgyis viszem a notebook-ot, és azon megy, de köszönöm.

    Na, most már ilyen előzmények után fogod megérteni, hogy miért létezik a rolling, és egyes emberek, mint én is, miért nincsenek oda a Debian, meg Ubuntu LTS, Mint, Elementary, Slackware, egyebekért. Mondjuk a CentOS-en meglepődök, mert ott a Stream-nek elvileg már friss rollingnak kéne lennie. Egyébként ha nem ragaszkodsz a CentOS-hez, akkor a szintén rolling (jó, csak félrolling) Fedorában minden a legújabb verzió, néhány csomagnál még az Arch-ot is megelőzik frissességben. Esetleg CentOS Stream 9-es is kint van már.

    Nekem hajbazer se hiszi el, hogy nem én vagyok fejlődés/frissességmániás, annak ellenére, hogy se babzsákfejlesztő, se mérnökúr nem vagyok, meg IT multinak se dolgozok.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    RHEL7/RHEL8 meg OEL8 van bőven, és azok "mellé" a CentOS a  jobb választás, mert így speciálisabb dolgokat is ki tudok próbálni a saját gépemen. Nem igazánnézelődtem egyébként, hogy hol lehet a probléma Zoom+CentOS8 között, mert tényleg ritka, hogy a benti gépről kéne Zoom-ot használni, ergo "nem fáj annyira" hogy utnánamenjek...

    Na, ez a tipikus eset, mikor nem a rendszerkomponens (pipewire) van eltörve, hanem egy visszafelé kompatilibitás hiányában törik el az alkalmazás, ilyenkor az adott alkalmazás fejlesztőjének a feladata, hogy elhárítsa a gikszert.

    Nekem is a 0.3.44 van fent ebből a Pipewire-ből és hibát nem tapasztaltam. Vagyis frissítésnél megszopatott, mert befrissült, és erre elkezdett akadozni böngészőben videó alatt a hang, de gyorsan rájöttem, hogy újraindítás kell neki, hogy rendesen életbe lépjenek a friss binárisok, újratöltődjenek, és lőn, így is lett, újraindítás után nem jött elő ilyen probléma. Most már egy jó ideje játékok alatt is tesztelem a Pipewire-t, natív linuxos, Wine emulátoros, Steam/Proton-t használó játékok és egyikkel sincs hanghiba, jól vizsgázik ez az új hangrendszer, a szoftverek rá sem jönnek, hogy nem Pulseaudio/ALSA fut. Ilyen OBS, audio, DAW, konferenciahívásos szoftverekkel nem tudom tesztelni, mert nem használok ilyeneket.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    ( locsemege v | 2022. 02. 17., cs – 23:20 )

    0.3.46

    Sok fontos és szép javítás.

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

    Emiatt a fos miatt (pontosabban az arch linux stable brancre csorgatott bugok miatt) váltok debian 11-re 10 év arch után. Úgy esik kel ahogy kell ez a pipewire és a barátai ( https://wiki.archlinux.org/title/PipeWire#Session_manager )

    Azért debian 11-re mert abban nincs defaulton bekapcsolva.

    Az https://wiki.archlinux.org/title/Archinstall használatával telepitettem az arch linuxot 2-3 hónapja. És az felrakta.

    Egyébként úgy gondolom hogy lényegtelen, ha most kézzel telepitesz arch linuxot akkor is húzni fogja magával. A csomag dependenciák már úgy vannak összerakva, hogy a pipewire van a pulse helyett is, nem tudod letörölni, mert akkor törölni akarja a fél rendszert magával, és pulse -val sem lehet helyettesiteni.

    Igazából nem is a pipewire a gondom hanem az hogy az archosok hajlamosan stablre ágra hozni upstream verziókat úgy hogy nem tesztelték ki alaposan..

    Kézzel húztam tegnap a rendszert, de megnéztem most és ha pulse-t akarok telepíteni akkor törli a pipewiret, szóval lehet nélküle is telepíteni. Annyi, hogy majd vernyákol, hogy pipewire-pulse törlésével megtörik a gnome-bluetooth (legalábbis nálam kell a bluetooth), de egy pulseaudio és pulseaudio-bluetooth csomag egyidejű telepítése megoldja ez a gondot, újraindítás után pulseaudio fogad.

    A pipewire media session egy minimalista demó verzió, amelynek az a célja, hogy bemutassa a programozóknak, hogyan lehet session manager-t írni, azt a pipewire ökoszisztémába ágyazni. A rendes, valódi session manager valóban a wireplumber. Úgy tudom, lehet session manager nélkül is üzemeltetni, de talán csak a Jack interface-en, s csak a legújabb változatok óta.

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

    Az a baj hogy az arch linux átveri az embert, mert olyan dolgok megtanulására és konfigolgatására kényszeriti időnként amik totálisan nem érdeklik. Van-e hang, az a kérdés. Igazából nem is a pipewire okozott nekem gondot, hanem az arch. Ubuntu 21.10-en is pipe van, és nincs semmi baja. Sőt, media session is van.

    Akkor en valami kulonleges ufo lehetek, mert nekem meg a bloat disztrokkal volt az, hogy allandoan szopni kellett valamivel, Arch alatt meg max egyszer tolok egy konfigot a kis minmal wm alatt es az onnan beton. :)

    A Pipewire tortenetesen ket kulonbozo architecturan is tokeletesen mukodik.(x86, ARM) Egyiken Arch van telepitve, a masikon pedig egy Manjaro. Mindketto minimal.

    Arch Linux [Sway WM]

    Omen by HP 2020 (Ryzen) + nvidia 1650.

    Frissités után nem ment a suspend. A hang boot után ~15 percig megy, aztán lefagy.

    A hálózat egy az egyben meghalt, reboot sem segitett. Ezek mind frissitések után jelentkeztek.

    Lezúztam az arch -ot, felraktam az Ubit és mind megjavult, tehát nem hw issue.

    Egyébként lehet hogy az archinstall csinált néhány rossz alapbeállitást, mert azzal raktam fel, ki tudja. https://wiki.archlinux.org/title/Archinstall

    Ha már volt official installer, gondoltam nem lehet rossz, de lehet hogy mégis.

    Hát, az archinstallal nekem is volt most rossz tapasztalatom, konkrétan egy HP microserver gen8-on elvérzett, végig sem csinálta a telepítést. Gyakorlatilag csak a base rendszer kicsomagolását végezte el, és ott elhasalt, bár a kimeneten csak az látszott, hogy a grub telepítéssel volt valami fail. De sem a locale, sem a konzol, sem a net, sem a jelszavak beállítása nem futott le pl. Arch-chroottal hagyományos úton meg gond nélkül befejeztem a telepítést.

    Systemrescue esetleg ér egy próbát, arch alapú, ha azzal megy, akkor telepítési, beállítási gond lesz. Persze csak ha akarsz még vesződni vele. Ja, és pont itt is előjött, hogy a linux-firmware csomag megbontása miatt volt hiányzó firmware (külön csomagba került). Mondjuk ez nem frissítés után jönne elő, hacsak nem régebbi a telepítőd mint ahogy ez megtörtént.

    Nem tudom, milyen környezetben használod, nekem több gépen is beton stabilan megy. Volt persze olyan, hogy elmúlt a hangja echo cancel használata esetén. Jeleztem a bugot, adtam elegendő információt, Wim revertelt egy patch-et, azóta megy szépen. De ez is hónapokkal ezelőtt volt már, ha jól emlékszem.

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

    ( SPYFF v | 2022. 02. 18., p – 23:08 )

    Jött egy Manjaro update és lőttek a hangnak :( USB-s mikrofonom megjelenik de hangot nem érzékel rajta. Három órányi körkörös dependencia meg szívás után sem sikerült visszaállnom pulse-ra, végül valami hangot kitapostam belőle, mikrofon továbbra sem jó.

    ( locsemege v | 2022. 02. 19., szo – 00:06 )

    0.3.47

    This is a quick emergency release to fix some severe problems with the previous release.

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

    ( locsemege v | 2022. 04. 14., cs – 09:52 )

    0.3.50, persze volt előtte 0.3.49 is. :) Remekl működik.

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

    Dettó. Továbbra sincs vele problémám, pedig már hosszabb távon tesztelem én is. Igaz a Pulseaudio-val sem volt gondom előtte, max. csak ilyen filozófiai szinten bloatságával. Ez a Pipewire se soványabb, eleinte memóriafogyasztásban vékonyabbnak tűnt, de mióta lapátolják bele a funkciókat, meg megérkezett bele ez a Wireplumber, azóta ebben a tekintetben is egálban vannak, de már ez is pozitív, hogy egy új hangrendszer legább még bloatabb, még szarabb nem lesz.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Nem néztem a memory footprint-jét mostanában. A PA-val nekem az volt a gondom, hogy VoIP alkalmazással recsegett-ropogott a hang. Bizonyos bolygóállások mellett jelentősen megemelkedett a CPU használata, és úgy 20 - 25 % fölött - egy magon természetesen - teljesen szétesett a PA hangja. Ezzel szemben a PW nem őrül meg, alig néhány százaléknál CPU-nál nem eszik többet, a hangja stabil, nincs rendszeres buffer underrun, mint volt a PA-nál.

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

    ( locsemege v | 2022. 04. 30., szo – 12:39 )

    0.3.51

    Már elég jó ahhoz - egyáltalán nem tapasztalok hibát -, hogy leszoktam a git repóból kihúzásról és forrásból fordításról.

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

    Engem nem érdekel a pipewire verziója, szállítsa le a distro a megfelelőt és kész.

    Egyébként pont az ilyen forever beta szutykok miatt váltottam el archról. Havonta egyszer biztos meghalt a hang emiatt a fos miatt, a végső döntést meg akkor hoztam meg amikor mellé a hálózat is beszart valamelyik másik forever beta miatt (talán a systemd-networkmanager-akármik környéke).

    Számotokra van jelentősége?

    Lehet igazad van, nem futottam ebbe bele, de lehet az extrém minimalizmus miattt. Nem használok túl bonyás audió/streamelős progikat (pl. OBS, LMMS, MusE, stb.), illetve networkmanagert, netctl-t, stb.-t sem. A hálózatot nálam szimplán dhcpcd és az xinitrc-ből vagy bspwmrc-ből indított wpa_supplicant kezeli, ennek csak az a hátránya, hogy nem olyan kényelmes hálózati kapcsolatot váltani (pl. másik SSID-re, bár többféle konfigfájlt előre legyártva, dmenu scripptel menne), meg ha leszakad a kapcsolat, magától nem kapcsolódik újra a rendszer (erre is tudnék egy shell scriptet írni, ami életben tartja), de ez nekem teljesen megfelel, egyféle eth és/vagy wifi/SSID kapcsolatot használok csak, minden gépen, fixre drótozva, ha meg leszakadna, gyorsbillentyűm van az újrakapcsolódásra. Plusz nincs tálcaapplet, de tálca sem, csak lemonbar panel, azon sincs systray. Nincs login manager, dokk, asztali ikonok, értesítések, stb. sem, se homed, se networkd. Pont azért is használok Linuxot, hogy ne fusson mindenféle bloat sallang a háttérben. Bár így is van, ami mégis fut, mert nem lehet tőle szabadulni, systemd, pipewire vagy pulseaudio (nekem elég lenne a sima ALSA, ha nem dependelnének programok állandóan valami bloatabb megoldásra), d-bus (ez sajnos sok alkalmazásnak kell), a Firefox betölt az Orca olvasója miatt két at-spi szutykot.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Nekem standard Ubuntum van. Érdekes lehet összekonfigolgatni ezeket a minimum környezeteket, meg szépen kioptimalizálni mindent, de ismerjuk a rohanós világról alkotott képet :D

    Sőt, archon is sima gyári gnome desktopot toltam. Ezektől elvárom hogy össze legyenek rakva, ne az én melóm legyen. Aztán az hogy 250MB helyett 2GB ramot eszik meg, etwas, hiszen 20GB ramom van.

    Nem csak a memória, mert az nálam is van minden gépen 16 giga. Hanem hogy ha felesleges dolog nem fut a háttérben, akkor nincs ami eltörjön, meg kevesebb sallang frissülget állandóan. Plusz a RAM-on kívül sebességben meghálálja magát, minden a képernyőre pattan, nincsenek töltési idők, nincsenek splash screenek, nincsenek mikrolagok.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Igen, ez szélsőséges minimalizmus, minimál WM, terminálos-billentyűzetorientált workflow. Mert nem mindenki akarja a jelenleg szokásos Linux desktop bloatságát, ami onnan indul, hogy mindenféle deamon meg applet, bloat fut a háttérben, és boot után idle-ben onnan indul az ember, hogy bekajált a rendszer 1 giga RAM-ot, és még innen további leakelgetés van. Mert azt kell érteni, hogy nincs mindenkinek igénye erre. Minek lenne nekem a háttérben mindenféle extra szolgáltatás, meg NetworkManager hálózati applet a tálcán, ha egyszer úgyse használnám, csak egyféle eth vagy Wi-Fi kapcsolattal használom a gépet, helyben, non stop? Egyszerűen ha megvan az embernek a fix beállítása, toolsetje, onnantól úgyis csak azokat használja, és át tud ugorni, ki tud hagyni egy csomó komplexitást az egész rendszerből. Bloat rendszer van elég, MacOS, Windows, egy csomó mainstream desktop environmentes disztró, azokat bárki fel tudja tenni, és elég hasonló desktop élményt kap rajtuk, de nincs szüksége mindenkinek erre.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Egyfelől igazad van, másfelől nem okos szappantartót, azaz otthoni routert kell használni desktop célra. :) Mit aggódjak 8 magos Ryzen 7-tel, 32 GiB RAM-mal azon, hogy fut a NetworkManager, de legalább kényelmes? Amúgy egy cseppnyi minimalizmus bennem is van, mert ezen a gépen Xfce a desktopom Compizzal.

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

    Már az Xfce sem annyira minimalista a Gtk3-ra átállással, mint régen, és még régen is elmaradt soványságban az egyszerű WM-ekhez képest. Ez nem a memórián múlik, mert nekem is 6-8 magos Ryzen-jeim vannak 16 giga RAM-mal, és beleférne az erőforrásokba, de nem akarok, hogy felesleges dolog fusson. Hiszen ha nem fut, akkor a rendszernek be sem kell töltenie bootkor, ami nem csak memória, hanem időspórolás, meg annyival kevesebb csomag van a gépen, kevesebb függőség, kevesebb cucc, ami frissítéskor update-et húz le, kevesebb kódsor, kevesebb sechole lehetőség, kisebb esély arra, hogy valami funkció egy köztes rétegen keresztülmenve eltörik frissítés után. Hibakeresést, bugok workaroundját, konfigurálást is megkönnyítheti, ha nem kell sok extra réteg komplexitáson átrágnia az embernek magát.

    Hiszen ha csak egyféle kapcsolattal használom a gépet mindig, ami fixre drótozva indul bootkor vagy bejelentkezéskor, akkor mit menedzseljen a NetworkManager a hálózaton? Ha nem váltok kapcsolatot, interface-t, stb.-t, akkor egyszerűen nincs mit rajta menedzselni, feleslegesen futna. Annak, aki mindenféle kapcsolatot váltogat, SSID-t, mert viszi mindenhova a gépet, meg VPN-ekkel variál, annak jól jön, de ez nem mindenkinek use case. Ezt nem tudják a corporate nagyok megérteni, hogy ami nekik kell, az a sok bloat az nem kell minden embernek. Ők is csak azért teszik bele, mert generic OS-ek akarnak lenni, amik jók bármilyen felhasználási célra, de nekem az én gépemre, az én felhasználásomra nem kell generic bicikli pótkerekes megoldás, ami megpróbálja nekem leegyszerűsíteni, elrejteni a dolgokat, meg megszabni, hogy mit hogy használjak, mi merre támogatott, stb..

    Ezt nem tudtad múltkor a Fedora bootjánál megérteni, hogy erőltetnek mindenféle secure bootot, shim-et, GRUB-ot, btrfs-t, talán LVM-et is, nekem meg egyik sem kell, annak ellenére, hogy ezek hasznosak lehetnek valamihez, csak nem nekem, egyszeri desktop usernek, akinek megfelel a titkosítatlan (valójában hardveresen titkosított, de az a szoftveres oldal felé transzparens), egyszerű ext4-es particionálás, egyszerű systemd-boot vagy EFI stub boot a GRUB helyett, ami sokkal egyszerűbb és az én igényeim lefedi. Ugyanez van, mikor elkezdett minden alkalmazás feleslegesen systemd-re, meg pulseaudio-ra dependelni, azok is overkill kategória a legtöbb mindenhez, és rá vannak tolva mindenkire függőségeken keresztül. Nekem egy sysvinit vagy OpenRC is megfelelne, sima ALSA-val.

    És nem, az nem érv, hogy belefér a 32 giga RAM-ba, meg úgyse foglal sokat. Ez igaz, de nem támaszt alá semmit. Ha megnézel egy 15-20 évvel ezelőtti Linux DE-s disztrót, azok megálltak 200-300 MB RAM-ból, kompletten, mindenestől, panelestől, stb.. Jó, azóta komplexebb lett minden, egy csomó security rést betömtek extra foltokkal, extra layerekkel lefedtek, meg ezek a régi rendszerek még 32 bitesek voltak, míg a maiak 64 bitesek, amik alapból több memóriát igényelnek, de most ugyanez az átlag rendszer kb. 1 gigából áll meg nagy átlagban desktopon. Pedig egyenként nem foglalnak ezek sokat, egy kis apróság itt, egy kis pár mega amott, és azon kapod magad, hogy a rendszereden lett +1000 csomag, meg +500-700 MB-os foglalás alapból, ami még a használat során még tovább hízik. Ami nem lenne baj, ha arra a sok extrára lenne szükségem, vagy hasznom lenne belőle, de nincs.

    Lassan már szervereken is agyonbonyolítanak mindent, webadmin UI-kkal és GUI frontendekkel, amik nettó feleslegesek annak, aki megtanulta a shell-t, readline-t, vi/vim-et, stb. használni egy egyszerű SSH kapcsolaton keresztül, amit lássuk be nem valami nehéz megtanulni, nem fekete mágia, nem kell hozzá zseninek lenni, csak hát annyira felnőtt egy generáció kizárólag GUI-n, hogy nem tudja elengedni, minden más megoldástól idegenkedik, és nem hajlandó még csak megpróbálni sem. Sőt, már egy olyan generáció is nő kifelé, akik nem hogy parancssort, shellt, terminált, config fájlokat nem láttak, de már GUI-ból sem azt a hagyományos, Windows-szerű desktop metaforát, meg még rendesen testre szabható, normálisan menüzött DE-ket szokták meg, hanem már ilyen lebutított telefonos, tabletes, flat dizájn UI-kon nőttek fel, ribonnal, átláthatatlan és elrejtett (aktív sarkokon és széleken, vagy swipe-olással előhozható) hamburgermenükkel, végletekig lebutított fájlkezelővel (ami még a meghajtó/mappastruktúrát is elrejti, és inkább tartalomkategóriákkal operál), és már csak annyit tudnak, hogy a képernyőn egy óriási ikonra egyet bökni, ebben megáll a tudomány, és elvárják, hogy a gép találja ki, hogy mit akartak, és természetes nekik, hogy minden JS-ben, Electronban, böngészőből fut, de igen ám, ha nincs net, meg nincs GUI, nincs gondolatolvasó, user errort javító pótkerék, meghalnak nélküle. Eleve soknak már PC-je sincs, csak telója, táblagépe, játékkonzolja, okostévéje.

    Nekik már te is egy dinoszaurusznak tűnsz a PC-s Fedorával, meg a hagyományosabb felületű Xfce-vel, és nem is értik, hogy ilyen „ósdi szarokat” még ki a fene használ. Ők lesznek majd az a generáció, akik szervert is csak úgy üzemeltetnek, hogy a weboldalon egy klikkre létrejövő felhős virtualizált konténer létrejön nekik default beállításokkal, mert ők maguk állítani nem tudnak rajta semmit. Hozzájuk képest a magabiztos felahsználó szintjén álló irodai LCDE Mancikák, akiken még néhány éve röhögtünk, mert toolbarokkal meg Excelben szebszámológéppel előre kiszámolt cellákkal operálnak, képeket Word és Powerpoint dokumntumokba ágyaznak, screenshotot úgy csinálnak, hogy kinyomtatják majd beszkennelik, minden dokumentumot és letöltést az Asztalra hánynak, de még ők is informatikai professzornak minősülnek a mostani legfiatalabb generációhoz képest. Ezt a folyamatot egyébként a nagy techcégeknek köszönhetjük, akik rászoktatták az embereket, hogy a géphez, informatikai dolgokhoz egyáltalán nem kell érteni, az szükségtelen lúzerség, csak annak való, akinek nincs élete, ehelyett elég kütyüket meg lebutított appokat nyomkodni, amit nem kell megtanulni, és több idő marad facebookozásra meg zombulásra.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Nem tudom, milyen hardware-ed van, nekem mennek ezek a cuccok. Fedorán egyébként az a policy, hogy ha valamit a fejlesztője magára hagy, nem fejleszti, akkor kidobják a csomagot a repóból. Szóval akár úgy is értheted, addig maradhat, amíg béta szutyok, mert ha egyszer elkészül, repül. :)

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

    "Nem tudom, milyen hardware-ed van, nekem mennek ezek a cuccok. "

    Nekem is megy. Sőt archon is ment. A hardver teljesen irreleváns. Ha csak a pipewire frissül, és megpusztul a hang, akkor nem a hardverrel van a gond, hanem a pipewire-rel.

    Szoktál programozni? Azért kérdezem, mert az állítás elvileg sem igaz. Van olyan lehetőség, hogy valami attól működik, mert rossz volt, megcsinálták korrekt módon, ettől persze eltörik a kompatibilitás, amivel kommunikál. Ha jól emlékszem, wifi driverrel jártam így. Nem rontották el, csak egy idő után a régi firmware-ek bugjainak workaroundját nem cipelték magukkal tovább. Hasonlóképpen van ez a titkosításokkal. Szándékosan tiltanak ki gyenge algoritmusokat, rövid kulcsokat, aztán nem működik tovább, ami eddig ment, de ez nem bug, hanem kényszerítő erő, hogy használj erősebb titkosítást.

    Ezzel nem azt mondom, hogy a pipewire hibátlan, fejlődik is, de a pulseaudionál sokkal jobb.

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

    Abból élek 11 éve. Vannak logikus mondások ebben, és láttam is ilyet, de nem segit a rögvalóságon:

    frissül a pipewire

    megpusztul a hang

    frissül a pipewire

    megjavul a hang

    Ez lement archon tavaly vagy 3-4szer, és meguntam. Dolgozni, meetingelni kell, nem ezt a fosadékot takaritani.

    Ezért váltottam ubuntura, mert ott fixálva van ennek (is) a verziója, igy ha tegnap működött, holnap is fog.*

    Hiába voltam stable archon és hiába szállitották többé kevésbé tesztelve a stabil pipewire verziókat, ez akkor is egy gyenge minőségű cucc (még, vagy tán az is marad).

     

    *elvileg úgy van összerakva a dolog 22.04 -en, hogy van pulseaudio és pipewire is, de alapból mindent a pulseaudio csinál, és a pipewire csak valami spéci dologra van engedélyezve (talán akkor müxik csak, ha wayland alatt screen share-t tolsz webrtc-vel..vagy valami hasonló. Mivel X11-em van, úgy érzem nem érint). Van hang, a többi nem nagyon érdekel.

    Ez is jogos. Van létjogosultsága annak, amit Lennart Poettering mond, hogy ne nyúljunk át rétegeken, hanem ott oldjuk meg a problémát, ahol a hiba van. Az viszont gyakorlati igény, hogy legyen hang, s ne a keményvonalas elvhűség teljesüljön, mert gyakorlatilag akarok zenét hallgatni. :)

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

    Ez szerintem nem releváns. Tény, hogy a pipewire nem való mindenkinek, ehhez képest szerintem túl agresszíven nyomják rá már ilyen korai fázisában is mindenkire. Jó, neked, nekem nincs vele bajunk, de ettől még simán vannak olyan felhasználók, akiknek teljesen más a felhasználása, meg más verzió/hardver-kombót használnak, és bizony ők szophatnak vele, ha programoznak, ha nem. Érdekes a Waylandet nem nyomják ilyen erőkkel (bár azért azt is elkezdték sok helyen defaulttá tenni), de a Red Hat-os cuccokat mindig is így terjesztették, systemd, pulseaudio, pipewire. Azt is értem, hogy a feljesztőknek ez agresszívebb hozzáállása azért van, mert ha a konzervatív usereken múlik, akkor 100 év után sem váltanak, mert használják azt, amit megszoktak, pl. MBR BIOS legacy / CSM bootot se tudja sok ember elengedni, már évek óta UEFI kompatilibis hardvereken sem. A 32 bitet is elég nehezen dobták egyesek, a végletekig ragasztkodtak hozzá foggal-körömmel, IPv6 sem fog elterjedni soha, az ilyen makacs hozzáállást meg csak erőszakkal lehet megtörni. Ezért kenyszeríti a frissítéseket a MS Windowson, meg az Apple sem volt szívbajos, anno fénysebességgel vezette ki a 32 bitet is, nyekkeni nem volt ideje. Voltak torrent oldalak, ahol az divx egyeduralmát is csak tiltással tudták letörni. Ez ilyen, a nagy tech cégek rájöttek, hogy ez türelemmel nem megy, ha átállási meg halogatási időt adnak a usernek, meg ultra eltéesss alapon hagyják őket halogatni, akkor csak a végtelen halogatás, időhúzás lesz, és hosszú évek után is azon kapják magukat, hogy felhasználók millió ragadtak ősi technológiákon, az új meg adoptáció híják nem halad sehová, technikai fejlődés nuku, bekövült minden.

    A rolling, Fedora, Arch világa viszont valóban más. Itt nincs cécózás, hogy valaki transzveszti, Jehova tanuja, ortodox konzervatív, itt szépen nyomják le a legújabb technológiákat, nincs LTS, nincsenek kifogások, hogy izé, de ő nagyon envidilyás, ne bántsuk, jajj, kapjon polkorrektségből egy kis haladékot, légyszi-légyszi már. Pl. Fedorán most fogják a SHA-1 eflogadottságát megszüntetni, nagyon helyesen, ebben többen is követni fogják őket. Ebben egyébként a kolléga által imádott Canonical és Ubuntu sem szent, mert azért ők is mocsokul nyomják az újat, hiába LTS, azért anno elég agresszíven letolták mindenki torkán az upstart, mir, majd systemd, Unity, most meg a default Gnome Wayland sessiont, a 32 bites támogatást is az elsők között szüntették meg. Pipewire még nem kényszerítve, de már náluk is csak 1-2 verzió kérdése, és meglesz az is.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    itt szépen nyomják le a legújabb technológiákat, nincs LTS, nincsenek kifogások, hogy izé, de ő nagyon envidilyás, ne bántsuk, jajj, kapjon polkorrektségből egy kis haladékot, légyszi-légyszi már

    nem teljesen világos, hogy ez a kívánatos állapot, vagy panaszkodsz :)

    ha az előbbi, akkor ki a célközönség?

    Azért, mert pipewire release nagyjából kéthetente van, én meg naponta csináltam build-et, azaz néhány commit-onként. :) Ez a reflex azóta volt bennem, amikor volt olyan bug a pipewire-ben, ami érzékenyen érintett VoIP kapcsán, jeleztem a bugot, majd Wim kérte, hogy teszteljem. Aztán küldtem logot, ő javított, s ezt néhány körben addig csináltuk, amíg kijavította. Amikor látom egy commit-ban, hogy valami vaskosnak tűnő bugot javít, akkor rámtör a fordíthatnék. :) De már elég jó, leszoktam róla.

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

    ( ibenny v | 2022. 05. 01., v – 17:03 )

    Aki jobban követte, nem úgy volt, hogy a 22.04-ben lecserélik erre a PulseAudio-t..? Mert nálam frissítés után bizony a Pulse az aktív (és nem "on PipeWire .."). 

    Szerintem a Fedorával kevered össze, ahol már 2 kiadás óta default, vagy a Gnome Wayland session-nel. Egyébként Ubuntura is felteheted kézzel, apt install pipewire pipewire-pulse, meg kéne kérdezzze, hogy leszedje-e a Pulseaudio-t, ott igent nyomsz neki, és már teszi is fel, egy újraindítás, használod.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Hát felrakni biztos, hogy felrakta a frissítéskor. Eddig még nem éreztem magamban elegendő erőt, hogy utána nézzek, hogy mi az, amelyik konkrétan fut. A top / ps-en kívül van valami erre kihegyezett eszköz is?

    tl;dr
    Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

    Én ezt látom 22.04 -en (21.10 -ről upgradeltem).
     

    **@**:~$ ps auxwww | grep -i pipewire
**      2254  0.0  0.0  42740  6300 ?        S<sl ápr29   0:00 /usr/bin/pipewire
**      2255  0.0  0.0  26496  5208 ?        Ssl  ápr29   0:00 /usr/bin/pipewire-media-session
**     27135  0.0  0.0  12116  2248 pts/0    S+   09:20   0:00 grep --color=auto -i pipewire


 pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-04-29 17:30:48 CEST; 2 days ago
TriggeredBy: ● pipewire.socket

    Gondolom akkor fut. Van hangom.

    Nálam ugyanennek eredménye:

     

    ps auxwww | grep -i pipewire
**       2038  0.0  0.0  45832  4672 ?        Ssl  Apr21   0:01 /usr/bin/pipewire
**       2039  0.0  0.0  29592  4204 ?        Ssl  Apr21   1:01 /usr/bin/pipewire-media-session
b**     321510  0.0  0.0  15192  2300 pts/2    S+   21:23   0:00 grep --color=auto -i pipewire
**@**:$ systemctl status pipewire.service
Unit pipewire.service could not be found.

    Továbbra is 20.04 --> 22.04. Nem kritikus, csak a kíváncsiságom vezérelt.

    Ez a kérdés nálam is.:) Egyik részről sem volt bennem akadékoskodás, csak nem világos, hogy most akkor mi hogyan van a PipeWire-rel, mert valami fut, de nem a pipewire.service, és nem is a PipeWire az aktív. Szóval valami fura, de tényleg csak kíváncsi vagyok/voltam.

    Köszi, íme:

    systemctl --user status pipewire\* wireplumber.service
Unit wireplumber.service could not be found.
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-04-21 23:28:54 CEST; 1 week 3 days ago
TriggeredBy: ● pipewire.socket
   Main PID: 2038 (pipewire)
      Tasks: 2 (limit: 18832)
     Memory: 1.6M
        CPU: 1.522s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
             └─2038 /usr/bin/pipewire

Apr 21 23:28:54 *** systemd[2031]: Started PipeWire Multimedia Service.

● pipewire.socket - PipeWire Multimedia System Socket
     Loaded: loaded (/usr/lib/systemd/user/pipewire.socket; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-04-21 23:28:54 CEST; 1 week 3 days ago
   Triggers: ● pipewire.service
     Listen: /run/user/1000/pipewire-0 (Stream)
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pipewire.socket

Apr 21 23:28:54 *** systemd[2031]: Listening on PipeWire Multimedia System Socket.

● pipewire-media-session.service - PipeWire Media Session Manager
     Loaded: loaded (/usr/lib/systemd/user/pipewire-media-session.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-04-21 23:28:54 CEST; 1 week 3 days ago
   Main PID: 2039 (pipewire-media-)
      Tasks: 2 (limit: 18832)
     Memory: 1.7M
        CPU: 1min 4.098s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire-media-session.service
             └─2039 /usr/bin/pipewire-media-session

Apr 21 23:28:54 *** systemd[2031]: Started PipeWire Media Session Manager.

    Csak ez ugye meglepő volt ezután:

    systemctl status pipewire.service
Unit pipewire.service could not be found.

    Nem meglepő, mert nem system daemonként fut, hanem user szolgáltatásként.

    Amúgy vagy az van, hogy fut egy pipewire, de annak az upstream-je nem közvetlenül a kernel alsa interface-hez csatlakozik, hanem futtatsz egy pulseaudio-t is, és annak az alsa interface-éhez, vagy mindenki közvetlenül pulseaudiohoz csatlakozik, a pipewire meg bambán néz. Szóval le kellene takarítani a pulseaudio szervert. A kliens library-k maradjanak, azokat nem írták újra a pipewire-hez.

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

    Nekem az volt, mert nem tudtam/nem emlékeztem, hogy a systemd-nek user kontextusa is van. Köszi, meggondolom. Jelenleg van hang, ezen érdemben nem változtatnék, azt az elvet követet, hogy ami működik, azt nem feltétlenül piszkálom. :)

    ( dzsolt v | 2022. 05. 02., h – 19:19 )

    Eddig csak olvastam ezt a szálat, de tegnap eldöntöttem, lesz ami lesz lecserélem a pulse-t erre. Fájdalommentesen ment, bár az easyeffect nem fut a háttérben, mint a pulse tesója tette ezt eddig. A pw-loopback-et kézzel kell betöltenem, valamiért nem húzza magával, de majd kap egy szkriptet. Ami változott, az pont a loopback. Ez akkora zajt keltett pulseval, mintha valami veszett sebességű venti lenne a gépben, a pipe alatt észre sem veszem. Már kicsit sajnálom, hogy nem korábban váltottam, mert féltem az átállástól, attól, hogy esetleg napokig nincs hang ha valami gebasz lenne :) A következő lépések a gentoom karcsúbbá tételéről fognak szólni, mint például systemd elhagyása, wayland az xorg helyett, stb... Ez meghozta a kedvem :)

    „Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

    dzsolt

    Ne scripttel csináld! A /usr/share/wireplumber környékén nézz körül, olvass bele a config file-okba, olvasd el a commenteket is, aztán onnan másold a megfelelőt a /etc/wireplumber alá, azt módosítsd, így a csomag tud frissülni, de a te beállításaid jutnak érvényre. De egyébként a wireplumber.conf file-ban a context.modules = [ kezdetű népi rigmust nézd meg! :)

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

    Én másolatot csináltam az eredetiről, ahogy fentebb írtam, majd ott a záró szögletes zárójel elé írtam:

      # Echo cancellation module
  { name = libpipewire-module-echo-cancel }

    Jó, ez echo cancel, mert nekem meg ez kellett. Kinek mi, ugye. ;)

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

    A pulseaudio legalább működik. Konkrétan a pipewire miatt hagytam ott 10 év desktop után az archot. Egyik héten volt hangom, a másikon meg nem. Játszós gépen biztos jó móka ezekkel szórakozni..

    Egy pár hónapja Uborkán vagyok (21.10 aztán 22.04), amiben a pipewire gyakorlatilag ki van kapcsolva (pontosabban gyárilag csak olyan edge case-ekben működik, ami engem nem érint), és béke van.

    Szóval egyszer majd ha minden bugot lecsapkodtak biztos fasza lesz, de most még szerintem egy instabil szutyok.

    Így van, engem az érdekel hogy az én laptopomon mi műküdik és mi nem.

    Az archról tudni kell, hogy folyamatosan ömleszti mindenből a latest upstream verziót, ez pedig ragyogóan kihozta a pipewire problémáját: minőség.

    Lehet hogy a pulseaudio is ótvaros a maga módján, ezt nem vitatom, de az legalább üzemel. Nálam. Az hogy a motorháztető alatt mennyire rothadt, már annyira nem érdekel. Dolgozom a gépen, szóval leginkább a funkció foglalkoztat, mennie kell a hangnak és a mikrofonnak, mert minden nap több órát meetingelek.

    Tőlem aztán nyugodtan kidobhatjuk a palánkon x-et és jöjjön helyette y, elhiszem hogy modernebb a megközelités, de az nem fogadható el egy dolgozós gépen, hogy random, hogy van-e hang. Legyen.

    Erről beszélek. Tehát ennek megfelelően a korrekt megfogalmazás az lenne, hogy "nálam a pulseaudio legalább működik."

    Egy fejlesztés alatt álló alpha szoftver esetén kicsit korai még minőségről beszélni. Főleg mivel nem csak maga a szoftver lehet bugos, de akár az underlying system is. Honnan tudod, hogy egy olyan disztróban, ami szavaiddal élve "folyamatosan ömleszti mindenből a latest upstream verziót", az nem törhet el valami mást, amire a PW-nek szüksége volt? Ha az Arch lecseréli a PW egyik - eddig működő - dependenciáját egy bugos verzióra, akkor az a PW hibája?

    Ez így már egy akceptálható álláspont.

    Nem a modernségről van szó, hanem, hogy a PA - írd és mondd: fundamentally broken, úgy, ahogy van.

    Oldschool Computer - http://oscomp.hu

    Arról nem is beszélve, hogy szerintem valami félre lett konfigurálva ott, vagy olyan bug volt, amelyet a következő kiadás javít, vagy tessék jelezni a bugot, Wim Taymans hozzállása nagyon korrekt, nem ignorálja. Volt nálam is regresszió, jeleztem, javított, teszteltem, javított, stb., végén megcsinálta, megköszönte, hogy az én környezetemben, ahol előjött a bug, teszteltem, küldtem logokat, én meg örültem, mert forrásból lefordítva a git repóból kihúzott legfrissebbet, rpm csomagot csinálva, feltelepítve működött jól. Mostanában már nem fordítok forrásból, mert jó.

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

    "10 sec alatt downgradelted volna a pulse-t."

    Miért dolgozzak a distro készitők helyett? Egyébként ránéztem a témára, egyáltalán nem volt triviális, ugyanis a gnome-ot már körbedrótozták a pipewire függőségekkel, tehát a 10 sec erősen túlzás.

    "bloat bughalmazra"

    Disagree, minden működik. Mitől lenne ez bloat? Upstream cuccokat szállít. Pontosan ugyanazt, mint a többi.

    ( locsemege v | 2022. 06. 15., sze – 20:30 )

    Elhanyagoltam ezt a topikot.

    0.3.52 sok javítással.

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

    ( dragi v | 2022. 06. 15., sze – 21:34 )

    Nekem most 16-os pulseaudiora frissítve meghalt a hang, pedig ugye alapban pipewire van már egy ideje. Visszraktam 15-t és ismét jó lett, 0.3.52-es pipewire mellett.

    Gondolom, azért, mert a pipewire a kliens oldalon a pulseaudio függvényeit használja (pulseaudio-libs). Továbbá 15-ös pulse szervert emulál szerver oldalon, az meg gondolom, nem kompatibilis a 16-os kliens libekkel. Gondolom, meg lesz csinálva, hogy menjen a 15-össel és 16-ossal is.

    Server Name: PulseAudio (on PipeWire 0.3.52)
    Server Version: 15.0.0

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

    Nálam 16.0-ás libpulse (Archon ez a pulseaduio-libs megfelelője) teljesen jól megy a 0.3.52-es pipewire-rel. Nem tudom mit emulál, meg pulseaudio sincs fent, csak wireplumber 0.4.10 az említetteken felül.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Van néhány ötletem, miért.

    1) Lusta volt a csomagkezelő készítője, s nem vagylagos függőséget írt elő, hanem kényelmesebb volt csak az egyikre, akkor meg legyen az újabb, jobb.

    2) Kihasználják a video átvitelt, s ezt a pulseaudio nem tudta.

    3) Racionális olyan szempont miatt is, mert van jack, pulse, alsa és video interface-e is, míg pulseaudio-nak csak pulse és alsa. Tehát jack kliensek is lenyelve.

    Önmagában az nem lenne érv dependenciára, hogy valaminek a hanghoz kell pulse vagy alsa interface, mert azt tudja a pulseaudio is, nem csak a pipewire. Sajnos? A legjobb dolog, ami a linuxos audio alrendszerrel történt, hogy megjelent a pipewire, és az erőforrászabáló, recsegő-ropogó, az alkotója sem tudja, hogyan működő pulseaudio-t leváltotta. A pulseaudio bufferkezelése, újramintavételezése valahogy úgy volt megfogalmazva, hogy nem triviális algoritmus. Ez számomra azt jelenti, hogy Lennart valamit nem értett, bekent sárral, írt egy zavaros algoritmust, amely bizonyos élethelyzetekben valóban működésképtelen volt.

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

    Persze, elviekben mehetne egymás mellett a pulseaudio és pipewire, de így redundáns az egyik, meg minek tenne így valaki? Nekem egyébként továbbra is hiba nélkül működik a pipewire, de kezdem nem szeretni. Az oka: bloat. Önmagában még nem fogyaszt több memóriát, mint a pulseaudio, de a pipewire-ön kívül ugye fut még a pipewire-pulse és a wireplumber is (meg van, akinél a jack is), és ez a három együtt már elég vaskos. Próbáltam a wireplumber service-t letiltani, de pl. a videólejátszás nem működik nélküle. Azzal is tisztában vagyok, hogy a pipewire egy általánosabb protokoll, nem csak a hangot kezeli, de a videót is, meg konténerizált appoknak (pl. ha flatpakként futnak, ami nálam nincs) is engedi a hang/videó-alrendszerek elérését, csak az a poén, hogy erre nekem nem lenne szükségem, elég lenne, ha csak a hangot tudná.

    Próbálom pedig a rendszerem soványan tartani, de egyre nehezebb küzdelem. Pl. kigyomláltam a at-spi-szutykokat, de a dbus-t nem lehet (kell a Firefoxnak, Steamnek, redshiftnek). Wireplumber is kigyomlálhatatlan. Sikerült megszabadulni a polkitd-től is, meg a systemd-journald-t is (bár ez utóbbit tiltani nem épp a legbölcsebb, de járható út). A systemd-vel is az a baj, hogy sok szutyka fut, pl. logind, udevd, rtkit-daemon, ezeket nem lehet letiltani. A legrosszabb a logind, aminek elogind formájában még nem systemd-s disztrókon is futnia kell, mert egy csomó alkalmazás dependel rá. Ráadásul nálam ilyen egyéb szutykok, mint a udisks, gvfs, kompozitor, NetworkManager, systemd-homed, stb. nem is fut.

    Így meg hiába a sovány rendszer, ha boot után a rendszer a tty konzolban már grafikus felület nélkül is bekajál 200 megát. 2 éve még egy inteles notin a komplett Arch, Sway (beépített kompozitorral és átlátszósági effektekkel), Xwayland, pulseaudio, Termite terminál kombó megált boot után 140 megából, most egy hasonlóan minimalista Arch, X.org + bspwm, lemonbar + scriptjei, pipewire, st terminál egy AMD-s notin 275 MB, jó ennek a különbségnek egy nagy szelete, hogy. az amdgpu driver komplexebb, nagyobb, ami a Ryzenbe integrált GPU-t hajta, míg a régi Intel GPU-t még egyszerűbb, kevesebbet tudó kód hajtotta. Sajnos bloatosodik a Linux, ahogy lesz egyre népszerűbb, elterjedtebb. Arra már rég rájöttem, hogy az nem lesz jó, ha eljön a Linux éve, mert akkor az egyben azt is jelenti, hogy Windowst fognak belőle csinálni, annak a szintjére züllesztik le.

    A BSD-knek ez egyben az előnye és hátránya is. Ez a sok szutyok, legalábbis ezek nagyobb része azokon még nincs jelen, cserébe viszont sok szoftver és driver nem is támogatott rajta, ami Linuxon megy.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Na jó, de nem lenne egyszerűbb RAM-ot tenni a gépedbe? Ha kevés RAM-mal akarod megúszni, használj OpenWrt/LEDE-t. :) Én sem szeretem az elhízott rendszereket, de nőnek a gépek képességei, nőnek az igények. Az meg miért baj, ha kihasználjuk a hardware-t? Nem azért van?

    A pipewire koncepciója nem változott, igyekszik pointerekkel operálni memcpy() helyett, de rengeteg hülye esetet kel kezelni. Lehet, hogy sztereóban hallgatnál zenét, de úgyis lesz valaki, akinek 24 audio csatornára van szüksége, s nyüszít Wimnek, hogy oldja meg, mert az kell. És akkor meg lesz oldva, kicsit nagyobb lesz a kód.

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

    Én sem szeretem az elhízott rendszereket, de nőnek a gépek képességei, nőnek az igények. Az meg miért baj, ha kihasználjuk a hardware-t? Nem azért van?

    Locsemege korábban: "Ja, ha nem számít a futásidő", "miért eszik egy rakás futásidőt a pipewire-rel szemben?", "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?"

    :)

    Egyébként ha jól elmékszem, azt is mondtam, hogy várjuk már meg ezt a lehet gyorsabban csinálni dolgot, míg fog is annyit tudni, mint a pulse. :)

    Gondolom, írtál már programot életedben - talán ebből élsz, nem tudom -, de ez nem úgy van, hogy kétszer akkora kód fele olyan sebességű. Csak belekerül egy rakás olyan dolog, ami az átlag gazembernek nem kell, a furcsa lények meg használják.

    Mondjuk valaki jelzi, hogy a Csillámpóni 2. 24 csatornás audio hardware nem megy pipewire-en, Wim Taymans beleír egy rakás kódot, az nagyobb lesz, de ha nem használsz 24 csatornás Csillámpóni 2-t, akkor neked az a kódrész sohasem fog futni.

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

    Ja, írtam már egy párat, úgyhogy tudom, hogy ha csak nem arról van szó, ami példát is írsz, hogy valami leafet (mondjuk egy drivert) tesznek bele, akkor bizony elég nagy esély van rá, hogy az új funkció többlet számításokkal fog járni, mert beépül a processing flowba. Arról nem beszélve, hogy ha nem kell a csillámpóni drivere, akkor, ha már háklisak vagyunk az erőforrásra, mi a péknek töltjük be RAMba egyáltalán.

    Engem egyébként ez nem zavar, szerintem is arra van a HW, hogy használjuk, a tükröt szerettem volna feltartani, hogy mikor ott voltunk, hogy mer a pulse többet eszik, akkor ez még vérlázító volt, és pottering szar programozó lett.

    Nem néztem az utóbbi időben, mennyit eszik a pipewire RAM-ból, CPU-ból, de nekem úgy tűnik, CPU-ban továbbra is lényegesen jobb a pulseaudio-nál. Az viszont egy elég lényeges különbség, hogy a pulseaudio egész egyszerűen nem működött, kliens oldalon állandóan buffer underrun lett, így VoIP klienshez visszhang elnyomással teljesen használhatatlan volt, a beszéd érthetetlen, recsegett, ropogott a hangja. Ezzel szemben a pipewire működik ebben a szerepben is.

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

    Engem a pipewire az ubuntuhoz való rohanásig szopatott 10 év arch után. Nem tudom hogy a bugokat lapátoló pipewire-re vagyok nagyobb pipa vagy a "jééé Józsikám lefordul ez" szintű QA-t alkalmazó Arch Linuxra. Nyilvánvalóan okkal nem engedélyezték a 22.04 LTS-ben sem. Majd a következőben, x év múlva. Addigra kivasalják a pipewire -t, mert ez egyelőre pre-beta (vagy az sem). Tudom, mert hetente ment el meg jött vissza a hangom archon, ahogy jöttek az új verziók.

    2021. 04. 11.-én cseréltem le Arch-on teljesen a PulseAudio-t PipWire-ra. Azóta is tökéletesen gond nélkül működik. Szóval a hiba lehet az ön készülékében van.

    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.

    "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

    Nem, kitartóan kerülgettem a megjön a hang, elmegy a hang témát. 10 évig archoztam, minden nap frissitettem. A gond az hogy állandóan frissitik és jönnek mennek a bugok, változó számban: https://github.com/archlinux/svntogit-packages/commits/packages/pipewir…

    Attól hogy a te gépeden most nem jött hiba, egy másik dolog. Amúgy én jópár hónapja váltottam, azóta frissült vagy ezerszer.

    RAM van elég minden gépemben, 16 giga, de elkezdtem debloatosítani a workflow-m, hogy visszavágjam a komplexitási fokot. Ugyanis minél nagyobb egy kód, minél több a függősége, annál nagyobb az esélye, hogy egy frissítéskor eltörik, vagy egy új disztró tárolójában nem lesz meg valami függőség, plusz minél több sor kód, annál nagyobb az esélye, hogy valami bug lesz, vagy sechole benne. Plusz a minimalista szoftverek nem csak hogy RAM-ot nem foglalnak, de már a felesleges sallang betöltésével a procinak se kell foglalkoznia. Nálam már valami 3 mp. körül van a bootidő, plusz UEFI képernyő. Azért, mert sok sallang nem fut, be sem kell töltenie a rendszernek, leállításkor nem kell kilőnie, stb..

    Pl. konkrét példát is tudok mondani most a múltból. Jó ideig az imv nevű képnézőt használtam, ez egy elég minimalista, CLI képnéző. Alapvetően be is vállt, de vannak benne extra feature-ök, pl. wayland-támogatás, freeimage2 mint függőség. Egyszer csak egyik napon eltört Archon, frissült a szoftver, a freeimage2 nem frissült hozzá, crashelt. Persze, helyrehozták 2-3 nap alatt, de ez egy jó példa, hogy miért nem jók a függőségek. Átálltam a még kisebb sxiv-re, ennek még kevesebb a függősége, ez nem fog eltörni, és az imv-hez nagyon hasonló CLI képnéző, sokkal jobban konfigurálható, és még ilyen előnézeti képes módja is van, ami az imv-nek nincs.

    Másik példa, hogy pl. az Alacritty terminál hogy elhízott verzióról verzióra. Megeszik 100+ megát egy terminálablak, igaz ennek nagy része shared lib, amit több terminál meg ugyanazon függőségeket használó program is tud használni, de akkor is bloat. Jó, van benne vi + blokk kijelölésmód, URL kezelés, GPU gyorsítás, ligatúrakezelés, stb., de ezek nekem nem kellenek. Helyette most simple terminal (st) megy, ez egy 9 KB-os bináris (strip után), függősége csak a szokásos xlib, mindössze 16 megát eszik, és épp úgy tud Unicode-ot, többféle fallback fontot kezelni, 24 bites truecolort, stb.. Egyedül a görgetést és egérkezelést kellett belepatchelnem. A vicc az, hogy érezhetően pattogósabban is indul, mint az Alacritty, pedig semmilyen GPU gyorsítás nincs benne. Ugyanez volt a bajom az xfce4, gnome terminálokkal is, hogy jónak jó, de bloat. A másik alternatíva, ami jó, az xterm, sokakat elriaszt, hogy alapból szarul néz ki, de be lehet konfigolni jól kinézőre, és támogat Unicode-ot, truecolort, sőt még sixel támgatás is van benne, amivel képeket tud megjeleníteni, és ugyan 9 KB helyett 900 KB, de memóriából mégis pár megával kevesebbet eszik.

    A Pipewire-nek pont az a baja, hogy túl sokat tud. Beletrafáltál, max. sztereóban hallgatok zenét, semmi sokcsatornás surround, semmi Bluetooth, stb. bonyolítás nincs nálam, se Jack, se OBS, se sztreamelés, se latency érzékeny DAW feladat. Nekem bőven elég az OpenBSD alap hangrendszere, vagy elég lenne az OSS vagy ALSA is, már a Pulseaudio is overkill volt nekem.

    Ugyanez a systemd-re. Nekem elég lenne a hagyományos POSIX shellscript alapú init. Mondom ezt annak ellenére, hogy a systemd-nek is van előnye, pl. az bootol a leggyorsabban az összes initrendszer között, mivel tud service-függőségeket kezelni, és a betöltődésüket hatékonyan párhuzamosítani. A systemd-boot is egy elég jó dolog, önmagában egy elég minimalista, de rugalmas megoldás, pehelysúlyú a GRUB-bal szemben. Összességében viszont mégis bloat ökoszisztéma. Ezt nem én mondom, hanem a gyakorlat. Pont most néztem a Miyo Linux nevű YouTube-csatornán egy videót, a faszi nagyon szolidan használható és jól kinéző Devuan + JWM setupot hozott össze, elsőre azt hittem, hogy KDE, olyan jól néz ki, és boot után idle-ben eszik neki 100-120 megát az egész rendszer. Nálam egy elvileg még minimalistább bspwm-mel vagy nowm-mel sem áll meg 275 MB alatt, mivel systemd+pipewire miatt eleve már a tty konzolon 200 megát eszik a rendszer, ami egy konzolos, CLI rendszertől nagyon sok foglalás.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Gondolom, desktopra is lehet BusyBox-ot rakni, csak minek. Nekem nincs annyi időm az életemből, hogy ezekre optimalizáljak, s az optimalizálás sokkal több időt visz el, mint az általános célú bloat program, amelynek valóban csak mondjuk 2 %-át használom ki.

    Ami a képnézegetést illeti, használj ffplay-t vagy mpv-t, ezek tudnak képet megmutatni, de a video file-okat is lejátsszák. :)

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

    Igen, akár azt is lehet. A Busyboxszal nekem az a bajom, hogy nagyon limitált, és ahhoz képest nem sok erőforrás-megtakarítás. Kicsit a dwm-ről is ez az érzésem, a nálánál szinte alig nagyobb bspwm sokkal rugalmasabb, használhatóbb, patchelés nélkül is. Tehát a minimalizmusnak mindig van egy olyan szintje, ahonnan nem éri meg, a hatékonyságot csak rontja, de már erőforrásban semmit se spórol érdemben.

    Képnézésre az ffplay, mpv szerintem overkill és nagy kódméret. Tartom ezeket is, mert az ffplay az ffmpeg-gel jön, ami sok mindennek függősége, meg használom is konvertálásra, meg az mpv-t is tartom videó/audiólejátszásra (használom online rádiók hallgatására is), de képeket jobb nézni egy erre tervezett, még soványabb alkalmazással, az külön hasznos, hogy vi/vim-módon működik, rendesen lehet benne nagyítani, mappákat áttekinteni. Az imagemagick is hasonló svájci bicska, használható képkonvertálásra, képnézésre, betűtípusok megjelenítésére, szerkesztésre, akár még X háttér beállítására, stb. is. Akár még szkriptekből is lehet hívni, pl. ha valaki transzparens bart, login screen-t akar kompozitor nélkül vagy pl. a pywall is használja, a háttérkép domináns színeinek kinyerésére az imagemagick convert-et. A másik ilyen hasznos svájci bicska az ffmpeg (megjelenítés, konvertálás, streamelés, stb.-re is jó), mpv, imagemagick mellett talán még a sox. Ha nem a médiaformátumokat nézzük, hanem általános shellt, akkor meg a vim (nem csak szövegszerkesztésre, de IDE-nek, tömeges átnevezéshez, terminál multiplexernek, pagernek, stb.), fzf, less, grep, sed, awk, tmux hasonlók még, esetleg valami terminálos fájlkezelő, mc, Vifm, lf, ranger, nnn, stb., a shell szkriptet, Pythont, Perlt, stb. nem számolva. Nem véletlen, hogy ezek a legtöbb Linux-telepítésen default ott vannak, vagy mert függőségnek vannak behúzva valami másik csomag által, vagy csak egyszerűen annyira hasznosak annyira kevés helyért cserébe, hogy nem éri meg őket kihagyni. A cfdisk, wget/curl, youtube-dl is igazi svájci bicska szerintem, ahogy a bc, calc, Python, Octave is, ha számolásokról van szó, mivel lehet számológépnek is használni, és ebben a szerepkörben simán hatékonyabb, mint hosszas műveleteket GUI számológépben kikattintgatni. Táblázatkezelés kiváltására elég jó még az sc, sc-im, R, SQLite, stb. is, ezek se sokat kérnek enni, bár azért az R nagyobbacska. Értő kezekben a groff, *tex, pandoc is csodafegyver, bár azért utóbbi kettő vaskos telepítés lehet. Esetleg links, w3m, mupdf, Zathura.

    Igaz nem minden disztrón, pl. a nagyon normiknak szánt disztrókon alap telepítésben hiányzik a vi/vim, git, htop, stb., amit nem is értek, mert ezek nem kérnek sokat enni, de gondolom úgy vannak vele, hogy akinek ez kell, az profi, és felteszi magának.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Nem használok groff-ot, de állítólag vannak rá hackek, hogy megegye a Unicode-ot meg a modern betűtípusokat (konverzió után). Én magam markdown-os és XeTeX-es vagyok, de a neten látok groff-veteránokat, és nagyon hatékonyak vele, még scriptekből is hívogatják, és röptében konvertálnak pdf-re. Man pages készítésére se árt ismerni, bevallom, hogy sose tanultam meg, mert nem bírom megjegyezni a tag-rendszerét ezeknek a *roff-oknak. Kicsit lyukkártya szintű minimalizmus még nekem is (a Fortrannal is így vagyok), de kétségtelen előnye, hogy minden unixlike és POSIX kompatibilis rendszeren ott van, sokat nem kér enni, és nagyon ergya, muzeális hardveren is elfut elméletben, olyan gyengéken, amiken pl. egy TeX is letérdelne már.

    Apropó (nem szójáték), ha már man pages, nekem mindig is egy funkció hiányzott belőle, a hyperlinkelés. Az nagyon hasznos lenne bele, egyik man pagesből nyitni a másikat, vagy ugrani ugyanazon man page másik anchor #szekciójára, hosszabb doksiknál segítene.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Karakteres felületű man olvasót nem láttam ilyet, de az xman kezelte a "hiperlinkeket"; értsd tudtál a doksinak a See also-jában meg egyéb helyeken levő másik man oldqlakra hivatkozásra kattintani és ezzel átugrani arra a doksira. Amúgy ahogy mondtad, nem egy nagy etwas, csak a megfelelő referencia tag-et kell felismerni. Mivel a man nroff/troff alapú, ahhoz meg van (volt) referencialista készítő, akár a natív megjelenítőbe is betehették volna. De mivel fizikailag egy "man 1 izé" kb erzzel egyenértékű:

    gzcat /usr/share/man/man1/izé.1.gz | (n)eqn | tbl | ... | soelim | nroff -man | col -b | more

    nem csoda, hogy a sokkal általánosabb more -ba nem rakták bele ezt az extrát. Mondjuk mivel Linux alatt more helyett amúgy is less van, ami milliószor bonyolultabb és több mindent tud, még az is lehet, hogy abban már benne van, csak nincs ember, aki végigolvasta volna a manual-ját, így simán lehet, hogy Alt - Ctrl - lábpedál, és máris ugrik a linken állva.

    tl;dr
    Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

    Kösz, ki fogom próbálni, de nekem ez a sok pipe túl bonyásnak tűnik. A more-ban egyetértek, nem is értem, hogy azt ki használja, szerintem azt Windows és DOS usereknek tették bele, hogy elérhető legyen az a parancs, amit ott megszoktak, ugyanez igaz a dir parancsra is. A less annyival többet tud, hogy nem éri meg a more-t használni, hacsak nem valami még többet tudó less-klónról van éppen szó. Én is minden szkriptemben és rendszeren a less-t használom, már csak eleve a vi-os billentyűk miatt, amit egyébként is használnék minden programban. Persze a PAGER környezeti változóban bármilyen program megadható, vi, vim, cat, bat, more, nano, stb., de a less elég bármihez, amit read only-nak akar az ember megnyitni.

    Elvileg ha a manpages olvasónak beállítja valaki a vim-et, akkor az tud normál módban Shift + K billentyűkre elugrani a kurzor alatti szó man oldalára, de teljesen ez sem pótolja a rendes hyperlinkeket. Ezt megoldhatnák alap man-ban, nagyon kéne már egy modernebb, újabb POSIX szabvány, amibe ezeket beleveszik, mert nem nagy szám lekódolni, sokat enni nem kér, és nagy kényelmet nyújtanak az ilyen apróságok.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Nem csak a komplex aritmetikát, hanem vektorok, mátrixok között is simán lehet vele számolni, tud mindenféle kombinatorikai számítást, számelméleti alap függvényeket, meg gigászi számokat is bőven kezel, gigászi pontosságot is, ha kell millió tizedesjegyet is, ráadásul meglepően gyorsan tolja ki ezeket még egy szarabb PC-n is, tényleg olyan szélsőségekről van szó, ami egy normál számológépen, GUI számológépappon esélytelen. Használható logikai számításokra, számrendszerek közötti konverzióra, stb. is. Plusz mivel CLI program, ezért gyorsabb begépelni hosszabb műveleteket, meg azok history-ból visszahívhatók, és mivel van benne readline, vi-os billentyűkkel is szerkeszthető akármelyik bevitt művelet. Komplett, Turing-képes szkriptnyelv van mögötte, C-s szintaxissal, így minimális tanulással automatizált szkriptek is írhatók vele. Aki nem ismerné, kicsit az awk matekos változatának kell elképzelni.

    Persze vannak korlátai, pl. ilyen analízis, numerikus módszerek, differenciálegyenletek megoldása nincs beépítve, de arra ott van a Python numpy-jal és sympy libekkel. A calc-tól ez szép teljesítmény, egy 22 KB-os apró program, függősége csak egy generic C lib, meg a readline (bár talán enélkül is lefordítható, ezek ott vannak általában már minden rendszeren), ahhoz képest rettenet hasznos program. RPN-t nem tud még, de arra meg ott van a dc.

    “A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

    Ma calc-kal Pythagoras volt napirenden, két pont közötti távolság. Írhattam volna az sqrt(x^2+y^2) formulát is, de kényelmesebb volt az abs(x+yi) forma. Nyilván konstansokkal, mert változóval nem így kell írni, hiszem yi-t változó névnek fogja nézni. Változóval abs(x+y*1i). Nyákot terveztem, és tudni akartam, a via széle és a track között mennyi hely van. Jó, be van állítva 0.2 mm clearance, de ha van lehetőségem, nem megyek ennyire közel.

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

    ( Sas66 | 2022. 06. 27., h – 12:30 )

    Azóta követem ezt a pipewire istennyilát mióta megjelent, és felzabálta a teljes 22 GB ramot. Akkor találkoztam vele először.

    És Ma ! Manjaro frissítés után eltűnt a hang. Teljesen. Mindenestül ! Hang beállítás: üres. Hibaüzenet nincs mindössze a VLC kiírja, hogy nem tudta azonosítani a default hangeszközöket.

    Tud valaki segíteni ?

    ( Mindez csak Manjaro alatt ! )

    Csak egy tipp, nálam 2 gép van az egyiken mindig szórakozik, a másikon stabil

    bash-5.1$ cat /etc/asound.conf
# ALSA system-wide config file
# By default, redirect to PulseAudio:
pcm.default pulse
ctl.default pulse

    Ahol a hanggal probléma van, ott a pcm és ctl sorok előtt is !jel van, tehát !pcm... !ctl... és így megy.

     Fedorán hiba nélkül teszi a dolgát a pipewire.

    Ennél azért árnyaltabb a kép, eszközök (főleg dokkoló) ki-be dugdosása után viszonylag rendszeresen kell pl hátba rúgni, hogy ugyanmár kisbarátom, hát vannak ott hangeszközök, olyat is láttam már pár alkalommal, hogy határozottan állította, hogy melyik mikrofont használja, de empirikusan nagyon hamar be lehetett látni, hogy határozottan hazudik, sőt olyan is volt már, hogy a radioboxos kimenetek között kettő is aktívnak látszott a desktop izén. Ja, meg egyszer már vertem agyon sigkillel a picsába, mert pörgött az arcán.

    Átfogalmazom. Azokban a felhasználásokban jó, amelyekben nálam előfordul. Desktop gép USB vagy bluetooth audio kimenet, analóg mikrofon bemenet, illetve notebook lokális hangszóró vagy bluetooth kimenet, itt jellemzően nem, vagy nagyon ritkán használok mikrofont.

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

    ( Sas66 | 2022. 06. 29., sze – 12:30 )

    Helyzet a következő:

    a hang a legújabb frissítés után tűnt el. Újraindítás után nincs. Majd 3 újraindítás után se. Majd ki és bekapcsolás után az etc/pipewire könyvtár conf fáljai kiürültek. Viszont lett hang. 

    A rendszerbeállítás>hang tartalma megjelent.

    Hurrá !

    Ma: manjaro bekapcs. Hang nincs. cat /etc/asound.conf fájl nem létezik. systemctl status pulseaudio nincs ... pipewire nincs.

    Egyebek: firefoxban, chromban youtube csak teker.

    Frissítés előtt minden oké volt.

    Most szünet. Felteszem vmware-ba lássuk mi lesz.

    Addig is köszi a figyelmet !

    Az, hogy conf file-ok eltűnnek, nem tűnik pipewire hibának, sokkal inkább a disztribúció bugja. Vagy a csomagban szúrtak el valami scriptet, vagy a filerendszerrel van baj. Gondolj csak bele, a pipewire nem tud különbséget tenni reboot és poweroff között. Ott az lehet a különbség, hogy a hardware - hangkártya - került más állapotba. Ez lehet hardware, firmware vagy kernel, esetleg alsa bug. Jó, meg a trivialitás, hogy labilis a gép.

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

    https://archlinux.org/news/undone-replacement-of-pipewire-media-session…

    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.

    "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

    ( Sas66 | 2022. 06. 29., sze – 21:18 )

    Világos, hogy a pipewire nem tud különbséget tenni.

    Feltehetőleg a gép stabil, mert a rajta futó w10, ubuntu 18.4, ubuntu 22.04, Mint 21 (egyenként) hibátlan, stabil.

    Annyi haszna van, - a problémának - hogy egy virtuális gépben megismerkedek a pipevire -val.

    És várok a manjaro újabb frissítésére. Csak mert korábban nagyon megtetszett.

    ( locsemege v | 2022. 06. 30., cs – 21:11 )

    Szerkesztve: 2022. 06. 30., cs – 21:13

    0.3.53

    The audioconvert plugin was rewritten. This should make it more maintainable. It also fixed some issues such as CPU spikes in some cases and crashes in others. The old plugins were removed, for a code reduction of some 6000 lines.

    Nekem ez is tetszik, Bode-diagram a hibajegyben:

    The resampler window function was changed to a cosh() window function. (#2483)

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

    ( locsemege v | 2022. 07. 08., p – 18:32 )

    0.3.54, elsősorban az előző release által elszúrt dolgok javításaival. Ebben ugyan átmenetileg kivették a resampler koszinusz hiperbolikusz ablakát :), viszont épp a kiadás előtt megtalálták, mitől torzított, de már ott nem tették vissza default-nak. Azóta viszont visszatették, tehát a következő kiadásban, vagy akár most forrásból fordítva visszakapjuk az immár javított cosh() algoritmust használó ablakot.

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

    ( locsemege v | 2022. 07. 12., k – 00:06 )

    A sok hozzászólás miatt nagyon lassú a lekérés, ezért arra kérem az érdeklődőket, ide ne kommenteljetek. Folytassuk a PipeWire #2 topikban!

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