Linux-kysymyksiä & yleistä keskustelua Linuxista

[love_doctor]

Näkeekö jostain lokia Windowsin Event Viewerin tyyliin tai mikä olisi paras tapa selvitellä ongelmaa? Tiedän kaivaneeni vähän verta nenstä, koska käytän bleeding edge distroa, ajan pelit Waylandilla ja näytönohjaimessakin on kevyet kellotukset. Valistunut arvaus on että ajuri kaatuu, mutta sille on varmaan joku hyvä juurisyy.. Google-hauilla ei löytynyt mitään yleisiä murheita Valheim ja Linuxin kanssa.

Jos näyttis kaatuu, voi kokeilla asentaa ssh:n ja vaikka toisella koneella lähiverkossa kirjautua sisään ja ajaa dmesg/journalctl. Tähän ei tarvi toimivaa näyttistä. Jos kerneli on täysin jumissu, niin sshd ei ota vastaan yhteyksiä. Jos kone ei ehdi kirjata talteen mitään, niin kernelilogit voi koittaa ohjata toiselle laitteelle sarjaportilla/usb:llä/verkon yli.

 

[Barbarossa]

Nyt on kuukausi täynnä OpenSuse Tumbleweedin käyttämistä. Windowsin puolelle ei ole toistaiseksi tarvinnut palata. Nyt minulla on kuitenkin ollut ongelmia Valheimin kanssa, jossa noin puolentoista tunnin pelaamisen jälkeen ruutun jämähtää kuva ja kone on pakko sammuttaa kylmiltään. Äänet ja ohjelmat itsessään toimii kaatumisen jälkeenkin. Kerran tuli myös artefakteja ruutuun.

Vika ei ole välttämättä pelistä kiinni, kun Valheim sattuu olemaan ainut peli mitä on tullut pidempiä jaksoja pelattua. Toinen semi-aktiivinen peli Elden Ring on pyörinyt ongelmitta, mutta siinä ei ole ollut illan pituisia sessioita ja vastaavaa vertailukohtaa ei ole.

Näkeekö jostain lokia Windowsin Event Viewerin tyyliin tai mikä olisi paras tapa selvitellä ongelmaa? Tiedän kaivaneeni vähän verta nenstä, koska käytän bleeding edge distroa, ajan pelit Waylandilla ja näytönohjaimessakin on kevyet kellotukset. Valistunut arvaus on että ajuri kaatuu, mutta sille on varmaan joku hyvä juurisyy.. Google-hauilla ei löytynyt mitään yleisiä murheita Valheim ja Linuxin kanssa.

Edit: Näytönohjaimena AMD 6900 XT.

Kernelin logit saa dmesg komennolla. Koko järjestelmän logeja voi selata journalctl. Jälkimmäisen man sivu kannattaa lukea ajatuksella, helpottaa käyttöä kun osaa oikeat vipstaakit valita.

Jos löytyy toinen kone verkosta ja ko. koneessa on sshd käynnissä, niin ssh:lla pääsee käsiksi kunhan edes jotakin on hengissä. Joskus diagnosoinut outoja jäätymisiä joiden jälkeen ei edes yhteyttä saa ottamalla yhteyden jo ennen jäätymistä ja journalctl -f jolla seuraa tapahtumia jumimiseen asti.

Lisäksi jos persistent journal optio on päällä distrossa (tai itse laitettuna) niin edellisten boottien journalitkin pitäisi löytyä, esim. journalctl -b -1 -e siirtyy edellisen bootin loppuun.

Ei tuo nyt vielä kovin extremeä ole, varsinaista veren kaivamista nenästä olisi käyttää jotain point release distroa ja vieläpä jotakin "LTS" releasea millään nykyraudalla jolla yrittää pelatakin.

 

[Swede]

Tuota yhdistelmää en uskalla luvata, mutta sai tosiaan "lisää HDMI-kaistaa" ja 4k/120hz täysillä väreillä ainakin toimii. Korjataan kuitenkin hieman arvostelua sen verran, että männävuosien "näyttö ei herää sleepistä" ongelmaa on nyt tämän adapterin kanssa välillä esiintynyt. Herää sitten kun nykäsee piuhan koneesta irti ja takaisin. Aktiivikäytössä ei mitään ongelmia ja alkukäynnistyksessä toiminut jne.

