PipeWire #2

Fórumok

A PipeWire - mi ez? topic folytatása. Maga a PipeWire és a repository. Hozzá még a WirePlumber.

Hozzászólások

Szerkesztve: 2022. 07. 12., k – 11:11

Kérdés: PipeWire kezeli a pcspkr-t? Azt tapasztalom (Ubuntu 22.10 preview) hogy hiába állítom be, hogy minden fülesen jöjjön, egyes notification hangok hangszóróból, de talán inkább a PC speakerből jönnek, annyira élesek. Blacklisteltem kernel argumentumok között a pcspkr modult, tehát elvileg nem kéne hogy használja. Van-e valami módszer, hogy a notification-ök ne hangszóróból/pc speakerből jöjjenek?

szerk.: gnome.desktop.event-sounds opciót kikapcsolva dconfből megszűntek az idegesítő hangok. Ezek szerint bizonyos hangokat rossz kimenetre routeol, valszeg hibás a konfig alapból.

Szerintem a PC speaker a hagyományos értelemben nem hang. Van még a régi Intel 8086 és IBM XT-k korából egy programozható timer, s annak kimenetére tettek egy flip-flop-ot, hogy 50 % legyen a kitöltési tényező, vagy lehet, hogy fel lehet programozni eleve 50 %-os négyszög jelre. A pipewire szerintem csak akkor tudná, hogy ez hang, ha a kernel az alacsony szintű ALSA driver-én keresztül stream-ben legenerálná azt.

Szóval engem inkább az lepne meg, ha ezt tudná.

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

Azzal árnyalnám a képet, hogy az alkalmazás természetesen küldhet hangkártya felé, tehát alsa, pulse, esetleg jack interfészen audio notification-t. Azt ne feledjük, a PC speaker az 1980-as, legfeljebb '90-es évek technológiai öröksége, sok disztribúcióba bele sem fordítják már ezt a kernel modult. Default szerintem a Fedorában sincs, bár lehet, lefordítják, de úgy kellene betöltenem modprobe-bal. A PC-k hardware-ében is visszafelé kompatibilitási okok miatt van az alaplap chipset-jén ez a timer, ha egyáltalán. Meg az alaplap egyik tüskesorára fel lehet dugni a kis piezo vagy dinamikus hangszórót.

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

0.3.55

Igazából ez a patch is kell hozzá, csak kiadás után lett javítva.

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

Folyamatosan fejlődik, nagyjából 1-4 hetes kiadási ciklussal. Nem úgy működik, hogy rojtosra tesztelik, majd kiadják, hanem kiadják, majd jön a bugreport, hogy valamelyik alkalmazással 32 csatornás módban baj van a 27. csatornán. :) De Wim Taymans legalább foglalkozik vele, nem olyan arrogáns barom, mint Lennart Poettering, aki az alsa fejlesztőire mutogatott, miközben a saját vacka egyrészt hiányosan volt implementálva, másrészt hibásan, s érzésem szerint ráadásul nem is implementációs, hanem elvi baj van vele.

Nekem a mindennapi használat során semmi problémám nincs a pipewire-rel. Amikor volt, jeleztem a hibát, kijavították.

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

Az felfogás kérdése, mi a jobb. Ha van egy hiba, feltesszük a kezünket, s szóljon, ha elkészült, akinél a hiba van, vagy csinálunk rá workaround-ot. Igaz, így bekenjük sárral, de legalább működik. A felhasználónak ez utóbbi kell. A felhasználó semmivel sem boldogabb, ha úgy nem szól a hang a gépén, hogy nem a pulseaudio-ban, hanem az alsa-ban van a hiba. A másik, hogy az imént több dologról beszéltem. A pulseaudio akkor is rossz, ha az alsa bugot már kijavították, vagy olyan hangkártyával használod, amelyiknek a driver-e teljes értékűen és hibátlanul volt implementálva.

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

A sok felhasználónak meg az, hogy konzisztensen működjön minél több dologgal, és hosszú távon az elég nehéz, ha az ember dagonyázik. Illetve továbbra se értem, hogy ilyenkor miért az a hülye, aki nem dagonyázik, miért nem az, aki faszik megjavítani a driverét, miközben a pipewirenél látszik, hogy akkor rendes ember valaki, ha ezt csinálja.

A pulse audio nekem hosszú évek óta köszöni, és működik az eszközeimmel, a pipe slightly rosszabbul teljesít. (és mindkettő subpar kezeli a bluetooth feletti hangot, szóval én speciel élvezném, ha fingreszelés helyett ezzel foglalkoznának, szerintem nagyságrendekkel több usert érint, mint hogy van-e integrált jack támogatás)

