3

At random times throughout the day I hear a notification sound on Ubuntu.

After having checked the usual suspects (deactivated all notifications in Thunderbird, muted all the system sounds in the settings, etc.) I am running out of ideas which application is causing these sounds?

The sound is maybe 1-2 seconds long. So there is no way to start an application while the sound is playing. What would be the best way to log all sound outputs so that I can identify the application (and deactivate it)?

Edit:

Here is what I did so far to trace down the problem:

(1) Checking that it is an application using pulseaudio:

Using the helpful script from @terdon below I could confirm that the sound is played through pulseaudio

(2) Checking the application usage of pulseaudio

With this snippet

$ while true; do p1=$p2; p2=$(pactl list clients | grep application.name);      dwdiff -1 -3 -c <(echo "$p1") <(echo "$p2"); sleep 1; done |  tee sound.log

I was able to confirm that when the sound is played there is no additional application connecting to pulseaudio. So the sound has to be played by one of the applications already connected.

(3) Disabling the Notifactions one by one

The applications that are connected to pulseaudio are:

        application.name = "Login Session 1"
        application.name = "evolution-alarm-notify"
        application.name = "Mutter"
        application.name = "Terminal"
        application.name = "Thunderbird"
        application.name = "Thunderbird"
        application.name = "Zotero"
        application.name = "GNOME Shell Volume Control"
        application.name = "GNOME Volume Control Media Keys"
        application.name = "Firefox"
        application.name = "Firefox"
        application.name = "Firefox"
        application.name = "org.gnome.Nautilus"
        application.name = "pactl"

In the notification settings I disabled sound notifications for:

  • Firefox
  • Thunderbird
  • Zotero
  • File manager
  • Evolution Alarm Notify

Yet I still get the occasional sound - also weirdly enough without any visible notification or anything like that.

If someone has another idea how to trace down actual sound outputs this would be highly welcome.

Olf
  • 71

3 Answers3

3

The solution I found to monitor the actual sinks of pulseaudio is:

last=""; while true; do cur="$(pacmd list-sink-inputs)"; if ! [ "$cur" = "$last" ]; then last="$cur"; echo "$(date) $cur"; fi; sleep 1; done | tee sound-inputs.log

It turned out that the sound was due to the system recognizing an external drive at random times and then playing the sound /usr/share/sounds/Yaru/stereo/device-added.oga. As I did not found an elegant solution to disable the sound I just deleted the sound file.

Olf
  • 71
2

You can try monitoring the sound card. I am not sure if the /dev/snd stuff are relevant today, but there's no harm in including them. Try this (you can copy/paste it directly into a terminal):

