Currently the sounds we ship by default aren’t very modern, and I myself end up muting system sounds 100% of the time. However, I feel like we’re missing out. Platforms like Windows and macOS use sound to enhance the polish of their experience. With good sound design, I think we could make GNOME feel more professional.
I think two things could improve: the quality of our default sounds, and how we use sound. I’d be interested in hearing if others have thoughts about the status quo of sound in GNOME and how it could improve.
This email from 2008 is still the most cogent outline of how system sounds should work in GNOME, as opposed to the overengineering of the “sound theme” approach. I recommend starting from that.
What I really don’t understand is why we still have the bark theme. It is 2022. GNOME by default let’s you change your system bell to a barking dog. This is still a supported thing. And somehow it survived the last redesign of the sound panel. Can we start by removing the dog bark?
I certainly agree that we don’t need 125 different sounds, but I agree with @christopherdavis that it would be nice if we had a handful of nice sounds for common things like alarms. The current alarm sound is so loud and jarring that evolution recently added an option to disable it outright: https://gitlab.gnome.org/GNOME/evolution/-/issues/1032 .
That issue is actually emblematic of how sound design is complicated and should be part of the overall design of a component. It’s also a demonstration of how sound themes are bad.
The alarm notification can play random sounds attached to the alarm itself; that would allow users to define their custom sound, and choose a short one. The annoying, loud alarm sound you most likely hear is defined in the sound theme as “alarm-clock-elapsed”. The problem is that the default sound theme shipped by Linux distributions defines a 6 seconds sound file for that name, and given the complexity of designing a replacement soundscape, nobody has really done that.
On top of that, alarms should allow being cancelled or snoozed from the UI, and that should stop the sound; nothing of sort is allowed within the current constraints of evolution-alarm-notify. Theoretically, you can cancel a sound being played using libcanberra, but nobody really does it because the API is byzantine and predates a lot of the existing best practices for modern GNOME libraries.
So what we really want for an alarm is:
a centralised alarm registration and notification system
being able to define a sound for each alarm, possibly from a pool of well-defined sounds provided by the OS
bonus points for having extra sound sources that can be passed around between sandboxes
provide UI to cancel or snooze an alarm that is currently playing
possibly integrated with the Shell, as a notification with actions so the user can also cancel the alarm if the session is locked without having to unlock it first
have a sound API that can play sounds (in a loop) and has a clear way to cancel the current playback
As you can see, this is highly self-contained to a specific feature—alarms. We should identify the sources of sounds that are not a simple system/error bell, and try to design the user experience for each one of those independently, instead of trying to figure out a generic way to solve a class of problem, and then overengineer an approach that will inevitably fail.
One case I’ve used sound is my app Solanum. I have two different sounds: one for when the timer starts, and another when it hits zero. These two sounds are different from each other so that users can immediately tell the context of the notification by sound.
There is work happening at librem on feedbackd which seems somewhat related to this and also an event naming spec , I know, I know, the scope is wider(haptics and led’s, not just sound) but accessibility is a thing these days and so haptic feedback is probably a good thing to consider for things like alarms, messages, calls etc. There also seems to be a desire to have it live in freedesktop space at some point in the future from what I can tell.
I think this is a topic that should have a lot of engagement with the accessibility team. I don’t know if screen readers use their own sounds but sounds could greating improve the experience for visualing impaired people.
Regarding the email, I like the idea of having 4 main sounds in a way the shell controls it and the shell can notify the app the notification/sound has been cancelled, snoozed, or disabled.
Example: On Android I use Pepperplate and they have a custom sound when the alarm goes off. But there is no system notification. The only way to turn it off is to unlock the phone, to go into the app, and press the dismiss button. Most other apps us the notification system.