Én már annak is örülnék, ha bármelyikben lenne rendes bluetooth headset támogatás. Amikor nem kell érmékkel meg kockákkal dobálózni, meg kecskét áldozni keresztútnál ahhoz, hogy egy BT fülest megbízhatóan életre tudjak kelteni vele.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Sajnos ezek a BT perifériák annyiféleképpen működnek, ahányan vannak. Nekem van egy BAA100-asom, ez 3.5 mm-es jack aljzatra teszi ki az analóggá konvertált hangot, ezzel megy a pipewire. Annak idején emlékeim szerint az én bugreportom hatására került blacklist-re a BAA100 olyan szempontból, hogy ne használjon hardware hangerő szabályozást. Nem azért mert nem tudja, hanem úgy emlékszem, lassan inicializálta magát, a pipewire beállította a hangerőt, a BAA100 utána feléledt, s felülírta valami default-tal. Erre lett a megoldás, hogy jó, akkor legyen software-es, szorozgassuk a hangmintákat, persze ez meg rongálja a dinamikát. Bár az elején még nem, mert a belső formátum float, de előbb-utóbb integer-ré kell konvertálni, s ott azért lesz baj.

Azóta nem tudom, változott-e ez, nem néztem utána. Csak azért meséltem el, hogy értsd, nem olyan egyszerű ezt megcsinálni, mert nincs mindenre szabvány - például hangerő init idejére -, így egy rakás paraméter gyártmányonként eltérő. Wim Taymans pedig nem múzeumigazgató, nem szenvedélyes gyűjtő, tehát nincs minden audio eszközből darab az asztalán, így a bugreportokra tud hagyatkozni. Már, ha nem csak szentségelnek az emberek, hanem jelzik is a problémát.

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

Tudod, én leszarom, ha a hangerőt utólag kell piszkálni. De legalább linkeljen fel normális duplex headsetként A2SP-n, és ne tetves mono HFP-n. Hogy torz, halk, nincs dinamika, az már másodrendű lenne nekem.

Amúgy, a PulseAudionak ugyanez volt a problémája, nem hiszem el, hogy annyi idő alatt, amíg az élt, nem sikerült legalább a fele hardverhez embert keríteni.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Azért nem ilyen egyszerű. Számít az is, hogy milyen BT modul van a gépben, és milyen közös nevezős codecet tud leegyeztetni a headsettel. De ja, a hangrendszer a Linuxnak, meg úgy általában a unixlike OS-eknek mindig is egy gyenge pontja volt. Ugyanis ezek nem audio-ra lettek teremtve, az csak utángondolás bennük, alapvetően konzolos szerver OS-nek készültek ezek, és bár be vannak fogva workstationra, desktopra, embedded felhasználásra, de itt-ott azért nem zárkóztak még fel a klasszik desktopos meg eleve professzionális audio-ra szánt rendszerekhez. Nem csak BT, de latency terén is.

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

Noha nagyon sok hozzászólásoddal egyetértek, ezzel most épp nem. Te most lényegében felmondtad, amit a '90-es évek Linuxáról illik tudni.

Egyrészt latency problémákra ott volt a Jack. Másfelől a Pipewire sok más mellet ezt is igyekszik orvosolni, ezért lett kitalálva. Nem véletlen az, hogy van pulse, jack és alsa interface-e, s ezeket egyidőben is lehet használni. Az erőforrás problémákra a minél kevesebb memcpy(), helyette a pointerek átadása a megfejtés.

Bufferelni muszáj, teljesen eliminálni nem tudod a latency-t, tekintve, hogy egy operációs rendszer semmilyen garanciát sem ad a process időben történő futtatására, legfeljebb csak halvány ígéretet, ha az betartható. Nézd meg a Windows-t. Desktop oprendszernek mondják, de annak sem jó az audio alrendszere. Volt olyan, hogy Teams megbeszélés volt, de hang nem volt megfelelő, gyorsan linuxos gépre váltottam, az mentett meg.

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

Nem is azt mondtam, hogy rossz, nekem, mint átlag desktop usernek mindig is megfelelt a hangminőség. De professzionális audiósoknak más az elvárása. Ez ilyen. A Linux sem tökéletes, megvannak a gyenge pontjai, nem csak a hangrendszer, a nehézkes mountolás (állandó rendszergazdai jog kell neki oda is, amikor olyan lemezképet, olyan mappába csatolsz, ami a sajátod), hibernációból/sleepből visszajövetel, és még van pár ilyen. Nyilván még így is köröket van a Windowsra, MacOS, de hát semmi nem hibátlan. Nagyban függ attól, hogy ez mennyire jön ki valakinek, hogy mire használja a gépet.

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

Igen, azt tudom, akár fstab-on kívül is lehet, ha a mount-nak extra paraméterként adom meg, de ez megint extra vergődés, amit nem kéne csináljon. Mert akkor okés, ha meghajtót csatolok fel /dev/-ből, vagy valami olyan mappába, ami rendszermappa, akkor kérjen, de egyébként ne. Mert akar a fene szenvedni fstab-bal, mount paraméterrel, meg fuse mount-tal (úgy is megy). Nagyobb DE-kben is van általában automount, fuse-alapú általában. Nyilván nem abszolválhatatlan, ez csak egy példa akart lenni, hogy vannak az Linuxnak ilyen oldalai, amik nehézkesek meg nem ideálisak maradtak, és mi, aki már évek óta toljuk, megszoktuk, de főleg új, kezdő linuxos usereknél eléggé kiveri a biztosítékot.

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

