Hálózaton át szeretnék lejátszani zenét egyik Linuxról a másikra. TLDR: Működget, de buffer underrun-szerűen pattog néha a hang.
Hosszan:
Ezen leírás alapján működik is TCP-n keresztül: https://gist.github.com/xarinatan/c415341ff34eab445cfb073988dcf6c1
De! Sajnos időnként van benne egy kis akadás, ami zavar. 99%-ra tippelem, hogy buffer underrun eset van amiatt, hogy nem elég sokat bufferel a protokol. (A cél gépen önmagában jól működik a PulseAudio, ha helyi fájlt játszok le például VLC-vel.) Több latency nem zavarna, mert csak zenelejátszásról van szó, nem videózásról, vagy játékról. Gondoltam csak megemelem a buffer méretét, és kalap kabát. De nem találom a paramétert sehol! Pedig esküszöm használtam a guglit!
Tudja valaki, hogyan lehetne megnövelni a puffert a szerver oldalon? Vagy van valami alternatív megoldás, ami rendesen működik?
Szerk.: A megoldás az lett, hogy elúntam a próbálgatást és csináltam egy sajátot.
Először PulseAudio modulként próbáltam, de elképesztően nehezen lehetett haladni, mert rohadt bonyolult threading modellje van, de dokumentálni elfelejtették. De annyira, hogy még a függvények headerjén sincs egy nyamvadt komment se egy csomó esetben. A vége ez lett részemről: apt remove --purge pulseaudio és telepítettem a pipewire-t.
A Pipewire megvalósítja a Jack API-t, ami régi kedvencem. Efelett megvalósítottam az audio stream faék egyszerűségű átlövését TCP felett. Az egyetlen bonyolítás, hogy az órák eltérő sebessége miatt újra kell mintavételezni a szerveren a streamet (ahogy dorsy a maga kedves stílusában rámutatott ez elkerülhető volna, de egyelőre így volt egyszerűbb megcsinálni), de erre is elő tudtam venni egy másik projektből példát, hogy hogy is kell ilyet csinálni, vannak rá nagyon jó libek. A "terméket" itt találjátok, ki van próbálva remekül működik, glitch nélkül megy órákon át is megállás és veszélyes buffer underrun nélkül: https://github.com/rizsi/TcpAudioStreamJack
Jöhet a házibuli, én kérem készültem!
Hozzászólások
Disabling LFE remixing
By default, PulseAudio remixes the number of channels to the default-sample-channels and since version 7 it also remixes the LFE channel. If you wish to disable LFE remixing, uncomment the line: ; enable-lfe-remixing = yes and replace yes with no: enable-lfe-remixing = no
esetleg?
meg:
Using RTP/UDP instead of native-protocol-tcp
There are serious issues with trying to send data in real time over TCP, especially over lossy connections like wifi. This is why RTP over UDP was invented. It can be used to increase reliability and reduce latency.
When RTP is working properly, late or dropped packets will just create a few milliseconds of silence instead of a long pause while TCP is orchestrating the packet resend logistics. As an added bonus, if the remote server is ever restarted, the connection will be re-established automatically. However there will no longer be a way to remotely control the server's master volume, with each client machine having its own independent master volume instead.
To use RTP instead of
native-protocol-tcp, pulseaudio clients must connect to a local pulseaudio server first. This local server then connects to the remote pulseaudio server through RTP.To use RTP in pulseaudio, install pulseaudio-rtp on the remote and local servers.
innen: https://wiki.archlinux.org/title/PulseAudio/Examples
Köszi a tippeket!
>will just create a few milliseconds of silence instead of a long pause
De miért nem lehet úgy beállítani, hogy van akár két másodperc latency, de menjen át minden momentuma a zenének? Én ezt szeretném megoldani.
Egyébként valóban Wifi mind a két oldal, de az egyik oldalt talán be tudom dugni kábellel, az tutibb minden szempontból.
mert a zene "realtime" a tcp meg nem.
ezt is nezd meg:
Sound stuttering when streaming over network
When streaming over Wi-Fi using module-native-protocol-tcp, you can experience periodic sound stuttering with buffer underruns. As a workaround, you can try to use the rtp protocol. On the sender side, create an rtp sink:
and switch to it:
On the receiver side, load the rtp module:
Értem én a problémákat, csak nem szeretem :-)
Pont ez volna egyébként a lényeg, hogy a zene real time abban az értelemben, hogy időre ott kell lennie a következő framenek és punktom. De olyan real time, hogy több másodperc késleltetést is megengednék, csak ne legyen zökkenő.
Szerintem az a baj, hogy Poettering nem ért az audióhoz, és nem csinálta ezt meg rendesen. Ebben a legtöbb Linuxos egyet tud érteni :-)
nem problema, csak igy mukodik.
a hang egy folytonos dolog (digitalis eseten bitfolyam), a tcp pedig by design nem ilyen (ezert nem jo voipra sem).
orok problema a tanc a buffermeret es a latency kozt, erre nincs "jo" megoldas, csak valamilyen kompromisszum. :)
bufferelni kliens oldalon tudnal (mint minden streaming eseten). fuss egy kort a VLC-vel, szerintem nem fogod megbanni :)
Egyetértek, érdekes lenne pontosan tudni mitől van ez a jelenség.
Ami biztos, hogy TCP-vel wifin mindig is voltak gondok. Elég sok csomag elveszik, ezek random, csatornából adódó vesztések, nem bufferméretből vagy torlódásból adódó csomagvesztések. WiFi 8-ba már ígérnek időréselést meg TSN és AVB-t megtámogató funkciókat, ezekkel biztos javul majd a helyzet. A fő baj, hogy egyenlő eséllyel veszik el egy 1500 bájtos adatcsomag és egy kb. 60 bájtos nyugta csomag, ami miatt újra kell küldeni az egyébként sikeresen célba ért adatcsomagot is. Szakdolgozatomhoz kísérleteztünk olyannal, hogy TCP letöltést végeztünk WiFi-n de a nyugta csomagokat a szerver felé kábelen küldtük vissza, amin több nagyságrenddel kevesebb a random loss és ha van is, L2-ben gyorsan újraküldi pár mikrosec alatt. Az eredmény kb. 15-45%-al gyorsabb letöltés volt WiFi-n (szabványtól és csatornától függően).
Ha ragaszkodsz a TCP-hez, amivel játszanék, azok a TSQ paraméterek, BBR vagy más WiFi barát torlódásszabályozó algoritmusok, esetleg egy állandó kétirányú 1ms gyakoriságú kis ping háttérfolyamat sink és a szerver között csak hogy ébren tartsa a rádiót.
pontosan attol amit leirsz. a wifin elvesznek random a csomagok, a tcp meg nem udp.
Az UDP nem segít, ha véletlenül elveszik egy csomag, akkor az is pattan vagy döccen egyet. Értem, hogy kisebbet, de észrevehető az is.
SOKKAL kisebbet, mert ha a retransmitekkel/tcp reorg-gal elmegy az ido es kifutsz a bufferbol az nagysagrendekkel sz*abb, mint elveszteni par csomagot UDP-n.
Plusz attol is fugg, hogy a datastreamedben milyen/mennyi error correction van vagy nincs.
A radiokommunikaciot nem most talaltak fel, ha pedig nem mukodne a valo eletben, akkor nem lenne digitalis foldi sugarzas sem.
Ez annyira "UDP", hogy itt 0 kommunikacio van visszafele. :)
Ha simán helyi hálón (akár drótos wifin, akár drótnélküli kábelen) nyitsz egy TCP streamet és random teszed bele a két oldalán adatot, akkor az tapasztalat szerint nem fog leszakadni órákig vagy napokig se. Előfordul, de ritka mint a fehér holló, ha nem szar a hálózatod.
A késleltetésben van egy kis ingadozás. Real time lejátszás esetén egy túl nagy késleltetésből pattanás lehet, ez tény. Ezért kell nagyobb puffert beállítani, mint amennyi ingadozás jó eséllyel előfordulhat. Ha egy házibulin egyszer pattan a hang, akkor nem lenne egy rossz szavam se, de nálam percenként több jön (és függ az egyéb wifi terheléstől, az érezhető), az már durva.
Van még egy nagyobb baj is! A két oldalnak nem egyformán jár az órája! A két hangkártya kvarcja vezérli a hangminták tempóját, ez azért elég pontos, és egy rövid lejátszásnál talán nem okoz galibát. De ha hosszú ideig él a kapocsolat, akkor abból baj lehet. Ha belegondolsz, akkor egészen kis szisztematikus tempó eltérés esetén is a vételi oldal puffere lerövidül, vagy túlcsordul. Sokat gondolkodtam ezen a problémán, szerintem csak úgy lehet jól megoldani, hogy a vételi oldal újramintavételez, és egy kicsit lassabban, vagy kicsit gyorsabban játssza le a mintákat úgy, hogy a usert még ne zavarja a tempó ingadozása, de a pufferét fix hosszon tartsa.
A vicc az, hogy ezt a problémát egy másik projektben egyszer már leprogramoztam és meg lehet csinálni jóra (ssh felett is működött egész megbízhtóan), csak végig kell gondolni és kezelni kell ezt a két issuet. Nem tudom még, hogy mit csinál a pulse odabenn, de az, hogy nincs bufferméret paramétere, az baljóslatú.
nyitsz egy TCP streamet és random teszed bele a két oldalán adatot, akkor az tapasztalat szerint nem fog leszakadni órákig vagy napokig se. > kevered a tcp keepalive-ot/conntrack-et a packet loss miatti kesessel/kiesessel. pont azert hasznalunk TCP-t, mert nem bizunk meg a koztes haloban es minden bitet helyesen meg akarunk tartani, de realtime audiostram eseten ez hibas koncepcio, mert szakadni/pattogni fog es joval nagyobbat, mint udp-n tenne (ha egyaltalan es a streamben kuldott ECC nem oldja ezt meg) 1-2 csomag elvesztesekor.
a tcp inkabb valo mp3 atmasolasara, meg on-demand streamre, mert ott "vegtelen" tudsz bufferelni, csak el kell kerned a file/kontent kovetkezo X kbyte/mbyte-jat elore. Audiostreamnel ilyet nem tudsz, az akkor "keletkezik", amikor, elore nem tudod megjosolni mi fog kijonni a pulseaudio sinkeden. :)
Az egyetemen úgy tanultuk, hogy a "real time" azt jelenti, hogy konkrét határidő van, aminek a be nem tartása buktát jelent. Tehát nem feltétlenül azt jelenti, hogy "gyors", vagy hogy az a határidő kicsi. Csak hogy van. És ez a TCP audió streaming megfejtése: létezik akkora latency és pufferméret, ami mellett a bukta esélye egészen minimális.
Például szerintem 1 másodperces pufferrel 1 évben 1 pattanás lenne. De lehet, hogy már 250ms is elegendő volna, ki kellene mérni. Zene lejátszáshoz(videó nincs, csak zene) bőven jó. Csak a méréshez előbb kellene egy megvalósítás, amibe be lehet állítani a pufferméretet és értelmesen ki tudja loggolni például a pillanatnyi töltöttséget, abból már lehetne következtetni valamit.
jatszhatsz az audio sinkek pufferelgetesevel, de a vegeredmeny LAG lesz. mondom, olyat akarsz, amire mar regen van megoldas, csak te nem azt szeretned megvalositani. VLC stream, kodi(es alternativai), icecast, stb. ezek valok erre. (tobbek kozt azert, mert a pulse-bol kijovo hang mar tomoritetlen (felteszem PCM?) - de legalabbis felteszem lossless kene atkuldeni mar es nem telhet el jelentos ido/cpu power a ki-becsomagolassal, mig a fentiek alapvetoen mar tomoritett dolgok streamelese).
gondolom nincs voip tapasztalatod, ezert nem "erzed at" a packet loss vs. realtime hangatvitel problemajat. ott akar 1 packet elvesztese is 10-20 ms kiesest jelent a hangban es akkor jon a pattogas/recseges/szakadozas/robothang :) vagy interpolalsz (amig tudsz), annak meg hozomanya a delay(+quality loss+processing power needs).
ha pedig a hangkartya(i)d clocksource-ja fele keresgelsz, nagyon rossz uton jarsz, semmi koze a dologhoz, ez digitalis atvitel, nem analog. az egyetlen clocksouce ilyen esetben a DA konvertere, a lejatszoeszkozon.
"Az egyetemen úgy tanultuk, hogy a "real time" azt jelenti, hogy konkrét határidő van, aminek a be nem tartása buktát jelent." > jelen esetben nem (csak) ez a realtime, hanem az eloallt informacio(folyam) tulajdonsaga, amit aztan at kell kuldened.
amugy ha barmi tomoritettet hallgatsz halon keresztul, jobban jarsz, ha inkabb az mp3-gyujtemenyt (whatever) osztod meg es localban jatszod le, mar csak azert is, mert nem a "kicsomagolt" hangot kell atpassziroznod wifin, a file bufferelesrol nem is beszelve.
tudom-tudom, igy nem lehet valtogatni, meg "hol jartam a lejatszasi listaban"... mento otlet/workaround kategoria.
B verzio: VLC streaming! tok jol mukodik.
A VLC streaminget kipróbálom, köszi!
Mert a pulseaudio egy szarul-húgyul implementált audioszerver, amivel a Red Hat a systemd-hez hasonlóan erőszakolta meg a Linux-világot. Korábban killer feature-ként influenszerkedtek a hálózaton keresztüli audiotovábbítással, amit azóta is 1000-ből 1 ember ha használni szeretne, a tiedhez hasonló problémákba fut bele. Szóval, Lenart Pöttering, aki a Red Hat-tól kapott korporatokrata felhatalmazással Windows-osította el a Linux Desktop-ot (és aki azóta nem mellesleg a Microsoft-nál dolgozik) csinált és lenyomott a torkokon egy audioszervert, ami tud hálózaton át is streamelni, cserébe se hálózaton, se localhoston nem működik kiszámíthatóan. Igen, localhoston is vannak olyan scenariok, ahol pattog.
Belenézegettem a PulseAudio forráskódjába, és azt kell mondanom, hogy igazad van. Régebben a Jack-et is megnéztem (ott csak az API-t), és ott pont fordítva olyan érzésem volt, hogy aki kitalálta baromira érti a dolgát, és a leírás minden mondatánál aha élményem volt, hogy erre sem gondoltam volna magamtól, de ez így nagyon jól ki van találva. Bárcsak a Jack lett volna a standard...
Igazából csak azon múlott, mi lesz a standard, hogy melyik mögött van ott egy arrogáns multi, aki ha standardnak kiált ki valamit, a talpnyalók máris nyálcsorgatva aligvárják, hogy beemelhessék a disztrójukba.
A Jack is lehetett volna standard, csak nem volt mögötte multi. Csak egy, a multikénál kompetensebb fejlesztő. Az meg ugye nem elég, a korporatokrata megszállás alatt tartott Linux világban.
Olyan kaput feszegetsz pajszerrel, amely mellett még csak kerítés sincs. :) Nyugodtan le lehet higgadni. A pipewire-nek van alsa, pulse és jack interface-e is, tudja a hálózaton történő audio átvitelt is.
Ezt mindketten tudjátok, ennek ellenére teljesen feleslegesen megy a sírás azon, hogy a gonosz multi meg a szabványok. Tessék a jack interface-t használni, ha az okoz jókedvet az adott napon! :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Kedvenc multikád állásfoglalása szerint a pulseaudio is tudja™.
A pipewire-t, ami mellett influenszerkedsz, is ugyanaz az arrogáns multi fejlesztette.
Azt azért talán elismered, hogy a pipewire-re részben azért volt szükség, mert a Red Hat is belátta, hogy a Linux világot korporatokrata felhatalmazással felforgató Pöttering túl messzire ment. Lehet, hogy a pipewire most még jó, bizonyos körülmények között még jól is működik. Ez egészen addig lesz így, amíg a Pöttering után ott maradt, szélsőségesen idealista fejlesztők (Clasen, Hutterer stb.) ki nem találják, hogy kell helyette jobb, vagy gyökeresen át kell refaktorálni.
A Red Hat nem kedvencem. Fedorát használok, ami közösségi fejlesztés. Annyi köze van a Red Hat-hez, hogy valóban erősen támogatja a Fedora fejlesztését, ezzel befolyásolva, meghatározva fejlődésének irányát.
Ebből semmi sem következik az adott kód, elképzelés, algoritmus vagy implementáció minőségét illetően. A pulseaudio tekintetében a legnagyobb gond Lennart Poettering túlértékelése, illetve a srác beképzeltsége, arroganciája volt. Elhitették vele, hogy jó valamiben, de ez csak részben volt igaz. Nem volt annyira jó, mint magáról ezt hitte. Nézd meg ezzel szemben Wim Taymans hozzáállását. Sokkal visszafogottabb, kommunikatívabb, van benne szakmai alázat. Teszi a dolgát, nyilván tudja, mit tud, de mégsem gondolja azt, hogy körülötte mindenki hülye, csak ő helikopter. Jut eszembe, az ugye megvan, amikor Poettering a bufferkezelés hibái kapcsán belogolta, hogy ez az ALSA driver bugja, ő pedig nem volt hajlandó megoldani? Vagy a pipewire fejlesztése közben derült ki, hogy valami nem volt rendesen implementálva a pulseaudioban, lényegében félbe lett hagyva?
Igen, a pipewire valóban azért született elsősorban, mert a pulseaudio rossz.
Egy kódot bárki szétbarmolhat. Szerencsés esetben akkor elforkolják, ha megéri, s a közösség úgy gondolja, az addigi kód elég jó, hasznos, megér annyit.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ezzel a paradoxonnal össze is foglalható a pipewire körüli Stockholm-szindrómás influenszerkedésed.
Nyilván, ha valakit COVID ellen oltottak a Pfizer oltóanyagával, akkor Pfizer rajongóvá válik. Most értettem meg az oltásellenesek mély filozófiaia mondanivalóját. Azért nem akarták, hogy oltsák őket, mert akkor akaratuk ellenére is az oltást gyártó cég iránt fognak vonzalmat érezni.
Semmi paradoxon nincs abban, amit írtam. Ráadásul a Fedora nem Red Hat (mint disztribúció), még akkor sem, ha nyilvánvalóan van köze a Fedorának a Red Hat-hez (mint céghez).
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Annyi a különbség, hogy te önként és dalolva, saját akaratodból lettél Red Hat influenszer. Annak is a rosszabbik fajtája, aki arra buzdít, hogy ingyen fejlesszünk, teszteljünk a Red Hat-nak.
Persze, hogy nincs, ha a szemellenződ kitakarja.
A Fedora a Red Hat upstream (értsd: testing, unstable stb.) ága, csak kiszervezte a tesztelési munkát a közösségnek, hogy a közösség ingyen és bérmentve csinálja neki a QA-t. Cserébe a Red Hat, amikor vissza kell adni a közösségnek, pl. egy stabil oprendszert (RHEL forkok), akkor paywall mögé rakja a forráskódot, meg ingyenélőt kiált. Na, egy ilyen multinak influenszerkedsz. Nem feltétlen a Fedora-használatoddal, hanem a pipewire-körüli sürgéseddel-forgásoddal, aminek ennek a fórumon is masszívan hangot adsz.
A pipewire egy multimédia szerver, amelyet nagyon nem érdekel, hogy egyesek hogyan viszonyulnak ahhoz a céghez, amelynek támogatásával fejlesztik. Érzelmi kérdést csinálsz ebből. Ingyen, nyílt forrással elérhető, használható, szerintem elég jó. Valamiféle Red Hat utálatból lehet nem használni, de attól nem a Red Hat-nek lesz rosszabb, hanem annak, aki érzelmi befeszülés okán kénytelen leporolni az ükkapja gramofonját, s azon hallgatni a zenéket. :) Tudtommal nem jelent meg a Magyar Közlönyben, hogy a pipewire használata kötelező.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Helyesen: elvi kérdést. Miért? Mert nem az az elsődleges kérdés, hogy a pipewire jó vagy szar. Lehet, hogy épp ez most jól sikerült, de maga az elv akkor is szar, hogy korporatokrata erővel van rátolva a Linux Desktop világra. Azt pedig láttuk, hogy a szart ugyanilyen módon le lehet tolni (pulseaudio).
Emellé bejön az a faktor, hogy az a kódbázis, ami egy multinál van, előbb-utóbb eltorzul a menedzseri idealizmusoknak köszönhetően. Előbb-utóbb addig lesz refaktorálgatva, amíg szar nem lesz, vagy előbb-utóbb felváltja valami, ami akkora szar, mint a pulseaudio volt.
Hiába lebegteted a kőkorszak kártyát, ALSA mai napig ott van minden gépen és a pipewire újrafeltalált kereked nélkül is lehet rajta keresztül zenét hallgatni. Nem kell a gramofon.
Ott nem, de a disztrókban megjelent és korporatokrata erővel le is lesz nyomva mindenki torkán. Ahogy le lett a systemd, a pulseaudio és a GTK3.
Nem érted, helyesebben nem akarod érteni, hogy az ALSA és a pipewire nem ugyanaz a réteg. Olyan ez, mintha azt mondanád, hülyeség a GTK4 meg a Qt, amikor ott az X protokoll, vagy minek X, amikor van framebuffer. A pipewire másra való, mint az ALSA. Csak egyet mondok, jack kliens nem fog ALSA-hoz csatlakozni. Meg pulse kliens sem. Meg vegyesen sem. Meg röptében, lejátszás közben, dinamikusan ALSA-val szerintem elég meredek a stream-et lokálból bluetooth-ra átttenni. És a többi. A pipewire nem egy ALSA alternatíva.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Leírtam az ominózus influenszertopikodban is, hogy értem, hogy két külön réteg. A szükségét vitatom, mind a pulseaudio-nak, mind a pipewire-nek egy klasszikus desktop könyezetben. Ne gyere a 2-3 külön bluetooth füleses, USB stúdióhangkártyás környezettel, nem arról beszélek, hanem azokról, amiken van egy mikrofon és egy hangszóró.
Olyan kliensek, amiknek semmi szükségük nem lenne jack-hez, meg pulse-hoz csatlakozni. ALSA-hoz meg csatlakoznának, ha nem lett volna belőlük kiinnoválva™ az ALSA support.
Mi szükség van kötelezően beleerőltetni a rendszerbe egy ilyen komponenst, ami semmi mást nem csinál, mint az ALSA-ban kényelmetlenül megoldható feladatokat kényelmesen megoldja egy másik rétegben?
Vagy csak nem kellett volna külön hangeszközt/hangkártyát csinálni minden egyes hangszóróból, veszteséges tömörítéssel. Egyik réteg hijack-elése szükségszerűen hozza magával egy másik réteg hijack-elését.
Ez már önmagában egy elég vaskos érv a létezésére. Nem kötelező egyébként. Ja, hogy a fejlesztő kényelmes? Nyilván, és ez természetes. Akkor minek vergődjön az ALSA interface implementálásával is, ha letudhatja a kliensben a pulse interface-szel, ami majd megold neki mindent.
Egyébként épp ez az operációs rendszer szolgáltatásainak feladata. Fedje el a hardware-t, az egyedieskedéseket, azt ne application layer-ben kelljen minden egyes alkalmazásban implementálni. Akkor ezzel az erővel legyen minden audio alkalmazásba beleszőve 423 féle hangkártya driver, lehetőleg azonos típusra is más-más, hiszen más a fejlesztője. A világ összes programozója kevés lenne ehhez az őrültséghez. Azért rétegzett az egész, hogy az alkalmazásréteg kész, előemésztett környezetet kaphasson, a programozó pedig már csak a lényegre, funkcionalitásra fókuszáljon.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A létezésére igen. A Linux Desktop világ torkán való lenyomására nem.
Jó vicc.
Ugyanezt a kérdést tedd fel a pulseaudio-val kapcsolatban, és ez a topik lesz rá a válasz.
Ja mert az ALSÁ-s alkalmazásokban benne van 423-féle driver. Ja nem, csak csúsztatsz egyet, hátha így igazolhatod a babzsákfejlesztői bloatware koncepcionális létjogosultságát.
Pulseaudio előtt kevesebb programozó volt és mégis minden ment jól ALSÁ-val.
A pulseaudio/pipewire esetében meg azért, mert a Red Hat ténykedése alatt az elmúlt 10 évben a Linux világ és a KISS-irányelvek megerőszakolását értjük.
Miért? Használták is a pulse interface-t az alkalmazásfejlesztők. Az más kérdés, hogy a pulseaudio egy rossz implementáció, de az interface jól van kitalálva. Ennek a javítására és bővítésére született a pipewire.
Ez csak azon múlik, hol húzod meg a határt. A kernel elfedi a hardware egy részét, de a csatornákkal meg bajlódjon az alkalmazásfejlesztő legfelül, mert az meg hardware-függő lesz ALSA esetében. Vagy írogassa a config file-okat hozzá a felhasználó. Azaz minden alkalmazás valósítsa meg a hiányzó médiaszerver réteget, mert az nincs. Ja, amúgy ezt most is megteheted. Olyan ez, mintha közvetlenül az X-re írnál grafikus alkalmazást GTK vagy Qt nélkül.
Dehogy ment jól! A desktop linux funkciótlansága, nehézkessége hirhedt volt azokban az időkben. Meg is szívod ALSA-val, ha beteszed a 64 csatornás hangkártyát a gépedbe.
A pulseaudionak illetve a pipewire-nek nem az a funkciója, hogy neked rossz kedved legyen, hanem egy hiányzó réteget valósít meg az alacsony, kernel driver és a magas, alkalmazás réteg között. A wireplumberrel együtt ideértve a session kezelést, a jelutak managelését, a mintavételi frekvenciák és felbontások különbözőségének kezelését.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Volt más választásuk? Nem. Onnantól, hogy pulseaudio default fut valahol, az ALSA általában foglalt az olyan rendszereken, ahol se hw se sw mixing nincs és a major disztrók így adták ki a szutykaikat. Ezt hívják egy szoftver invazív elterjesztésének.
Arról lehetne jogosan vitatkozni, hogy a legacy OSS-t leváltó ALSA nem sikerült-e túl high-level-re elődjéhez képest. Ha viszont már arra sikerült, akkor inkább az ALSA-hoz kellett volna pavucontrolt és egyéb könnyen kezelhető GUI-kat írni, nem még egy réteget felhúzni, szarul-húgyul megvalósított implementációkkal.
Ez nem érv az ALSA ellen, elvégre írogathatna pactl parancsokat is, ha nem lenne GUI, de nem kell neki, mert van GUI. ALSA-hoz is lehetett volna config fájlokat parse-olni és leírni képes GUI-kat készíteni. Babzsákfejlesztőéknek mégis fontosabb volt a "legyen nekünk is sajátunk" elvén először minden DE-hez saját audioszervert írni, aztán meg ugyanezt a trágyadomb koncepciót összegyúrni egy még nagyobb trágyakoncepcióba, amit még implementálni is szarul-húgyul sikerült.
Software mixing. ALSA tudja. Ha a hangkártya tudja, akkor meg van hardware mixing.
Művelődj: https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture
Nem, lásd fentebb az ALSA-t szorongató pulseaudio/pipewire és a software mixing hiánya miatt.
https://xkcd.com/619/ minősített esete.
Mert minden Linux Desktop alatt van egy 64 csatornás hangkártya. Nem, nincs. Csak azoké alatt van, akik elég baromállatok voltak ahhoz, hogy Linuxot használjanak stúdiózásra, amire régen is alkalmatlan volt és most is alkalmatlan. Nem az ALSA/pulseaudio/pipewire miatt, hanem a rá elérhető szoftverek hiánya miatt.
Senki nem is állította, így én sem.
https://a.te.ervelesi.hibad.hu/szalmabab
Ez nem igaz, mert a pulseaudionak és a pipewire-nek is van ALSA interface-e felfelé, az alkalmazások felé éppen a régi software-ekkel való kompatibilitás miatt. Én a mindennapokban használom a seren nevű terminálos VoIP klienst, amelynek ALSA interface-e van, de pipewire-hez csatlakozik, amely hangszerver egyúttal megoldja a visszhang elnyomást is.
Inkább az történt, hogy a pulse interface kényelmes volt az alkalmazásfejlesztőknek, s úgy rúgták le magukról pillanatok alatt az ALSA interface-re programozás terhét, mintha az sohasem létezett volna. Ez épp azt bizonyítja, hogy a pulse interface jó.
Az elődjéhez képest lehet, de abszolút értelemben nem.
Itt nem egyszerűen arról van szó, hogy generáljunk valamivel egy bonyolult alsa.conf-ot, mert a wireplumber és pipewire ennél több, dinamikusan old meg mindent úgy, hogy a stream épp nyitva van, folyik rajta az adat, de épp átrendeződik alatta a jelfolyam gráfja.
Ez jó hír, de a pipewire != ALSA + software mixing, hanem ennél lényegesen több. Félve jegyzem meg, hogy a pipewire viszi a video stream-et is, amelyhez az ALSA-nak semmi köze.
Nem, nem amiatt, ha végre észrevennéd, hogy a software mixing csak egy abból a rengeteg feature-ből, amelyet a pipewire tud.
Viszont épp az az operációs rendszer lényege, hogy lehetőleg mindent is tudjon kezelni. Attól, hogy neked esetleg semmi szükséged LVM-re meg RAID-re, másoknak, hovatovább nekem például kell.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem értetted meg, amit leírtam. Még egyszer: ha hardware/software mixing nincs bekapcsolva, a pulseaudio (vagy a pipewire) fogja az ALSÁ-t és más ALSÁ-t használó alkalmazásnak esélye nem lesz használni (Device or resource is busy).
Ez is biztosan történt, meg az is történt, amit mondtam. Meg az is, hogy ha valami csak ALSÁ-t használ és nem működik pulseaudioval (a fent említett dolog miatt), akkor kizárják a disztróból.
1. Szeretnék legalább egy szakmai értekezést látni arról, hogy ez sehogy sem lenne megvalósítható ALSÁ-val.
2. Mi történik, ha egy pillanatra megszakad a stream, amikor bejön a bluetooth fejhallgató a képbe? Jahogy semmi.
Én inkább attól félek, ez mekkora extra bloat-ot jelent a rendszernek. Miért nem volt jó simán az X-től elkérni a frame-eket, mondjuk egy screencapture esetén? Miért kell plusz egy rétegen még áttolni? Inkább azzal foglalkoznának, hogy végre működjön 2. generációtól felfele a H.264 videódekódolás Linuxon. Mai napig nem működik rendesen. Pedig egy 14 éves, 2. generációs Intel képes 4K videót is dekódolni. Ehelyett a CPU-t izzasztják vele és küldik a szeméttelepre azokat a gépeket is, amiket a Windows 11 nem tudott.
Ez az egyetlen feature, amire feltétlenül szükség van egy átlagos desktop környezetben. A többi körítés és bloat.
Ezt nem vitattam. Más kérdés, hogy kötelezően bele van erőltetve az LVM vagy sem. Tudsz olyan desktop alkalmazást mondani, ami csak LVM-es fájlrendszerről indul el? Én tudok tucatnyi olyat, ami pulseaudio/pipewire nélkül nem működik.
Nem arról volt szó, hogy nekem mire van szükségem. Nekem Windows XP-re van szükségem és azt használok.
https://a.te.ervelesi.hibad.hu/szemelyeskedes
Az a device or resource busy akkor van, ha továbbra is a natív, valódi ALSA-t akarja megnyitni az alkalmazás, nem pedig a pulseaudio vagy pipewire ALSA interface-ét. Ha jól sejtem, erre való a /etc/alsa/conf.d/99-pipewire-default.conf file. Mondom, van továbbra is ALSA interface a retro alkalmazások részére.
Félő, hogy ott az alkalmazásfejlesztő gányolt, mindent hardcode-olt, magasról tett arra, hogy nem mindig mindent úgy neveznek, ahogy az az ő gépén van. Olyan ez, amikor egy kezdő webfejlesztő az <img src="C:\pictures\cica.jpg" alt="miau" /> módon szúrja be a képet, és nem akarja érteni, miért csak az ő gépén működik. Az ilyen alkalmazásokat ki is kell szórni, mert rosszak.
Jó, de ez most hogy jön ide?
De egy oprendszernek nem csak a feltétlenül szükségest kell kielégíteni, hanem lehetőleg minden esetet. Továbbá senki sem kényszerít arra, hogy telepíts pipewire-t vagy pulseaudio-t. Azért lesz mégis az belőle, mert végre van egy jó interface, és a fejlesztők ALSA támogatás nélkül írják a programokat. Csak tudnám, ez miért fáj neked, meg az, hogy akkor kell a pipewire, ami nagyjából mindent tud.
Remek. Egyrészt tudtam, másrészt a többiek már kifejtették a gondolataikat, aligha tudnék érdemben mit hozzátenni.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem, nem és nem. Egy oprendszernek az alapigényeket kell kielégítenie, a plusz igények megoldhatók plusz szoftverekkel. Ez a KISS filozófia lényege. Amin már acélbetétes bakanncsal áttaposott Pöttering és most áttaposol te is. Amivel semmi baj nem lenne, ha Windows-ra fejlesztenétek a pipewire-t és azzal influenszerkednél. De a Linux világot forgatjátok fel és csináltok belőle egy olyan trágyadombot, ahol a disznószarral kevert szalmaszálakat egy idő után már esélye se lesz senkinek elválasztania egymástól, minden mindenre fog dependálni és egyre nagyobb, átláthatatlanabb bloat lesz az egész rendszer.
De igen, már elmondtam: Azok az alkalmazásfejlesztők, akik olyan, mindennapokban megkerülhetetlen alkalmazásokat fejlesztenek, mint pl. a Mozilla Firefox és kiszedik belőle az ALSA supportot, így vagy futtatod multiék szarát-húgyát, vagy nincs hangod. Vagy fordítasz magadnak saját Firefox-ot forrásból. Utóbbi viszont meghaladja a felhasználói kompetenciát, így nem tompítja az élét az ALSA kiherélésének.
Ugyanezt ígérte Pöttering is a pulseaudio torkokon lenyomása előtt.
Hát persze, ami épp az új idealizmus az mindig mindent™ is tud. Aztán 5 év múlva jön egy másik, ami még a mindennél™ is többet fog tudni. Azért fáj, mert egy arrogáns multitól (Red Hat = IBM) függ a jövője és a fejlesztési iránya. Nem attól a közösségtől, aki használja. Attól az arrogáns multitól függ, aki már lenyomott a Linux világ torkán egy pulseaudio-t, egy systemd-t, egy gtk3-at. Erre éljeneznem kéne? Mi a garancia arra, hogy a pipewire nem lesz egy gigabloatware 5 év múlva? Semmi. Az ALSÁ-ra legalább ott van Linus Torvalds, mint garancia, hogy orbitális faszságok és önkényes API-törögetések nem kerülnek be csakúgy a kernelbe, csak mert multi küldi a patchet.
Nyilván ezen hülye felfogás mentén nem megy az ujjlenyomat olvasóm az egyik notebook-omban. Nekem valóban semmi szükségem rá, de azért nem bánnám, ha menne. Nem az a linuxok lényege, hogy csak kevés hardware-en működnek jól, hanem az, hogy minden környezetben jól működnek, viszont moduláris, jól skálázódik, tetszőleges módon konfigurálható.
Senki nem vette el tőled az ALSA-t, ott van az, mégis nyafogsz! Az, hogy a Firefoxnak nincs ALSA interface-e, nem a pipewire bugja, hanem ezek szerint van egy programozói szempontból végre kényelmes interface, a pulse, s ezt a pulseaudio és a pipewire is ismeri. Épp az bizonyítja a pulse interface létjogosultságát, hogy csak az van a Firefoxban. Még mindig nem értem, mi a frász fáj neked azon, hogy feltelepíts egy pipewire-t, és legyen a Firefoxnak hangja. Az egész művelet lassú gépen másfél percnél nem több, amúgy pár másodperc. Miért okoz neked fejfájást egy pipewire és egy wireplumber futása? Nálam fut, de ettől még ugyanolyan jól tudom használni a gépemet például programozásra, meg bármire, amire egy számítógépet lehet. Nem kell a Firefoxot forrásból fordítanod. Minek?
Válasszuk ezt ketté. Az elképzelés jó volt, az implementáció meg rossz. Nem az elképzelést kell ilyenkor törölni, hanem az implementációt helyrehozni. Ezt a Red Hat is belátta, ezért lett a pipewire, de emelték a lécet a jack és video interface-szel.
Hány patch-et, ötletet, bármit küldtél be, hány project fejlesztésén veszel aktívan részt, hogy meghatározd az irányát? Az úgynevezett közösség többsége csak élvezni akarja az ingyenes software-ek előnyeit, de ha bele kellene ölni munkát, akkor épp rohanni kell a gyerekért, sörözni kell a kollégákkal, ünnepelni kell az asszony születésnapját, nincs idő, fáradt, nem érdekli. Sőt, te például lenézed, megveted azokat, akik bármilyen módon hozzájárulnak a fejlesztéshez, teszed ezt velem is. Pőcze Barnabás legalább ír a pipewire-be. Én néha tesztelem, segítek, ha olyan feature törik el, ami nekem fontos, vagy jön elő bug, ami nálam került felszínre az én hardware és software környezetemben.
Lenyomták a Linux világ torkán projecteket? Az mennyivel lenne jobb, ha továbbra is feature hiányos alrendszereink lennének? Jó is indító scripteket írogatni függőségek kezelése nélkül. Tudod, hogyan lehetett konfigurálni? Speciális kommentben voltak metainfók, s jött GUI felől a script író program. Éppen úgy, mint az udev előtti időkben az fstab-ot röptében író scriptek, programok. Ezek mind förtelmes gányolások voltak. Szerintem örülni kellene annak, hogy túlléptünk ezen a korszakon, s vannak megfelelő tudással rendelkező alrendszereink.
Igen. Vagy legalább csendben örülni neki.
Egyébként mi tart vissza, hogy írj egy pulse -> ALSA wrapper réteget, azaz egy minimalista pipewire-t, amit utána nem hízlalsz? Különben a pipewire moduláris. Nem kell feltelepítened az összes csomagot ahhoz, hogy működjön, nekem sincs fenn minden. Illetve nem kell betölteni eszetlenül minden modult. Ha nem kell a hálózaton hangot átküldés, akkor azt nem kell betölteni. Ha nem kell az echo-cancel, ne használd. De legyen ott a pipewire-ben, nekem például kell.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
> mintavételi frekvenciák és felbontások különbözőségének kezelését.
Bocs a belevauért! Szórakoztató amúgy titeket olvasni :)
Azért itt fehívnám valamire a figyelmet! Az nem úgy van. h orrba-szájba lehet játszani a mintavételi frekvenciák konvertálásával. Persze addig, amíg egy kvazi telefonbeszélgetés szintű hangminőség megfelelő, addig nincs vele gond. De a konvertálás drasztikus minőségromlással jár. pl 44100 -ről > 48000 -ra kész borzadály. Akik virtuális zongora progikat készítik általában 96000Hz-t használnak a felvételnél és az utómunkálatoknál, és végül azt konvertálják 44100-ra a kész termékbe. Tehát a nagyobbtól a kisebb felé tud működni. De ott is spéci konvertáló progik vannak kiválasztva és használva, amik bizony igen sokat számolnak és lassan futnak - napokban probálgattam ilyeneket több 10.000 hangmintán és eltartott egy darabig amíg átdolgozott 50 gigányi wavot a ReSampler - a Sox-hoz képest is többszöröse volt az idő amíg futott. Szóval az egy kérdés, h a pipewire ezt a konvertálgatást a különböző sampleratek között h valósítja meg realtime? Rábízza a hangkártyára? Vagy saját algoritmust használ? Az elöbbi valószínüleg jobb megoldás lehet, bizonyára van erre chip a hangkártyán ami a konvertálással foglalkozik és remélhetően a benne lévő algoritmus sem csapnivaló - mondjuk hangkártya gyártók esetében ilyesmiben bízik az ember! Vagy csak az van a konvertálás megvalósítása helyett, h a feladat szépen tovább van delegálva az ALSAnák, és majd az eldönti h mit kezd vele? Mert ez esetben nem tudom, h miért lenne érvényes állítás, h a pipewire kezeli a mintavételi frekvenciák különbözőségét?
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
pl 44100 -ről > 48000 -ra kész borzadály. > te se tudod hogy mukodik a digitalis hang :) segitek https://www.youtube.com/watch?v=cIQ9IXSUzuM
Mit akarsz ezzel mondani? Ha megnézi a videót, akkor jobban fog szólni az újramintavételezett zene? És miért kell sértegetni a másikat, anélkül nem lehet megfogalmazni a mondandót?
azt, hogy hulyeseget beszel, mert nem erti hogyan mukodik a digitalis audio.
neked baszkodas helyett azt ajanlom, hogy mondjuk nezd meg te is a materiat, esetleg olvasd el a hozza tartozo wikioldalt. hatha atjon, hogy egy eleve bandimitelt dolgot hiaba teszel at magasabb sample rate-be... semmi sem fog valtozni. hacsak direkt nem barmolod el "ut kozben".
A véges ablakfüggvények problematikájáról hallottál-e már? Szerintem eljutottal a tananyag negyedéig és ott megálltál, hogy te már mindent tudsz, lehet osztani az észt.
es a hallhato tartomanyrol hallottal-e mar? mert az, hogy a dithering utan ott van boven -100dB alatti zaj, annal a piacon levo barmelyik fizikai eszkoz (erosito, DAC, hangszoro, sot maga a kornyezeted alapzaja is) szarabbat tud. meg fel kellene tenni, hogy kozben a "semmit" hallgatod. eletszeru :)
a fuled meg... :) maradjunk annyiban, hogy a meroeszkozeink minimum egy nagysagrenddel pontosabbak.
es akkor mutass nekem plz. negyszogjelet hangszorobol felveve, utana visszaterhetunk a vegtelen iteraciora (illetve, hogy miert baromsag ezen agyalogni, amikor audio reprodukciorol beszelgetunk).
Sőt, jobban belegondolva a dinamikus hangszóró egy lineáris DC motor, a v(t) = ds(t) / dt összefüggés alapján, valamint tudva, hogy v ~ u, a hangszórón lévő négyszögjelhez Dirac-delta táplálás kellene. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
meg is fone tole a coil meg az erosito a 3.14-csaba :D meghat a cucc a fizikai tehetetlensege okan nem tud teleportalgatni a ket vegallapot kozt, de ha tudna sem tudsz a levegobol negyszogjel hullamformat kicsikarni.
nem veletlen van _minden_ ilyen elott felul/alulatereszto szuro (nomeg hal'istennek mar lassan minden class-D, hi-freq PWM-mel), hiszen egyreszt csak egetnenk az elektronokat a semmiert, masreszt az utrasonic "zaj" - hacsak nem erre celeszkozzel, levalogatva csinalod - "visszapofazna" a hallhato tartomanyba.
Amire ki akartam lyukadni, hogy a matematika végtelen hosszú periodikus jelekről és hasonló elméleti konstrukciókról szól, amit mi hangkártyákkal csinálunk az meg egy kicsit más. Ezért nem lehet egy az egyben alkalmazni a matekot - amit meg lehetne alkalmazni az már sokkal bonyolultabb. Szükség van túlmintavételezésre, a resampling pedig mindig veszteséges. A gyakorlati megvalósításoknak pedig ismert hibáik vannak, ez az állítás, hogy "a resampling semmilyen hatással nincs arra amit hallunk" nem állja ki a valóság próbáját. Még a rögzített fájlok újramintavételezése esetén sem, mert azok sem végtelen hosszú periodikus jelek.
Real time újramintavételezés esetén pedig minden mintát úgy kell meghatározni, hogy csak a múltat ismerjük, vagy ha előre akarunk nézni egy kicsit is, akkor további késleltetést adunk a rendszernek, ami szintén nem mindegy.
Nem akartam volna szemtelenül fogalmazni, de "rákényszerítettél". Tényleg az van, hogy az egésznek a matekja akkor kezd el bonyolódni, amikor bejönnek a nem ideális szűrők, a transzformációs eljárások véges időablakai és satöbbi. Ezért mondom, hogy a Shannon tétel a tananyag harmadánál-negyedénél van, de lehet, hogy túlbecsültem. Bevallom, hogy nem szakterületem ez, és nem vágom már az egészet fejből, de annyit tudok, hogy mind a mintavételezésnek, mind az újramintavételezésnek elvi okok miatt is van hibája, és a gyakorlatban pedig praktikus okokból egyszerűsítéseket alkalmaznak, amik még további hibákat visznek be.
Ez mind igaz, csak itt jön az, hogy az LSB-n egy-egy eltérést úgy sem hallasz meg. Túl nagy gyakorlati jelentőséggel nem bír, hogy az adott minta értéke 4327 vagy 4328.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Először is azzal kezdtük ezt a rész-szálat, hogy matematikailag ugyanaz lesz tökmindegy hogy van-e resampling. Most már ott tartunk, hogy LSB-n 1 különbség már mindegy. Akkor most bizonyítsd be, hogy a fent nevezett eltérések LSB-n 1 elérést adnak csak! :-) Szerintem ez sincsen így, pláne ha a real time újramintavételezés gyakorlatban lézető megvalósításait nézzük. Tehát nem kerekítési hibán belüliek lesznek a különbségek. De én sem tudom bizonyítani, inkább ne is kérjétek, mert nem akarok napokat fektetni elméleti kérdésekbe most amikor 1000 sürgős és fizetős dolgom is van :-)
Tökéletesen nem lesz ugyanaz, viszont gyakorlatilag jó lesz, mert igen jó elvi módszereink vannak arra, hogyan lehet diszkrét pontokra legjobban illeszkedő görbét fektetni. Ha megvan ez a görbénk, annak bármely t időpillanatbeli értéke ismert. Már az intervallumon belül, nem a jövőre nézvést. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
nem. onnan indultunk, hogy nem fog semmi valtozni, mert nem fogsz hallani kulonbseget/az audio eszkozeid pontatlansaga nagysagrenddel nagyobb. es akkor a fuledrol ne is beszeljunk.
senki nem arrol beszel, hogy tokeletesen le lehetne modellezni a valosagot bandlimitalt samplinggel. :)
nehéz ezt követnem. Lesz majd egy harmadik link is ami végre arról szól majd, amit előadsz? 44.1 > 48.0 garantált a minőségromlás, erről egy kukk sincsen. A bemenő analóg jel AD majd DA átalakítást követően nem állítható tökéletesen helyre. Minden átalakításnak vannak veszteségei.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Mit jelent a tökéletesen ebben a kontextusban? 0 - 20 kHz spektrumon? Nyilván nagyobb sávszélességen nem fog menni. Mondtam, hogy Shannon-tétel. Gondolom, az is világos, hogy a 20 kHz-es sávszélesség nem jelent 20 kHz háromszög, fűrész, négyszög jelet, hanem az 20 kHz szinuszos, tehát nincs további harmonikusod.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Hát ilyen értelemben az a probléma, h való világ hangjai nem bandlimiteltek. Az AD meg limitálja. Oké h nem hallod, de mégis befolyásolja a számítást és így megjelenhet a hallható tartományban is. Persze ezen túl is vannak veszteséget meg torzítást produkáló tényezők, az elektronikai alkatrészek, illetsztések, az AD minősége - ezektől nem lehet eltekinteni, mert ha lehetne akkor nem gyártanának kismillió féle hangkártyát. Mindenképp lesz veszteség a gyakorlatban. A linkelt videóban lévő 1 Hz es sinusos jel ami előáll aztán DA után is, nem releváns a gyakorlati alkalmazással.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
való világ hangjai nem bandlimiteltek > bezzeg a fuled... ertem en, hogy vannak, akik denevereknek keszitenek szimfoniat, de egyelore maradjunk csak az emberi hallasnal, ami gyerekkent sem nagyon megy 20kHz kozelebe.
1 Hz es sinusos jel ami előáll aztán DA után is, nem releváns a gyakorlati alkalmazással. > hat, eloszor is kHz es ezek szerint nem nagyon jutottal el a negyszogjelig (ami a legkomplexebben leirhato "waveform", mar ha annak lehet egyaltalan nevezni :D)
maradjunk meg annal, hogy elso korben a fuled, majd az elektronikad meg a fizikai hangkeltoid a limit. es csak utana jon a digitalis sampling/dither/quantize/reproduction zaja/tokeletlensege, mar 44.1k/16 bit eseten is ha nem voltal kreten masterelesnel.
Nem igaz, amit a ficko mond a videoban, h csak egyetlen lehetséges összekötése van a pontoknak. Épp ez a lényeg, hogy nem képes tökéletesen eltalálni két mintavételi pont közt lévő értékeket, csak közelítőleg számolni. Lehet h van erre egy komplikált matematikai modell, amire igaz az állítás, csak az nem egyezik a valósággal. Nincs mese, a hiányzó értékek csak becsülhetőek, és két olyan mintavételi frekvencia között amik nem többszörösei egymásnak, az a kínos helyezt áll elő a konvertálás során, h leginkább a becsült értékből kellene előállítania az eredeti hangot eltérő samplerattel. Ez minőség romlással - értve ez alatt az eredeti hang megváltozását - kell h járjon! Most lehet h erre azt mondod, h nem hallani a különbséget, de ez szintén nem igaz. Mondjuk egy zeneszám esetén lehet h nem hallanám én se. De a virtuális zongorám hangzását pontosan ismerem. Tudom milyen hangot várok amikor leütök egy billentyűt. Ha mintákat átkonvertálom 44.1 > 48.0 és betöltöm az újonnan előálított hangokat immár 48kHz-en, azonnal hallom h ez nem az amit megszoktam. Kipóbáltam több konvertáló programot, paraméterezést stb. Legjobb eredményt a fentebb linkelt ReSampler adta.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
nem is kell kitalalni. tenyekkel vitatkozol. tokmindegy, hogy hol jarsz idoben a sampling eseten (jel eleje-kozepe-vege). ezt is bemutatja a video. a samle rate csak annyit hataroz meg, hogy mekkora a legmagasabb frekiju sinusjel, amit az adott sampling kepes leirni. semmi mast. amig ez alatt vagy, tokeletesen vissza tudod epiteni a jelet. (felteve, hogy rendesen alulateresztettel elotte)
ha szarabbul szol a zongorad 48kHz-en, hasznalj 44.1-et. hidd el, hogy a zongorad (vagy a hangszorod, ha mar itt tartunk) nem fog neked 15kHz folotti hangokat kiadni, tippre tizet is alig. ezt egy jol iranyzott spektrumanalizissel ellenorizheted.
A legmagasabb hang 4200 Hz körül van -függ több mindentől: hangolás, zongara fizikai méretei. De persze nem csak a húr rezgéséből áll a hang, hanem van még egy rakás dolog ami zizeg, rezonál. Szal vannak magasabb hangok is. Monitor hangfalak vannak, meg szuper fejhallgatóim.
Kawai gs60 spectrum analyzing 18K nál még látni egy kis jelet - 44.1-es minták; a b7,c8 billentyűk hangjai
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
innentol mar csak az kene, hogy mikrofonnal felvenni mi jon ki a hangszorobol/fejhallgatobol.
a 4.2k Hz a fundamentum, viszont a magas hangjai a zongoranak nem rendelkeznek olyan telt (sok) felharmonikusokkal, mint a mely hangok. mar az elso oktav is csak epphogy van ott, a masodik pedig szinte semmi (ahogy a spektrumodon is latszik). az felett pedig mar a fuled nem fogja hallani a kovetkezot, meg ha felvetelbe bele is kerul amibol a sample-ok keszultek.
18k az boven 22.05k alatt van, amit ha szamolunk nagyvonaluan 2k Hz headroomot a lowpassra, bele is fer 44.1k-s mintavetelbe.
azert nincs ertelme igazabol felkodolni 48k-ra, mert semmilyen plusz informacio nem lesz a hanfile-okban. csak mashova kerulnek a mintak.
Ez filozófiai kérdés. Persze, a pontokat végtelen sokféleképpen összekötheted, de egy olyan összekötés létezik, ami jó. Ezután lehet arról beszélni, mit nevezünk jónak. Mondok két nem túl jót. Az egyik esetben legyen két pont közti érték mindig a kisebb időpillanathoz tartozó pont pillanatértéke. Ekkor lesz egy lépcsős jeled. Kicsit jobb, ha a pontokat egyenes szakaszokkal kötöd össze, azaz lineárisan interpolálsz.
Honnan tudjuk, hogy ezek nem elég jók? Onnan, hogy mindkét esetben keletkezett egy rakás felharmonikusod. Ha ráeresztesz egy ideális szűrőt, amelynek az átvitele egységugrás-szerű, azaz f0 frekvencia alatt 1 az átvitele, f0 frekvencia fölött 0, akkor optimális íven fog kunkorodni a görbéd, mert a lehető leghajlékonyabb lesz, de nem lesz túlmozgásos. Az első példámban a függvényben lévő ugrások, szakadások okozták a túlmozgást, már az első deriváltunk végtelen volt, a második példámban a mintáknál lévő töréspont miatt az első deriváltnak lesz szakadása, ugrása, ott csak a második derivált válik végtelenné.
Ha tehát ezt a sávkorlátozást fogalmazod meg kritériumként, akkor pontosan egyféle görbével tudod összekötni a pontjaidat. Ha megvan ez a legjobb görbe, akkor a pontosságnak csak a számábrázolás szab határt, de a double típus jóval pontosabb, mint amilyen felbontású D/A konvertert képesek vagyunk építeni, szóval aggodalomra semmi ok. A görbéd egy folytonos függvény, bármely t időpillanathoz hozzárendel egy u(t) értéket, tehát kedvedre csinálhatsz bármilyen frekvenciával resampling-et. Már persze teljesülni kell a Shannon törvénynek, tehát a sávkorlátozás f0 frekvenciájának kétszeresénél az eredeti és az új mintavételi frekvenciának is nagyobbnak kell lennie.
Ez elméletileg nem igaz, az más kérdés, hogy igénytelen, kókányoló programozók mindig vannak. Aztán persze, hogy rossz a kedved, ha megnyerted valami szegény legény lineáris interpolációs algoritmusát.
Már csak az a kérdés, mit teszünk valósággá.
Nem. Pontosan számolható, leírtam, hogyan. Abban az értelemben persze igazad van, hogy becsülhető, hogy két pont között már az eredeti hanganyagban sem volt információnk. De akkor miért is lesz veszteséges, amikor az az információ az eredetiben sincs meg? Az eredetiben csak a spektrum f0 frekvenciáig tartó része van meg, az viszont teljesen. Azon elgondolkodtál, mi történik, az eredeti mintavételi frekvencián? Ugyanúgy van egy aluláteresztő szűrőd, amelynek kimenetén ott lesz a folytonos időfüggvényű analóg jel. De ez pont ugyanaz, amit számolva csináltunk! :)
Nem kell. Miért kellene? Spektrumanalízis, Fourier-transzformáció, aminek utána kellene olvasnod.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
> Ha megvan ez a legjobb görbe
Az lehet h van egy legjobb görbéd, csak a valóság az, ami nem felel meg a legjobb görbének.
Amig nem változtatom meg a sampleratet a felvétel és a lejátszás között addig nincsen veszteségem. Lesz egy felbontása dolognak, annyit tud és kész.
> De ez pont ugyanaz, amit számolva csináltunk! :)
Majdnem, azzal a különséggel, h az eredetinél a valós értékek alapján áll elő az analóg jel, a konvertáltnál meg már a számoltak alapján - ami nyilván rosszabb.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
az a gond, hogy meg mindig nem erted hogyan mukodik :/
Ha jot akarsz magadnak, kezdesnek megnezed az egesz playlistet.
Miért, a valóságban mi történik az eredeti hangod két mintavételi pontja között? Mondom, az általad eredetinek nevezett hangodban sincs ott információ. Vagy az A/D konverter utáni aluláteresztő szűrő, vagy az erősítőd véges sávszélessége, vagy a hangszóród membránjának tehetetlensége, vagy a hangszóród tekercsének induktív reaktanciája határozza meg a membrán mozgását - valójában ezek együtt - a pontok között, de ez mind aluláteresztő szűrő. Azt értsd meg, hogy az eredeti hangban sincs több információd, ami a spektrum f0 frekvenciája fölött lenne - f0 legyen 20 kHz -, de ha lenne, azzal sem mennél semmire, mert úgysem hallanád.
Meg utána sincs. Pontosabban szólva a resampling által okozott veszteség a spektrum azon részére esik, amely információ az eredeti hangban sem volt benne, az f0 frekvencia fölé.
Ez butaság így. Egy folytonos időfüggvényt kell reprodukálni diszkrét értékek alapján. Bizonyos feltételek teljesülése esetén a kettő ekvivalens - mármint az eredeti és az újramintavételezett -, csak ezt nem akarod belátni. Mondom, az eredetinek nevezett hangodban sincs meg a végtelen sok pontod, a folytonos függvényt ott is meg kell becsülnöd, ahogyan te mondod.
Kultúrtörténeti érdekesség, hogy a 48 kS/s és a 44.1 kS/s azért nem egész számú többszörösei egymásnak, illetve azért nem azonosak, mert hozzád hasonlóan gondolkodtak a zenemű kiadók, megrettenve attól, hogy veszteségmentesen lehet másolni a digitális technika felbukkanásával CD-ről DAT-ra, s az eltérő mintavételi frekvencia miatt kell majd analóg szakasz, ami a konverzió pontatlansága és zaj miatt ront majd a minőségen. Viszont nem gondolták végig ennek az elvét, hogy ez nincs így, meg talán akkoriban nem nagyon voltak könnyen elérhető digitális jelprocesszorok (DSP), illetve nem volt elérhető ilyen nagy számítási kapacitás ilyen olcsón, mint ma. Valószínűleg a zenemű kiadók sem értettek a spektrumanalízishez. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
igazabol ezek a S/s-ek onnan jonnek, hogy az analog kepatvitelbe ezek fertek bele egesz tobbszoroskent :) ahol fekete-feher savok/kockak voltak a 0 meg 1.
probald ki magad:
- nyiss egy audacity-t, importalj be egy 44.1k 32bit float muzsikat
- duplikald a tracket
- egyik tracket resample-ozd 48k-ra
- egyik trackre tolj egy invert effectet
- mixeld le a ket tracked egy uj trackbe (invert miatt ez lesz a ketto kozti kulonbseg)
- nyomj az uj mixelt trackedre egy analize > measure RMS-t
nekem ez jott ki.
Az Audacity hogy adja össze a 44.1k és a 48k tracket? Véletlenül nem úgy, hogy közös frekvenciára hozza pont ugyanazzal az algoritmussal? Persze, hogy ugyanaz lesz belőle.
Inkább azt kellene, hogy 44.1 -> 48 -> 44.1 -> invert -> mix az eredetivel. Bár a mérésben akkor is lehet hiba, ha csak egyetlen mintával elcsúszunk.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
parancsotok szamomra keres! :)
Ez azt igazolja, hogy működik a matematika és az Audacity is. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Én ezt a képet nem értem, a mix most is 48kHz-es.
Jé, tényleg, ezt észre sem vettem.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
az egesz project az, epp ezert a mix is az kell legyen (nincs valasztasod). mi ertelme volna fel-le konvertalgatni ha a project kisebb mintavetelu? a lenyegen mit valtoztat, megvolt a fel-le konverzio es a ket 44.1k-s track kozotti kulonbseg lett annyi, amit latsz.
ha csak egy 44k-s tracket mixelsz le, az is 48k lesz.
ha megnyugtat, amennyiben a hangeszkozod 48k-ra van beallitva, akkor is lesz "upsampling", mikor a 44k-s file-t lejatszod. raadasul on-the-fly.
a CPU-m pl. tapasztalatbol kiindulva 40-50-60 upsamplinget megcsinal realtime. 1 szalon, de van belole 12. szoval nem gondolnam, hogy tulzoan fajna barkinek is :) (mar vagy 20 eve barmilyen DSP chip is megcsinalja ezt neked miliwattokbol)
Egy modern pelda.
nem kell ezt az audio dolgot tulmisztifikalni, mert semmi rocket science nincs benne.
>mi ertelme volna fel-le konvertalgatni ha a project kisebb mintavetelu?
Talán az, hogy a fel-le konvergálgatásra tettél egy állítást, amit fel-le konvertálgatással lehetne bizonyítani.
>a lenyegen mit valtoztat
A lényegen azt változtatja, hogy ha végül mindkét mintát 48kHz-re konvertálod, akkor nem bizonyítottál semmit.
de nem konvertaltam mindket mintat 48-kra, ket 44.1k-s mintat mixeltem ossze, amibol az egyiket eloszor fel- majd le- konvertaltam: 44.1 > 48 > 44.1, majd invertaltam...
de legyen "igazad", tessek, belerakom neked a 44.1k-s project samplerate altatli "veszteseget":
https://i.imgur.com/4abECdN.png es ott is lesz a -120dB-s "zaj", amit ez okoz. csak ennek igy nem sok ertelme van :) es meg igy sem fogsz belole semmit sem hallani... :) mert nincs olyan AD/DA konverzio/erosito aminek a jel/zaj aranya ehhez kozelitene.
Ez hihetőbb, szerintem most csináltad jól. Ha jól látom, ez a 44.1 - (44.1 -> 48 -> 44.1) adja a -120 dB-t.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
nem, szerintem az a project "tokeletlensege" kovetkezmenye (mert hulye modon igy 44.1k-ra van limitalva a prject maga, mikozben a benne levo track fole lett konvertalva), de ezen nem fogunk osszeveszni :)
igy is -120dB a hiba, ami fizikai eszkozok szintjen a semmivel egyenerteku.
Meggyőzőnek tűnik, de...
Hogy működik az Audacity belül, tudod? Mi a konverzió pontos algoritmusa? Én még kötném az ebet a karóhoz, hogy még így is lehetséges, hogy a működési módjából adódó artifactot látunk. Ismereteim szerint az ilyen algoritmusok mind időablakokkal kell hogy dolgozzanak. (az időablak persze lehet a teljes zeneszám is, mondjuk 5 perc) Ha a konverzió oda és vissza pontosan ugyanazon időablakokra van meghívva, akkor ugyanazt kapjuk vissza. De ha másképpen vannak az időablakok, akkor meg nem. Vagy meg kellene sejtenem, hogy milyen példa hozza ki amit gondolok, vagy bele kellene másznom az algoritmusba. Plusz még ott van az a fonál is, hogy ez a konvertáló belenéz-e a jövőbe, azaz van-e inherens késleltetése? Tehát megvalósítható-e egyáltalán egy real-time rendszerben? Tudom az Audacity nyílt forrású, nem áll előttem semmi akadály, de mégis áll, mert dolgozni is kell valamikor. Meg mozogni. Meg főleg trollkodni. Úgyhogy ez egy hosszú szórakoztató témának ígérkezik, részemről még nincs lezárva az ügy :-) De nem tudom mikor lesz időm rá.
Nem értek hozzá, de talán a sinc() függvényt használják a minták súlyozására, ablakolására, ami a sin(x) / x úgy, hogy x = 0 helyen a kilyukadt függvényt annak határértékével, y = 1-gyel tömik be. Tehát ahol a pointerünk tart, onnantól előre-hátra távolodva egyre kisebb súllyal lesznek jelen a minták, s a kvantáltság miatt nem kell végtelen messzire menni.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
ha van elszabhato idod nezegetni mi okozza a kulonbsegeket amik a valosagban 0 jelentoseguek (-120dB, -1dB-re normalizalt jel mellett. hint: 110dB mar fajdalomhatar), hajra :D en nem tartalak vissza :)
Itt lefelé van az a 120 dB, de értem, hogy a dinamikatartomány nagyságát szeretted volna érzékeltetni. Ha jól látom, ez 6 nagyságrend, azaz ha a jelünk 1 V-os, akkor ez a -120 dB 1 µV lesz. Fene a jó hallását annak, aki ezt kiszúrja, pláne úgy, hogy az erősítő zaja nagyobb lesz, meg úgy, hogy ehhez azért kellene egy 21 bites D/A, ha jól számolom, s hát jól. :) Eleve 16 biten ábrázolják a hangot legtöbb esetben, bár nem kizárólagosan, van, amikor nagyobb felbontással.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
en nem a line level jelre, hanem a reprodukalt hangnyomas(kulonbsegekre)ra gondoltam, de a lenyeg ugyanaz, igen. mar az erositesnel elbukod az SNR-nel.
bar, kb. barmi modern eszkozon hallgatod le, jo esellyel lesz kozte egy (vagy tobb) olyan DSP amit fentebb emlegettem/linkeltem, ami mar alapbol azt fogja okozni, hogy "semmi koze" nem lesz a hangnak ahhoz, hogy audacity-ben -120dB vagy merhetetlen a diff. :)
Mindent el lehet rontani, de itt most arról beszélünk, hogy van elvi lehetőség arra, hogy jól csináljuk.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
hat, audio eseten sosem az a kerdes vegul elrontjuk-e (igen), hanem, hogy mennyire es ez a valosagban merheto vagy hallhato lesz-e vagy amugy erdekel-e barkit :)
Nem a matematikánk vagy a számítási teljesítmény a szűk keresztmetszet, gondoljunk csak a digitális oszcilloszkópokra GS/s mintavételi frekvenciákkal, vagy PLL szintézeres rádiókra - vaskos pendrive méretben is létezett már 15 éve, telefonokban is ott van -, ahol digitálisan oldanak meg mindent. Viszont érdemes kiszámítani, egy adott frekvencián hogyan alakul a gyorsulás és az erő a tekercs és membrán között, s lehet tűnődni, hogy a fenébe nem szakad szét a hangszóró darabjaira.
Ezzel csak azt akarom mondani, hogy a leggyengébb láncszem a fejhallgató, hangszóró lesz, elektronika oldaláról pedig a zaj. A többit megoldjuk. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Hát, izé. Van a Shanon-tétel. Aztán van a Fourier-transzformáció. Pontokra görbét fektetni sokféleképpen lehet, de akár úgy is, hogy egy nagyon meredek digitális szűrőt használsz hozzá. Utána bármely közbenső pont értéke megvan például float-ban bármely időpillanatban. Mivel nem akarod a spektrum átlapolódását, aluláteresztő szűrni mindenképpen kell. Vagy sohasem tanultad ezeket, vagy már elfelejtetted.
Hangkártyára csak akkor tudod bízni, ha egy hangforrásod van. Ha software-esen mixelsz, akkor számolsz, mint kisangyal.
Most azokat hagyjuk, akiknek jobban szól a hang, ha az erősítő tápegységének 230 V-os aljzata és a dugó aranyozott.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Oké, és ezt szoftveres mixet a pipewire számolja, vagy delegálja a feladatot tovább az ALSAnak? ALSA el lehet ugy is indítani, hogy a saját sampleratét játssza csak le, meg úgy is h ha eltérő forrást kap akkor konvertáljon - erre van pluginje.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Nekem úgy tűnik, hogy számolja, de alaposabban nem néztem át.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A Jack sztenderd lett, a legtöbb DAW, audio/zeneszerkesztő, pluginhost azt használja. A Pulsaaudio-ban egyetértek, a Red Hat meg Pöttering elcseszett egy banda, de ha azt hitted, hogy a Pulseaudio bloat, majd nézd meg az új alkotásukat, a Pipewire-t, Wireplumber-rel nyakonöntve, simán ötször nagyobb bloat. Ahhoz képest a systemd és a PA még egyszerűnek tűnik.
Sajnos a dolgok ebbe az irányba haladnak régóta, anno az ALSA is bloatabb volt, mint az azt megelőző OSS. Ez az ára, annak, hogy a Linux egyre inkább megy át mainstreambe, ahogy ki akarják vele szolgálni a tömegeket, viszik bele ezeket a hülyebiztosított, agyonbonyolított cuccokat, ami a felhasználó helyett próbál gondolkodni, mindent lezárni előle, meg a multi érdekeket kiszolgálni.
Ugyanez a bajom a GNOME-mal, meg a többi most divatos, erőltetett technológiával, minden fusson konténerben, konténerizált csomagformátumok (ráadásul a natív csomagok kárára erőltetve), immutable disztrók. A Wayland talán kivétel, az nem lenne rossz, de azt szerintem még túl korán nyomják, és túl erőszakosan próbálják kinyírni a X-et a kárára.
Persze meg kell jegyezni, hogy a topikindító problémáját nem a PA okozza, hanem hogy alapvetően nincs elég hálózati sávszélessége ahhoz, amit akar, így két alternatíva közül választhat: 1) vagy sűrű, kis bufferelést vállalja be, akkor lesz az a pattogás, amit most tapasztal, vagy 2) nagyobb bufferelést választ, akkor meg a lag, meg az esetleges leakadások lesznek nagyok, hosszúak. Egyik se jó, eldöntheti mindenki, hogy mit preferál. Én a helyében azt csinálnám, amit javasoltak, Icecast vagy hasonló megoldás, úgy a kliens saját hatáskörben megoldja lokálisan a bufferelést, és nem kell az audioszervernek bonyolítania hozzá a háttérben.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Erről próbáltam meggyőzni ügyeletes Red Hat influenszerünket is (locsemege), kevés sikerrel.
Az ALSA azért volt "bloatabb", mert többet tudott, nem azért, mert szándékosan overengineer-elték, hogy beleilljen a multis fejlesztési modellekbe, meg a Pöttering-félék idealizmusaiba.
Ennek a kettőnek nincs sok köze egymáshoz. Az alkalmazások a fejlesztői lustaság (babzsákfejlesztők) és az "overengineering for the win" mentalitás miatt bloat-abbak. Utóbbi azt jelenti, hogy az előléptetéseket és a szakmai dicsfényt nem azért osztogatják, ha egy problémát egy mérnök a lehető legegyszerűbben old meg, hanem azért, ha minél reprodukálhatatlanabb módon. Ez az open-source multik berkein belül elterjedt módi, amivel azt igyekeznek garantálni, hogy rajtuk kívül kevesen rendelkeznek akkora erőforrásokkal, hogy átlássák, megértsék és saját égisz alatt továbbvigyék a szaraikat, így veszélyeztetve a hegemóniájukat. Ezzel helyettesítik azt a réteget, amit az open-source elterjedése kivett a rendszerből és anno a closed-source garantált. Láttuk ezt a systemd-nél, láttuk a pulseaudio-nál, láttuk a GTK3-nál (csak ott folyamatos API-törögetések formájában).
A Linux pedig annyira "mainstream" 2024-ben, mint a Windows 7. A Linuxot nem teszi mainstream-mé a sok elbaszott Windows-osítás, cserébe elveszi azoknak a kedvét, akik eddig használták más rendszerek helyett.
Túl korán? 15 éve tákolgatják azt a szarkupacot és a mai napig nem sikerült felülkerekedni vele az Xorg-on. Mit csinál ilyenkor a multi? Korporatokrata erővel, FUD kampánnyal erőlteti rá mindenkire.
ha rajtad mulna a fejlodes iranya, nem kellene operacios rendszer, jol mukodott az is, amikor a punchcard-kupacodat odaadtad az operatornak, az meg bedugdosta amikor epp arra jart vagy jutott neked gepido.
mert ahhoz kepest mar egy 9600 baudos serial console interface is bloat!!!!11111 :D
szerencsere jelenleg nem ez az irany.
Picit értem a fájdalmát. Az engem is frusztrál, hogy míg a számítástechnika hőskorában józan paraszti ésszel kitalálható volt minden, egy aszinkron soros átvitel például, addig egy USB szabvány több, mint 600 oldal doksi, vagy egy vacak, párszáz forintos mikrokontroller dokumentációja 1000 oldal fölött van. Sokat tudnak, de van, amikor a kevesebb több, mert kegyetlen az a tanulási görbe, amíg egy ilyet kellő mélységben megismersz, megértesz.
A jó hír viszont az, hogy vannak MCU-k olcsón, ha neki bonyolult a PC, akkor ott vannak a mikrokontrollerek, retro gép tudású cuccot ma már olcsón meg lehet tervezni, persze az értelme kérdéses. Vagy PC-re is lehet konzolos alkalmazást írni C-ben, vagy valamilyen script nyelven, USB-hez driver sem kell, a device file-okat elég olvasni vagy arra írni, meg miegymás. Szóval igaz, hogy marha bonyolult, de épp Linuxon megvan a lehetőség az egyszerű dolgokra. Tapasztalatból mondom, nem olvastam itt meg ott, a munkám része, hogy cégesen saját fejlesztésű műszerhez írok valami kezelői felületet, firmware letöltőkét, parancsokat adó, válaszokat stdout-ra küldő alkalmazást, effélék.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
en is eretm a seggfajasat, csak ha nekem van egy USB hangkartyam, nem akarom a rajta levo chipet meg az usb-t programozni, user oldalrol nekem az kell, hogy bedugom, mukodik, utana meg feluleten ugy tudjam dugdosni az in/out-ot, mint a jack dugokat a valo eletben is. oldja meg az OS/driver/GUI.
vagy ha mar user interface vs. DSP: van ket kvazi ekvivalens DSP pedal. az egyikben van BT/wifi, szines touch screen, online save/restore/library/update lehetoseg... a masikon meg 4+2 gomb, 4 rotary switch meg egy 128x32-es monochrome kijelzo. vajon melyikkel lehet hatekonyabban ugyanazt a vegeredmenyt elerni 0-rol? adott parameteret egy adott effektnek modositani? vagy csak megmondani egyaltalan mi hogyan van eppen beallitva? nem, nem a masodik az. nem kell mindent pilotavizsgasra csinalni, csak ForFucksSake.
ALSA ezt eddig is megoldotta. Drivereket ebben az esetben a kernel kezeli, ami az OS része. GUI-t meg bármikor bárki írhatott volna hozzá, még egy plusz bloat réteg belegányolása helyett.
A pipewire nem a GUI-t oldja meg, mivel nem az.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Felfogtam, de te nem kellettél hozzá.
Azt mondtam, hogy egy ALSA-hoz is lehetett volna rendes GUI-s konfigurátort írni, ami mindent tud, amit a config fájlokba írnál.
Szokásos túlzó vadbaromság, amivel a fejlődésmániások érvelnek. Ha úgy lenne, ahogy mondod, akkor punchcard-kupacom mögül írnám ezeket a sorokat, de nincs punchcard-kupacom.
Nem, nem az. A soros port valódi innováció a lyukkártyához képest. A pipewire nem valódi innováció a pulseaudio-hoz képest, csak egy újrafeltalált kerék egy nála valamivel szarabbul sikerült újrafeltalált kerék helyett, de legalább még nagyobb bloat. Sem a pulseaudio-ra, sem a Red Hat egyéb balfaszságaira (gtk3, systemd, libinput stb.) nem lenne szükség ahhoz, hogy a tech-világ előre menjen. Menne ilyen koncepcionális felforgatások és bloat nélkül is.
Szerencsére™ az az irány, hogy innovációt hazudva dobatnak ki számítógépeket a szoftvertámogatás önkényes megvonásával, miközben valódi, nagy léptékű fejlődés már évek óta nincs az egyes hardvereszközök között. Változtatgatás és erőltetett növekedés van. Eggyel több CPU mag, eggyel több giga memória, eggyel több megapixel. Nem, ezek közt nincs akkora különbség, mint a lyukkártya és a soros port között. Ezért fos az érvelésed. Mint mindig, dorsyka.
Ami valós fejlesztői igény. A fejlesztő kapott egy kényelmes interface-t, amit végre kényelmesen használhat. Épp ez a dolga az operációs rendszernek, a libeknek.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A gépkidobás nem fejlesztői igény.
Nem kell kidobni a gépet a pipewire használata esetén.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem a pipewire használatára írtam, amire reagáltál, hanem általában a szoftveres elavultatásra.
Az ALSA-val nem elavultatás történt. Az ALSA él és virul, ellenben az ALSA nem az a réteg, amelyet az alkalmazásnak kell kezelnie. Mint ahogyan az X11 sem az a réteg. Ettől még lehet közvetlen X11-et kezelő alkalmazást írni, csak nem jó ötlet.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Az ALSÁ-val nem elavultatás történt, hanem egy bloated trágyadomb behúzása az alkalmazásréteg és az ALSA közé, a te aktív influenszerkedéseddel.
De igen, jó ötlet, mert az esetek 99%-ában, ahol nem stúdiózásra használnak Linuxot, ott semmi keresnivalója nincs sem egy pulseaudio-nak, sem egy pipewire-nak. Van keresnivalója viszont egy valamirevaló ALSA konfignak és konfigurátornak.
Nem értünk ebben egyet. Ugyanazokat a köröket futjuk, szerintem túlbeszéltük.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Szerintem is.
Én ilyesmit darkice és icecasttal oldottam meg, a kliens androidon volt javaban írva, de nyilván bármilyen netradiós progit lehet használni [linux alatt].
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Na, de miért pulseaudio, amikor az lokálban is képes volt teljesen széteső, folyamatos buffer underrun hangot produkálni, amikor van pipewire?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
pipewire-rel működik?
Én teszteljem ezt hálózaton? Nem akarod kipróbálni? ;)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem teljesen ugyanez a szitu, de van itthon egy ikeás sonos hangfal (ne kérdezd). Az gyakorlatilag airplay, egyszer viccből megnéztem, hogy mi a helyzet vele, kb be kellett tölteni valami raop-disvover modult, aztán megjelent, és szólt.
Gyors gugli után úgy látom vannak mindenféle protokolljai, amikkel mehet over network, szóval érdemes lehet kipróbálni.
Lehetséges workaround: átmásoltatod egy tempfájlba az adott zenét, lejátssza a tetszőleges program mint helyi audiot, majd ha vége és kilép törlöd és jöhet a következő.. egy kis scriptbe megírod az egészet. Esetleg pipe használattal is mehetne ha zavar az a minimális szünet 2 szám között amíg átszedi a gépre. Persze ezeket nem próbáltam, csak tippek úgyhogy peace ha hülyeség :)
Engem wifin ami beszivatott korábban ilyen nagyon realtime dolgoknál, az a background scan. Egyrészt a számítógép is periodikusan keresgetett, másrészt anno openWRT alapú router is x percenként nyomott egy scan-t, bár minek ilyen sűrűn, azt nem tudom. Routerben le lehetett tiltani, számítógépen pedig lehetett állítani, hogy bizonyos jelerősség fölött ne is legyen roaming miatt keresés, és így megszűntek ezek az időszakos mikroakadások