PulseAudio 8.0

Szerszám

Megjelent a POSIX rendszerekhez készült hangrendszer, a PulseAudio 8.0-s kiadása. Ugyan a PulseAudio elsősorban Linuxhoz készült, de portolták Solaris, FreeBSD, NetBSD, OS X, Windows 2000 és Windows XP operációs rendszerekre is. Amellett, hogy szerves része napjaink releváns Linux terjesztéseinek, különböző mobilgyártók is felhasználják különböző mobileszközeikben.

A 8.0-s kiadás főbb jellemzői:

  • Automatic routing more likely to change profile
  • OS X and NetBSD support improvements
  • Systemd journal logging for clients
  • New LFE balance programming interface
  • Module-dbus-protocol
  • More flexible configuration file handling
  • pulsecore-8.0.so moved to a private directory
  • New script for measuring memory consumption
  • Various bug fixes and small improvements

Letölthető innen. Változások listája itt.

( carlcolt | 2016. 01. 25., h – 11:40 )

"OS X and NetBSD support improvements"

Rotfl, ki az a hulye, aki OS X-re feltenne ezt a foshanyast :D

pl. aki OSX alatt akar X2Go-t használni :) Ugyanez Windows-ra is [aminél 10-en is szépen megy, nem vágom ezt a 2000/XP dolgot a postban]

Egyébként meg már jó ideje nagyon kényelmesen és stabilan működik, nincs vele gond és sok tekintetben jobb, mint bármelyik rendszer audio alrendszere.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Szerintem meg sokkal jobb a tiramisu...

Azt akartam mondani, hogy az ALSA és a Pulseaudio egészen más dolgok. Másra valók. Mi több, a Pulseaudio ALSA driver-eket használ, van neki alsa kompatibilis interface-e, kezel hálózatot is, valós időben átrakhatod az audio stream-et másik kimenetre, tud visszhang elnyomást, újra mintavételezést, dinamikus a buffer méret, stb. Nagyon más a kettő.

Összehasonlítani az ALSA-val nem lehet, mert alma, körte.

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

Ez bőven lehet az alsa is, néhány chipnél az megcsinálja automatikusan a váltást [vagy nem] (füles - hangszóró, mikrofon - beépített mikrofon). Előbbivel egy netbook-on találkoztam, hogy aztán a gond az volt-e, hogy az ALSA-nak kellett volna [mert nem külön outputként mutatja a pulse-nak] és nem csinálta, vagy annak nem kellett volna és mégis, már nem tudom megmondani. Alsamixer-ben nézd meg, mit látsz mielőtt és miután bekötöd a fülest/mikrofont.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

No igen, amikor a Pulseaudio megjelent, nagyon rosszul működött. Ennek legtöbb esetben hibás ALSA driver volt az oka. Ha jól emlékszem, nem adott vissza helyesen valami pointert. Addig ez senkinek sem tűnt fel, mert azt a függvényt senki sem hívta. Lennart emlékeim szerint azon tajtékzott, hogy mások hibáit nem fogja hibaelfedéssel rendbe tenni, annak a megfelelő rétegben kell jónak lenni. A pulseaudio ilyenkor a logba bele is írja, hogy a hibával kapcsolatban vedd fel a kapcsolatot az ALSA driver fejlesztőivel.

Szóval van azért olyan is, amit pulse hibájának tulajdonítanak, de alsa hiba, csak alsa nem használja, így ott nem ütközik ki.

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

Jaj, Lennart mindig ilyeneken tajtékzik.
A systemd-ben is rendszeresen bele lehet futni 5+ éves bugokba, amiket Lennart egyszerűen nem hajlandó javítani. Aztán (mivel neked fáj, és muszáj workaroundot találnod) elkezded beleásni magad és rájössz, hogy az egész problémát Lennart csinálta magának, amikor egy szar design-t talált ki.
---
Régóta vágyok én, az androidok mezonkincsére már!

