Hang átvitele lokális hálózaton

Gondom az volt, hogy a picike notebook hangszórója is picike ennek megfelelő hangminőséggel. Jó volna például megnézni egy videót úgy, hogy az asztali gépre kötött HiFi cuccon szóljon a hang. Mindez Pulseaudio hangszerverrel igen egyszerűen megoldható. Kliensnek nevezem azt a gépet, amelyről a hangot küldöm, s amelyen az alkalmazás fut, ez esetben ez a notebook. Szervernek pedig azt nevezem, amelyiken megszólal majd a hang, tehát amelyre az erősítő és a hangfalak vannak kötve.

A kliensen a /etc/pulse/default.pa file-ba írandó az alábbi sor:

load-module module-tunnel-sink-new server=itt_szóljon

A szerver /etc/pulse/default.pa file-jába pedig ez írandó az ott eredetileg megtalálható konfigon felül:

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24 auth-anonymous=1

Értelemszerűen az alhálózatot és a maszkot helyesen kell megadni. Ezen felül a szerveren be kell engedni a 4713-as tcp portot. Ez a Fedora tűzfal beállításaiban pulseaudio nevű szolgáltatásként már definiálva van, így elegendő a permanens beállítások között ezt bepipálni.

Utána mindkét gépen indítsuk újra a hangszervert sima user joggal, aztán működni fog:

pulseaudio -k
pulseaudio --start

A kliens gép keverőpultján választható lesz, hogy az alkalmazás a lokális hangszórón, vagy az itt_szóljon nevű szerveren szóljon. A stream akár lejátszás közben átrakható egyik kimenetről a másikra.

( persicsb | 2017. 06. 27., k – 21:53 )

És mennyi a hang késleltetése a videolejátszáshoz képest? Össze tudja hangolni automatikusan, figyelembe véve a hálózati átvitel késleltetését?

> Nem mértem

Eredeti angol hangu filmnel lehet latni, hogy a hang kesik a szereplok szajahoz kepest.

Ilyen 0.1-0.2sec-et lazan eszre lehet venni. "valami nem stimmel".

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( after | 2017. 06. 27., k – 22:13 )

Ha feltelepíted mindkét gépre az avahit és a pulseaudio-zeroconf csomagot (néhány distro alapból szállítja a pulseaudio mellé), majd a kliensen betöltöd module-zeroconf-discover, a szerveren pedig a module-zeroconf-publish modult, automatikusan megtalálják egymás a hálózaton, és nem szükséges hardcodeolni az IP címeket.

Először az Arch doksiját néztem, de összemostam a natív protokollt azzal, amit írtál. Ennek az lett a vége, hogy egyetlen stream több példányban jött át, ráadásul csak a szerver oldali keverőn tudtam hangerőt állítani. Megevett nagyjából 1 MB/s sávszélességet. Ennyi 5 stream-nek is elegendő. Tudom, ez nem az, amit írtál. Azért nem zavar a szerver bedrótozása, mert az erősítő is értelemszerűen ehhez az egy desktop géphez csatlakozik csupán, s nincs olyan hobbim, hogy hetente változtatom a hostnevét. Még a háttérképet sem szoktam cserélgetni. :)

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

( locsemege v | 2017. 06. 28., sze – 01:07 )

Egyébként azon tűnődöm, hogyan lehetne hangot tömöríteni valamelyik alacsony latency-t tudó kodekkel, mint például az opus. Talán lehetne azt csinálni, hogy a kliensen pipe-sink tunkolná hanggal a named pipe-ot, majd egy shell daemon a másik végét nyalná fel, opus codec tömörítene, majd socat-ba pipe-olás után menne ki hálózatra. Szerver oldalon pedig socat után az opus codec, végül named pipe, onnan pedig pipe-source a pulseaudioban, s lőn hang. Ami ezzel gondom, az a két oldal szinkronja. Ha picit is eltér az ütemezés a gépek között, akkor vagy buffer underrun lesz, vagy overflow. Meg azt sem tudom, a hálózati csomagok jó sorrendben jönnek-e majd meg. TCP fölött gondolom, igen, ha meg UDP-t használok, magamra vessek.

Lehetne ezt így? Vagy marhaság, s ha ilyen egyszerű lenne, már rég belerakták volna a hangszerverbe?