Voin vahvistaa, että HDMI/Display Port adapterilla saa Linuxin toimimaan 8K/60 Hz asetuksilla. Taajuus on hieman pienempi kuin 60 Hz.

 

[love_doctor]

Voin vahvistaa, että HDMI/Display Port adapterilla saa Linuxin toimimaan 8K/60 Hz asetuksilla. Taajuus on hieman pienempi kuin 60 Hz.

Aika harvoin taajuus on tasan 60 Hz, jos on 60 Hz:n näyttö:

 

[Ezzy]

Nyt on kuukausi täynnä OpenSuse Tumbleweedin käyttämistä. Windowsin puolelle ei ole toistaiseksi tarvinnut palata. Nyt minulla on kuitenkin ollut ongelmia Valheimin kanssa, jossa noin puolentoista tunnin pelaamisen jälkeen ruutun jämähtää kuva ja kone on pakko sammuttaa kylmiltään. Äänet ja ohjelmat itsessään toimii kaatumisen jälkeenkin. Kerran tuli myös artefakteja ruutuun.

Vika ei ole välttämättä pelistä kiinni, kun Valheim sattuu olemaan ainut peli mitä on tullut pidempiä jaksoja pelattua. Toinen semi-aktiivinen peli Elden Ring on pyörinyt ongelmitta, mutta siinä ei ole ollut illan pituisia sessioita ja vastaavaa vertailukohtaa ei ole.

Näkeekö jostain lokia Windowsin Event Viewerin tyyliin tai mikä olisi paras tapa selvitellä ongelmaa? Tiedän kaivaneeni vähän verta nenstä, koska käytän bleeding edge distroa, ajan pelit Waylandilla ja näytönohjaimessakin on kevyet kellotukset. Valistunut arvaus on että ajuri kaatuu, mutta sille on varmaan joku hyvä juurisyy.. Google-hauilla ei löytynyt mitään yleisiä murheita Valheim ja Linuxin kanssa.

Edit: Näytönohjaimena AMD 6900 XT.

Protonin logeista voi ehkä kans kaivella jotain

PROTON_LOG=1 %command%

 

[Jaguafgeg]

Ketjussa on ollut keskustelua äänien pätkimisestä ja siitä on itselläkin oma kokemus, käytössä Focusrite Scarlett Solo 3rd Gen.

Äänien pätkiminen näkyi pw-top:lla tasaiseen tahtiin ERR luvun nousuna, ja se mikä tähän auttoi oli pavucontrol ohjelman pitäminen päällä ihan missä tahansa muulla virtuaalityöpöydällä, kunhan sen asetuksista on laitettu päälle "Show volume meters".
Mikä tämän sitten aiheutti ja miksi tämä auttaa, en tiedä, mutta ääni ei sen koommin pätki ja ERR luku pysyy nollassa.

 

[timppeli]

Ketjussa on ollut keskustelua äänien pätkimisestä ja siitä on itselläkin oma kokemus, käytössä Focusrite Scarlett Solo 3rd Gen.

Äänien pätkiminen näkyi pw-top:lla tasaiseen tahtiin ERR luvun nousuna, ja se mikä tähän auttoi oli pavucontrol ohjelman pitäminen päällä ihan missä tahansa muulla virtuaalityöpöydällä, kunhan sen asetuksista on laitettu päälle "Show volume meters".
Mikä tämän sitten aiheutti ja miksi tämä auttaa, en tiedä, mutta ääni ei sen koommin pätki ja ERR luku pysyy nollassa.

Kiits, mielenkiintoinen havainto, pitänee kokeilla. Asensin OpenSUSE:en jo pavucontrolin kun piti ratkoa miksi Team Fortress 2 meni välillä mutelle ilmeisen itsekseen. En kylläkään nyt löydä mitään "pavucontrol" koneelta mutta jos laitan sen hakuun start-kentässä, johdattaa se ihan Volume Controlliin josta kyllä voi säädellä eri juttujen volumeita, mikä käsittääkseni on pavucontrolin tarkoitus? Ainakin sieltä saan aina näppäistyä Team Fortress 2 muten pois päältä jos se on jostain oudosta syystä päälle mennyt.