hát, én nem tudom mikor láttam utoljára olyan linuxos DEt, amibe ha belenyomtam valami randomszart, akkor ne tudta volna password nélkül felcsatolni.

Meg egyébként is tök érdekes, hogy az egyik oldalról pápázod itt a minimalizmust, meg az akkor vagy hatékony, ha megtanulod a mindenfélét, másrészt meg hatalmas vergődés, hogy be kell írni egy plusz paramétert a mountnak

Mondjuk nem tudom mit, mert ami megy sima userként is, az flag nélkül is megy, és egyébként se nagyon látom, hogy van egy alapvetően security feature, akkor miért lenne egy --leszarom-nekem-akkor-is-szabad opciója a mountnak.

Igen, mert a minimalizmus nem hozza azt magával, hogy kényelmetlennek kell lennie egy megoldásnak. Nyilván megoldom, felveszek a speciális paraméteres mount-ra egy aliast a shell rc-jébe, vagy írok rá egy fzf-scriptet, amit bedrótozok gyorsbillentyűre (ennél maradtam, doas-zal oldottam meg, hogy ne kérjen jelszót se), csak ezt úgy érzem extra körlefutásnak, hogy valójában nem lenne szükséges ilyennel a usert szivatni. Gondolom még udev-szabállyal vagy init által futtatott service scripttel is meg lehetne oldani, stb..

Az egészből csak azt akartam kihozni, hogy a Linux sem hibátlan, nem ideális mindenben. Nyilván az olyan szutyok rendszereknél, mint a Windows, MacOS, ChromeOS, Android, stb. dimenzionális ugrás a pozitív irányba, de azért megvannak a hibái, nehézségei, amin lehetne még bőven javítani. Annak ellenére, hogy egy rutinos linuxos user már megszokta ezeket, vannak workaroudjai, de ettől még nem természeteseket ezek.

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

Elképesztően sokat fejlődtek a Linux alapú operációs rendszerek az utóbbi két évtizedben. A korábban nehézkes megoldások kényelmessé, elegánssá váltak a legtöbb esetben. Minap tapasztaltam, hogy Thunar filemanager meglátott egy iso9660 image file-t, automatikusan loop mount-olta, s máris hozzá lehetett férni a belsejéhez, mindezt úgy, hogy ehhez semmit sem kellett tennem, csak rá kellett kattintani az iso file-ra, vagy valami ilyesmi. Nem is tudtam, hogy ezt ilyen kényelmesen tudja, véletlenül fedeztem fel.

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

Általában a legtöbb mai modern DE (nem WM-ről beszélek, hanem komplett asztali környezetről), megoldja ezeket, tipikusan GVFS-sel, amihez vannak mindenféle modulok, azok mindent tudnak csatolni, automatikusan, és egy kattintásra is, és a GVFS még a polkit jogosultságokat is tudja kezelni (pl. rendszerfájl szerkesztéséhez a GUI text editornak nem kell emelt jogokkal futni, csak a fájlt éri el emelt jogokkal), meg a kukát is így oldják meg. De ez pl. nekem felesleges bloat, hogy állandóan fusson a háttérben gvfs, egy csomó komponenssel, van helyette udisks, udiskie, stb. megoldások, de azok sem sokkal kevésbé bloatok. Megoldható, persze minden, de ennek alapból így kéne mennie, bármilyen sallang nélkül.

Az .iso fájlokhoz nem csak mounttal férsz hozzá, hanem fuse-zal is, meg bármilyen archívumkezelővel, commanderrel, azok is meg tudják nyitni, fájlokat eléred benne, ha csak ez a cél, még mountolni sem kell hozzá.

Már nekem is van a kényelmes mountolásra doas + saját scriptes fzf-es megoldásom, ami megfelelő paraméterekkel csatol, hogy a felhasználóm is írni tudja az adott drive-ot, lemezképet, ami fel van csatolva, stb., ennek ráadásul nem is kell állandóan a háttérben futni, csak a csatolás, lecsatolás erejéig fut le, aztán kilép. De ez akkor sem teszi természetessé, hogy nekünk, rutinos linuxos felhasználóknak vannak már workaroundjai erre. Aki viszont most kezdi a linuxos pályafutását, az a haját tépi ettől, hitéből kitér, vagy bloatot kell használjon, nem olyan ideális a helyzet, mint elvileg lehetne.

Vannak még a Linuxnak ilyen oldalai, mint írtam, hibernálás, sleep általában nem működik megbízhatóan, nyomtatáshoz kell a CUPS, mikor egyszerűbben is meg lehetne oldani, böngészőkben általában default nem megy a hardveres videódekódolás, bár ez utóbbi nem a Linux hibája, hanem a böngészősök sara, és be lehet ugyan kézi hekkelésekkel kapcsolni, de csak bizonyos csillagok együttállásakor megy (van, hogy Wayland kell hozzá, van hogy adott verziós GPU driver, csak bizonyos GPU + driver kombó), sok disztrón alapból tearingel a X.org, és még lehetne jó hosszan sorolni ilyen problémás területeket. Mind-mind megoldható, de nem olyan ideális, mint lehetne. Az is igaz, hogy mindenben ideális rendszer nincs, nem volt, nem is lesz soha. Törekedni lehet rá, de teljesen megvalósítani nem.

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