Szerk.: Kipróbáltam. Az a vicces, hogy akar működni, bár nem működik. A szerveren kell még a module-loopback, hogy a source-ön bejövő hangot visszahurkoljuk a sink-re.

Most a kliensen egy néhány perces zenés YouTube video lezajlik alig néhány másodperc alatt. :) Felhangzanak olykor felismerhető hangrészletek. A szerveren ezt csináltam:

#!/bin/bash

VOICE_PIPE='/tmp/music.input'
if [ ! -p "$VOICE_PIPE" ]; then
    rm -f "$VOICE_PIPE"
    mknod "$VOICE_PIPE" p
fi
socat "TCP4-LISTEN:4713" "EXEC:opusdec --rate 44100 - $VOICE_PIPE"

A kliensen pedig:

#!/bin/bash

VOICE_PIPE="/run/user/`id -u`/pulse/fifo_output"
if [ ! -p "$VOICE_PIPE" ]; then
    rm -f "$VOICE_PIPE"
    mknod "$VOICE_PIPE" p
fi
socat "EXEC:opusenc --raw --raw-rate 44100 $VOICE_PIPE -" "TCP4:itt_szóljon:4713"

A szerveren az opusdec nagyon zabálja a futásidőt, de lényegesen gyorsabban falja a hangot valós időnél. Pedig arra gondoltam, szép békésen fogja felszedni a pulseaudio a fifo tartalmát. Lehet, hogy ez így is van, csak esetleg ehhez forszíroznom kell a mintavételi sebességet, vagy akármi.

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

Na várj! Nem multimédia lejátszót írok, s momentán nem a késés a legnagyobb problémám. Ez van most:

kliens program --> pulseaudio (kliens) --> helyi hálózat --> pulseaudio (server) --> hangszórók

Ezt szeretném:

kliens program --> pulseaudio (kliens) --> named pipe (kliens) --> tömörítés --> helyi hálózat --> kitömörítés --> named pipe (server) --> pulseaudio (server) --> hangszórók

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

( KoGa v | 2017. 06. 28., sze – 11:42 )

Bluetooth? Ha a hifid tudja akkor nem kell semmi extra eszköz hozzá. (Feltételezem hogy a notebookban van.)

Notiban van, de a HiFi cucc egy öreg Panasonic, analóg bemenete van csak. Jó, meg USB. Tudom, lehetne azzal operálni, hogy egy mikrokontrollerrel USB masstorage eszközt emulálok, amelyre például blootooth-on jönne az adat. Viszont a HiFi cucc végképp nem számít arra, hogy röptében változnak a file-ok alatta, vélhetően nem olvassa újra az alkönyvtárat. Meg nem akarok ezzel hosszasan foglalkozni, kicsit nagy munka lenne.

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

Ha a hifidben van analóg audio bemenet és a bluetooth elfogadható alternatíva lenne, akkor aliexpressen vagy ebayen néhány dollárért beszerezhető "USB bluetooth audio receiver", ami USBről veszi az áramot, bluetoothról a hangot, és analóg jack kimeneten továbbadja a hifidnek. A minőségüket nem ismerem, de feltételezem, nem audiofileknek való.

Erre valóban nem gondoltam. Előnye lenne, hogy nem kellene az asztali gépnek is működni, ha a notebook-ról hallgatnék zenét, vagy bármit, hátránya, hogy akkor az asztali gépre is kellene bluetooth interface, hiszen a HiFi cuccnak csak egy analóg bemenete van, azt meg elhasználná a kékfog vevő.

Az eredeti problémára: rájöttem, hogy nem közvetlenül pulseaudioval kell ezt megcsinálni, ha tömöríteni szeretnék. Az ffmpeg tud tömöríteni és stream-elni is. Egyik oldalon bele kell küldeni a hangot, a másik gépen futó ffmpeg pedig felszedi hálózatról, kitömöríti, s mint a pulseaudio egyik kliense, elküldi a hangszervernek. Ennyi ez, nem kell elbonyolítani. Csak kell hozzá olvasni, mert az ffmpeg paraméterezése nem triviális.

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

Nagy varázslás ez a realtime stream-elés. Az úgy nyilván elvileg nem megy, hogy mindkét oldalon azonos a mintavételi frekvencia, majd az egyik oldalon mintavett jelet átküldjük a hálózaton, a másik oldalon pedig lejátszásra kerül. Nem jó, mert nem lesz hajszál pontosan azonos a mintavételi frekvencia, így vagy hízik folyamatosan a buffer, vagy alulcsordul, s néha elakad a lejátszás.