Piti googlettaa mikä tuo Focusrite on, ilmeisesti jonkinlainen pieni vahvari?

 

[Barbarossa]

Piti googlettaa mikä tuo Focusrite on, ilmeisesti jonkinlainen pieni vahvari?

Focusrite tekee USB audio interfaceja, eli tarjoaa outputin lisäksi inputtia mm. Hi-Z laitteille (soittimille), haamuvirtaa vaativille kondensaattorimikeille ym. Ja jonkinlaista sisäistä mikseriä. Usein löytyy myös MIDI. Scarlett Solo on kevyemmästä päästä 2x2 input/output kanavillaan. Nämä alkaa siis olemaan niitä "ammattilaislaitteita" jotka on paskoja koska kiinalainen stereo-DAC toimii ongelmitta.

 

[timppeli]

Ketjussa on ollut keskustelua äänien pätkimisestä ja siitä on itselläkin oma kokemus, käytössä Focusrite Scarlett Solo 3rd Gen.

Äänien pätkiminen näkyi pw-top:lla tasaiseen tahtiin ERR luvun nousuna, ja se mikä tähän auttoi oli pavucontrol ohjelman pitäminen päällä ihan missä tahansa muulla virtuaalityöpöydällä, kunhan sen asetuksista on laitettu päälle "Show volume meters".
Mikä tämän sitten aiheutti ja miksi tämä auttaa, en tiedä, mutta ääni ei sen koommin pätki ja ERR luku pysyy nollassa.

Kun etsin "pavucontrol" OpenSUSE:ssa, se tarjoaa "Volume Control" joten otaksun että puhun samasta asiasta.
Tarkoitatko että avaan näytölle kyseisen ikkunan?
Pidin sitä päällä kun katsoin Youtubea, ääni alkoi silti säristä minuutin tai kahden kuluttua, eli ei tainnut auttaa minua.

 

[timppeli]

Jos käytössä on Pipewire (ja erityisesti jos myös Mint): https://forums.linuxmint.com/viewtopic.php?t=450701

Kaikki mahdolliset audiolaitteiden virransäästöt täytyy myös poistaa käytöstä. Linux on jostain syystä oletuksena aggressiivisempi niiden kanssa.

Nuo ohjeet olettivat että käyttäjän alla on tiedosto .config/pipewire/pipewire.conf jota muuttaa, mutta ei sellaista ole OpenSUSE:ssa joten tein, ja lisäsin sinne noissa ohjeissa mainitun rivin, ainoaksi riviksi.

Buuttasin koneen ja kaikki muuttui hitaaksi, sisäänloggautuminen kesti puolisen minuuttia ja työpöydän tuleminen toiset puoli minuuttia. Äänet eivät sen toimineet ja äänikonfiguraatio taisi sanoa jotain "Lost connection to audio server".

Vaihdoin pipewire.conf toisennimiseksi ja buuttasin koneen, ja nyt kone taas toimii "normaalisti".

No, nyt on nuokin ohjeet kokeiltu, tässä aiheutti vain lisäharmia. Onko joissain distroissa tuo pipewire.conf valmiiksi paikallaan vai tuo ohje vain oletti että käyttäjä on joskus aikaisemmin sellaisen sinne luonut? Joku template tuolle configille saattaa olla jonnekin piilotettu mutta ei ainakaan tuonne.

EDIT: Tarkistin että olen tuon ohjeen riviä:

default.clock.min-quantum = 1024

kyllä kokeillut tiedostossa /etc/pipewire/pipewire.conf (muistaakseni), mutta ei se sielläkään mitään auttanut. Sinne olin jostain kopioinut tuon conf-tiedoton templaten ennalta, en muista mistä.

 

[Pörkyle]

Nuo ohjeet olettivat että käyttäjän alla on tiedosto .config/pipewire/pipewire.conf jota muuttaa, mutta ei sellaista ole OpenSUSE:ssa joten tein, ja lisäsin sinne noissa ohjeissa mainitun rivin, ainoaksi riviksi.

