[solved] Nur Buster: leises Brummen, selbt bei Stummschaltung

[ingo2]

Ich habe hier ein nevendes Problem mit Pulsaudio, und zwar nur unter Buster, nicht mit Stretch nor Jessie.

Beim Booten hört man bei allen Systemen einen recht leisen ca. 100Hz-Ton im Hintergrund, der verschwindet aber sobald ich auf der graphischen Oberfläche bin (Login mit lightdm, Desktop XFCE). Man hört deutlich den Moment, wenn der Brumm "abgeschaltet" wird.

Bei Buster bleibt der Brumm jedoch bestehen - selbst wenn ich in pavucontol den Line-Out Ausgang stummschalte und pavucontol geschlossen ist. Ein merkwürdiges Phänomen ist dabei:
Sobald in pavucontol der Mixer geöffnet ist, ist es totenstill (egal welcher Tab gerade den Fokus hat). Schließe ich pavucontol, bleibt es noch ca. 5 Sec. still, dann erscheint der Brumm wieder.

Merkwürdig und lästig, da das selbst bei Stummschaltung noch stört.

Haben das noch andere User beobachtet, oder gar eine Lösung?

Gruß, Ingo

[willy4711]

Mal in pavucontrol unter dem Reiter "Ausgabegeräte" mit dem Port gespielt ?

Da kann man diverses wählen von S/PDIF über Analog Stereo, Surround usw. das wirkt sich in der Regel ziemlich auf die Wiedergabe aus.

Edit:
Auch der Alsamixer kann der Übeltäter sein
Siehe unter MIXER:
https://wiki.ubuntuusers.de/Sound_Problembehebung/

[ingo2]

Mal in pavucontrol unter dem Reiter "Ausgabegeräte" mit dem Port gespielt ?

Da kann man diverses wählen von S/PDIF über Analog Stereo, Surround usw. das wirkt sich in der Regel ziemlich auf die Wiedergabe aus.

Da habe ich nur "Line-Ausgang" - mehr gibt's garnicht.
Und nicht vergessen:
Buster läuft auf der selben Hardware wie Jessie und Stretch (verschiedene Partitionen).
Und nochwas: Buster basiert auf einer Kopie des aktuellen Stretch, wurde nur auf Buster upgegradet.
Alle Einstellungen, auch ALSA-Mixer sind bei den Systemen gleich.

Auch der Alsamixer kann der Übeltäter sein
Siehe unter MIXER:
https://wiki.ubuntuusers.de/Sound_Problembehebung/

Tja, die tüfteln dort nur, weil sie keinen Sound haben - bei mir geht ja alles korrekt.

Ich hatte schon den Verdacht, daß eventuell die CPU einen anderen Scheduler nutzt oder Ähnliches womit die Belastung der Spannungswandler anders variiert oder das Umschalten zwischen den einzelnen CPU-Cores, was dann auf den Line-Out durchschägt 8Übersprechen)? Ich bekomme das Ding bei "Desktop idle" einfach nicht vollkommen stumm.

Mal sehen,vielleicht melden sich noch andere User.

[smutbert]

Eine Masseschleife kann sich schon sehr merkwürdig auswirken, möglicherweise wirklich in Verbindung mit einem anderen Scheduler, irgendeinem Stromsparmodus oä.
Ist das ein stationäres System (mit Verbindung zum Schutzleiter) oder vielleicht gar ein Notebook, bei dem es auch ohne Netzteil auftritt?
Hängt das System möglicherweise an einer geerdeten Stereoanlage, an geerdeten Aktivlautsprechern oder irgendeinem anderen geerdeten Gerät?
Viele oder zumindest einige Systeme/Gehäuse bringen mit der Verbindung zur Frontblende ihre eigene Masseschleife mit – gibt es einen solchen Anschluss zur Frontblende, den du testweise vom Mainboard abziehen kannst?

Auf der Softwareseite, könntest du einmal die Ausgabe von

Code: Alles auswählen

aplay -l

posten und in weiterer Folge die Mixerkonfiguration von mit und ohne Brummen vergleichen, indem du jeweils einmal ausführst

Code: Alles auswählen

amixer -D hw:Name_oder_Nummer_der_Soundkarte_in_Alsa