Marad tehát az, hogy úgy kell átvinni a jelfolyamot, ahogyan analóg módon tennénk, ott ugye nincs efféle probléma. Ez azt jelenti, hogy nagyon pontos időbélyegekkel kell néha ellátni az adatcsomagokat, a másik oldalon pedig ehhez az időhöz igazítani a lejátszást, s újramintavételezni az egészet. Így megszabadulunk a küldő és fogadó fél eltérő mintavételi frekvenciájából adódó problémáktól. Csak ugye, ezt nem triviális megoldani, valamint ntp szinkron kell mind a küldő, mind a fogadó gépre.

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

Hát ez igen vacak lenne.

Az újramintavételezest csinálja a windows kmixer, vagy pl a Soundblaster Extigy.
Profi rendszereknél átviszik az órajelet is.
Ehhez kell még néhány sample buffer, és általában "újraclockolják", amivel kiküszöbölhető a jitter.
Aztán lehet az órajelet szinkronizálni a jelfolyamhoz is, pl. TOSLINK.

A szabványos a 48kHz pont azért jó, mert csak arra kell AD átalakítót tenned. Mindenesetre az újramintavételezés marhaság, mert további zajt és torzítást viszel a jelbe.

Az időbélyeget nem a világórához kell szinkronizálni, hanem a képet a hanghoz. ;)
Több utas jeltovábbításnál legegyszerűbb a legnagyobb késleltetéshez igazodni.

Milyen képet a hanghoz, ha éppen nincs is kép? Kell valami abszolút idő. Ha nem pontosan azonos a mintavételi frekvencia adóban és vevőben - ami nyilvánvalóan így van -, akkor az a helyzet áll elő, hogy átviszel az adó oldalról egy hangmintát, de a vevőben nem pont azt mintavételezed, hanem valahol két minta között, ezért kell interpolálni. Hiába a 48 kHz, ha az csak annak közelében van a két gépben. Kell valami globális idő, amelyik mindkét gépen ugyanannyi. Kis jitter belefér, de frekvenciahiba nem.

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

Zavart érzek az erőben. ;)
Az AD átalakításnál van mintavételezés. Digitális jelnél meg nincs interpoláció. Örülsz, ha megkaptad a digitális jelet, hiszen azt már csak DA átalakítani kell, méghozzá pontosan a műsorforrás sebességével. Az AES 50ppm eltérést enged meg a mintavételi frekvenciában gyengébb készülékek esetén, de ott azért digitális studióberendezésekről van szó.

A gyakorlatban a két kvarc frekvenciája ennél sokkal jobban eltérhet. Az eltérést még akkor sem fogod hallani, ha abszolút hallásod van. Mondok egy gyakorlati példát. VHS digitalizálásakor elég nagy lehet a magnó és a számítógép frekvenciájának eltérése (digitális rögzítést feltételzve), de az eltérés legfeljebb 0,2%. A műsor ilyenkor elcsúszhat időben, ezért külső szinkronizálást kell alkalmazni. Ilyenkor rögzíted a hangot 48kHz mintavétellel, de csak mondjuk 47,645kHz sebességgel jön. A kép meg ezzel szinkronban.

Globális idő nem kell, ha a műsornak nem kell valamivel szinkronban lennie. Az időt mindig a műsor elejétől mérjük.

Igazából nem a szegény füleimet sajnálom, mert azokba nincs frekvenciamérő építve, így velem simán elhiteted az 580 Hz-ről is, hogy az a normál "A" hang, nem fogom észrevenni. :)

A gond ott van, hogy ha úgy visszük át az adatot, hogy azonos a mintavételi frekvencia nominális értéke adóban és vevőben is, s minden adó által küldött hangmintát lejátszunk a vevőben is hangmintánként, akkor az alábbi két eset lehetséges:

a) Az adó mintavételi frekvenciája picit nagyobb, mint a vevőé. Ekkor a vevő bufferében másodpercenként a két frekvencia különbségének megfelelő darabszámú minta gyűlik, így a buffer hízik az örökkévalóságig, vagy amíg ki nem pukkad, mint egy lufi.

