Kiitos avusta. Näissä on vaan se ongelma, että pitäisi ensiksi keksiä kaikki mahdolliset konffit noihin tiedostoihin jostain. Mulla on 2015 asti päivitetty Kubuntu ja Pipewire tuli ehkä pari päivitystä sitten. /etc/pipewire/media-session.d/ :ssä ei ole yhtikäs mitään. Eli joutuu lukemaan manuaaleja, että mitä niihin pitää tunkea jos ei ole valmiita pohjia missään, niin menee vaan rutosti aikaa.
Tuo mainitsemasi hakemisto viittaa vanhaan pipewire-media-sessioniin, joka oli PW:n aikaisempi sessionhallinta ja jonka kehitys loppui jokunen vuosi sitten kun WirePlumber korvasi sen. Ennen enempää perehtymistä kannattanee varmistaa että kyseessä ei ole jäännös vanhasta versiosta ja että Ubuntukin on jo siirtynyt WirePlumberin käyttöön.
GRUB kun on käytössä, niin voit lisätä numeron 3 kernelin boot parametreihin editoimalla GRUB-bootmenussa, niin kone käynnistyy suoraan komentoriville ilman grafiikkaa. Sen jälkeen vaan logeja kattelemaan missä vika.
Vastausta en osaa antaa mutta ittellä on jo yli 10v takaa aika samanlainen kokemus debianin kanssa. Se sitten jäikin viimeiseksi kokeiluksi kyseisen distron kanssa.
Debian on yksi eniten vakaimmista distroista, näin melkein 30-vuoden kokemuksella sanottuna. Stable releasin pitäisi päivittyä aina ongelmitta. Mutta suosittelen ottamaan niitä varmuuskopioita levystä ja tiedostoista. Suosittelen varmuuskopiomaan käyttöjärjestelmän esim. Clonezillalla aina silloin tällöin niin välttyy isommilta asennus ruljansseilta.
Kyllä tuo mulla ainakin näyttää ihan oikeata aikaa.
En tiedä saisiko tuon prioriteettia heti prosessin käynnistyksessä säädettyä (varmaan onnistuisi jostain palvelun asetustiedostosta) mutta ainakin käynnissä olevan prosessin prioriteettia voi muokata renice-komennolla. Ja tuon renice-komennon sopivilla parametreilla saisi varmaan johonkin koneen startup-skriptiin laitettua.
Ei ole tullut Ubuntujen kanssa tolskattua Pipewire-aikakaudella, mutta tuon pitäisi toimia ilman että tarvitsee käsin härppiä. Pipewire asettaa itse prioritynsä korkeammalle jos tarvittavat oikeudet ovat kunnossa, tai vaihtoehtoisesti pyytää sitä RTKitiltä DBusin kautta. Jälkimmäisen tavan vaatimuksista ei tietoa, mutta ensiksi mainittu on ainakin muutamassa muussa distrossa sidottu
pipewire groupiin. Eli käyttäjän jolla halutaan pipewireä käyttää tulee olla tuossa groupissa./etc/security/limits.d/ hakemistoon tulevaa confia, jos tulee niin siitä pitäisi selvitä group johon käyttäjä lisäämällä homman pitäisi suttaantua. Jos sitä ei tule niin kenties Ubuntulla on joku eri tapa tehdä tuo./etc/security/limits.d/25-pw-rlimits.conf jossa:@pipewire - rtprio 70
@pipewire - nice -19
@pipewire - memlock 4194304
Erikoinen tapaus kyllä. Jotenkin kai pitäisi pystyä haarukoimaan että mitä tuossa on eri tavalla silloin kun se toimii ongelmitta verrattuna rätinään. Onko jokin tietty softa jonka äänet rätisevät? Ja onko se joka kerta sama softa? Tai onko useampi aktiivinen ääntä tuottava softa käynnissä?Eipä se tuo käsin prioritetin nosto auttanu sittenkään...kahta kauheempana rätisee.
Kokeilaan käyttäjän lisäämistä vielä tonne pipewire ryhmään....tosin minusta minä tämänkin koitin jo aikasemmin.
Semmosen huomion tein kans, kun ihmettelin tuota system monitoria, että kun ääni rätisee ja poksuu niin niin pipewire-pulse prosessi hyppii sleeping ja running väliä minusta jatkuvasti. Sillon kun audio toimii niin toi pysyy running tilassa koko ajan niin pitkään kuin ääntä soittaa.
pw-top tai pw-dump työkalujen ulosantia äänten toimiessa ja rätistessä. Jälkimmäinen tosin tuuttaa pitkän JSONin jonka vertaaminen voi vaatia toisenkin kupillisen kahvia.
Mikä se ratkaisu oli?
Hmm...
Ne core multiplierit oli sittenkin liian suuret 44,43,42,41 eli joku oli niitä säätänyt joskus, kun tuonhan piti olla 3,5 GHz ja "turbo" 3,9 GHz. Pienensin kaikkia yhdellä niin sitten sain ajeltua virustarkistukset (yms. näennäispuuhat) läpi. Ajoin myös memtest:iä 20 minuuttia. Muistista ei löytynyt mitään vikaa tuolla ajalla, joten en tiedä lopulta mihin kaatui, muuta kuin "liian korkeaan multiplieriin".
Ei tuolla pitäisi normaalisti olla merkitystä, vaikka olisi yhtä aikaa useampi lähde eri sample ratea puskemassa.Hmm...
Ulostulon sample rate näyttäs olevan mulla kait väärä?
Eikös tuon pitäs olla sama 44.1kHz kuin tolla lähteellä eli VLC:lla?
Tosin rätinään toi ei vaikuta, kun Firefox ja esim. Youtube videot ovat 48kHz ja silloin toi lähde on myös 48000 mutta silti rätisee. Sitähän en tosin tiiä onko Youtube videooiden audio raidat sitten 48kHz oikeasti...
Tuo ei varsinaisesti ole virhe, kertoo vain että kernelin retire_capture_urb funktio haluaa logittaa enemmän mitä rate limit antaa myöten ja että 108 logiviestiä on suppressoitu.
Mitehän nuo sitten saisi näkyville?
Ehkä voisi koittaa ottaa ratelimiting pois päältä ja sen jälkeen toistaa ongelma. Ajossa olevan kernelin ratelimit asetusta pitäisi voida muuttaa sysfs:n kautta kirjoittamalla
kernel/printk_ratelimit:een 0, esim. sysctl -w kernel.printk_ratelimit=0Käyttääkös se fedora pulseaudiota vai pipewire? Alunperin vaihdoin pulseaudiosta pipewireen juuri sen takia kun bluetooth vehkeitä ei saanut PA:lla toimimaan kunnolla vaikka kuin rukoili ja hinkkasi. Pipewirellä ei ole ollut enää mitään onglemia ja joissain distroissa se tulee jo oletuksena tai ainakin voi valita asennusvaiheessa.Mikähän bluetooth usb-dongle toimisi luotettavasti linuxissa? HP:n pöytäkoneella ja fedoralla on lähes mahdotonta saada bluetooth-kuulokkeet yhdistettyä. Jos kuulokkeet pitää aina samassa koneessa kiinni eikä koskaan yhdistä niitä muualle, niin toimii kohtalaisesti. Muussa tapauksessa pitää aina parittaa uudelleen ja se on yhtä helvettiä, koska laitetta joko ei löydy, tai sitten fedora yhdistää laitteen minkä paritus on jo moneen kertaan purettu (!?!?). Ainoa tapa mikä toimii jotenkin, on ajaa bluetooth-palvelu alas, laittaa kuulokkeet paritustilaan, käynnistää bluetooth-palvelu ja yrittää sitten paritusta. Asiaa ei helpota se, että kuulokkeiden saaminen paritustilaan onnistuu ehkä yhdellä kertaa viidestä, mutta ei kai uutena lähemmäs 300 euroa maksaneilta sonyn kuulokkeilta voi mahdottomia vaatiakaan
En ole kylläkään varma onko vika bluetooth-piirissä vai eikö bluetooth vaan toimi linuxissa tuon paremmin. Äsken piti katsella 20min rust-video loppuun, mutta se 20min meni kuulokkeiden paritukseen.
aur.archlinux.org
Pipewireä käyttää. Hyvä puoli on toki se, että kun kuulokkeet on kerran saanut paritettua ne kyllä toimii ja jopa yhdistyy automaattisesti, kunhan niitä ei vaan välillä käytä muilla laitteilla.
/OT