Buuttasin koneen ja kaikki muuttui hitaaksi, sisäänloggautuminen kesti puolisen minuuttia ja työpöydän tuleminen toiset puoli minuuttia. Äänet eivät sen toimineet ja äänikonfiguraatio taisi sanoa jotain "Lost connection to audio server".

Vaihdoin pipewire.conf toisennimiseksi ja buuttasin koneen, ja nyt kone taas toimii "normaalisti".

No, nyt on nuokin ohjeet kokeiltu, tässä aiheutti vain lisäharmia. Onko joissain distroissa tuo pipewire.conf valmiiksi paikallaan vai tuo ohje vain oletti että käyttäjä on joskus aikaisemmin sellaisen sinne luonut? Joku template tuolle configille saattaa olla jonnekin piilotettu mutta ei ainakaan tuonne.

EDIT: Tarkistin että olen tuon ohjeen riviä:

default.clock.min-quantum = 1024

kyllä kokeillut tiedostossa /etc/pipewire/pipewire.conf (muistaakseni), mutta ei se sielläkään mitään auttanut. Sinne olin jostain kopioinut tuon conf-tiedoton templaten ennalta, en muista mistä.

oisko menny väärään paikka se conffin osa. ~/.config/pipewire/pipewire.conf.d/ taitaa olla oikea paikka conffin osille.

Config PipeWire · Wiki · PipeWire / pipewire · GitLab

Multimedia processing graphs

gitlab.freedesktop.org

edit. lisäys
~/.config/ on sitten käyttäjäkansiossa eli sitä tuskin on valmiiksi missään distrossa. Pipewire lukee conffit tuolta /usr/share/pipewire/ jos missään muualla ei ole conffeja

 

[Barbarossa]

Nuo ohjeet olettivat että käyttäjän alla on tiedosto .config/pipewire/pipewire.conf jota muuttaa, mutta ei sellaista ole OpenSUSE:ssa joten tein, ja lisäsin sinne noissa ohjeissa mainitun rivin, ainoaksi riviksi.

Ei mahda toimia noin. PipeWiren konffiformaatti ei ole paljaita rivejä vaan eräänlaisia JSON objekteja, ja saattaa lisäksi olla että pipewire.confin oletetaan sisältävän koko konfiguraation, osittaiset asetukset on tarkoitettu asetettavaksi drop-in fileissä.

Eli jos tuon yhden asetuksen haluaa käyttäjän konffeissa muuttaa niin pitää luoda drop-in hakemisto ~/.config/pipewire/pipewire.conf.d ja sinne tiedosto, esim. 10-default-min-quantum.conf johon sisällöksi:

context.properties = {
    default.clock.min-quantum  = 1024
}

 

[timppeli]

oisko menny väärään paikka se conffin osa. ~/.config/pipewire/pipewire.conf.d/ taitaa olla oikea paikka conffin osille.

Config PipeWire · Wiki · PipeWire / pipewire · GitLab

Multimedia processing graphs

gitlab.freedesktop.org

edit. lisäys
~/.config/ on sitten käyttäjäkansiossa eli sitä tuskin on valmiiksi missään distrossa. Pipewire lukee conffit tuolta /usr/share/pipewire/ jos missään muualla ei ole conffeja

Minun käsitykseni on, joka toki saattaa olla myös väärin:

/usr/share/pipewire/ alla ovat conffitiedostojen templatet. Niitä ei ilmeisesti lueta ollenkaan? Eli niihin muutosten tekeminen ei vaikuta mitään, vaan ne tulee kopioida sieltä jonnekin ja sitten muuttaa. Aiemmissa ohjeissa ilmeisesti oletettiin että käyttäjä on jo tehnyt näin ja nimenomaan vain käyttäjän kotihakemiston alle.

~/.config/pipewire/ alle jos haluaa niiden koskevan vain yhtä käyttäjää.

/etc/pipewire/ alle jos haluaa niiden olevan järjestelmätasoisia eli koskevan kaikkia käyttäjiä.

