Linux-kysymyksiä & yleistä keskustelua Linuxista

[Viilee]

Tulkitsin avautumisen siten, että isot toimijat, joilla on paljon valtaa (/rahaa), kusee standardien päälle, jos siihen vain on jokin kannustin (vendor-lock-inin mahdollisuus, datan keräys tms.), ja saa valitettavan usein myös tahtonsa läpi.

Hiiristä puheenollen, ei ole vielä koskaan tullut vastaan hiirtä joka ei toimisi standardina HID-hiirenä. Melkeinpä niin päin, että kalliimmissa spesiaalihiirissä joissa on jos jonkinlaista hilavitkutinta ja erikoisominaisuutta, on osa ominaisuuksista saattanut olla jonkin erityisemmän, mutta kuitenkin jonkin kohtuullisen standardin, takana. Osa erikoisnapeista voi ollakin esim. näppäimistö Kernelin mielestä. RGB:kin on yleensä reverse-engineerattu ja saa toimimaan jollain harrasteiljoiden softalla; mutta perushiiirenä (tarkoittaa siis vähintään 5-, usein 7-nappinen osuus) toimii ihan standardiajureilla.

Toki on ihan uskottavaa, että halvimmista halvimmat tietokonehiiret (tai jotkin erät) on tehty jollain mahdollisimman halvalla saaduista ylijäämäosista, jotka ei sitten tuekaan mitään standardia, koska osat on aluperin mihinlie puoliksi suljettuun tarkoitukseen tehty. Siis tarkoitan, että uskon kyllä ylläolevan keskustelun, Deltacon hiiret ei toimi, mutta varmaankin poikkeus?

Noin ihan mielenkiinnosta ja ehkä jopa hyödyllisenä tietona, näkisin miten ko. hiiri näkyy lsusb:n listauksessa (erityisesti valmistajan ja osan id:t kiinnostaa, eli ne xxxx:yyyy -numerosarjat, varsinkin jos niitä on monta) ja mitä xev ja evtest sanoo.

EDIT: Linuxille ei todellakaan tarvitse ostaa kalliimpaa ja erityisen laadukasta hiirtä. Ongelmat näitten kanssa on todella harvinaisia.

 

[Barbarossa]

Pintapuolisesti yksinkertainen asia mutta koska kyseessä USB niin mikään ei olekaan enää yksioikoista jos kurkistaa syvemmälle. Aihe on melko monimutkainen eikä riitä aika tai motivaatio kovin syvällistä tekstiä kirjoittamaan, mutta raapaisen vähän pintaa:

USB HID Class speksin mukaiset hiiret ja näppikset pääsääntöisesti toimivat Linuxissakin ilman ylimääräisiä säätöjä, peliohjaimetkin mutta näiden tukeminen on paljolti pelistä kiinni. Toki täydellistä maailmaa ei olekaan ja kaskessa voi olla monta kantoa, tässä muutama toivottavasti havainnollistava esimerkki osin omien havaintojen pohjalta ja osin speksin rajoissa teoriaa.

Laitevalmistaja voi olla lähtenyt sooloilemaan ja tekee jotakin speksin ulkopuolista, ja vaatii ajurin joka kertoo käyttöjärjestelmälle että mitä se tekee. Yleensä ajuri on tarjolla ainoastaan Windowsille ja ellei valmistaja tiedä mitä tekee, voi olla turhauttava kokemus. Harvinaista näppisten ja hiirten kohdalla, mutta tämä on selkeä tapaus jos sellainen sattuu.

Yleisemmät tapaukset ovat kuitenkin hiukan hankalampia avata. USB HID (kuten useimmat USB luokat) luokka toimii siten että laite itse ilmoittaa isännälle (report descriptor) että mitä sen lähettämät reportit pitävät sisällään, esim. hiiren osoittimet, näppäinpainallukset, analogiohjainten asennot, ym. Ja on laitteen (valmistajan) vastuulla huolehtia että nuo descriptorit ovat järkeviä, ja että ne reportit vastaavat descriptoreita ja ovat myös kuranttia tavaraa. Kuten ylempänä jo sivuttiinkin, yksi fyysinen laite voi ilmoittaa useamman USB laitteen isännälle eikä se ole mahdotonta että vaikka jokin astetta monimutkaisempi peliohjain ilmoittaa olevansa hiiri, näppäimistö ja joystick yhtä aikaa,

Esimerkkinä hiiri. Oikea ja vasen nappi ovat aika lailla pienin yhteinen nimittäjä kaikille, nykyään myös rulla jonka painallus toimii myös keskinappina käytännössä aina. Mutta siitä eteenpäin ollaankin vähän ohuemmilla jäillä. Vaikkapa nykypäivänä ei mitenkään harvinainen hiiri, kolme nappia, rulla ja kaksi peukalonappia. Hiiri voi ilmoittaa yksinkertaisesti että nappeja on viisi, vastaanottajan päätettävissä mitä nelos ja vitosnappi tekee. Tai sitten ne lähettävätkin browser forward/backward näppäinkoodit.

Jos kiinnostaa ryömiä kaninkoloon niin kernelin dokkari Introduction to HID report descriptors — The Linux Kernel documentation lienee hyvä alkupiste.

 

[ylivoima]

Mikä open source vaihtoehtoa suosittelette officen korvaajaksi ubuntulle?

 

[IcePen]

Se mikä tulee Ubuntun matkassa..

 

[Katali]

Mikä open source vaihtoehtoa suosittelette officen korvaajaksi ubuntulle?