b) Az adó mintavételi frekvenciája picit kisebb, mint a vevőé. Ekkor a vevő picit gyorsabban falja az adatokat a bufferből, mint amilyen tempóban az adó írja, a két frekvencia különbségének megfelelő mintával lesz kevesebb minta a FIFO-ban minden másodpercben addig, amíg a buffer kiürül, s így a hang elakad. Aztán várunk, amíg a buffer feltöltődik a névleges adatmennyiséggel, s lehet folytatni a lejátszást.

Lenne egy c) eset is, az azonos órajelfrekvenciák esete. Ha ezt PLL-lel, vagy valahogy biztosítják, akkor persze nincs baj. Rövid idejű eltéréseket a buffer megold, átlagban viszont pontosan azonosnak kell lenni az órajeleknek, azaz nem lehet statikus hiba. Ilyet az integráló szabályozók tudnak.

Ugyanakkor, ha elgondolkodunk azon, analóg technikában miért nem merül fel a probléma, akkor a megoldás is megvan. Az adóban mintavételezem a hangot, majd bizonyos mennyiségű hangmintánként hozzátűzök egy időbélyeget is. A vevőben csinálok resampling-et, s ha az időbélyeg eltér attól, ahol az általam, a vevőben mérve tartok, ki tudom számolni, hogy mennyi idővel hány minta alatt tért el az egész, így az újramintavételezésem új frekvenciája mi legyen. Ebből persze az lesz, hogy olyan helyen kell mintát venni, ami az adóban két minta közé esik. Nagy dolog, lehet interpolálni.

A minőségromlás nem érv, van egy rakás resampling algoritmus, a pulseaudio is használ ilyet, még választhatsz is közülük. Egy lehetőség, hogy lineárisan interpolál az ember, utána csinál fft-t, a 20 kHz fölötti együtthatókat kidobja, aztán inverz fft idő tartományba, s meg is vagyunk. Ezzel 10 kHz fölötti alapharmonikusok lerendezve, az alatt meg már nem olyan jelentős a hiba. Ha meg mégis, akkor más algoritmus kell.

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

Tulajdonképpen csak arról írtam, hogy szükségszerű. Tehát az nyilván nem megy, hogy átviszem a hangmintákat hálózaton, aztán utánam az özönvíz. Ja, mellesleg most jutott eszembe, valóban meg lehet ezt csinálni időbélyeg és a két gép közötti időszinkron nélkül. Az adó elküldi a mintákat, a vevő meg úgy mintavételez, hogy a buffer tartalma - már a minták mennyiségét illetően - átlagosan konstans legyen. Lényegében a buffer telítettségére kell egy integráló szabályzót csinálni. Viszont ki kell szúrni a hálózati kieséseket, mert ha azért nem jön adat, abból nem az következik, hogy gyorsan olvassuk fel a hangot, hanem csak akadozik a hálózaton az átvitel. Tehát hirtelen jelentkező nagy eltéréseket vagy limitálni kell, vagy nemes egyszerűséggel ignorálni.

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

Szerintem a probléma akkor is felvetődik, ha egy lokális program állít elő hangot, ugyanúgy egy fifoba/bufferbe kerül az adat. Persze lokálisan a program is kezelhetné a problémát, de logikusabbnak tűnik, hogy ez alacsonyabb szinten egy helyen legyen megoldva. Ha viszont így van, akkor teljesen mindegy, hogy az audio streamet egy program állítja elő lokálisan vagy hálózaton keresztül érkezik, ugyanúgy le lesz kezelve a probléma.

Egy dolog miatt nem. Gépen belül ugyanaz az órajel időzít, így az önmagával tökéletesen azonos frekvenciájú.

Egyébként, ha csak egy file lejátszása a feladat, nincs baj, mert senkit nem érdekel, ha néhány ppm-mel lassabb vagy gyorsabb, valamint mélyebb vagy magasabb a hang, ennyit nem hall meg az ember. Akkor van baj, ha valós időben keletkezik a hang, s ezt kell átvinni. Például VoIP.

Persze ebben az esetben meg kell oldani, hogy legyen valamilyen handshake, az adó tudja, mikor kész a vevő buffere fogadni egy csomagot.

Jó messzire keveredtünk attól, hogy végre beletehetnék hivatalosan is az opus codec támogatását a pulseaudio-ba, különösképp, hogy erre már volt, aki vette a fáradságot.