Noita ./pipewire.conf.d/ alihakemistoja käytetään jos haluaa jakaa conffitiedoston moneen osaan, ne eri conf-tiedostot sitten tuonne alihakemistoon eikä esim. /etc/pipewire/pipewire.conf

Joku voi kertoa jos meni jotain väärin.

 

[timppeli]

Ei mahda toimia noin. PipeWiren konffiformaatti ei ole paljaita rivejä vaan eräänlaisia JSON objekteja, ja saattaa lisäksi olla että pipewire.confin oletetaan sisältävän koko konfiguraation, osittaiset asetukset on tarkoitettu asetettavaksi drop-in fileissä.

Eli jos tuon yhden asetuksen haluaa käyttäjän konffeissa muuttaa niin pitää luoda drop-in hakemisto ~/.config/pipewire/pipewire.conf.d ja sinne tiedosto, esim. 10-default-min-quantum.conf johon sisällöksi:

context.properties = {
    default.clock.min-quantum  = 1024
}

Juu ok, ei ole tuttu millainen formaatti pitää olla.

Oletan että tarkoitus on kopioida /usr/share/ alta conf-tiedoston template jossa on ilmeisesti kaikki tarvittavat rivit (useimmat tai kaikki kommentoituna) vaikka sinne /etc/pipewire/ alle (jonka senkin joutuu ensin luomaan koska ei ko. alihakemistoa ole valmiina), ja sitten muokkaa sitä. Vai? Tämä steppi tuntuu puuttuvan melkein kaikista pipewiren konffausohjeista, oletetaan että conf-tiedosto on jo oikeassa paikassa paikallaan.

 

[Pörkyle]

Minun käsitykseni on, joka toki saattaa olla myös väärin:

/usr/share/pipewire/ alla ovat conffitiedostojen templatet. Niitä ei ilmeisesti lueta ollenkaan? Eli niihin muutosten tekeminen ei vaikuta mitään, vaan ne tulee kopioida sieltä jonnekin ja sitten muuttaa. Aiemmissa ohjeissa ilmeisesti oletettiin että käyttäjä on jo tehnyt näin ja nimenomaan vain käyttäjän kotihakemiston alle.

./config/pipewire/ alle jos haluaa niiden koskevan vain yhtä käyttäjää.

/etc/pipewire/ alle jos haluaa niiden olevan järjestelmätasoisia eli koskevan kaikkia käyttäjiä.

Noita ./pipewire.conf.d/ alihakemistoja käytetään jos haluaa jakaa conffitiedoston moneen osaan, ne eri conf-tiedostot sitten tuonne alihakemistoon eikä esim. /etc/pipewire/pipewire.conf

Joku voi kertoa jos meni jotain väärin.

Ainakin arch wikissa sanoo niin että oletus conffit luetaan /usr/share alta. Niitä ei yleensä muokata sen takia kun ne tiedostot korvataan aina päivityksessä eli omat muutokset sinne katoaa joka päivityksessä.

Toki jossain distrossa voi vaatia että se conffi on vähintään /etc/ sijainnissa tai palvelu ei toimi ollenkaan.

 

[Barbarossa]

Minun käsitykseni on, joka toki saattaa olla myös väärin:

/usr/share/pipewire/ alla ovat conffitiedostojen templatet. Niitä ei ilmeisesti lueta ollenkaan? Eli niihin muutosten tekeminen ei vaikuta mitään, vaan ne tulee kopioida sieltä jonnekin ja sitten muuttaa. Aiemmissa ohjeissa ilmeisesti oletettiin että käyttäjä on jo tehnyt näin ja nimenomaan vain käyttäjän kotihakemiston alle.

~/.config/pipewire/ alle jos haluaa niiden koskevan vain yhtä käyttäjää.

/etc/pipewire/ alle jos haluaa niiden olevan järjestelmätasoisia eli koskevan kaikkia käyttäjiä.

Noita ./pipewire.conf.d/ alihakemistoja käytetään jos haluaa jakaa conffitiedoston moneen osaan, ne eri conf-tiedostot sitten tuonne alihakemistoon eikä esim. /etc/pipewire/pipewire.conf