und gegebenenfalls die Ausgabe in eine Datei umleitest um sie in Ruhe vergleichen zu können.

Bei Pulseaudio wäre es vielleicht noch interessant ob zum Zeitpunkt des Brummens wirklich nichts über die Soundkarte ausgegeben wird. Wenn der Start von pavucontrol das ganze stört, dann versuch es vielleicht mit

Code: Alles auswählen

pactl list sink-inputs

(eventuell zuerst mit short hintendran um mit einer simplen, übersichtlichen Auflistung anzufangen)

[ingo2]

Auf der Softwareseite, könntest du einmal die Ausgabe von

Code: Alles auswählen

aplay -l

posten

Code: Alles auswählen

$ aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC892 Analog [ALC892 Analog]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 1: ALC892 Digital [ALC892 Digital]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

Auf der Softwareseite, könntest du einmal die Ausgabe von
und in weiterer Folge die Mixerkonfiguration von mit und ohne Brummen vergleichen, indem du jeweils einmal ausführst

Code: Alles auswählen

amixer -D hw:Name_oder_Nummer_der_Soundkarte_in_Alsa

und gegebenenfalls die Ausgabe in eine Datei umleitest um sie in Ruhe vergleichen zu können.

Code: Alles auswählen

$ diff buster.out stretch.out 
5c5
<   Mono: Playback 52 [81%] [-12.00dB] [on]
---
>   Mono: Playback 44 [69%] [-20.00dB] [on]

Bis auf das Bischen Pegel alles gleich.

Bei Pulseaudio wäre es vielleicht noch interessant ob zum Zeitpunkt des Brummens wirklich nichts über die Soundkarte ausgegeben wird. Wenn der Start von pavucontrol das ganze stört, dann versuch es vielleicht mit

Code: Alles auswählen

pactl list sink-inputs

Code: Alles auswählen

$ pactl list sink-inputs
      -/- (nix)

# pactl list sink-inputs
Verbindungsfehler: Verbindung verweigert
pa_context_new() fehlgeschlagen: Verbindung verweigert

Tja, da ist nichts zu finden.
Ich habe jetzt nochmal genau beobachtet:
das Brummen (ist sehr leise, aber es stört, wenn man es mal bemerkt hat) ist während des Bootvorgangs auf allen Systemen zu hören. Es verschgwindet bei Stretch in dem Moment, wenn der Bildschirm vom Text-Modus auf Graphik umschaltet, ca. 2 sec bevor lightdm den Login-Screen zeigt.

Könnte also auch die Graphik (Intel HD HD Graphics 4000 im Ivy-Bridge i5-3570K) sein?

Ingo

[smutbert]

Code: Alles auswählen

[...]
# pactl list sink-inputs
Verbindungsfehler: Verbindung verweigert
pa_context_new() fehlgeschlagen: Verbindung verweigert

Das ist normal, weil Pulseaudio unter dem Benutzeraccount Benutzer läuft und root so nicht ohne weiteres mit dieser Pulseaudio-Instanz interagieren kann.

Tja, da ist nichts zu finden.
Ich habe jetzt nochmal genau beobachtet:
das Brummen (ist sehr leise, aber es stört, wenn man es mal bemerkt hat) ist während des Bootvorgangs auf allen Systemen zu hören. Es verschgwindet bei Stretch in dem Moment, wenn der Bildschirm vom Text-Modus auf Graphik umschaltet, ca. 2 sec bevor lightdm den Login-Screen zeigt.

Könnte also auch die Graphik (Intel HD HD Graphics 4000 im Ivy-Bridge i5-3570K) sein?

Ich kenne einen Monitor, der in der nativen Auflösung sogar abhängig vom Bildinhalt etwas brummt, aber das kann es hier ja eher nicht sein.

Ein Zusammenhang scheint jedenfalls zu bestehen, auch wenn ich immer noch eher an eine Masseschleife denke, die sich dank irgendeiner Änderung bei der Software stärker bemerkbar macht. Es ist gar nicht so untypisch, dass sich dann die Grafik oder Mausbewegungen oder ähnliches akustisch bemerkbar machen.
Wenn du die Softwareseite des Problems weiter untersuchen willst (obwohl ich die nicht für die Ursache halte) könntest glatt testweise den alten stretch-Kernel in buster installieren und starten (wenn er problemlos mit buster zusammenspielt).

