Miksi niitä kannattaa käyttää, sen sijaan että muuttaa jotain riviä pipewire.conf:ssa?
Varsinkin jos nuo drop-init pitää itse väsätä jollain tietyllä formaatilla niin mieluummin en ala arpoa niiden kanssa vaan ohjeiden mukaan muutan jotain tai joitakin arvoja yhdessä konffissa jossa ne ovat jo valmiiksi oikeassa formaatissa.
Lähinnä siksi koska kuten huomasit, se on hieman monimutkanen kokonaisuus jossa on paljon nippeleitä. Jos otat default configuraatiosta kopion ja muutat yhtä riviä, niin käytännössä olet naulannut muutkin nippelit
sen hetkiseen defaulttiin. Toki kuten huomasitkin niin osa niistä on muutenkin kommentoituja, joten käytetään buildiaikaisia defaultteja.
Mutta niiden osalta mitä asetetaan, ja jos PipeWiren päivittyessä defaultit muuttuvat, käytät jatkossakin aikaisempia vaikka ne olisivatkin nyt väärin. Tai jos tulee uusia parametrejä, niin ne ravistetaan jostakin hihasta etkä edes tiedä sellaisen olemassaolosta, saati mitä se pitää sisällään koska vanhassa kopiossa sitä ei ole ollutkaan edes kommentoituna.
Paljolti mieltymyskysymys, toki voi kopioida sen oletus pipewire.confin ja mulkata sitä haluamaansa suuntaan jos sen kokee helpommaksi, mutta muutaman kerran antiikkisella default configilla hankalasti ratkottavia ongelmia metsästäneenä pidän sitä vähän riskialttiimpana tyylinä. Muuttaa sen mitä tarvitsee muuttaa eikä yhtään enempää ja tottuu käytäntöön, vastaavanlaisia drop in konfiguraatioita löytyy muualtakin, mm. systemd:stä.
Se formaattihan on täysin sama kuin pipewire.confissa, sen vaan on mahdollista ja jopa suotavaa olla typistetty minimiin. Voit copypastata koko lohkon missä haluamasi arvo on pipewire.confissa ja poistaa sen sisältä ne arvot joihin et halua koskea.
Mutta kunhan valitsee tavan millä etenee ja pysyy siinä, vähentää tulevaisuudessa WTF hetkiä.
Itse noita on paha muutella, yritin lukea läpi noita selityksiä mitä eri parametreja siellä on ja mihin ne vaikuttajat, ja aivan hepreaksi jäi, ainakin sen suhteen mikä saattaisi auttaa minua äänen säröytymisen estämisessä, vaikuttaa niin monimutkaiselta himmeliltä tuo pipewire. Esimerkkejä joissa pysähdyin hoomoilasena miettimään:
Tässä yksi syy miksi kannattaa pitää muutokset ja oletuksesta poikkeavat parametrien asetukset minimissä, jos ei tarkalleen tiedä mitä joku arvo tekee niin sen asettaminen voi olla jännä kepponen tulevaisuuden itselleen.
Multimedia processing graphs
gitlab.freedesktop.org
support.dbus = true
Enable DBus support. This will enable DBus support in the various modules that require
it. Disable this if you want to globally disable DBus support in the process.
Mistä tiedän haluanko vai enkö DBus-tukea, ja voiko sillä olla merkitystä äänen säröytymiselle? Pitääkö vain testata tämän vaikutusta?
link.max-buffers = 64
The maximum number of buffers to negotiate between nodes. Note that version < 3 clients
can only support 16 buffers. More buffers is almost always worse than less, latency
and memory wise.
Eli...? Ei kannata koskea, tai ainakaan kasvattaa tuosta arvosta, oli mikä oli koska se olisi "almost always worse"?
mem.allow-mlock = true
Try to mlock the memory for the realtime processes. Locked memory will not be swapped out by the kernel
and avoid hickups in the processing threads. The amount of locked memory is however limited per
user but can be tuned.
Ei sano yhtkäs mitään. Vaikuttaa ehkä johonkin?
Näihin ei pitäisi olla normaalikäytössä olla mitään tarvetta koskea. Yleisesti ottaen, jos on epäilys että tarvitseeko jotakin arvoa muuttaa oletuksesta, niin melkoisella todennäköisyydellä ei tarvitse.
Oletan että minun ongelmani saattaa kulminoitua jotenkin liian pieniin buffereihin tai latensseihin ja jotenkin siihen vaikuttaa jokin "quantum-arvo" yhdessä käytetyn näytteenottotaajuuden kanssa tms., ja asiaan saattaa liittyä jokin "respampling" joka ilmeisesti on huono juttu jos sitä joutuu tekemään mutta ei hajuakaan tapahtuuko sitä minun tapauksessani ja jos tapahtuu, miten voin sen estää.
Nyt minulla on taas päällä /etc/pipewire/pipewire.conf:ssa (kopioitu /usr/share/pipewire/ alta tuonne root-käyttäjänä) muutettu tuo yksi rivi taas näin (alunperin se oli kommentoitu pois ja arvona 32):
default.clock.min-quantum = 1024
Tätäkin voi kokeilla hienosäätää suuremmaksi (tai pienemmäksi). Pienempi arvo parempi latenssien kannalta, mutta normaalikäytössä harvoin on syitä tavoitella yksinumeroisia latensseja niin voi sitä kokeilla kasvattaakin.
Niin ja tämän rivin muutin jonkun täällä antaman vinkin perusteella, ehkä auttaa sen "resamplingin" välttämisessä? Tuokin oli alunperin kommentoitu pois koko rivi:
default.clock.allowed-rates = [ 44100 48000 88200 96000 192000 ]
Katsotaan auttaako mitään, mutta mielestäni koitin juuri näitä samoja muutoksia aiemminkin. En ole varma auttoiko ongelmaan yhtään mutta joskus ääni säröytyi edelleen. Katsotaan onko nyt parempi onni.
Jos nämä muutokset eivät edelleenkään poista ongelmaa, tarkoittaako se että ongelmani on jokin muu mihin nuo quantumit tai bufferien koko tai resampling ei vaikuta?
Resamplingia tapahtuu aina jos jokin ääntä toistava ohjelma tuuttaa ulospäin erilaista formaattia mitä äänilaitteeseen syötetään sillä hetkellä. PipeWiressa tuo(kin) on dynaamista ja pyritään yleensä parhaaseen lopputulokseen, eli jos esim. alat soittamaan jotakin ns. studiotasoista FLACia jonka sample rate on vaikkapa 48kHz ja 24-bittisellä tarkkuudella ja PipeWiressä tämä formaatti on sallittu, ja äänilaite tukee sitä, niin silloin sitä syötetään suoraan laitteelle.
Nyt jos samalla musiikkia kuunnellessa käynnistät pelin joka lähes 99.9999% varmuudella tuottaa perinteistä 44.1kHz ääntä 16-bit tarkkuudella, niin PipeWire resamplaa sen 48kHz 24-bit formaattiin.
Mutta jos allowed-rates listalla on esim. vain 44100, niin PipeWire työntää laitteeseen yksinomaan tuota sample ratea riippumatta siitä mitä sille syötetään. Sitä en varmaksi osaa sanoa mitä tapahtuu jos joku softa sille tyrkyttää toista formaattia, resamplataanko vai torpataanko se kokonaan.
Perus kuluttajatason vehkeissä yleensä 44100 16-bittisenä toimii varmuudella, jos muita on edes tuettuna. Luonnollisesti PipeWire ei laitteelle syötä muotoa jota se ei ilmoita tukevansa, mutta koska on valitettava fakta että suurillakin firmoilla softaa monesti tekee monenlaista porukkaa *köh*intialaiset*köh* ja laite saattaa ilmoittaa tukevansa vaikkapa 48kHz formaattia mutta se ei silti toimi todellisuudessa kunnolla.
Lyhyesti, jos et tiedä tarvitsevasi noita "parempia" sample formaatteja etkä käytä DAWeja tai muitakaan pro(sumer) softia tai laitteita, ei liene haitaksi kokeilla rajoittaa pelkästään 44100:een, ja jos käyttämäsi softat tarjoaa ulosmenoformaatin konfigurointia, katsoa että nekin tuottaa aina 44100 16bit tavaraa (jos ei niin todnäk se on tuo 44100 16bit ellei lähde ole muuta).