Nem, nem az a baj, hogy szerver alapú. Hanem hogy feleslegesen komplex. Elég lenne egy sima service vagy egy egyszer futó CLI tool hozzá, ami fogadná a bemenetet, rárakná a szükséges, bekonfigurált szűrőket, és kitolná a megfelelő formátumba, protokollal a nyomtatóra. Simán nyomtatáshoz a legtöbb felhasználónak overkill és bloat a CUPS, az a vele a baj, komplett szerver, webszerver, stb. fut miatta akkor is, ha épp nincs nyomtatás, ami cégeknél, megosztott nyomtatónál oké, de home usernek agyrém.

Hála istennek, ha valami sztenderd, IPP-s nyomtatója van az embernek, ma már a CUPS elkerülhető, és megfelelő formára (PS, Pdf, SPL, stb.) konvertálva az anyagot néhány pipe-olással be is lehet küldeni a nyomtatónak netcat paranccsal, valami ilyen egyszerűségű megoldás kéne általánosan.

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

Ha általános, akkor az a cups, ha pedig valami rugalmatlan, egyedi, picike, akkor ott van a netcat, socat, ahogy írtad is. Mi a félelem tárgya egy szervertől? Nem fut le az összes kódsorából fordult kód minden egyes alkalommal, amikor időszeletkét kap. Legtöbbször hamar rájön, hogy üresek a bufferek, semmi dolga, aztán visszatér. Gondolom, írtál már programot, akár nagy programot, s tudod, hogy csak ritkán fut a nagy és bonyolult része, de akkor azért fut, mert arra van szükség.

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

Igen, tudom nem fut a nagy kód minden kódsora, a legtöbb esetben csak egy várakozó loop benne (vagy még az se, amikor a kernel altatja a folyamatot, mert nem hívja semmi), de ez a pár sor is feleslegesen fut, ha épp nincs rá szükség. Az egész ezzel a jogkiosztással, szerverezéssel, sorkezeléssel túl van bonyolítva, cégekre van szabva, magánembernek, otthoni felhasználónak legtöbbször overkill az egész, és mégis rá van tolva mindenkire. Persze, lehet trükközni, hogy valami scripttel indítani a szolgáltatásokat, utána lpr-rel kinyomkodni a cuccot, majd szolgáltatást leállítani, de ez csak elfedi a komplexitási fokot, nem szünteti meg. Működni működik, de bonyás, főleg egyszeri felhasználónak, aki nem rendszeradminisztrátor, hogy mindenféle service-ekkel, és szerverrel, jogokkal, ppd fájlokkal huszárkodjon. Meg lehet tanulni, ahogy neked, nekem is megy, de ettől ez még mindig felesleges komplexitás sok esetben. Azért, mert már valamit megszoktál, és a komplexitása fel sem tűnik, egyszerűnek érzed, az nem azt jelenti, hogy az a legegyszerűbb, meg a legjobb megoldás.

Jó példa erre a bootolás. Sok esetben, ha a a gép tud UEFI-t, és csak home felhasználás, akkor lenne a GRUB-nál sokkal egyszerűbb módszer, de mégis a mainstream disztrók a GRUB-ot tolják rá mindenkire, ami sokszor el is törik. A systemd-boot, EFI stub boot sok esetben egyszerűbb, kisebb komplexitású, és emiatt nem is törik el. Igaz nem is tud annyit, mint egy GRUB, mert utóbbi tud szoftveresen titkosított kötetekről, RAID-ről, egzotikus fájlrendszerekről, btrfs snapshotról, stb. bootolni, de ez megint overkill a legtöbb otthoni usernek, akik csak sima partíciókat használnak, sima ext4-gyel, titkosítatlanul (vagy transzparens hardveres titkosítással), stb..

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

nyomtatáshoz kell a CUPS, mikor egyszerűbben is meg lehetne oldani,

Hogyan? A másik lehetőség az lpd, az is egy démon. Linuxon nincs szerver nélkül nyomtatás, ahogy grafikus megjelenítés sincsen. Ez egy adottság.

és még lehetne jó hosszan sorolni ilyen problémás területeket

Akit ezek zavarnak, az átmegy Windowsra vagy vesz egy Macet és hirtelen teljesen más dolgok fogják zavarni. Meg kell érteni, hogy Linuxon a grafikus felület és a desktop felhasználás nem kezdettől fogva természetes dolog. Eredetileg ez egy szerver-jellegúű operációs rendszer, minden, a grafikus felület fejlesztésést és a r=1 user számára "kikönnyített" használatot illeti, alacsony prioritással ment hosszú-hosszú évekig, és most is jórészt hobbiból fejlesztik. Ez még évekig ilyen lesz, ha nem áll teljes grafikus környezetek mögé egy cég, és kezdi el termékként árusítani. Nem azt mondom, hogy ezt szeretném, azt mondom, hogy a stabilitásnak és a wide-spread kompatibilitásnak ez lesz az ára.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Valószínűleg az is számít, ki mennyire agresszív. Lennart használt olyan alsa függvényt, amelyet korábban szinte soha senki sem használt - talán a pointer lekérdezése, hol tart a tényleges lejátszás a hangkártyán, vagy valami ilyesmi -, s mivel nem használták, sok driver-ben nem volt implementálva, vagy rosszul. Könnyen belátható, ha csak az a szempont, legyen meg a függvény, de nem használja senki, egy return 0; épp jó is lesz. :)

