Kernel downgrade wegen sound problem

hi,

ich benutze seit gestern opensuse tumbleweed und bin soweit sehr zufrieden! allerdings habe ich ein kleines problem, bei dem ich einen zusammenhang zum aktuellen kernel vermute. gelegentlich habe ich einen kleinen sound hiccup, wann und wie oft das passiert lässt sich schwer nachvollziehen. nicht sehr oft, 1-2 mal am tag ca. es ist jedoch subjektiv leider sehr störend.

ich habe vorher eine weile endeavourOS ausprobiert, wo das selbe problem auftrat! beides sind ja rolling releases mit einem ziemlich aktuellen kernel und beim recherchieren habe ich einige posts gefunden, in denen ein ähnliches problem beschrieben wird.

vor endeavourOS habe ich monate lang MX linux genutzt, dort ist dieses problem über die gesamte zeit nicht ein mal aufgetreten. deshalb vermute ich einen zusammenhang mit dem linux kernel. die installierte software war bei allen distros die selbe und da ist eigentlich nichts allzu außergewöhnliches dabei, das das problem verursachen könnte. abgesehen von software aus den offiziellen repos nutze ich nur autokey und 2 AppImages: electronIM und simplenote.

ansonsten sollte ich vielleicht noch erwähnen, dass ich unter MX linux ext4 verwendet habe. bei endeavour OS und tumbleweed habe ich stattdessen btrfs genommen. da könnte also theoretisch auch das problem liegen, das glaube ich zwar nicht aber vielleicht kann mich da jemand eines besseren belehren!

über hilfe wäre ich sehr dankbar :smile:

ich habe zwar schon recherchiert, allerdings habe ich mit wechsel von kernels gar keine erfahrung und würde ungern direkt mein system zerschießen!

Wird nun Pulseaudio oder Pipewire unter openSUSE Tumbleweed eingesetzt?

Falls Pulseaudio:
Das standardmässig mit normalen Benutzerrechten laufende Pulseaudio muss als Echtzeitanwendung ausgeführt werden.

# ps -o ni -o pri $(pidof pulseaudio)
 NI PRI
-11  30

Dazu muss Polkit (früher: PolicyKit) korrekt konfiguriert sein. Wie Polkit korrekt konfiguriert wird, damit Pulseaudio mit Realtime-Priorität gestartet wird, habe ich unter:

ausführlich beschrieben (=> Zweizeilige Anpassung von /etc/polkit-default-privs.local).

Generell sollten noch die Hinweise unter:

zu “USB-Soundkarten” beachtet werden.

pidof pulseaudio gibt nichts zurück, pidof pipewire hingegen schon. die pakete pipewire und pipewire-pulseaudio sind beide installiert. wenn ich das richtig verstanden habe verwende ich also pipewire.

zu dem hinweis bezüglich einer usb-soundkarte: ich habe aktuell leider keine alternative. der laptop hat nur begrenzt ports und ich habe einiges an geräten. davon abgesehen funktionierte das, so wie ich es aktuell angeschlossen habe, monate lang problemlos sowohl in windows als auch in MX linux. ich nutze unter windows ableton und spiele über die soundkarte auch gitarre ein, nie gab es probleme. deshalb finde ich es sehr naheliegend, dasss es sich um ein software problem handelt.

wie sieht es denn aus mit kernel wechseln unter tumbleweed, das sollte doch möglich sein? bei manjaro gab es dafür sogar eine GUI. ich würde es gerne einfach mal testen, um zu wissen ob es daran liegt.

ansonsten bin ich natürlich offen für weitere vorschläge. ich habe hier noch einen bluetooth audioempfänger, den ich direkt an die anlage anschließen könnte. den werde ich jetzt erstmal benutzen und schauen, ob das problem weiterhin auftritt.

Wie man ein Downgrade von einem installierten Softwarepaket (RPM) durchführt, wurde unter:

beschrieben.

Der Linux-Kernel sollte sich auch bei openSUSE TumbleWeed im RPM “kernel-default” befinden. Zur Kernellieferung gehören auch einige Firmware-Softwarepakete. Auszug von SUSE Linux Enterprise Desktop 15 SP4, was openSUSE Leap 15.4 entspricht:

# rpm -qa |grep -i kernel
kernel-firmware-ath11k-20220509-150400.4.13.1.noarch
kernel-firmware-network-20220509-150400.4.13.1.noarch
kernel-firmware-bnx2-20220509-150400.4.13.1.noarch
kernel-firmware-platform-20220509-150400.4.13.1.noarch
kernel-firmware-liquidio-20220509-150400.4.13.1.noarch
kernel-firmware-sound-20220509-150400.4.13.1.noarch
kernel-firmware-mediatek-20220509-150400.4.13.1.noarch
kernel-firmware-usb-network-20220509-150400.4.13.1.noarch
kernel-firmware-brcm-20220509-150400.4.13.1.noarch
kernel-firmware-media-20220509-150400.4.13.1.noarch
kernel-firmware-prestera-20220509-150400.4.13.1.noarch
kernel-firmware-ueagle-20220509-150400.4.13.1.noarch
kernel-default-5.14.21-150400.24.38.1.x86_64
kernel-firmware-ath10k-20220509-150400.4.13.1.noarch
kernel-firmware-i915-20220509-150400.4.13.1.noarch
kernel-firmware-mwifiex-20220509-150400.4.13.1.noarch
kernel-firmware-radeon-20220509-150400.4.13.1.noarch
kernel-firmware-amdgpu-20220509-150400.4.13.1.noarch
kernel-firmware-dpaa2-20220509-150400.4.13.1.noarch
kernel-firmware-mellanox-20220509-150400.4.13.1.noarch
kernel-firmware-qlogic-20220509-150400.4.13.1.noarch
kernel-firmware-atheros-20220509-150400.4.13.1.noarch
kernel-firmware-serial-20220509-150400.4.13.1.noarch
kernel-firmware-iwlwifi-20220509-150400.4.13.1.noarch
kernel-firmware-nfp-20220509-150400.4.13.1.noarch
kernel-firmware-intel-20220509-150400.4.13.1.noarch
kernel-firmware-realtek-20220509-150400.4.13.1.noarch
kernel-firmware-marvell-20220509-150400.4.13.1.noarch
kernel-firmware-ti-20220509-150400.4.13.1.noarch
kernel-firmware-bluetooth-20220509-150400.4.13.1.noarch
kernel-firmware-nvidia-20220509-150400.4.13.1.noarch
purge-kernels-service-0-8.3.1.noarch
kernel-firmware-chelsio-20220509-150400.4.13.1.noarch
kernel-firmware-qcom-20220509-150400.4.13.1.noarch
kernel-firmware-all-20220509-150400.4.13.1.noarch
kernel-default-5.14.21-150400.24.33.2.x86_64

Es können mehrere Versionen des Linux-Kernels gleichzeitig installiert sein:

# rpm -qa |grep -i kernel-default
kernel-default-5.14.21-150400.24.38.1.x86_64
kernel-default-5.14.21-150400.24.33.2.x86_64

Siehe dazu openSUSE - Referenzhandbuch, Kapitel “6 - Installing multiple kernel versions”.

Im Notfall kann im Bootmanager (GRUB 2) eine ältere, bereits vorinstallierte Linux-Kernelversion ausgewählt und direkt gestartet werden.

Aus Sicherheitsgründen ist in jeder Linuxdistribution entweder die aktuellste und gepflegte LTS-Version (“longterm”) vom offiziellen Linux-Kernel zu verwenden:

https://www.kernel.org/category/releases.html

https://www.kernel.org/

Oder man verwendet einen sogenannten “Frankenstein-Kernel” von SUSE, Debian, Canonical (Ubuntu) oder RedHat. Auch beim Einsatz von einem “Frankenstein-Kernel” ist darauf zu achten, dass man stets die aktuellste, gepflegte Version des “Frankenstein-Kernels” einsetzt.
https://www.heise.de/hintergrund/Linux-Kernel-Security-Linux-Distributionen-fixen-manche-Kernel-Luecken-nicht-6146364.html

Wer auf der Webseite:

stichprobenartige Kontrollen durchführt, ob der “Frankenstein-Kernel” auch wirklich alle erforderlichen Sicherheitsupdates erhalten hat. Wird feststellen müssen, dass einzig SUSE alle bekannten und mit CVE-Nummer versehenen Sicherheitslücken zeitnah mit Sicherheitsupdates in ihrem “Frankenstein-Kernel” schliesst. SUSE veröffentlicht im Durchschnitt alle 2 Wochen eine neue Version von ihrem “Frankenstein-Kernel”. Von SUSE in das Softwarepaket “kernel-default” eingeflossene Sicherheitsupdates (patches) sind mit dem Befehl:

# rpm -q --changelog kernel-default |grep -i cve

einsehbar.

Wieder ein Beitrag von GrandDixence2 der schlicht und ergreifend vor Linkspamming, Unwissen, Lügen und Wortkreationen strotzt.

Das ist eine dreiste Lüge und nicht belegbar, da jede Linux Distribution ihre Kernelversion auf den aktuellen Stand patcht.

Eine offizielle (und zuverlässige) Bescheibung wie man unter Tumbleweed einen älteren Kernel installiert ist hier zu finden:
https://opensuse.github.io/openSUSE-docs-revamped-temp/updating_upgrading_reverting/

danke für deine anregungen. das ist gerade…etwas viel!

der hinweis mit usb soundkarte über den hub war eventuell hilfreich. ich habe meine anlage seit 2 tagen über den hdmi audio ausgang des monitors mit dem laptop verbunden, bisher trat das sound problem noch nicht auf. allerdings habe ich unter der woche auch wenig zeit, am wochenende wird sich zeigen ob das problem tatsächlich damit zusammenhängt.

ehh ok. ich bin komplett neu im forum, weiss von nichts und werde deshalb nichts dazu sagen

danke für den link! ich habe die hoffnung, dass das mit dem kernel vielleicht gar nicht mehr notwendig sein wird. ich teste jetzt erstmal in ruhe ohne usb-soundkarte und schaue, ob das problem trotzdem auftritt.


eure persönlichen einschätzungen würden mich schon interessieren. die usb-soundkarte über den usb hub zu betreiben war bisher kein problem und das mit dem kernel ist auch eher eine aus der not geborene vermutung meinerseits.

okay, das problem ist eben gerade wieder aufgetreten. es liegt also defitiniv nicht an der usb-soundkarte bzw. dass sie über einen usb-hub angeschlossen ist!