Joku voi kertoa jos meni jotain väärin.

Periaatteessa oikein, mutta /usr/share/pipewire alla on oletuskonfiguraatiot, yleensä suoraan PipeWirestä ja niitä ei ole käyttäjän tarkoituskaan muuttaa.

Sitten /etc/pipewire kuten tiesitkin järjestelmätason konfiguraatioille, usein distron paketoijat tekevät jonkinlaisen oletuskonfiguraation joka tulee tänne, mutta jota ei päivitysten yhteydessä enää ylikirjoiteta kyselemättä. Kuitenki PipeWiren tapauksessa ilmeisesti useat distrot menevät oletusarvoilla eivätkä paketoi mukaan tänne mitään. Tällöin tehdään juuri noin että kopioidaan /usr/share/pipewire alta oletuskonffi tarpeen mukaan joko /etc/pipewire tai ~/.config/pipewire alle ja muokataan.

Mutta yleisestiottaen, vaikka näin kuinka ohjeistetaan, ei välttämättä kannata jos tarkoitus on muokata yksittäisiä parametrejä, vaan tähän on parempi käyttää noita drop-inejä. Niiden perimmäinen tarkoitus varsinaisesti ei ole jakaa konffeja osiin, vaan ainoastaan asettaa joitakin arvoja eri tavalla kuin pipewire.confissa.

Eli jos muuten kelpaa oletukset ja haluaa pelkästään vaikka tuon default.clock.min-quantumin asettaa, niin ei ole juuri hyötyä korvata koko pipewire.confia kun voi tehdä sen drop-inillä täsmäiskuna.

Järjestys menee kutakuinkin näin:

1. Luetaan käyttäjäkohtainen $XDG_CONFIG_HOME/pipewire/pipewire.conf jos sellainen löytyy (eli se ~/.config/pipewire/pipewire.conf ellei distrossa olla menty määrittämään XDG_CONFIG_HOME eksoottisella tavalla)
2. Jos ylläolevaa ei ole, luetaan järjestelmätason /etc/pipewire/pipewire.conf
3. Jos ei sitäkään ole, niin oletuskonffi /usr/share/pipewire/pipewire.conf
4. Jos sitäkään ei ole, joko käytetään buildiaikaisia oletuksia tai kieltäydytään käynnistymästä, en jaksanut tarkistaa

Tämän jälkeen luetaan drop-in hakemistojen sisällöt järjestyksessä

1. Oletuskonffit /usr/share/pipewire/pipewire.conf.d/*
2. Järjestelmätason konffit /etc/pipewire/pipewire.conf.d/*
3. Käyttäjän konffit $XDG_CONFIG_HOME/pipewire/pipewire.conf.d/*

Drop-init toimivat niin että jos järjestyksessä myöhempänä olevasta hakemistosta luetaan samanniminen tiedosto, niin se ylikirjoittaa aiemmin luetun. Ja luetaan "luonnollisessa" järjestyksessä myös hakemistoittain, eli jos samassa hakemistossa on useampi tiedosto jossa muutetaan samaa parametriä, niin jälkimmäinen jää voimaan.

Lopuksi ylläkuvatulla tavalla luetut drop-in tiedostojen sisältö yhdistetään, ja niissä asetetut parametrit ylikirjoittavat ensimmäisessä vaiheessa luetussa pipewire.confissa määritellyt vastaavat parametrit.

Tulikin pitempi sepostus mitä meinasin, toivottavasti sain edes ilmaistua itseni selkeästi.

 

[timppeli]

Kiitos pipewire conffaus tarkennuksista.

Mutta yleisestiottaen, vaikka näin kuinka ohjeistetaan, ei välttämättä kannata jos tarkoitus on muokata yksittäisiä parametrejä, vaan tähän on parempi käyttää noita drop-inejä. Niiden perimmäinen tarkoitus varsinaisesti ei ole jakaa konffeja osiin, vaan ainoastaan asettaa joitakin arvoja eri tavalla kuin pipewire.confissa.

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.

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:

Config PipeWire · Wiki · PipeWire / pipewire · GitLab

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?

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

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?