Ezzel szemben Wim hozzállása jobb, eleve nem használ olyasmit, ami nincs, vagy hiányosan van implementálva. Úgy tekint a driver-re, mintha csak a gyakran használt függvények képeznék az API-t, minden mást megcsinál saját maga.

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

Van az ideális világ, meg van a valóság. Kellemetlen, de sokszor egy-egy errata-ból tudod meg, mi minden nem működik egy processzorban, s vannak olyan hardware bugok, amelyekre workaround sincs. Illetve az a workaround, hogy nem használod az adott hardware funkciót. Példának szántam a valóságra.

A mérnök gányol, ha nincs ideje valamire. Diagnosztikai célból kellett volna mérnünk valamit önmaga függvényében, erre jött egy szép nagy hibaüzenet. Kértük kollégát, javítsa meg. Ő meg mondta, hogy a valóságban nem lesz ilyen mérés, most meg nincs erre ideje.

Szóval de, a mérnök néha gányol. Nyilván törekszem én is igényes munkára, általános megoldásokra, de van az a helyzet, amikor átnyúlsz rétegek fölött, mert nincs arra futásidőd, hogy szépen csináld meg. Például kihasználod, hogy mekkora az USB buffer mérete, miközben semmi köze felsőbb rétegnek a szállítási réteg bufferméretéhez.

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

már elmagyaráztam, akkor sem értetted, vagy értettél vele egyet. ha szerinted pottering rossz, mert használta az alsat, miközben tudhatta volna, hogy a többi kiváló mérnökszakember "elég ide egy return 0, és már implementáltam is az intefacet módon dolgozott", wim meg jó, mert hát ő csak azt használja ami biztosan van [zárójel nyit, és amit igazából nem tud, csak hasal, és aki emiatt újra fogja írni azt is, ami már kész van], és ezt olyan példákkal támasztod alá egy generikus hangszerverhez, hogy te már jártál úgy, hogy valami egyszeri méréshez nem volt értelme megcsinálni, és nem érted, hogy mi ezzel a baj, akkor nincs értelme ezt megint hosszan elmagyarázni.

Úgy, hogy közben a pulseaudio szerinted még elméletileg is hibás, holott arról van szó jó eséllyel, hogy a te konkrét scenariod pont pofára esett akkor, amikor pötyi épp az általad nagyrabecsült gányolást csinálta :)

Nem az a baj, hogy nem értem. Nem értek vele egyet. Az meg miért probléma? A mérnöknek nem idealistának kell lennie, nem egy ideális világ problémáira kell megoldást adnia, hanem egy reális világ nagyon is valós problémáira. Ha az alsa rétegben valami hiányos, akkor ezt tudomásul kell venni peremfeltételként.

Mondhatod, hogy jogodban áll Ferrarival járni Budapest utcáin, csak épp nem bölcs, ha tele van kátyúkkal, fekvőrendőrökkel, meg néhol még gödrös földutat is találsz. Erről az jut eszembe, hogy fiatal csajsziknak is jogukban áll szokásosnál is kihívóbb öltözékben buliba menni, csak utána ne tessék meglepődni, meg hüppögni, ha az este nem egészen az elképzelések szerint alakult.

Ha rád hallgatnék, használnám egy 32 bites MIPS köré épített PIC perifériákból álló MCU i2c interface-ét, de akkor sem fog működni, ha az én kódom hibátlan, és akkor sem, ha ujjal mutogatok a Microchipre. A piacon nem tudom értékesíteni azt a szemléletet, hogy nem miattam nem működik a berendezés, hanem a Microchip hibájából. A berendezésnek működnie kell. Lennart pedig épp ezt csinálta. Olyannyira, hogy arrogáns módon még be is logolta. A pulseaudio jó, az alsa implementációs hibája miatt sz.r az egész. Ezek alapján bizony azt gondolom, Lennart egy beképzelt figura, nem pedig jó mérnök.

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

Még várok a váltással, de kíváncsian követem :)

Már régen jobb, mint a pulseaudio, de tudom, vannak óvatos emberek. :) Különben a váltás néhány csomag feltelepítését jelenti, ami azért nem egy két napos project. Sokkal inkább néhány perces. Jó, meg kellhet a logout, majd login, vagy megoldás a megfelelő service-ok (újra)indítása a systemctl --user daemon-reload után.

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

sub.

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.

Ahogy nézem a patch-eket (július 12-ét érdemes meglesni), a következő verzióban - meg nekem már most, mert forrásból csináltam csomagokat - érkezik az Audio Video Bridging.

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