LibreOffice

 

[Ryzkis40]

Noin ihan mielenkiinnosta ja ehkä jopa hyödyllisenä tietona, näkisin miten ko. hiiri näkyy lsusb:n listauksessa (erityisesti valmistajan ja osan id:t kiinnostaa, eli ne xxxx:yyyy -numerosarjat, varsinkin jos niitä on monta) ja mitä xev ja evtest sanoo.

Lsusb näyttää

Bus 003 Device 002: ID 0603:0002 Novatek Microelectronics Corp. Sino Wealth keyboard/mouse 2.4 GHz receiver

xev ja evtest ei reagoi mitenkään kun painelen noita eteen/taakse-namiskoja. Muutoin tulee palautetta kaikilta muilta OK. Evtest näytti tällaista

/dev/input/event6: SINO WEALTH USB Composite Device
/dev/input/event7: SINO WEALTH USB Composite Device Mouse
/dev/input/event8: SINO WEALTH USB Composite Device System Control

Vauras on USB laite Hiiri siis Deltaco MS-776.

 

[SamCer]

Mulla on ongelmana, että en saa Rocky Linux 9.2:sta poistettua salasanalla kirjautumista ssh:lla.

# cat /etc/ssh/sshd_config

Spoileri

#    $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# To modify the system-wide sshd configuration, create a  *.conf  file under
#  /etc/ssh/sshd_config.d/  which will be automatically included below
Include /etc/ssh/sshd_config.d/*.conf

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile    .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#KbdInteractiveAuthentication yes
KbdInteractiveAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in RHEL and may cause several
# problems.
#UsePAM no
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server

# cat /etc/ssh/sshd_config.d/04-ipa.conf

Spoileri

# IPA-related configuration changes to sshd_config

PubkeyAuthentication yes
##Lisätty Yubikey autentikointia varten
PubkeyAuthOptions verify-required
KerberosAuthentication no
GSSAPIAuthentication yes
UsePAM yes
ChallengeResponseAuthentication yes
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Mistä se vielä voi vielä sen kaivaa vielä luvan sille? Ubuntu 22.04 servuissa on toi sama /etc/ssh/sshd_config.d/04-ipa.conf -tiedosto, eikä ne päästä passulla sisään, ainoastaan noi Rockyt ei suostu tottelemaan. Niin joo ja muita conffeja ei tuolla /etc/ssh/sshd_config.d -hakemistossa ole.

Sain tämän viimeinkin ratkaistua, se kun levisi myös Ubuntu Servuihini. Eli ongelmana oli se, että autentikointitavoissa näkyi järkähtämättä "KbdInteractiveAuthentication", vaikka se oli nimenomaan estetty conffeissa, jolloin pääsi kirjautumaan sisään passulla, vaikka sekin oli konffeissa estetty.

Se mikä tuon "KbdInteractiveAuthentication" pakotti päälle on "ChallengeResponseAuthentication yes", sen kun vaihtoi asentoon "ChallengeResponseAuthentication no", niin samalla katosi toi "KbdInteractiveAuthentication" sallituista autentikointi metodeista. PAM:illa ei ollut mitään tekemistä asian kanssa.

 

[jkaart]

Mikäs juttu tuossa Ubuntu 24.04:ssa ja ilmeisesti(?) Pipewiressä ilman Pulseaudiota oikeen on, kun ääni kuulostaa ihan siltä kuin se tulisi vanhalta vinyyliltä? Sellasia ihme rusahuksia jatkuvasti. Heti kun asenti Pulse audion niin ongelmat korjaantu.
Edit: vitut se mitään korjannu.

 

[lors lara]

Github on muuttunut archived ja read only tilaan ihan hiljattain.

"Neofetch is a CLI system information tool written in BASH. Neofetch
displays information about your system next to an image, your OS logo,
or any ascii file of your choice. "

 

[vaalea limppu]

Lainaan Linux distrokeskustelu -langasta viestin:

Tähän saakka nVidialla on myös koko työpöydän virkistystaajuus sidottu siihen, missä ohjelmassa on matalin virkistystaajuus. Jos joku X11 (Xwayland) CAD softa pyörii 15 fps, silloin koko työpöytä on lukittu 15 Hz, koska nVidian binääriajuri ei tue lainkaan Implicit synciä. Explicit syncin jälkeen tämä(kin) on vihdoin kunnossa Waylandilla.

Linux-aloittelijana kokeilin kuukausi sitten eri distroja, enkä saanut työpöytää yli 60 hz virkistystaajuudelle, vaikka nvidian ajurin onnistuin asentamaan.

Keskustelut tuntuvat pyörivän pelien ympärillä, mutta itselle olisi merkittävämpää saada työpöydälle 144 hz. Ei tarvitse olla edes variable refresh rate. 60 hz tuntuu lagiselta ja tökkivältä, tosin Gnome saattoi muutenkin tuntua hitaalta.

Onko varmin ratkaisu vaihtaa AMD:n näyttikseen? Raudan vaihtaminen on helppoa, kun taas käyttöjärjestelmän kanssa kikkailu tökkii, kun oma ideaali on pidättäytyä pitkälti vanilla-ratkaisussa ja asentaa mahdollisimman vähän mitään.

edit. Tai olisiko peräti Intel Arc -näyttis vielä parempi?

 

[JiiPee]

Onko varmin ratkaisu vaihtaa AMD:n näyttikseen? Raudan vaihtaminen on helppoa, kun taas käyttöjärjestelmän kanssa kikkailu tökkii, kun oma ideaali on pidättäytyä pitkälti vanilla-ratkaisussa ja asentaa mahdollisimman vähän mitään.

AMD:n näyttisajurit on pitkälti kernelissä suoraan eli mitään binaari ajureita ei AMD:n puolella tartte asennella

 

[VoNpo]

Lainaan Linux distrokeskustelu -langasta viestin:


Linux-aloittelijana kokeilin kuukausi sitten eri distroja, enkä saanut työpöytää yli 60 hz virkistystaajuudelle, vaikka nvidian ajurin onnistuin asentamaan.

Keskustelut tuntuvat pyörivän pelien ympärillä, mutta itselle olisi merkittävämpää saada työpöydälle 144 hz. Ei tarvitse olla edes variable refresh rate. 60 hz tuntuu lagiselta ja tökkivältä, tosin Gnome saattoi muutenkin tuntua hitaalta.

Onko varmin ratkaisu vaihtaa AMD:n näyttikseen? Raudan vaihtaminen on helppoa, kun taas käyttöjärjestelmän kanssa kikkailu tökkii, kun oma ideaali on pidättäytyä pitkälti vanilla-ratkaisussa ja asentaa mahdollisimman vähän mitään.

edit. Tai olisiko peräti Intel Arc -näyttis vielä parempi?

Sellainen huomio AMD korteista, että 4K@120hz ei toimi 4:4:4 chromalla, mikäli käytössä HDMI.
HDMI 2.1 sisältää suljettua koodia, joten ei toimi täysin AMD:n open source ajureilla.

 

[Barbarossa]

Sellainen huomio AMD korteista, että 4K@120hz ei toimi 4:4:4 chromalla, mikäli käytössä HDMI.
HDMI 2.1 sisältää suljettua koodia, joten ei toimi täysin AMD:n open source ajureilla.

Ja taustalla on täysin HDMI forumin kusipäisyys*. Onneksi DisplayPort > HDMI muutenkin.

* HDMI Forum Rejects Open-Source HDMI 2.1 Driver Support Sought By AMD - Phoronix

 

[VoNpo]

Ja taustalla on täysin HDMI forumin kusipäisyys*. Onneksi DisplayPort > HDMI muutenkin.

* HDMI Forum Rejects Open-Source HDMI 2.1 Driver Support Sought By AMD - Phoronix

Juurikin näin.
Ongelma koskettaa lähinnä TV:n käyttämistä näyttönä, joista harvemmin löytyy DP portteja. Oma lehmä ojassa LG C2:n kanssa...
PC puolen ruuduista taitaa olla hankala löytää +60Hz näyttöjä ilman DP porttia, ainakaan uudemmista.

 

[TemeV]

Mikäs juttu tuossa Ubuntu 24.04:ssa ja ilmeisesti(?) Pipewiressä ilman Pulseaudiota oikeen on, kun ääni kuulostaa ihan siltä kuin se tulisi vanhalta vinyyliltä? Sellasia ihme rusahuksia jatkuvasti. Heti kun asenti Pulse audion niin ongelmat korjaantu.
Edit: vitut se mitään korjannu.

Mulla pätki äänet kuorman alla Pipewirellä. Tuolla jotain ohjeita asiaan liittyen: PipeWire - Debian Wiki

Käytännössä tein tiedoston ~/.config/pipewire/pipewire.conf.d/10-choppy-under-load.conf
ja mulla se toimi tällaisella conffilla.

context.properties = {

    default.clock.min-quantum = 1024
    default.clock.quantum = 1024

    default.clock.max-quantum   = 4096
}

 

[jkaart]

Mulla pätki äänet kuorman alla Pipewirellä. Tuolla jotain ohjeita asiaan liittyen: PipeWire - Debian Wiki

Käytännössä tein tiedoston ~/.config/pipewire/pipewire.conf.d/10-choppy-under-load.conf
ja mulla se toimi tällaisella conffilla.

context.properties = {

    default.clock.min-quantum = 1024
    default.clock.quantum = 1024

    default.clock.max-quantum   = 4096
}

Varsin erikoinen onglema, kun eilen keskiviikkona ei ollu audiossa mitään ongelmaa, mutta tiistaina rätisi ja poksu ihan jatkuvasti. Minusta ihan sama oliko muuta kuormitusta vai pelkkä selain ja siinä youtube auki niin audio oli ihan hirvee. Testasin myös säätää noita qauntum asetuksia mutta ei niillä ollu mitään vaikutusta oikeastaan ellei kaikkia kolmea arvoa arvolle 32 jolloin äänestä tuli kovin robottimainen.
Hyvin mystinen ongelma joka korjaantui nähtävästi itsestään.
Edit: niin ja se ei tosiaan ole varsinaista pätkimistä vaan juurikin äänet kuulostaa siltä kuin tulisi joltain vinyylilevyltä soitettuna.

 

[jak_pdgm]

Sellainen huomio AMD korteista, että 4K@120hz ei toimi 4:4:4 chromalla, mikäli käytössä HDMI.
HDMI 2.1 sisältää suljettua koodia, joten ei toimi täysin AMD:n open source ajureilla.

Oho. Tuo koskee ilmeisesti omaa setuppiani, kun käytän ryzenin gpu:ta ja hdmi -> dp muunninta, koska emolevyssä ei ole dp-liitintä eikä näyttö huoli 4k@60hz kuvaa hdmi:n kautta.

En ole kylläkään huomannut mitään, mutta musta teksti valkoisella pohjalla näyttänee ihan samalta pakattunakin.

 

[Juha Kokkonen]

Tämä ketju on ajan myötä muotoitunut pienten Linux-kysymysten ohella myös yleiseksi Linux-keskusteluketjuksi, joten muokattu otsikkoa kuvaamaan paremmin ketjun tarkoitusta.

 

[Viilee]

Edit: niin ja se ei tosiaan ole varsinaista pätkimistä vaan juurikin äänet kuulostaa siltä kuin tulisi joltain vinyylilevyltä soitettuna.

Vinyylilevyssä on tosi hyvä soundi!!!! (jos on levyt ja laitteet kunnossa )

Vakavissaan, oliko toi siis jatkuvaa ritinää vai oliko myös tajuusvasteessa / volyymissä jotain vikaa, vähän tyyliin niin kuin olis RIAA-korjan rikki tms.?

Jos pelkkää rätinää, niin jokin puskurijuttuihan tuo on. Joko puskurin koko laitettu liian tiukille tai sitten ketjussa / äänistackissä joku osa bugittaa ja muodostaa pullonkaulan / ei välitä dataa riittävän nopeasti.

Tosiaan aika omituinen juttu. Itse olen lähinnä Linux-puolella törmännyt tilanteeseen, että on pitänyt säätää puskureita yleensä pienemmälle, jos on pitänyt saada latenssit oikeasti pieniksi. Oletusasetukset tuppaa olemaan konservatiivisia, jotta äänet toimii jokaikisellä perunakoneella oikein ilman isompia pätkimisiä (mutta PulseAudion ja Pipewiren myötä oletuksiakin on pienennetty).

 

[jkaart]

Vinyylilevyssä on tosi hyvä soundi!!!! (jos on levyt ja laitteet kunnossa )

Vakavissaan, oliko toi siis jatkuvaa ritinää vai oliko myös tajuusvasteessa / volyymissä jotain vikaa, vähän tyyliin niin kuin olis RIAA-korjan rikki tms.?

Jos pelkkää rätinää, niin jokin puskurijuttuihan tuo on. Joko puskurin koko laitettu liian tiukille tai sitten ketjussa / äänistackissä joku osa bugittaa ja muodostaa pullonkaulan / ei välitä dataa riittävän nopeasti.

Tosiaan aika omituinen juttu. Itse olen lähinnä Linux-puolella törmännyt tilanteeseen, että on pitänyt säätää puskureita yleensä pienemmälle, jos on pitänyt saada latenssit oikeasti pieniksi. Oletusasetukset tuppaa olemaan konservatiivisia, jotta äänet toimii jokaikisellä perunakoneella oikein ilman isompia pätkimisiä (mutta PulseAudion ja Pipewiren myötä oletuksiakin on pienennetty).

Tämä vinyyli on niitä pykälää huonompia kunnolta ei siis mitään mint kuntoista!
Juurikin sellaista ei täysin jatkuvaa ritinää mutta ritinää kuitenkin (tai ritinää jossa on taukoja jopa minuutteja välissä). Eilen ei tosiaan ollu ongelmaa, mutta tänään taas on ollu. Jotain tekemistä tuolla pipewirellä (ja uusimmalla Ubuntu 24.04 matella) on asian suhteen, kun ei ikinä aikasemmin oo ollu äänien kanssa mitään ongelmia. Tosin aikasemmin on ollu pulseaudiota tai alsaa käytössä pelkästään.
Miltä kuulostaa rikkinäinen RIAA-korjain?

 

[Ryzkis40]

EDIT: Linuxille ei todellakaan tarvitse ostaa kalliimpaa ja erityisen laadukasta hiirtä. Ongelmat näitten kanssa on todella harvinaisia.

Sattuipa kyllä lotto kohdalle kun tuossa vakkari-Deltacon hiiressä ei toimi eteen/taakse-napit mutta kun kaivoin kaapin periltä parit langattomat ebayn törkeen halvat kiinanhiiret niin toimi kaikki napit. Onnistuin siis Suomesta ostamaan vielä kiinalaisempaa laatua kuin suoraan Kiinasta. Ainut huono noissa ebay-hiirissä vaan että imevät patterit kolminkertaisella vauhdilla.

 

[Viilee]

Miltä kuulostaa rikkinäinen RIAA-korjain?

Itse asiassa kovin montaa rikkinäistä RIAA-korjainta ei ole tullut kuunneltua ;-). Mutta vinyylisoitin (jossa ei ole sisäänrakennettua RIAA:ta) on tullut monta kertaa laitettua line-in:iin.

RIAA voisi mennä rikki monella tapaa (harvoin menee). Voisi olla, että rikkinänen RIAA, kuulostaa vähän samalta kuin levari yhistettynä line inputtiin; eli äänessä on täysin pielessä oleva taajuusvaste tavalla tai toisella, esim. kuuluu pahvilaatikosta, tinapurkista tms.; pointti siis, että se ei lisää ritinöitä. Lähinnä koetin saada tarkempaa kuvausta, mistä vois ehkä päätellä, mikä on tossa Linuxin äänijärjstelmässä/ajurissa/stackissa on rikki.

Spoileri: OFFTOPIC / RIAA

RIAA-korjainhan tekee käänteisen (RIAA-)muunnoksen taajuusvasteeseen, mikä ääneen on tehty ennen kuin se on kaiverrettu vinyylilevylle. Sillä ei (varsinasesti) ole mitään tekemistä ritinän kanssa, vaan bassot korostetaan ja koko äänen (jännite-)tasoa nostetaan vähän, jotta se voidaan laittaa eteenpäin tavalliselle vahvistimelle (eri asetukset MC- MM-rasioille ja kiteille yms., mutta ei niitä muuntyyppisiä rasioita ole ollut kuin low-end vehkeissä 70-luvulla ja sitä ennen; MM on yleisin ja "tavallinen", jos RIAA-korjaimessa ei ole asetusta tai erikseen mainintaa niin se on MM-rasialle. 2000-luvun jälkeisissä low-end vinyylisoittimissa RIAA-korjain on usein sisäänrakennettu, ja sen tietää siitä että levarin voi yhistää tavallisen vahvistimen line-inputtiin suoraan).

Paitsi, noh, olihan itse asiassa yksi syy RIAA-muunnokselle oli siinä, että pölystä, naarmuista ja prässäysvirheistä johtuvat ritinät on enimmäkseen korkeilla taajuuksilla. Kun tehdään kaiverros suhteellisesti korostamalla korkeita taajuuksia, vaimenee myös ritinät, kun tehdään käänteinen muutos RIAA-korjaimella. Savilevyt ja muut äänitteet, joita tehtiin enne RIAA-järjestelmää (ja vastaavia), rätisivät huomattavasti enemmän. Isompi syy muunokselle on se, että levylle ei ole mahdollista kaivertaa bassotaajuuksia ilman sitä. Jotakuinkin realistiselta kuulostavan äänilevyn tekeminen on mahdotonta ilman RIAA-muunnosta.

RIAA equalization - Wikipedia

en.wikipedia.org

 

[jkaart]

Ajuri ongelmalta toi ei vaikuta, koska usb-liitäntäisillä kuulokkeilla kuuluu myös tota ritinää ja niillä se on vielä voimakkaampaa, joka johtunee varmaan tausta melun vaimenemisesta.
Jotta helvetin hienosti toimii tämä uusi ja hieno pipewire
Toisaalta ihan hyvä kun eivät menneet tota xorgia korvaamaan waylandilla Ubuntu matessa vielä, tiiä mitä ongelmia siitäkin ois syntyny.

 

[kaakau<"'\\/>]

Mullakin oli jotain ongelmaa Pipewirellä. Aina kun äänen soitto loppui, niin kuului raksahdus. Ongelma loppui, kun heitin Pipewiren veks. Kai senkin olisi saanut jotenkin korjattua, mutta ei mitään hajua miten, ja miksi tuhlata aikaa. Mäkään en ala kokeilemaan Waylandia samasta syystä. Jos KDE nyt sitä edes tuki kunnolla vielä.

 

[lors lara]

psmem ohjelma linuxille on tosi näppäri sillä sillä näkee tarkkaan paljon RAMmia menee mihinkin ohjelmaan
htop ei välttämättä näytä yhtä tarkkoja lukuja

 

[Barbarossa]

Aina kun äänen soitto loppui, niin kuului raksahdus.

Melkoisen suurella todennäköisyydellä ongelma on äänilaitteessa joka mennessään virransäästötilaan synnyttää äänen. Korjaantunee joko estämällä laitteen powersave tai ottamalla PW:n suspend ko. sinkille pois käytöstä.

 

[lors lara]

Mullakin oli jotain ongelmaa Pipewirellä. Aina kun äänen soitto loppui, niin kuului raksahdus. Ongelma loppui, kun heitin Pipewiren veks. Kai senkin olisi saanut jotenkin korjattua, mutta ei mitään hajua miten, ja miksi tuhlata aikaa. Mäkään en ala kokeilemaan Waylandia samasta syystä. Jos KDE nyt sitä edes tuki kunnolla vielä.

Melkoisen suurella todennäköisyydellä ongelma on äänilaitteessa joka mennessään virransäästötilaan synnyttää äänen. Korjaantunee joko estämällä laitteen powersave tai ottamalla PW:n suspend ko. sinkille pois käytöstä.

jos kyseessä on usb laite ja oli kuulokkeet tms. suoraan kiinni usb äänikortin 3.5mm plug liititmessä niin kuulokkeistahan sen raksahduksen kuulee ja pipewire jotenkin katkaisee virrat usb:hen kun se on hetken aikaa käyttämättä
jos on aktiivikajarit kytkettynä usb laitteeseen samalla tavalla, ei todennäköisesti tota edes huomaa

 

[Cor3]

psmem ohjelma linuxille on tosi näppäri sillä sillä näkee tarkkaan paljon RAMmia menee mihinkin ohjelmaan
htop ei välttämättä näytä yhtä tarkkoja lukuja

Itse Linux / BSD puolella tykännyt myös:

btop

ja

bashtop

noita ennen myös

glances

tullut vastaan.

 

[Viilee]

Melkoisen suurella todennäköisyydellä ongelma on äänilaitteessa joka mennessään virransäästötilaan synnyttää äänen. Korjaantunee joko estämällä laitteen powersave tai ottamalla PW:n suspend ko. sinkille pois käytöstä.

Tämä on just se ongelma. En tähän hätään muista, miten ton sai korjattua, mutta löytyi kohtuu helposti googlettamalla oikea kohta asetustiedostoista. Kts. linkit lopussa.

Tällä ongelmalla ei ole mitään tekemistä Pipewiren kanssa, vaan sama ongelma tulee myös Pulseaudion kanssa, jos se on asetettu siten että se laittaa äänilaitteet virransäästötilaan (minulla nimenomaan oli tämä ongelma Pulseaudiolla). Distribuution oletusasetuksilla on hyvinkin paljon asian kanssa tekemistä, ja nyt vain on niin että aiemmalla postaajalla distribuutio (ilmeisesti) Pulseaudiolla oletuksena ei käytä em. virransäästöä, kun taas Pipewirellä käyttää.

EDIT: Asetus kannattaa ehkä jopa pitää päällä läppäreillä, vaikka aiheuttaisi poksumista, mutta ehkä säätää aikaa pidemmäksi, jos voi (ainakin PipeWirellä voi, Pulseaudiolla ei?). Pöytäkoneilla tuskin on tällä virransäästöllä mitään väliä, jatkuva poksuminen aina esim. äänimerkkiä ennen ja sen jälkeen sen sijaan on hyvin rasittavaa.

EDIT: Mahdollisesti näistä linkeistä apua - mutta kannattaa tarkistaa oma distribuution dokumentaatio, voi olla että homma toimii kuten Archissa tai sitten enemmän tai vähemmän erillä tapaa: PulseAudio/Troubleshooting - ArchWiki ja PipeWire - ArchWiki

 

[kaakau<"'\\/>]

jos kyseessä on usb laite ja oli kuulokkeet tms. suoraan kiinni usb äänikortin 3.5mm plug liititmessä niin kuulokkeistahan sen raksahduksen kuulee ja pipewire jotenkin katkaisee virrat usb:hen kun se on hetken aikaa käyttämättä
jos on aktiivikajarit kytkettynä usb laitteeseen samalla tavalla, ei todennäköisesti tota edes huomaa

Stereot emolle 3,5-liittimeen. Ei USB:tä.

 

[lors lara]

Stereot emolle 3,5-liittimeen. Ei USB:tä.

okei, sitten en ole varma onko kyse samasta ongelmasta, mutta ainakin usb laitteiden kanssa se teki niin

 

[kaakau<"'\\/>]

Tämä on just se ongelma. En tähän hätään muista, miten ton sai korjattua, mutta löytyi kohtuu helposti googlettamalla oikea kohta asetustiedostoista. Kts. linkit lopussa.

Tällä ongelmalla ei ole mitään tekemistä Pipewiren kanssa, vaan sama ongelma tulee myös Pulseaudion kanssa, jos se on asetettu siten että se laittaa äänilaitteet virransäästötilaan (minulla nimenomaan oli tämä ongelma Pulseaudiolla). Distribuution oletusasetuksilla on hyvinkin paljon asian kanssa tekemistä, ja nyt vain on niin että aiemmalla postaajalla distribuutio (ilmeisesti) Pulseaudiolla oletuksena ei käytä em. virransäästöä, kun taas Pipewirellä käyttää.

EDIT: Asetus kannattaa ehkä jopa pitää päällä läppäreillä, vaikka aiheuttaisi poksumista, mutta ehkä säätää aikaa pidemmäksi, jos voi (ainakin PipeWirellä voi, Pulseaudiolla ei?). Pöytäkoneilla tuskin on tällä virransäästöllä mitään väliä, jatkuva poksuminen aina esim. äänimerkkiä ennen ja sen jälkeen sen sijaan on hyvin rasittavaa.

EDIT: Mahdollisesti näistä linkeistä apua - mutta kannattaa tarkistaa oma distribuution dokumentaatio, voi olla että homma toimii kuten Archissa tai sitten enemmän tai vähemmän erillä tapaa: PulseAudio/Troubleshooting - ArchWiki ja PipeWire - ArchWiki

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.

 

[meridian]

Päätinpä sitten eilen illalla päivittää Debianin komennoilla apt update ja apt full-upgrade.

Alkuun vaikutti toimivan hyvin ja versioksi muuttui uusin 12.5, mutta sitten tapahtui jotain mystistä. Kun yritin normaalisti päivittää apt upgradella, niin tuhatkunta pakettia jäi "odottamaan päivitystä".

Noh, kone toimi normaalisti, joten jatkoin puuhastelua ja lopulta sammutin koneen. Kun seuraavan kerran yritin käynnistää, tuli eteen vain musta ruutu. Ilmeisesti joku/jotkut näistä paketeista olisi ollut tarpeen päivittää vaikka väkisin... Ei auttaneet mitkään näppäinkomennot, että olisi päässyt pelkälle komentoriville ilman graafista käyttöliittymää.

Kertaalleen sain bootattua grubin kautta valitsemalla vanhan kernelin, mutta kun siellä sit päivittelin systeemiä, lakkasi sekin toimimasta...

Sain kuitenkin oleelliset tiedostot talteen toiselle osiolle, joten kikkailun välttämiseksi vedin sileäksi koko käyttöjärjestelmäosion ja asensin tikulta uuden version. Nyt toimii taas.

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

 

[Barbarossa]

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.

Suspendin disabloimiseen löytyy pari eri tapaa PipeWire FAQista Troubleshooting · Wiki · PipeWire / pipewire · GitLab ja WirePlumberille lyhyt opas Disable Pipewire Suspend on Idle to avoid audio pops, delays, and white noise

 

[SamCer]

Päätinpä sitten eilen illalla päivittää Debianin komennoilla apt update ja apt full-upgrade.

Alkuun vaikutti toimivan hyvin ja versioksi muuttui uusin 12.5, mutta sitten tapahtui jotain mystistä. Kun yritin normaalisti päivittää apt upgradella, niin tuhatkunta pakettia jäi "odottamaan päivitystä".

Noh, kone toimi normaalisti, joten jatkoin puuhastelua ja lopulta sammutin koneen. Kun seuraavan kerran yritin käynnistää, tuli eteen vain musta ruutu. Ilmeisesti joku/jotkut näistä paketeista olisi ollut tarpeen päivittää vaikka väkisin... Ei auttaneet mitkään näppäinkomennot, että olisi päässyt pelkälle komentoriville ilman graafista käyttöliittymää.

Kertaalleen sain bootattua grubin kautta valitsemalla vanhan kernelin, mutta kun siellä sit päivittelin systeemiä, lakkasi sekin toimimasta...

Sain kuitenkin oleelliset tiedostot talteen toiselle osiolle, joten kikkailun välttämiseksi vedin sileäksi koko käyttöjärjestelmäosion ja asensin tikulta uuden version. Nyt toimii taas.

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

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.

[edit] Toi on tosin vain arvailua näillä tiedoilla. Pitäis saada enemmän dataa tapahtuneesta logien kautta. Toi, et jätetään päivityksiä odottamaan, johtuu ainakin Ubuntulla siitä, että kyseiseinen päivitys, kyseisellä käyttisversiolla on johtanyt ongelmiin X-prosentilla päivityksen asentajista, jonka vuoksi sen jakelu on keskeytetty kyseiselle käyttisversiolle.

Toi tuhatkunta on kyllä niin julmeton määrä, et kyse ei taida olla tuosta...

 

[jkaart]

Semmonen huomio, että noi ritinät ja poksahdukset ei tallennu Pipewire FAQ:ssa neuvottuun audio data dumpiin. Koneella kuunellessa tietenkin kuuluu noita (ja joka kerta eri kohassa), mutta kun tuo siirti puhelimeen ja sillä kuunteli niin äänessä ei ollu mitään ylimäärästä häiriötä.
Edit: niin eikä niitä kuulu samaisen Ubuntun asenustikulta löytyvästä puhtaasta asennuksesta.

 

[JiiPee]

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

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.

 

[Cor3]

Päätinpä sitten eilen illalla päivittää Debianin komennoilla apt update ja apt full-upgrade.

Alkuun vaikutti toimivan hyvin ja versioksi muuttui uusin 12.5, mutta sitten tapahtui jotain mystistä. Kun yritin normaalisti päivittää apt upgradella, niin tuhatkunta pakettia jäi "odottamaan päivitystä".

Noh, kone toimi normaalisti, joten jatkoin puuhastelua ja lopulta sammutin koneen. Kun seuraavan kerran yritin käynnistää, tuli eteen vain musta ruutu. Ilmeisesti joku/jotkut näistä paketeista olisi ollut tarpeen päivittää vaikka väkisin... Ei auttaneet mitkään näppäinkomennot, että olisi päässyt pelkälle komentoriville ilman graafista käyttöliittymää.

Kertaalleen sain bootattua grubin kautta valitsemalla vanhan kernelin, mutta kun siellä sit päivittelin systeemiä, lakkasi sekin toimimasta...

Sain kuitenkin oleelliset tiedostot talteen toiselle osiolle, joten kikkailun välttämiseksi vedin sileäksi koko käyttöjärjestelmäosion ja asensin tikulta uuden version. Nyt toimii taas.

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

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.

 

[Lammas]

Mistä johtuu, että Ubuntu 24.04:ssä "dmesg --ctime" näyttää kellonaikoja, jotka on noin 11,5 tuntia edellä verrattuna oikeaan aikaan (jonka mm. "date" näyttää)?

Joskus kauan sitten dmesg:n näyttämät kellonajat oli ihan pielessä, mutta se johtui ilmeisesti siitä, että se kello pysähtyi aina kun koneen laittoi lepotilaan tms., mutta tuo bugi korjattin jo aikoja sitten ja esim. Ubuntu 20.04:ssä ajat oli aina oikein.

 

[jkaart]

Mistä johtuu, että Ubuntu 24.04:ssä "dmesg --ctime" näyttää kellonaikoja, jotka on noin 11,5 tuntia edellä verrattuna oikeaan aikaan (jonka mm. "date" näyttää)?

Joskus kauan sitten dmesg:n näyttämät kellonajat oli ihan pielessä, mutta se johtui ilmeisesti siitä, että se kello pysähtyi aina kun koneen laittoi lepotilaan tms., mutta tuo bugi korjattin jo aikoja sitten ja esim. Ubuntu 20.04:ssä ajat oli aina oikein.

Kyllä tuo mulla ainakin näyttää ihan oikeata aikaa.

 

[jkaart]

Taisi löytyä viimein ratkasu tohon ääni ongelmaan ja näyttäs ratkeavan nostamalla pipewiren prosessin prioritettia.
Mutta kysymys kuuluu, miten tämän saa pysyvästi korkeammalle prioriteetille?
Kun esim. system monitorista tai vaikka topissa tota saa käsin muutettua kyllä, mutta miten ton sais pysyvästi isommalle, että ei tarviis joka buutissa ruuvata tota?

 

[Hyrava]

Taisi löytyä viimein ratkasu tohon ääni ongelmaan ja näyttäs ratkeavan nostamalla pipewiren prosessin prioritettia.
Mutta kysymys kuuluu, miten tämän saa pysyvästi korkeammalle prioriteetille?
Kun esim. system monitorista tai vaikka topissa tota saa käsin muutettua kyllä, mutta miten ton sais pysyvästi isommalle, että ei tarviis joka buutissa ruuvata tota?

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.

Ilmeisesti pipewiren konffissa on joku "nice.level" -parametri jolla tuota voisi säätää mutta itsellä ei ole kokemusta.

 

[Barbarossa]

Taisi löytyä viimein ratkasu tohon ääni ongelmaan ja näyttäs ratkeavan nostamalla pipewiren prosessin prioritettia.
Mutta kysymys kuuluu, miten tämän saa pysyvästi korkeammalle prioriteetille?
Kun esim. system monitorista tai vaikka topissa tota saa käsin muutettua kyllä, mutta miten ton sais pysyvästi isommalle, että ei tarviis joka buutissa ruuvata tota?

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.

Kannattaa kurkistaa onko pipewiren paketissa mukana /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.

Esim Fedorasta pipewire-paketista löytyy /etc/security/limits.d/25-pw-rlimits.conf jossa:

@pipewire   - rtprio  70
@pipewire   - nice    -19
@pipewire   - memlock 4194304

 

[jkaart]

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.

 

[Barbarossa]

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.

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ä?

Jotakin vinkkiä voisi saada myös jos vertaa esim. 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.


Hämärä flashback tuli miten vuosia sitten painiskelin vastaavan ongelman kanssa, satunnaisesti äänentoistossa oli epämääräisiä napsumisia ilman että mikään ilmiselvä olisi muuttunut välissä. Parin spirtismisession jälkeen hoksasin että äänilaitteen sample rate oli eri tapausten välillä.

Ongelman ilmetessä oli käynnissä useampi ääntä tuottava softa (en muista mitkä), ja riippuen missä järjestyksessä softat avasivat streamin ongelma joko tuli tai ei tullut. Toiston sample rate asetettiin ensimmäisen streamin mukaan, jos softa X oli ekana, niin sample rateksi tuli 48kHz ja toisen softan toisto poksui. Jos softa Y kerkesi ensin, sample rate oli 44.1kHz ja äänet toimivat täydellisesti.

En muista enää löytyikö tähän oikeakin ratkaisu vai päädyinkö johonkin workaroundiin, mutta ei tuota ole tapahtunutkaan vuosikausiin. Saattoi jopa olla kun vielä käytin PulseAudiota, joten ei välttämättä edes liity juuri sinun ongelmaasi.

 

[Ryzkis40]

Mint Cinnamonin jälkeen kokeilin Matea ja mikäs sen tehtäväpalkkia mahtaa vaivata kun välillä ei voi klikata toista tehtäväpalkissa auki olevaa ikkunaa/ohjelmaa esille, vaan se alkaa vilkuttamaan sillä hetkellä esillä olevaa ikkunaa/ohjelmaa tehtäväpalkissa. Kun klikkaan sitä niin se esillä oleva ikkuna minimoituu ja vasta sen jälkeen voin klikkailla muita luukkuja tehtäväpalkissa. Tilanne missä tämän saa varmasti ainakin itsellä aina toistettua on pitää ohjelma A esillä ja klikata starttivalikko auki, minkä jälkeen en voi sen jälkeen suoraan klikata ohjelmaa B tehtäväpalkissa esille vaan pitää klikata ohjelmaa A ensin jolloin se minimoituu. Hivenen kankealta ja epäloogiselta tuntuu.

Edit: Jahas, nähtävästi johtui Window managerin vaihdosta oletuksen Marco + compositing -> Marco + compton minkä yksi tuninkisivu neuvoi vaihtamaan. Typerä tuunausneuvo kun huonontaa käytettävyyttä.

 

[Marquette]

Mikähän on vika? Kone on vanha 4770K ja siinä Debian (uusin, päivitetty) ja Virtualbox ja siellä Windows 11, missä ajoin sitä Microsoftin virustorjunnan full scannia. Sain kolme kertaa koneen buuttaamaan hallitsemattomasti, eli jotenkin rasitukseen tämä

.. tämä jo ratkesi

 

[SamCer]

Mikähän on vika? Kone on vanha 4770K ja siinä Debian (uusin, päivitetty) ja Virtualbox ja siellä Windows 11, missä ajoin sitä Microsoftin virustorjunnan full scannia. Sain kolme kertaa koneen buuttaamaan hallitsemattomasti, eli jotenkin rasitukseen tämä

.. tämä jo ratkesi

Mikä se ratkaisu oli?

 

[jkaart]

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ä?

Jotakin vinkkiä voisi saada myös jos vertaa esim. 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.


Hämärä flashback tuli miten vuosia sitten painiskelin vastaavan ongelman kanssa, satunnaisesti äänentoistossa oli epämääräisiä napsumisia ilman että mikään ilmiselvä olisi muuttunut välissä. Parin spirtismisession jälkeen hoksasin että äänilaitteen sample rate oli eri tapausten välillä.

Ongelman ilmetessä oli käynnissä useampi ääntä tuottava softa (en muista mitkä), ja riippuen missä järjestyksessä softat avasivat streamin ongelma joko tuli tai ei tullut. Toiston sample rate asetettiin ensimmäisen streamin mukaan, jos softa X oli ekana, niin sample rateksi tuli 48kHz ja toisen softan toisto poksui. Jos softa Y kerkesi ensin, sample rate oli 44.1kHz ja äänet toimivat täydellisesti.

En muista enää löytyikö tähän oikeakin ratkaisu vai päädyinkö johonkin workaroundiin, mutta ei tuota ole tapahtunutkaan vuosikausiin. Saattoi jopa olla kun vielä käytin PulseAudiota, joten ei välttämättä edes liity juuri sinun ongelmaasi.

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...

 

[Marquette]

Mikä se ratkaisu oli?

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".