[willy4711]

Was passiert eigentlich, wenn du PulseAudio stoppst?

Code: Alles auswählen

pulseaudio -k

Brummt es weiter?
ich hab mal in der Startsequenz bei mir geforscht:

Code: Alles auswählen

journalctl -b |grep "pulse\|snd\|alsa" -C1
Jun 07 07:33:21 debianxfce kernel: sp5100-tco sp5100-tco: initialized. heartbeat=60 sec (nowayout=0)
Jun 07 07:33:21 debianxfce kernel: snd_hda_intel 0000:01:00.1: Disabling MSI
Jun 07 07:33:21 debianxfce kernel: snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client
Jun 07 07:33:21 debianxfce kernel: input: PC Speaker as /devices/platform/pcspkr/input/input10
--
Jun 07 07:33:22 debianxfce systemd[1]: Starting Save/Restore Sound Card State...
Jun 07 07:33:22 debianxfce alsactl[854]: alsactl 1.1.8 daemon started
Jun 07 07:33:22 debianxfce polkitd[846]: started daemon version 0.105 using authority implementation `local' version `0.105'
--
Jun 07 07:38:49 debianxfce systemd[8564]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Jun 07 07:38:49 debianxfce systemd[8564]: pulseaudio.socket: Succeeded.
Jun 07 07:38:49 debianxfce systemd[8564]: Closed Sound System.

Zwei Dinge Fallen mir auf:
Anscheinend macht Pulseaudio nach der Aktivierung erstmal "dicht", so interpretiere ich jedenfalls die letzte Zeile
Das ist 5 s nach Boot- Beginn und 8 s bevor das Booten beendet ist.
Aktiv bleibt es trotzdem:

Code: Alles auswählen

$ systemctl --user status pulseaudio.service
● pulseaudio.service - Sound Service
   Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor pr
   Active: active (running) since Fri 2019-06-07 07:33:26 CEST; 18min ago
 Main PID: 1157 (pulseaudio)
   CGroup: /user.slice/user-1000.slice/user@1000.service/pulseaudio.service
           └─1157 /usr/bin/pulseaudio --daemonize=no

Jun 07 07:33:24 debianxfce systemd[1028]: Starting Sound Service...
Jun 07 07:33:26 debianxfce systemd[1028]: Started Sound Service.

Jun 07 07:33:21 debianxfce kernel: input: PC Speaker as /devices/platform/pcspkr/input/input10

Kann der PC-Speaker eventuell eine Brummschleife produzieren (Systemklänge aktiviert) ?
Abschalten (probeweise) wird hier erklärt:
viewtopic.php?f=27&t=115949

[ingo2]

Fortschritte:

Habe jetzt mal willie's Tipp getestet:
In Stretch:

Code: Alles auswählen

$ systemctl --user status pulseaudio.service
● pulseaudio.service - Sound Service
   Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

In Buster:

Code: Alles auswählen

$ systemctl --user status pulseaudio.service
● pulseaudio.service - Sound Service
   Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor pr
   Active: active (running) since Fri 2019-06-07 10:40:43 CEST; 6min ago
 Main PID: 1099 (pulseaudio)
   CGroup: /user.slice/user-1000.slice/user@1000.service/pulseaudio.service
           └─1099 /usr/bin/pulseaudio --daemonize=no

und noch

Code: Alles auswählen

# pulseaudio -k
E: [pulseaudio] main.c: Hintergrundprozess konnte nicht abgebrochen werden: Kein passender Prozess gefunden

Schluß daraus:
in Buster läuft Pulseaudie garnich dauernd als Daemon, sondern wird nach den besagten 5-7 sec. gestoppt.
Habe mir daraufhin mal die geladenen Module angeschaut un dies gefunden:

Code: Alles auswählen

$ pactl list modules
Modul #13
	Name: module-suspend-on-idle
	Argument: 
	Nutzungszähler: k. A.
	Eigenschaften:
		module.author = "Lennart Poettering"
		module.description = "When a sink/source is idle for too long, suspend it"
		module.version = "12.2"