Sajnos ilyen részleteket nem tudok, de azzal az elvvel egyetértek, hogy nem nyúlunk át rétegek fölött. Tehát, ha az OSI-modell szerinti adott rétegben van egy hiba, azt nem egy másik rétegben orvosoljuk, hanem ott, ahol a hiba van. Mégpedig azért, mert olvashatatlan, kézbentarthatatlan, gány kódot eredményez, amelyet aztán rettentő nehéz debugolni, ha valami hiba van. Csábító dolog máshol hibát javítani, csak nem szabad.

Más kérdés, hogy mit tekintünk más rétegben történő hibajavításnak, s mennyire vagyunk vaskalaposak. Mondok rá példát. Assembly-ben szoktam mikrokontrollerre programozni. Mondjuk van egy táblázatunk, amelynek indexe 0..15 tartományban lehet. Ilyen esetben én mindenképpen egy AND 0xf jellegű paranccsal kezdem azt a függvényt, amely a táblázatot kezeli. Mondhatjuk, hogy ezzel a túlcímzés elleni védekezéssel hibát javítok, s nem a hívó helyen garantálom azt, hogy a paraméter 0..15 tartományba essen, s ez csúnya dolog, de felfoghatom úgy is, hogy a táblázatot kezelő függvényem az alsó 4 biten várja az indexet, a felső 4 biten bármilyen szemét lehet, tehát definíciószerűen ez nem hibajavítás, hanem így várom az inputot.

Az én hozzáállásom az, hogy ilyen „hibajavítások” viszont megengedettek. Nem fáj semmiben, megússzuk a túlcímzést, az eltévelygő programot, mi több, a hívott függvény ezen tulajdonságát tudatosan kihasználhatjuk. Tehát nem workaround, hanem tulajdonság.

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

Ha elkezdesz a hibák részleteibe jobban belemenni elég jellegzetes lesz, hogy nem a 'rétegeken átnyúlás' probléma, hanem hogy Lennart rendszeresen szar megoldásokat talál ki, amik más rétegek nem létező vagy opcionális feature-jeire függenek, vagy kifejezetten provokálják azoknak problémás cornercase-eit.
Kedvenc példám a systemd-notify esete, ami egy klasszikus bad design, gyakorlatilag bele van tervezve egy kritikus versenyhelyzet.
- Kb 100 másfajta megoldást lehetett volna kitalálni ugyanerre a problémára, ami nem elvi hibás
- 1db sleep megfelelő helyre berakásával is elég jól workaroundolni lehet (ocsmány megoldás, de jobb híján megteszi és működik)
Erre mi történik, Lennart hisztizik, hogy a kernelfejlesztők "fixálják ki" a unix domain dgram socket implementációt (értsd: feature request, hogy csak neki csak most a túlsó process cgroup-jai is lekérdezhetőek legyenek). Ezt persze a kernelfejlesztők nem csinálták meg, mert túl speciális igény, Lennart meg kb 2008 óta csak várja a megoldást. Mi meg szívunk a javítatlan systemd buggal.
---
Régóta vágyok én, az androidok mezonkincsére már!

Elhiszem, bár az is kérdés, melyik verziót használod. Én desktop gépen statikus konfiggal, van két hangkártyám, 7.1-es Pulseaudio-m, meg 4.3.4-es kernelem. Most is zenét hallgatok épp, VoIP is működik.

Ugyanakkor tudom, hogy nem hibátlan. VoIP-hoz használom a visszhang elnyomást, működik is, de gyakorta megszórja a logokat olyasmivel, hogy eltévedt a pointere a bufferben, ezen felül szerintem lehet benne algoritmikus hiba is. Ha valami oknál fogva túl nagy futásidőt visz, akkor öngerjesztő a folyamat, s szétesik a hang. Néhány verzióval korábban ezt elő tudtam hozni, ha nagyon igényes resampling algoritmust konfiguráltam. Az utóbbi időben nem néztem, mert noha szerintem valóban vannak hibái, a gyakorlati feladatokhoz jól használható. Abból, hogy lehet úgy konfigurálni, hogy ne működjön, még nem következik, hogy rossz. Jól kell konfigurálni. Az alapértelmezett konfig például működőképes.

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