( 
  lsof /dev/snd/* 2>/dev/null | 
    grep -v '^COMMAND' | 
      awk '{print $2}'
  pw-dump | grep -oP 'application.process.id": \K\d+'
) | 
  sort -u | 
   xargs -I{} ps -p {} -o cmd= |
     sort -u

This uses lsof /dev/snd/* and pw-dump to get a list of processes that are accessing the sound system. We then parse the output of the two commands in order to extract just a list of process IDs (PID) which is then piped to xargs and used to run ps -p $PID, setting the output to just the command name. These are then passed through sort -u, resulting in a list of names of those commands that are using the sound. For example, on my system, I get:

$ (    lsof /dev/snd/* 2>/dev/null |      grep -v '^COMMAND' |        awk '{print $2}';   pw-dump | grep -oP 'application.process.id": \K\d+'; ) |    sort -u |     xargs -I{} ps -p {} -o cmd= |      sort -u
cinnamon --replace
csd-media-keys
/home/terdon/.local/share/Steam/ubuntu12_32/steam
/opt/brave-bin/brave --type=utility --utility-sub-type=audio.mojom.AudioService --lang=en-US --service-sandbox-type=none --crashpad-handler-pid=794818 --enable-crash-reporter=, --change-stack-guard-on-fork=enable --shared-files=v8_context_snapshot_data:100 --field-trial-handle=0,i,2837077814463129096,8659860663691947099,262144
/opt/enpass/Enpass
/opt/spotify/spotify --uri
/usr/bin/pipewire
/usr/bin/pipewire-pulse
/usr/bin/wireplumber
/usr/lib/chromium/chromium --type=utility --utility-sub-type=audio.mojom.AudioService --lang=en-US --service-sandbox-type=none --crashpad-handler-pid=799438 --enable-crash-reporter=,Arch Linux --change-stack-guard-on-fork=enable --shared-files=v8_context_snapshot_data:100 --field-trial-handle=0,i,5619683321696231452,8577485665950155815,262144
/usr/lib/xdg-desktop-portal

You can make that a little script:

#!/bin/bash
( 
  lsof /dev/snd/* 2>/dev/null | 
    grep -v '^COMMAND' | 
      awk '{print $2}'
  pw-dump | grep -oP 'application.process.id": \K\d+'
) | 
  sort -u | 
   xargs -I{} ps -p {} -o cmd= |
     sort -u

Make it executable, and then run it in an infinite loop, passing through a second script that de-duplicates the output (foo.sh is the script):

while :; do foo.sh ; sleep 0.1; done | awk '++a[$1]==1'

The final awk ensures we only see each command name once. Leave this running for a while, monitor the output, and you might be able to find your culprit. You can also redirect the output to a file:

while :; do foo.sh ; sleep 0.1; done | awk '++a[$1]==1' > file

And then use tail -f file to monitor while still keeping a permanent record.

terdon
  • 104,119
2

I had this very same problem, but with a different cause. The sound I was trying to identify was:

  • Melodious, and playing frequently, but randomly, so I was sure it was an alert of some kind.
  • There were no "sound icons" appearing in browser tabs when the sound came.
  • There were no "bell icons" appearing in any notification tray when the sound came.

I had tried the actions suggested in the question itself, as well as the steps suggested by terdon's answer above. No joy.

My main clue came from Olf's accepted own answer, when I went to explore the contents of /usr/share/sounds/

$ ls -l /usr/share/sounds/Yaru/stereo/
total 760
-rw-r--r-- 1 root root   8078 Jun  9  2023 audio-volume-change.oga
-rw-r--r-- 1 root root  23389 Jun  9  2023 battery-low.oga
-rw-r--r-- 1 root root  15813 Jun  9  2023 bell.oga
-rw-r--r-- 1 root root  48977 Jun  9  2023 complete.oga
-rw-r--r-- 1 root root 159288 Jun  9  2023 desktop-login.oga
-rw-r--r-- 1 root root  73320 Jun  9  2023 desktop-logoff.oga
-rw-r--r-- 1 root root  21799 Jun  9  2023 device-added.oga
-rw-r--r-- 1 root root  20096 Jun  9  2023 device-removed.oga
-rw-r--r-- 1 root root  18476 Jun  9  2023 dialog-error.oga
-rw-r--r-- 1 root root  20936 Jun  9  2023 dialog-question.oga
-rw-r--r-- 1 root root  16992 Jun  9  2023 dialog-warning.oga
-rw-r--r-- 1 root root  19100 Jun  9  2023 message-new-email.oga
-rw-r--r-- 1 root root  20907 Jun  9  2023 message-new-instant.oga
-rw-r--r-- 1 root root  19100 Jun  9  2023 message.oga
-rw-r--r-- 1 root root  21799 Jun  9  2023 power-plug.oga
-rw-r--r-- 1 root root  20096 Jun  9  2023 power-unplug.oga
-rw-r--r-- 1 root root 159288 Jun  9  2023 system-ready.oga
-rw-r--r-- 1 root root  63914 Jun  9  2023 trash-empty.oga

My idea was to play each of these sounds one by one, except it was annoying for an entire media app to boot up, such as Rhythmbox, for each sound.

This article gave me the tool I needed: Vorbis.

sudo apt install vorbis-tools
ogg123 trash-empty.oga
ogg123 system-ready.oga
ogg123 power-unplug.oga
Etc, etc ....

Turns out I had a loose power cable, and it was detecting a power-unplug followed by an immediate power-plug event, over and over again, triggered by how I shifted my weight on or off the desk!

Stewart
  • 616