Más. A notebook mikrofonját használva akartam hálózaton „átszólni” a desktop gépre kötött hangszóróra. Ezt ugye úgy, hogy a mikrofon source-t module-loopback segítségével visszahurkoltam a module-tunnel-sink-new modulra. Szánalmas, hogy már a 10-es pulseaudio-nál járunk, de ettől az egyszerű művelettől összeomlik a pulseaudio, amint a loopback stream-et a tunnelre irányítom. Szépen ott volt a logban a híváslista, megfeküdt szegény. :(

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

:-D
A másik szálon nem győzködlek tovább, de elfelejtettem írni, hogy a pulseaudio biztosan kiváló lehet.
:-D bezárva
Ennek ellenére szeretnék konstruktívan hozzáállni a dologhoz. Mit szólnál a NASA szintű megoldás helyett egy keverőhöz? Rövid kábel esetén 6db ellenállás. Ha a kábel hosszabb, akkor kell két erősítő, meg néhány járulékos alkatrész. Ezzel be sem kell kapcsolni a másik gépet, max. a standby 5V kap 10mA terhelést.

Jól van már, nem gúnyolódik! :) Nyilván van bug a systemd-ben is, a pulseaudio-ban is, meg Lennart Poettering felfogásában is, de ettől még alapjaiban jó eszközök ezek. Csak olykor bosszantó hibákat találni bennük.

Ami az analóg elképzelésedet illeti, tetszik, de lemondanék a hosszú kábelről. A wifi átvitel lett volna a lényege az egésznek. Amúgy működik - a blog nyitójába működő megoldást írtam -, csak tömöríthetnékem van.

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

:)
A windows hangrendszere csapnivaló, a linuxé meg egy fokkal rosszabb. Állítólag a mac nem okoz problémát, de még nem volt a kezemben.

A tömörítésről...
Volt egy balatoni hajóállomáson egy forgalomirányító néni. Kb. 1,50m magas és 2,0m széles. Mint a vasutasok, a hajó indulásánál meg kellett jelennie a hajóállomáson. Eközben összeszólalkozott az egyik hajós legénnyel. A hajó elindult, már 12m távolságra járt a parttól. A legény meg lezárta a vitát.
- Ha én most azt mondanám magának, hogy egy kövér kurva, akkor engem lecsuknának. Ezért semmi ilyesmit nem mondok!

Arra gondolsz, hogy a hangkártya mikrokontrollere saját órajelről jár, szemben az operációs rendszer, így a hangszerver egyéb ütemezésével? Mert így igazat adok. Titkon azt reméltem, hozzá lehet férni a hardware időzítéséhez.

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

Lokálisan úgy működnek a tipikus hang alrendszerek, hogy a lejátszó program a drivertől kap kérést, amikor a következő pufferre szükség van. Ez meg valami interrupton keresztül jön az audio HW-ből. A ritmust tehát a lejátszó HW adja végső soron a saját kvarc órajele alapján. Ezért lokális lejátszásnál nincs órajel eltérés probléma.

Távolra küldés esetén viszont szükségszerűen előjön a probléma, hacsak nincs szinkron óra, de manapság többnyire nincs.

Nem említéd vala, hogy mutáns vagy. ;) A többi ember fülében ugyanis brutális bonyolultságú frekvenciamérő és spektrumanalizátor van elrejtve. Ha nem hiszed, olvass utána. (google: human ear cochlea)
Ha ez a szerkezet nem működne jól, akkor értelmét vesztené a zeneszerzők tevékenysége.
Abban igazad lehet, hogy a szemed helyén nincsen digitális kijelző, ami kiírná a torzítást. De nem is így működik! Saját szavaimmal úgy írnám körül, hogy miközben ugyanazt hallod, de másképp szól.

Az analóg technikában az az egyszerű, hogy amit leadsz, az akkor jelenik meg amikor leadtad. (Meg a késleltetések, de most nem ez a fókusz.)

A digitális technikában meg a sync source: external esetén a forrás mintavételi frekvenciáját tudod használni. Ez az a) és b) eset. Gyakorlatilag a forrásból állítják elő az órajelet.

Komolyabb berendezéseknél sync source: world clock, ahol a clock értéke néhány ppm pontosságú, és a jel minősége pontosan specifikált - elkerülendő a jitter.