Ezt biztos is, hogy használod? Mármint ezt az AVB-t. Egyébként nekem is működik a Pipewire, de én nem tudok annyira lelkesedni érte, mint te. Valahogy nekem csak egy n+1. RH-es bloat. Használom, mert már most se ajánlott pulseaudio-t használni, szépen vezeti ki mindenki, de én még mindig inkább használnék ALSA-t szívesebben.

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

Nem használom az AVB-t, inkább az azóta történt bugok javítása miatt fordítottam a git repóból kihúzott forrást. Bloat? Mert tolják bele a mindent is mennyiségű feature-t, bár szerintem ez nem baj. Amit nem használsz, az nem fog futni, nem viszi a gépidőt. Hiába van egy ezer soros switch() case szerkezeted, ha csak az egyik ága fut mindig.

Szerintem használhatsz alsa-t, bár kliens oldali támogatás egyre kevésbé van hozzá. Audacious-ban még van, de abban van ALSA, OSS3, pulse, jack, SDL, QtMultimedia, szóval szinte minden. Az ALSA-nak az a hátránya, hogy bután csak egy végződtetés a hangkártyához. Pipwire - meg persze a pulse is - megoldja a több kliensről érkező, különböző mintavételi frekvenciájú hangok esetleges keverését, resampling-et, egy időben több kimeneti interface-re küldését, a jelutak route-olását, visszhang elnyomást, hálózati audio I/O-t, szóval úgy kb. mindent, plusz a pipewire szállít mellé video-t is.

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

Másnál is van úgy, hogy nem veszi észre, ha bedugom a fülest, csak egy pkill pipewire; pkill pipewire-pulse után?

A korrekt megoldás az lenne, ha nem kéne újraindítgatni. Azt észreveszi, ha kihúzom, de azt már nem, ha visszadugom.

De más érdekesség is volt már a ki-bedugásnál, pl. bekapcsolom az AV receivert, akkor észrevette, és ki lehetett választani, hogy mondjuk a böngésző HDMI-n küldje a hangot, aztán amikor kikapcsoltam, a receiver ugyan eltűnt, de a hangot nem lehetett visszaterelni az alaplapi hang"kártyá"ba (pkill-ig).

Az az igazság, hogy ezt a többféle kimenet között váltást már anno a pulseaudio se kezelte tökéletesen. Én ebből a szempontból szerencsés vagyok, mert ugyan dugdosok fülest, de csak egyféle kimenetet használok, HDMI-t nem, így nem okoz kavart.

Próbáld meg bedugásnál letiltani azt a kimenetet, ami a gondot okozza. Lehet rá írni egy szkriptet is, ami meghívja a pactl-t, megfelelő paraméterekkel letiltva az adott kimenetet, majd ennek lehet párját írni, ami engedélyezi, ha szükség van rá.

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

Igaz. Ha tőlem is akartok olvasni egy bugot, legyen. Egyszerre két bluetooth eszközre route-oltam hangot. Az egyik egy Panasonic SA-PMX80 micro hifi, a másik egy JBL Flip 5. Hát... meszólalt, egy darabig volt hang, aztán kicsit akadozott, majd az egyiken teljesen kimúlt a hang. Fogalmam sincs, hogy ez pipewire, wireplumber, netán bluetooth réteg hibája. Vagy így együtt.

Ja, a host-on egyetlen bluetooth interface volt, tehát nem volt dedikált interface a két kliensnek.

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

Na most rászántam magam egy kis kísérletezésre, és rájöttem, mi a baj. Az a baj, hogy nekem normál hangszóró nincs is rádugva a gépre, csak fülhallgató. Ha ezt kihúzom, akkor a pipewire az egész hangkártyát offba teszi (mert nincs egy működő kimenete se). Innen viszont nem engedélyezi, ha újra bedugom a fülest. PulseAudio Volume Control-lal visszakapcsolhatom, akkor nem kell pkill. Ha dugok rá egy hangszórót, akkor is jó. Ez azért így elég hülye viselkedés. Talán megér egy bugreportot. Addig is a workaround: üres jackdugó a hangszórókimenetbe.

(Ja, és PulseAudio Volume Control helyett nincs natív? Vagy amúgy is a pulse interfaceit implementálja, szóval jó ez?)

Ez így sokkal korrektebb. Valóban van egy null sink arra az esetre, ha semmi sem nyeldesi a hangot. És szerintem is rájöhetne, hogy ha megjelenik az a sink. Nálam észreveszi, ha USB-n megjelenik az SA-PMX80. Ez inkább tűnik wireplumber bugnak.

Tudtommal nincs natív, mert kliens oldalon a pulseaudio-lib van használatban, s az összes eszközzel működnie kell. Esetleg tedd fel a Carla-t, ez jack kliens, s tudod látványosan route-olni a dolgokat, mintha azok kábelek lennének. Akár fel is cserélheted a bal- és jobboldalt. Én is ezzel oldottam meg, hogy az audacious hangja egyszerre menjen a két bluetooth kliens felé.

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

Nekem hasonló hibám volt Ubuntu 22-n, ha kihúztam a fülest, akkor átváltott a laptop belső hangszórójára, és nem volt hajlandó visszaváltani amikor bedugtam újra. Néhányszor oda-vissza kellett kapcsolgatni a kimeneteket, amíg magához ájult. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