Aha, PA kann also nach einer Leerlaufzeit von x automatisch stoppen - und das ist der Verursacher:

Wenn der Brumm da ist, einfach

Code: Alles auswählen

$ pactl unload-module module-suspend-on-idle

und schon ist Ruhe!
Modul wieder laden

Code: Alles auswählen

$ pactl load-module module-suspend-on-idle

und nach 7 sec. brummt's wieder leise!

Fazit:
das mit "suspend-on-idle" hört sich zwar gut an, hinterläßt aber offenbar alle Inputs/Outputs in offenem (hochohmigen) Zustand und macht das System empfindlich gegen Störeinstrahlungen! Inputs sollten in so einem Fall doch wohl abgeschlossen|geerdet sein?

Mal sehen, es ist also auch eine Hardware-Sache wie smutbert vermutet, aber softwareseitig lösbar, bzw. nicht korrekt umgesetzt.

Danke Euch,
Ingo

[smutbert]

Also module-suspend-on-idle ist ja bestimmt nicht selbst die Ursache. Dieses Modul sorgt nur dafür, dass Pulseaudio ständig die Soundkarte offen/belegt hält, selbst wenn gar keine Anwendung etwas ausgeben will. Ich könnte mir mehrere Gründe vorstellen aus denen das Entladen dieses Moduls das Brummen beseitigt:

• du hast mit den „offenen Inputs/Outputs“ recht. Das halte ich für unwahrscheinlich und es würde wohl nicht erst mit Buster auftreten.
• Der Onboardsound geht bei geladenem Modul in einen Stromsparmodus und der verursacht direkt das Brummen. Dann müsste sich das Brummen mit der Moduloption power_save=0 des Moduls snd-hda-intel beheben
• Das Brummen wird durch Rechenlast, Prozessorschlafzustände uä in Verbindg mit einer Masseschleife verursacht und das Offenhalten der Soundkarte (dazu sendet Pulseaudio sozusagen ständig Stille an die Soundkarte) verhindert, dass es zu (hörbaren) Brummen oä kommt.
  Das Entladen bzw. Nichtladen von module-suspend-on-idle wäre dann nur ein Workaround. Die schöne Lösung wäre dann das Finden und Durchtrennen der Masseschleife. (Auf die Fragen zum System und was daran hängt (geerdet oder nicht) bist du noch gar nicht eingegangen.)

Ist es eigentlich wirklich nur Brummen oder hörst du auch gelegentlich andere Störgeräusche, zum Beispiel beim Starten oder Laufen irgendeines 3D-Programmes oder bei Mausbewegungen oder bei Kopieraktionen auf USB-Gerät oder irgend so etwas?

[ingo2]

Also module-suspend-on-idle ist ja bestimmt nicht selbst die Ursache. Dieses Modul sorgt nur dafür, dass Pulseaudio ständig die Soundkarte offen/belegt hält, selbst wenn gar keine Anwendung etwas ausgeben will.
[*]Der Onboardsound geht bei geladenem Modul in einen Stromsparmodus und der verursacht direkt das Brummen. Dann müsste sich das Brummen mit der Moduloption power_save=0 des Moduls snd-hda-intel beheben

Genau das ist der Fall, habe dafür jetzt eine /etc/modprobe.d/snd-hda-intel.conf angelegt - und Ruhe ist!

Noch zur Information:

• Das Brummen sind keine 50Hz, sind also keine direkten Netz-Einstrahlungen, ich schätze mal ca. 100Hz - meinen Oszillogaph packe ich dafür aber nicht aus . "Brummen" ist also eigentlich eine falsche Benennung. Außerdem sind Oberwellen drin, das hört man. Eine Masseschleife ist damit unwahrscheinlich, könnte jedoch von einem Brückengleichrichter stammen, so einer sitzt in meinem Billig-Stereo-Verstärker, der am Line-Out des PCs hängt.
• Eine Abhängigkeit von Rechnerlast, Maus oder sonst was konnte ich noch nicht beobachten. Frequenz und Lautstärke sind konstant.
• Das Brummen tritt schon beim Rechnerstart auf, also wenn Grub das Boot-Menu präsentiert, ist es schon hörbar - und zwar bei allen Systemen. Nur verschwindet es auf dem Dektop bei Stretch und Jessi und taucht auch während der ganzen Laufzeit nicht auf - das passiert erst unter Buster. Warum das so ist, ist mir ein Rätsel bei praktisch gleicher Software und Konfiguration.