Jól kell konfigurálni. Az alapértelmezett konfig például működőképes.

+1, meg nem árt, ha értelmes fejlesztők használják.

Esettanulmány: Microsoft és a Skype.
A gyári default configban ott van a module-role-cork, ami azt hivatott megoldani, hogy ha kommunikációs stream is van, akkor a többit lepauseolja (ha jól rémlik pl. Amaroknál ez kifejezett Play/pause, nem csak némítás). Korrektül működik is, a Skype is teljesen kulturáltan bejelentkezik, mint telefon stream. Minden hangra, legyen az tényleges hívás, vagy csak a "Belépett a Béla" figyelmezetető pop-up hangeffektje... ja.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( mrev | 2016. 01. 25., h – 17:26 )

A mostani gépekben a HDMI miatt általában több hangkártya is van (vagy legalábbis külön subdevice az analóg és digitális kimenetnek), azért az ALSA konfiguráció önmagában sem mindig zökkenőmentes.

Vagyishogy felrakja az ember a Linuxot, és nem szól magától a rohadék. Mikor ez bekövetkezik, addigra már mindig elfelejtettem, hogyan kell hangot konfigurálni. Az a tapasztalatom, hogy jobban járok, ha a pulse-t leszedem, mert úgy kevesebb akadályon kell átküzdeni magam. Szerintem csak egy felesleges plusz réteg.
--
ulysses.co.hu

+/-1.

+1, mert tényleg van, hogy nem találja el, hogy mit akarsz csinálni (nem is tudhatja), -1, mert annyira nem bonyolult állítani. Felteszem KDE-t használsz, ott tényleg kicsit elborult a hangbeállítás, de egy $PACKAGE_MANAGER install pavucontrol megoldja, azzal a legtöbb alap beállítást (melyik stream melyik be/kimeneti eszközt használja) pár kattintás megcsinálni.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem fogalmaztam elég részletesen ezek szerint, azt hittem világos lesz.

Ha Ubuntut telepítesz, akkor sehol nem lesz pavu. A hangszóró ikonra klikkelve egy más fajta hangbeállító felület jön elő, amely nem sok mindenre jó. Nem tudom a HDMI-re átállítani a hangot, meg logikátlan eszközöket jelentet meg, nem sok értelme van a cuccoknak rajta.

A pavucontrol meg olyan amilyenre én is tervezném. Ott vannak az eszközök, átállítom egyikre vagy másikra, hangerő stb.

Szerintem teljesen lényegtelen, mi a default telepítés. Engem nem is érdekel, nagyjából addig fontos, hogy legyen egy shell és egy csomagkezelő, azzal már bármi megoldható. Ha az alapértelmezett telepítést nézném, akkor most nem lehetne Xfce-m Compizzal, a felső lécen azokkal az eszközökkel, amelyeket szeretek, nem lenne automatikus update, ehhez nem tartozna notify, nem lenne backup-om, és sorolhatnám a véges sokaságig. :)

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

Ezt nézem https://en.wikipedia.org/wiki/PulseAudio:

In a typical installation scenario under GNU/Linux, the user configures ALSA to use a virtual device provided by PulseAudio. Thus, applications using ALSA will output sound to PulseAudio, which then uses ALSA itself to access the real sound card.

Elég zagyva dolognak tűnik. Innen nézve elég ijesztő, hogy a systemd-t használjuk.
--
ulysses.co.hu

Ez miért zagyvaság? A pulseaudio az alsa driver-ek fölötti réteg, viszont ha az alkalmazásnak nincs pulseaudio interface-e, akkor kell, hogy a pulseaudio az alkalmazás felé alsa felületet mutasson. Ettől persze még a pulseaudio-t fogja az alkalmazás használni - nyilván az eltérő API miatt korlátozott képességekkel -, majd a pulseaudio az újramintavételezett, kevert jelet a fizikai alsa-n keresztül juttatja a hangkártyára.