0.3.56

Nem tudom, ez segít-e itt bárkin is:

A channel mapping bug was fixed in audioconvert. Unit tests were added.

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

Most olvastam én is a redditen. Állítólag elég sok BT feature került bele, kódekek, stb., akinek korábban Bluetooth problémás volt, próbálja meg újra.

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

Ezen felbuzdulva rápróbáltam tegnap, pillanat alatt párosodott és még codec-et is jól választott. Ja, és mást választ, ha filmet nézek, vagy zenét hallgatok, mint ha headsetként használnám.

Teljesen elégedett vagyok.

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.

Bocsánat, elfelejtettem linkelni:

0.3.58

Azóta van már néhány patch, amit érdemes belefordítani. Legegyszerűbb git repóból mindent.

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

Ez tetszik, fordítottam is egyet forrásból, már ez szól. :)

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

Hú, apám, nagyon keményed tolod. Pedig én is frissességmániás meg verziófetisiszta vagyok, de ez még nekem is meredek, hogy a rollingos kiadást se várod meg, hanem már pörgeted ki forráskódból meg kézzel patcheled. Szerintem feleslegesen dolgozol vele, kb. 1-2 nap után ott kéne lennie a Fedora, Arch, stb. tárolóiban, pl. Arch testingre tegnap érkezett meg a 0.3.59. Tényleg nem értem, hogy egy audio subsystemért hogy lehet ennyire rajongani :D

Persze, még mindig inkább ez, mint az, amit az ubuntusok meg debianosok csinálnak, hogy az új verzió majd csak a fél-egy év múlva megjelenő kiadásban lesz benne, persze addigra már elavult verzió lesz, de annak kell örülni, mert az még stabil volt, ilyen dinoszauruszok kövültek bele, és akkor már muzeális értéke is lesz.

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

Valóban szorosan követem a projectet, ennek érzelmi okai vannak. Mivel használom a seren nevű VoIP klienst peer to peer, s a pulseaudio elfuseráltsága miatt recsegett-ropogott a hangja, a pipewire egy megváltás volt számomra. Aztán előfordult olykor regresszió benne, akkor segítettem Wim Taymansnak debugolással, s így javításra került a kódja.

Pipewire-t fordítani nagyon könnyű. Virtuális gépen szoktam, leszedem a Fedorához való source rpm-et, amiből csak a pipewire.spec file kell. Kihúzom git repóból a forrást, törlöm a .git alkönyvtárat, átnevezem aktuális verziószámúra a legfelső directory nevét, majt tar-ral egybe rakom és egyúttal tömörítem. Utána rpmbuild -bb pipewire.spec, és meg is vagyunk. Nyilván törlöm az esetleges patch-eket a spec fle-ból, mert a forrásban már úgyis minden megvan. Az rpm-eket visszamásolom a host-ra, telepítem, systemctl --user daemon-reload, utána újraindítom, s meg is vagyunk.

Ráadásul gyorsabb csinálni, mert shell history-ban minden megvan már, a fordítás is megvan kb. 2 perc alatt.

De igen, már nálam is a Fedorára Wim által fordított 0.3.59 van. :)

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

Van-e arra megoldás hogy ne ordítson a fülembe a rendszer indítása után? Bővebben: Általában szerényebb hangerőt használok. Kikapcsoláskor is ez van érvényben. Azonban a gép következő bekapcsolásakor a pipewire teljes hangerőt állít be. Aztán pedig meglepetésemben letépem a fejhallgatót. Mintha régebben megjegyezte volna az utoljára beállított hangerőt. Vagy tévednék? Természetesen keresgéltem a beállítások között, de nem találtam olyat amivel kapcsolni lehetne ezt a viselkedést. Fedora 35 és Xfce az alaprendszerem. Örülnék ha valaki tudna segíteni.

Meg szokta jegyezni a hangerőt. Amit én csinálnék:

Leállítanám a pipewire-t:

systemctl --user stop pipewire\* wireplumber.service

Utána törölném azokat a file-okat, ahol ilyesmit tárolhat:

~/.local/state/{pipewire,wireplumber}

~/.config/{pipewire{,-media-session},wireplumber,pulse}

Aztán elindítanám a pipewire-t:

systemctl --user start pipewire\* wireplumber.service

Majd beállítanám a hangerőket a pavucontrol nevű eszközzel, végül leellenőrizném, sikerült-e a kísérlet.

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

Nekem egy ~/.local/state/wireplumber/ alkönyvtáram volt. A ~./config/pulse/ tartalma meg júniusban frissült utoljára.

A törlések után újraindítottam PipeWire-t. Csak a ~/.local/state/wireplumber/ alkönyvtár jött újra létre. A korábban futó zenelejátszót ismét elindítottam és az most nem ordít. Viszont a hangerőszabályozó nem tud kapcsolódni: "Kapcsolat felépítése a PulseAudióval. Kis türelmet..." Ez látszik egy ablakban. Egészen addig amíg úgy nem határozok hogy a kis türelem elfogyott és bezárom az ablakot. Gondolom egy rendszer indítás majd megoldja. Köszönöm a választ.

