KMix is KDE’s forgotten redheaded stepchild.
Humble beginnings
It is old, has been maintained my Christian Esken since early 2001, and has grown organically. Through no fault of Christian’s or anyone else’s, it is buggy, messy, and nobody else wants to help fix it, or at least has the constitution to do so.
Us redheads need to stick together.
At last year’s Randa, I started working on refactoring and rebuilding KMix from the ground up. Why should adjusting the volume in your desktop be so frustrating? It shouldn’t, thats why.
KMix is back with a new edition~
That is the prototype for the new KMix. The UI design has been shamelessly stolen from pavucontrol:
pavucontrol
As you can see, there is much work left to do. However, I feel that it is ready for others to hack on and test. This restructuring of KMix contains a *lot* of the original KMix code that has been contributed to over the years by over 142(!) people. The biggest committers have been Christian Esken (601), Colin Guthrie (130), and Laurent Montel (123). Mad props to those people and everyone else involved for their work and dedication.
When I started out on this endeavor, I aimed to fix a number of issues I had encountered before:
- Sometimes at startup, your volume would be all kinds of broken since the KDED module, Tray application, and a session startup script would all sometimes try to restore the volumes and sometimes it just wouldn’t.
- The GUI was completely rebuilt with every device change. Back in the early days of KMix, hot-pluggable audio devices wasn’t a major use case so it wasn’t included in the design.
- Since there is no one process that controls all the volume everywhere, that means lots and lots of backend libraries and their respective data structures loaded into many processes, such as plasma, the tray application, the KDED module, the tiny script at startup that restores your volumes.
- All these different points of control had to make sure they didn’t step on each others toes all the time.
- To control the volume over dbus, the tray application had to be running. There was no dbus autolaunch, and why would you want a GUI application to automatically launch and do weird things when you just want a small script to turn down your volume between the hours of 3 am and 6 am?
- pavucontrol had neat VU meters
- I’m just kinda okay at UI and UX design for end-users.
In response, I’ve come up with the following design:
- There exists a unique daemon on the session bus at org.kde.kmixd, which is managed via dbus autolaunch
- This unique daemon supports multiple backends being loaded at once, such as ALSA and PulseAudio (note: currently requires commenting out an if statement)
- Clients don’t need to worry about learning the oddities of ALSA or PulseAudio control since all interaction happens over the bus in a backend-agnostic manner. You are given a set of controls (such as your internal audio output, or the output of chrome’s flash plugin), a set of control groups (Output Devices, Recording Streams, etc), and a single interface to adjusting the master volume (which is whatever the user configures).
- Thanks to dbus autolaunch, you don’t have a daemon running in the background until the very instant during your session that volume control is needed. This helps to decrease startup time and overall resource usage.
- The UI is decoupled from the volume control itself, so others can easily create much better looking UIs in QML, Plasma, QtWidgets, or whatever other language that supports DBus.
All of this is in my kmix-improvements branch on KDE git’s kmix repository. I’ll reiterate: this is mostly just a pre-alpha. Don’t expect everything to work, though I have been using it on my desktops without significant issues. Feedback and contributions are welcome.