Különben hasonló lesz majd a wayland és a Xorg viszonyában is, bár ott a wayland nem a Xorg-ot használja alul. Az alkalmazások közvetlenül a waylandhoz kapcsolódnak majd, de ha valakinek kell a xorg, mert az alkalmazás nem kompatibilis a waylanddal, vagy ki akarja valaki használni a Xorg hálózatos szolgáltatásait, úgy a Xorg-hoz kapcsolódik majd az alkalmazás, a Xorg pedig a waylandon keresztül a VGA kártyához.

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

Na jó, de hogy oldanád meg? Van az alsa, tudja kezelni a fizikai hangkártyákat a driver-eken keresztül, tehát ezt nem kell újraírni. Szükség van keverésre, resampling-re, hálózatra stream-eléshez, visszhang elnyomásra, a csatornák fizikai eszköztől független logikai blokkokban kezelésére, automatikus erősítés szabályozásra, dinamikus buffer méret kezelésre az alacsony latency miatt, s megannyi ilyen dologra. Ezt megoldja a pulseaudio, de az új feature-ök és kényelmes használhatóság miatt egy új API-val. Viszont, ha új az API, az alkalmazásokhoz hozzá kell nyúlni. Ez meg is történt mondjuk 95 %-ban. Mi legyen azon alkalmazásokkal, amelyek továbbra is csak alsa API felé képesek csatlakozni? Mivel az alsa foglalt a pulseaudio által, legyen a pulseaudio-nak az alkalmazások felé mutatott emulált alsa API-ja, s már meg is vagyunk. Minden működni fog. Szerintem ez így logikus, működőképes, célszerű.

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

Semmi különös. Egy zip fájl tartalmazhat egy zip fájlt, egy fájlban lehet egy egész fájlrendszer, egy változó tartalmazhat egy komplett forrásprogramot, ezer ilyet ki lehet találni. A pulse viszont nem csökkenti, hanem szaporítja a problémákat. Attól még működhet jól is, de én jobban érzem magam nélküle.

Valami ubuntus oldalon olvastam a bennfentes okosságot, hogyan kell pulse-t konfigurálni. Az első pont: Ne purgáljuk a pulse-t! Na, már ez is sokat elárul a dologról.

Hálózaton keresztüli hang. Javaslatom: Az ftp-t, sshfs-t és társait le lehet váltani, csak meg kell oldani tetszőleges adat hangformátumra konvertálását. Ha ez kész, jöhet a Pulse OS:)
--
ulysses.co.hu

Hálózaton keresztüli hang. Javaslatom: Az ftp-t, sshfs-t és társait le lehet váltani, csak meg kell oldani tetszőleges adat hangformátumra konvertálását.

SSH-FS over TCP/IP over (De)ModulatedSound over PulseAudio over SSH over TCP over L2TP over IP over PPP over Ethernet.
Mi a gond? :) Mert akkor ugye már profin csináljuk és nem simán sshfs-t/ftp-t, hanem egy teljes L2-t emulálunk hang-moduláción, kicsit már amúgy is kezdem hiányolni a modem tárcsahangot. (és az igazán perverz dolog, hogy valszeg működne...)

Komolyra fordítva: az ALSA is hozott egy OSS kompatibilitási réteget (ez ugye a PA-nál az a réteg, amikor az alkalmazásnak nem kell PA-t "beszélnie", hanem használhatja a PA-t, mint egy ALSA-t). A Jack pedig szintén az ALSA-t használja kimenetre.
Ez a "közbeiktatott réteg" eléggé bevett gyakorlat és architektúra, mert amíg mindkét irányba tartod az interfészt, tetszőleges működéssel ki tudod egészíteni.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)