Természetesen. Egy szolgáltatás sem veszi jónéven ha a futása közben törlöm a hozzá tartozó fájlokat. Azóta viszont béke van. A pipewire ezeket a fájlokat hozta létre ismételten:

~/.config/pulse/cookie
~/.local/state/wireplumber/default-nodes

~/.local/state/wireplumber/default-routes

~/.local/state/wireplumber/restore-stream

Ha változtatom a hangerőt akkor ez a fájl frissül: ~/.local/state/wireplumber/default-routes

Közelebbről pedig ez a sor:

alsa_card.usb-ASUSTeK_XONAR_SOUND_CARD-00:output:analog-output-speaker:channelVolumes=0.27461725473404;0.27461725473404;

 

--------

Azt még hozzáteszem hogy volt már két rendszerindítás.

Elnézést, nem néztem meg hogy esetleg válaszoltál-e valamit. Nos a nyomorult megint ugyanúgy szívózik velem mint korábban. A grafikus felületre való bejelentkezés után az első dolog amit látok az egy kis felbukkanó ablak a jobb felső sarokban (Xfce). Ebben egy hangerőszabályozó látszik ami a maximumon áll. Pedig úgy kapcsoltam le a gépet hogy kis hangerőn volt. Azóta felfedeztem mást is. Ha hosszabb időre itthagyom bekapcsolva a gépet akkor azt szoktam csinálni hogy a Ctrl+Alt+F7 kombinációval átkapcsolok egy olyan terminálra ami nincs aktiválva. Ezután lekapcsolom a képernyőt. (Mindezt azért hogy ne tudjak figyelmetlenségből csinálni valamit ha véletlenül megpiszkálom az egeret vagy a billentyűzetet.) Amikor visszajövök és ismét dolgozni akarok akkor képernyő be és Ctrl+Alt+F1. Aztán Ctrl gombbal felébresztem az ablakkezelőt. (Azért a Ctrl gomb mert az önmagában nem okoz adatbevitelt.) Erre megjelenik a jelszót kérő ablak, vagy az asztal ha csak kis ideig voltam távol. Ha több idő telt el akkor feloldom a képernyőzárat és azonnal látszik a jobb felső sarokban a jelzés hogy már megint teljes hangerőre állt a pipewire.

Arra gondolok most hogy ez lehet esetleg az Xfce sara is.

Eddig mindig azt használtam. Most a javaslatodra kidobtam és egy indítómenübe felvettem a pavucontrol-t. Aztán próba.

Ctr+Alt+F7: Elhallgat mint máskor.

Ctrl+Alt+F1: Megszólal a korábbi hangerővel. Nem ordít. Óriási.

Ezt ösztönzés nélkül is kipróbálhattam volna de nem gyanakodtam pont a hangerőszabályozó modulra. Valami mélyebben gyökeredző disznóságot sejtettem a háttérben.

Akkor remélhetőleg ennyi volt. Köszönöm a javaslatot.

0.3.60 rengeteg módosítással.

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

Úgy néz ki, hogy mégis van gondom ezzel a PW-rel. Csak nem a hang terén, ahogy az ember várná. Már több hónapja akadozik a netes videók lejátszása (pl. YouTube), ha beletekerek egy videóba, akkor random elkezd megállni a videó, mintha töltené a hátralevő részét, de sose fejezi be. Nem mindig, de elő-elő fordul. Eddig azt hittem, hogy a szar Wi-Fi okozza, de gyanús lett, hogy a net a videón kívül működőképes, nem szakadt le, vagy ilyesmi. Aztán jött egy újabb PW verzió, ezzel azt csinálta, hogy megállt a videó, de a hang ment tovább, innen jöttem rá, hogy a PW-rel van a baj, eszembe jutott régebbről, hogy mikor a wireplumbert szedtem le, akkor nem játszotta le a videókat. Következő PW frissítésre (azt hiszem, hogy 0.3.59) megjavult. Jelenleg a 0.3.60-nal megint nem jó, néha beállnak a videók. Mit lehetne ezzel csinálni?

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

Nem tapasztaltam ilyesmit. Melyik disztribúciót használod? Arch? Ha nincs jobb ötleted, a disztrubúciód csomagkészítő utilityjével git repóból kihúzott legfrissebb forrásból fordíts és csinálj új csomagot magadnak, illetve jelezd a problémát a gitlabon egy új ticketet nyitva. Elég jó a hozzáállása Wim Taymansnak. Volt nem rég olyan bug, amit jeleztem, másfél óra múlva javította.

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

Archról van szó. Jelenteni fogom bugként. Az a trükkös benne, hogy eddig félrevezetett, és nem tudtam, hogy emiatt van. Nem biztos, hogy maga a PipeWire, lehet a Wireplumber is, de most már tuti, hogy valahol itt keresendő a probléma gyökere, esetleg a Firefoxnak nem tetszik ez a PW környezet. Az is elég furcsa, hogy csak néha csinálja, tehát nem minden videónál, és azoknak sem minden pontján. Minél többet tekerek bele egy videóba, annál jobban megnő az esélye, de ez sem garancia rá, hogy előjön a bug.

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