Ich glaube, es hat wenig Sinn, da jetzt an der Hardware rumzuprobieren - was würde es denn letztlich bringen?
Hätte ich jetzt eine High-End Soundkarte und einen qualitativ hochwertigen Verstärker mit optischer Anbindung, wäre das sicher die Mühe wert. Also mit power_save=0 geht alles und ich werde das als Workaround nutzen.

Danke euch Beiden für die Hilfe,
Ingo

[halo44]

Wenn Du schon der englischsprachigen Welt mitteilst, daß das Problem "solved " ist, könntest Du auch das Thema ändern in "Only Buster: slight hum, even when muted".

Gruss H.

[ingo2]

@halo44: Ich versuche, in Postings, speziell im Titel, ohne deutsche Sonderzeichen auszukommen, deshalb kein "gelöst".

Das Ganze hatte übrigens noch einen guten Nebeneffekt:
In linphone hat in Buster vorher die Sprache bei ankommenden Anrufen für kurze Zeit gestottert bis die "Echo-Stornierung" sich eingependelt hatte. Das ist jetzt auch weg!

[smutbert]

Das Brummen sind keine 50Hz, sind also keine direkten Netz-Einstrahlungen, ich schätze mal ca. 100Hz - meinen Oszillogaph packe ich dafür aber nicht aus . "Brummen" ist also eigentlich eine falsche Benennung. Außerdem sind Oberwellen drin, das hört man. Eine Masseschleife ist damit unwahrscheinlich [...]

In dem Fall halte ich es wahrscheinlich, dass du recht hast, aber ganz allgemein hört man bei Masseschleifen von Quietschen bis Knistern alles mögliche nur kein Brummen (deswegen sag ich auch nie Brummschleife).

Das Brummen tritt schon beim Rechnerstart auf, also wenn Grub das Boot-Menu präsentiert, ist es schon hörbar - und zwar bei allen Systemen. Nur verschwindet es auf dem Dektop bei Stretch und Jessi und taucht auch während der ganzen Laufzeit nicht auf - das passiert erst unter Buster. [...]

Kann gut sein, dass unter Stretch und Jessie aus die Stromsparmodi vom Onboardsound aus irgendeinem Grund nie aktiviert wurden oder, dass der neuere Kernel einfach sparsamere Stromsparmodi nutzt. Es könnte meiner Meinung nach also in erster Linie entweder an einer Änderung von Pulseaudio oder des Kernels liegen.
Wenn du dem auf den Grund gehen willst, könntest du unter stretch einen neueren Kernel versuchen (vielleicht den aus den Backports?) oder unter buster einmal testweise den alten stretch-Kernel installieren und starten.

[ingo2]

Wenn du dem auf den Grund gehen willst, könntest du unter stretch einen neueren Kernel versuchen (vielleicht den aus den Backports?) oder unter buster einmal testweise den alten stretch-Kernel installieren und starten.

Es ging viel einfacher:
Habe unter Stretch die Moduloption

Code: Alles auswählen

options snd-hda-intel power_save=5

gesetzt - und siehe da
exakt das gleiche Verhalten wie unter Buster. Nach ca 7 sec. auf dem Desktop setzt auch hier das leise "Brummen" ein, verschwindet beim öffnen vom PA-Mixer und kommt mit Verögerung nach Schließen wieder!

Ist also eine Frage der Kernel-Konfiguration.
Bei Stretch

Code: Alles auswählen

cat /boot/config-4.9.0-9-amd64 | grep -i power_save
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0

Bei Buster

Code: Alles auswählen

cat /media/sda5/boot/config-4.19.0-5-amd64 | grep -i power_save
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1

und somit völlig logisch!
Hatte schon vorher daran gedacht und die Kernel-config nach dem String SND_HDA_INTEL duchsucht, aber nichts gefunden.

Na, ja, jetzt herrscht endlich volle Klarheit

P.S.: werde die Modul-Option auch gleich bei Stretch konfigurieren, dann ist's für das spätere Upgrade auf Buster bereits erledigt.