A resampling az teljesen másra való. A digitális jel pont azért jó, mert nincs vele más dolgod. Szükséges lehet resampling, ha pl. a hardvertől eltérő mintavételi frekvenciával kell dolgozni, vagy más mintavételi frekvenciára kell átalakítani. Lineáris interpolációt meg nem szoktak alkalmazni.

A fül működését értem, de akkor sem fogok emlékezni a 440 Hz-re egy hét után, hogy az melyik sejtemet birizgálta, szóval simán elhiszem egy másik frekvenciáról, hogy az az. Mert nem számokban gondolkodom a hangról, hanem érzések alapján, nagyjából a tetszik vagy nem tetszik a zene skálán.

Azt nagyon bőven elhiszem, hogy lineáris interpolációt nem szoktak használni, mert borzalmas, de hozzátettem, hogy fft, aluláteresztő szűrés és inverz fft után lényegében kellemesen hajladozni fog az a vonal, amely korábban egyenes volt. De lehet már kapásból hajlítgatni a vonalat, illeszteni őket úgy, hogy az illeszkedési pontban a deriváltjuk azonos legyen, így ne legyen törése neki.

Az egy dolog, mire való a resampling, de nekem nem tiltja a vallásom, hogy arra használjam, amire jólesik.

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

Analog technikában azért nem jön elő a probléma, mert a jelterjedés végig konstans késleltetéssel megy, ezért a drót másik pontosan ugyanaz a frekvencia jön ki, ugyanannyi idő alatt játsszuk le a mintát.

Digitális telefontechnikában - ha jól emlékszem, nekem ez már csak tananyag volt, nem csináltam ilyet soha - helyi szinten - kb 60-100km-es sugarú körben lehet szinkron hálózatot csinálni, ami tényleg működött is. Ezeket valami nagy pontosságú órához szinkronizálták. Amikor összekötöttek két ilyet - pl távhívás ilyen volt, akkor a kettő között minimális mintavételi frekvencia előfordulhatott, ezt egy erre a célra készített újramintavételező HW oldotta meg. Tudtommal ez nemes egyszerűséggel kihagyott, vagy betoldott egy mintát ha muszáj volt. Mivel pontos órák vezérelték a rendszereket, ez ritkán jött elő, és a gyakorlatban nem okozott problémát.

Persze, az is lehet egy döntés, hogy néhány másodpercenként underrun esetén megismételjük a legutóbbi mintát, overflow esetén meg eldobunk egyet, így lesz a hangban egy szerintem alig észrevehető percenés. Telefonos beszédátvitelnél ez talán nem akkora gond, de zenénél szerintem nem jó ötlet.

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

( locsemege v | 2017. 06. 28., sze – 13:26 )

Csináltam egy ilyet:

mpg123 -s zene/Bikini/Bikini\ -\ Elmúlt\ Illúziók\(2011\)/09-Szep\ vagy.mp3 >/tmp/music.input

Ebből kiderült, hogy nagy az a fifo, azonnal benyelte a szám jelentős részét. Visszajött a prompt, szól a zene - bufferből. Nagyszerű, mert leállítani sem lehet értelemszerűen. :) Persze némítani igen. Azért az egész nem fért a bufferbe.

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

( locsemege v | 2017. 06. 29., cs – 14:05 )

Találtam egy ilyet, itt van patch is hozzá, de ez a 6-os pulseaudio-hoz készült, ma meg a 10-esnél járunk. Gondoltam lefordítom újra, de két dolgon akadtam el. Egyrészt multilib csomagokat nem tudok még fordítani, de szerintem kellő olvasást követően ezt megoldom. Másfelől nem jött össze a patch-elés, mert annyit változott már a pulseaudio a 6-os óta, hogy nem lehet ezt eszetlenül, kell a manuális beavatkozás, átbogarászás, az eredeti patch új pulseaudio-ra való elkészítése.

Amit nem értek, hogy van rá igény, valaki vette is a fáradságot, hogy implementálja, akkor miért nem olvasztják be a mainline-ba? Vagy ez sem szól másról, kinek az apukája fogott nagyobb halat? Tehát ha nem a pulseaudio karbantartói írják a kódot, akkor sem teszik bele, ha az valós igényeket elégít ki, és jó?

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