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.
That sounds great. Will Kmix also learn to adjust sound above 100% for tracks which are not loud enough? Veromix and VLC allow it and I have been missing it very much in Kmix.
Yes. It actually does that now, but that is technically a bug where the volume keys aren’t bounded with max/min values
Can we use the percentage bar widgets that are used in Krita?
They look so much nicer for something like this.
I’m not sure what widgets you are talking about. Screenshot maybe?
I think he mean something like this:
http://timotheegiet.com/images/krita/22-Multihand.png
But I think that solution is not very usable. A very neat widget for KMix volume controls would be the one that uses Kmetronome:
http://mib.pianetalinux.org/blog/images/stories/k/kmetronome1.png
But again, is not very usable (It’s hard to change it to an specific value… A work on Qt, maybe?)
I don’t like either of those, because they display some kind of absolute volume level.
When you’re turning up your stereo system, do you turn the volume control to -3dB, or do you turn it to “louder”?
In case you didn’t noticed, I’m not the author of the original entry of this thread. And in both cases I wrote “it’s not very usable”… guess why.
trn t t -3dB
[Where are the vowels?]Agree that its not very usable – rotating volume controls in a mouse controlled UI are the spawn of Satan
Stick with sliders.
The first one blablabla linked to, but it doesn’t necessarily mean you should display a number in the middle.
As I mentioned somewhere else in the comments, I’m very much against displaying any kind of number in the volume controls. It makes absolutely no sense and is extra information with no benefit. Never in my life have I turned a volume control to “exactly 8″ or “-3dB”, I turn it to whatever is comfortable at the time.
When will that land in KDE? Please tell me 4.11
No idea, really. It’ll be done when it gets done, but hopefully before 4.13.
Excellent work so far Trever, I’m eagerly waiting for it to arrive
Can you please make it vertical again? There are two big reasons for it:
1) It’s familiar. Old KMix was vertical. Windows mixers are all vertical. Every mixer console, real or virtual, is vertical. This is the de facto industry standard – there is no reason to change it just because you want to be different. Also, it just makes much more sense and takes up way less screen estate.
2) It’s much more frustrating to move horizontal scrollers on laptop touchpad or even a mobile device.
Do you want vertical sliders? That wasn’t very clear in your comment.
A me too, for the vertical sliders from me.
Not only are they easier to control with things like touchpads, it also maps very good to mousewheels( The use whhel when hover mouse over mixer icon in taskbar, is something that really annoys me that does not work on things like Windows).
And you always turn the volume up or down, not left or right.
Honestly, I think I’ll end up doing something similar to what VLC does:
http://1.bp.blogspot.com/_MfwRx_4ERx8/Sc6Tpp9KwNI/AAAAAAAAA1o/dpKYvntGH58/s400/vlc-400-volume.png
The diagonal slope gives an immediate visual cue as to what direction you move when turning the volume “up”.
But please make them vertical, your current design wastes huge amounts of space and I can only imagine how horrible it will look on my 24″ monitor. Especially then showing more devices/outputs (I have at least eight).
Are you implying that vertical sliders will make the current unfinished design better? It isn’t finished, so please don’t assume things are set in stone.
Also, I’m open to pull requests.
Tht slp lks hrrbl btw. dn’t wnt gddmn vlm mxr t b flshy-flshy n m. Bsds, s pntd t n my cmmnt blw, tht s N sldr. Th vlm mxr wll hv lts f thm. Bsds, KD X gys wll prbbly kll y f y d th flshy-flshy bcs t’s ncnsstnt wth th rst f KD G’s. nd rghtly s, bcs ths s hnstly rlly bd d.
[Where are the vowels?]Ys, d thnk tht vrtcl sldrs fr mxr s th wy t g. Bcs ths s hw t’s dn.
[Where are the vowels?]“This is how it’s done,” is a horrible reason to make any change ever. All I’m seeing from your comments is “I want the bike shed to be red because the bike sheds I am familiar with are red.”
design
If you do a google images search for “mixer volume” then 48/50 search results has vertical sliders. Just so you know that people will be expecting that. Also KMix users expect vertical sliders since that’s how it has always been.
Another thing to consider is doing a max-length on the sliders. Especially the hardware controls are hard to do a glance at.
I don’t believe in making decisions simply because “thats how it has always been”.
Usability: go with the (mouse) flow. On horizontal panels a vertical slider, on vertical panels a horizontal slider. The up/down movement of the mouse wheel won’t fit to the horizontal slider, but only a minority will have this setup.
Mouse wheeling has absolutely nothing to do with usability. There is no affordance offered by a wheel on the mouse.
And while in fact it related somewhat with the concept of scrolling using a scroll bar back in the days, nowadays it also does zooming (? no clue how that ever happend to a scroll wheel), and altituding (MMORPGs), and weapon swaping (FPS), and outright fake-scrolling in a list (think text editor where you can select the font from a dropdown *or* by scrolling),…
Keeping all that in mind the affordance-less wheel on my mouse does actually iterate through linear thingies of any kind.
Qt n th cntrry. Thr’s n bttr wy t mk fn djstmnts t mxr lvls thn t d ms scrll.
[Where are the vowels?]Ys, bt y dn’t rnvnt th whl jst bcs y dn’t wnt t g wth th flw thr. Smtms y jst hv t ccpt th fct tht f n ntr ndstry ds t tht wy, myb ths s th bst w’v cm p wth s fr. Lk wndws, nd txtbxs, nd cns, nd systm try. Y dn’t chng thm jst bcs y dn’t wnt t cpy Wndws/Mc/nty/whtvr nd hll bnt n bng dffrnt.
Y mntnd mbl dvcs. Hnt-hnt: thy hv vrtcl scrns, s t mks sns fr sldrs t b hrzntl. Bt thn gn, nt ll f thm r, nt vn th mjrty. Lts f d/vd plyrs n ndrd hv vrtcl sldrs. Bsds, w’r nt tlkng bt sngl sldr. W’r tlkng MXR. m n d ngnr. ’v nvr sn mxr (b t nlg, dgtl r sftwr) wth hrzntl sldrs N MY NTR LF. Hrzntl sldrs fr mxr smply sck. Pls, dn’t rn KMx.
[Where are the vowels?]This guy isn’t a troll. What I can make out of his comment is logical and rational. It’s not cool to obfuscate his posts and embarass him just because you disagree.
You need to remember that KMix is part of the core desktop UI. People use it all the time, every day. You should expect them to react passionately when you propose making radical changes that they don’t like. You’re proposing changes that affect them personally, so you shouldn’t be surprised when they have strong feelings.
It’s frustrating when developers propose major changes and then take opposing comments so personally that they get offended–remember that the users are offended by the opposing changes! It would be good if developers viewed these kinds of core software as being more community-owned rather than personal, pet projects.
If you search for “volume slider” than the 40/50 are horizontal.
ok
“Up” and “Down” are intuitive for everyone in the world. Gravity has the same direction everywhere, it’s “Turn the volume *down*” not “Turn the volume left”. Down is associated with “less”, “up” with “more”.
To asociate “left” with “less” (or “back”) has perhaps something to do with our reading direction, but that’s not a general rule for all languages.
I also think it’s more easy to compare silder values if they form a sort of “horizontal mountain range” compared to sth. like a “waterfall”.
Sliders from left to right feel more natural for sth. like a “balance” (e.g. colors in a painting programm). They also tend to emphasize the middle position as “neutral” which makes no sense for a volume slider. Most people I know tend to set their volume slider to approx. 2/3 as that is associated with a “strong but undistorted” signal and set the absolute volume with the hardware knob on the amplificator or the speaker.
Tell YouTube, QuickTime, VLC, my TV, iTunes, gnome-shell, and all my Android devices about that.
There is no solid argument for horizontal, just as there is no solid argument for vertical.
No possibilty to reply directly to your comment?
Well, I think i do have some valid arguments. Wasn’t it you who said “I don’t believe in making decisions simply because “thats how it has always been”.”?
So other examples shouldn’t matter, right?
One problem I noticed is if the device name is really long it forces the window to match the width. This means the dialogue box can be bigger than the screen destroying any hope of properly controlling the volumes in this situaiton. Also you can’t shrink the window thinner than the device name text.
Yeah, the UI is totally buggy. At this point it is nothing more than a thin wrapper around the DBus interfaces that I use for testing.
Nice! Are planning to support the advanced PulseAudio features with this? In Veromix for example it’s possible to change audio outputs by dragging audio sources to them. It also supports PulseAudio equalizers (it’s bit lacking on this area) and controlling volume per application and adding effects to them. Also are you planning to write a kmixd based plasmoid yourself?
Thanks.
Yup. The screenshot doesn’t show it, but you can move audio streams to other devices.
I don’t plan on writing a KMix plasmoid for various reasons, but others are welcome to figure it out.
Thank you for picking up kmix. It really needed the love.
Now, if someone could express the same love to kwallet.
Nobody wants me to touch KWallet, I’d end up scrapping it and replacing it with gnome-keyring.
I’d be more than happy to see ksecretservice actually take off, if that’s what you mean!
I see a lot of problems in this prototype:
1) What is the direction that the user must slide the control to increase volume? And to decrease volume? Problem: missing min-normal-max labels 0% – 100% – X%
2) What these ‘lock’ buttons means? Why are so big? Why is layout broken? (you can see that the last button has not the same width that the others ‘lock’ buttons).
3) What these speaker buttons means? Why are so wider?
4) Why device labels are center aligned? It’s a lot better to have them right or left aligned, plus aligment is preserved.
5) Why all of these volume sliders are so wider? Imagine that you maximice kmix window in your new widescreen monitor and you want to change the volume without dislocate your shoulder.
In constrast, pavucontrol has a better ui design (for a horizontal slider’s one). It’s a lot more clear than the prototype.
Keep the good work.
I’m very well aware of all those problems and plan on fixing them. As I said, it is a prototype and shouldn’t be taken all too seriously
Why no plasmoid?
I’m bad at plasma.
I very much appreciate the service – that way if people really disagree with the UI a different one can be easily written.
Yup, thats the plan
You really should get in touch with falkTX, the developer behind KXStudio. KXStudio is the ultimate Linux Audio system and it is centered on KDE. He actively patches KDE to make for the best system, and kmix works pretty well. He’d have good insights and suggestions to make things work best. He really knows his audio stuff. Try him on IRC at #kxstudio
Anyway, I have crazy request that would dramatically improve things for me: embed level meters! The problem is, sometimes it looks like something is on and there should be a signal, but something elsewhere is set wrong. Also, sometimes the input levels are just guesses. It would be amazing if there could be meters to show the signal when setting the levels!
Finally, I concur with others. Do NOT use horizontal sliders! Virtually all audio equipment and software is vertical. Vertical is correct here, period.
Anyway, I have crazy request that would dramatically improve things for me: embed level meters!
A superlative suggestion, sir, with just two minor flaws. One, it’s not possible (at least AFAIK) with ALSA without using a plugin*, and two, it’s not possible with ALSA without using a plugin.
But I’d love to see something like that, too.
* for it to work you would have to set a VU-meter plugin for every ALSA device
Great work!
Are you going to add OSS4 support?
I would like to, but I don’t have any system to test OSS4 on yet. If someone else wants to implement it, that would make my day.
Pingback: New Kmix is Coming, New Kmix is Coming | PHP World
Horizontal ftw!
(Posting so it won’t look like everybody prefers vertical.)
I’m no UX guy, but looking at pavucontrol i get the feel that something’s missing. IMO basing yourself on that design is a good thing, but you should contact somebody from UX at KDE for advice. I love the fact that you are taking care of kmix, as the last time it was the reason i uninstalled KDE.
The thing pavucontrol is missing in the screenshot is strong separation between sections. Bigger titles and icons and maybe a different backgound for single items?
Last time I went to the KDE usability list, everyone said I needed to support switching between vertical and horizontal layouts instead of trying to figure out how to make horizontal layouts work better.
Good idea though, I’ll experiment with alternating background colors for individual control groups.
First of all.. Yay for rethinking kmix & fixing the bugs
But oh boy… that window seems HUGE. Thats one thing I really liked about kmix, its small.
I guess I could get used to horizontal-sliders, but we will see
The only problem is that, I can not imagine how to make a “small” window with horizontal sliders.
The old kmix window shows 11sliders, now lets imagine a new kmix with 11horizontal sliders too.
Now try to resize the window as small as possible (but still being able to use the sliders).
The old kmix: is more width than height, like for example 600x200px.
The new kmix: is more height than width, for example 200x600px (maybe less).
While horizontal sliders may feel natural on a typical 16:10 screen, the dialog size itself doesn’t. And the situation gets even worse if you have more sliders on a small screen, at some point you will need to scroll. The horizontal sliders maybe better for a smartphone or tablet, but a desktop is still 16:10.
I really just want a small&easy kmix, I don’t want to do rocket science with kmix, just change my volume
(Anyway just to make sure, its only my personal opinion, feel free to disagree.)
The tray popup controls will be a lot smaller. Likely just the master control and a single slider/mute button for each stream. No independent channel control, no stream rerouting, just a very simple interface.
Please don’t make sliders horizontal! Horizontal sliders are the worst thing on pavucontrol UI.
Vertical sliders are much more intuitive and practical (because of mouse wheel) in mouse-driven environment (and also all hardware mixers have vertical sliders).
How do vertical sliders support long text labels of streams without obnoxious wrapping of each word to its own line?
Make the text tiny and/or force shorter text…
Please can we get something like this for kmix http://i2.wp.com/www.synthtopia.com/wp-content/uploads/2012/01/masterlink-ipad-mixer.jpg
I tried plugging in my speakers to this mockup I threw together but now my monitor is perforated and off. Your idea might not work out.
Who said sliders should even have long text labels? And who said wrapping is always obnoxious?
Anyway, I think this looks fine, and makes sense, and works well: http://alphapapa.net/outbox/kmix-vertical-sliders.png
This reminds me of one thing. Is the “left” for lower volume and “right” for higher volume natural for everyone? I mean, is it possible that eg. for RTL languages the opposite would be more natural? I don’t think vertical sliders can suffer from such problem.
Hello there,
Thanks for taking this on. Your prototype and the pavucontrol screenshot look promising, but I wonder if you could do anything about a pet peeve of mine?
These mixers always show so many options! Most people just want to adjust the speaker and microphone volume but they are shown mysterious sliders like PCM, Capture and Master. What do these mean? I bet most people are also confused by labels like Aux and Line, even with icons to illustrate them. I seem to remember there being some kind of toggle option to switch on all the advanced options. I’d like to see that back, and KMix/distro intelligently handling other options in the background until you switch on the advanced options.
Getting a mic to work can sometimes involve endless fiddling with the mixer options, and even loading up alsamixer to identify options you don’t see in KMix. I know this is often the fault of the distribution, so you can’t fix everything with KMix. I just really loathe getting audio to work on GNU/Linux, I wish it wasn’t still such a pain in the bum.
Finally, yes please to either having small VLC-like widgets or vertical sliders. A further reason nobody has yet mentioned is that you turn the volume up or down, you never say you’ll turn the volume left or right! The vertical slider corresponds to common English language. I don’t know whether it is the same in other languages and cultures.
A further reason nobody has yet mentioned is that you turn the volume up or down, you never say you’ll turn the volume left or right
Now it looks I just copied your argument, but I have exactly the same feeling about that.
PS: I should really read other comments before posting It would take much less work, because then I could just post “+1″
Thanks for this, KMix definitely needed some love
I hope you’ll reconsider the UI part though… it looks horrible (same goes for pavucontrol). The existing UI is very nice. Why change it?
It’s nice to see some kmix development and that the bugs are being fixed. I wish you good luck with that.
But the GUI is the worst mixer GUI I have ever seen (with pavucontrol not being much better). It’s chaotic and completely unintuitive.
The biggest problem is in my opinion that the horizontal controls are not intuitive for mixer. If you look at the volume control elsewhere, vertical control is the prevailing one (with the exception being most of music players, but these usually have just one volume slider). It holds true even for most hardware mixing devices. It actually makes sense, because you are turning volume “up” or “down” not “left” or “right.”
The second problem I see here is the use of space, which is bad especially on the widescreens. If you have lots of controls, you will use the space better if the controls are vertical. As you can see from the screenshots, you actually need scrollbars with the horizontal controls, while they were not necessary before.
To si děláte srandu, takovej humáč.
Strange, I didn’t notice that it was the redheaded buggy stepchild, for me it always pretty much did what I wanted.
Anyway, I appreciate the effort done, even if it worked for me does not mean that there was no room improvements
.
Good luck, looking forward seeing your work one day in KDE.
Good work – I wish someone writes default Kmix applet in Veromix style. Currently Veromix hogs 50% CPU and crashes my desktop sometimes.
Horizontal / Vertical – The argument can go both ways. I think VLC style is better because vertical makes the UI bit unwieldy. Even I feel there should be an ‘Advanced’ option. Show all Devices – option should be on top? Round Slider does not look that draggable, check below pages for slider. Let us show some love for Mark
Mockup UI for sound applet.
http://www.markshuttleworth.com/archives/446
http://img.obfuscatepenguin.net/ubuntu/panel/volume-applet/july-2010-mockup/
Pingback: KMix estrena interfaz y recibe numerosas mejoras
Awesome! Thanks a lot, it was about time for some changes in kmix. Using PulseAudio it was so buggy, using like 100MB of RAM. Not that I would care, but still too much for a little piece of software. I started hacking right away and added scroll support for the status icon. Though last time I coded in C++, Qt had 3 in its version
These days a lot of people are using DACs (and thats tends to grow). So, (I don’t know if it is viable) but a nice Kmix new feature would be a easy way to assign a interface as ‘Bit Perfect Audio’, avoiding any resampling and so in order to send the original information to a DAC (via snd-usb-audio, coaxial, etc.). It’s not really difficult to do on (i.e.) Alsa confs but need some work.
Cheers!
Oops, I think it’s more a Phonon fature than a Kmix one.
Y cn mrk m s trll, fn. Hwvr t sms t m tht ny prsn n hr tht knws wht s mxr sys tht t shld hv vrtcl sldrs. Ths lds m t blv tht y dn’t prbbly knw wht y’r gttng nt – tht s fn, ndrstnd tht nt vryn s n d prfssnl, nd nt vryn hs t b. Hwvr tryng t d cwby cdng hr wn’t hlp nyn. Nt chngng nythng jst bcs t hs lwys bn lk tht s bd rsn nt t chng, bt chngng smthng jst bcs t hs lwys bn tht wy s n vn wrs rsn fr chngs. Y dn’t s dvlprs f nw wndw mngr mkng wndws rnd jst bcs thy hv lwys bn sqr.
Wht y shld sk yrslf thgh s, r ny chngs t ll ndd? Wht r y tryng t chv wth ths? Hw s tkng hg chnk f scrn stt, brkng xpctd pttrns nd gng gnst th flw fr th sk f gng gnst th flw ccmplshng nythng sfl? KD gys wr rght – f y wnn b cwby nd mk hrzntl mxr, fn – bt lv th vrtcl s n ptn. r thrws jst lv th ld ntct.
h, nd by th wy – mxr sn’t vlm sldr – s nn f th “bt YTb ds t!” rgmnts pply hr.
[Where are the vowels?]I think you misread the part where I said this is a prototype and none of the design is finalized. Chill out, friend.
I feel frustrated when I see what could be a great thing turned into a potentially very frustrating thing. A new developer takes over a mildly-neglected project, one that represents core, basic desktop UI. Yay!
But then he decides to do it in a radically different way, a way that people actively dislike, a way that’s not logical, a way that is the opposite of real-life hardware UIs.
Why? Who knows? Maybe he wants to make a name for himself by doing something different. Maybe it’s his personal preference and he doesn’t want to write code to do it both ways. Maybe he is on a power-trip and wants to feel control over other people (I’m not accusing you of this, but I’ve seen it before).
In the end, it doesn’t matter why. What matters is that one person has control over something that is used by many, many people. What matters is that this one person needs to remember that, “with great power comes great responsibility.” What matters is that this one person needs to do what is best for everyone, not what he personally prefers, or what he personally thinks is best for everyone. “You’ll grow to like it,” or, “Someday you’ll see that I’m right,” or, “This is what the designers came up with,” or, “This is what fits with our vision”…none of these are acceptable reasons to the real people that actually use the software.
So please, by all means, take KMix to its potential as being the best FOSS desktop mixer app. But don’t reinvent the wheel. Mixers are rooted in reality, in real hardware–you won’t see any professional audio mixing gear with horizontal level sliders, because they fundamentally don’t make sense when compared to vertical ones. “Ugly” labels are a minor issue compared to the primary function, which is adjusting levels.
Why yes, I do accept patches.
Having read all the high adrenalin pumped emotional stuff above I would like to take the opportunity to get back to basics…
Firstly why is Kmix needed?
1) Obviously, to simply adjust the volume when watching a video or listening to music, etc.. This is best done with a plasmoid in the task bar.
2) To control the sound cards – that is, to actually configure the gain settings and mode switches on the cards as opposed to adjusting stream levels going to and from the sound cards.
For example:
- setting the microphone amp gain
- switching between HDMI, S/PDIF and analogue outputs
3) For hobby, semi-pro and professional studio users – to precisely set levels optimising the signal-to-noise ratio and avoid clipping. And yes I do set the controllers to exactly 0 dB gain when my laptop is connected to a Behring U-Control.
4) For fault finding – “Why can I not hear anything?” or “Why is my microphone not working?”
If each control had a level meter then you literately “see” if a signal is there and where it is (or is not) going.
For the KDE Desktop the only way to do the above tasks without resorting to the command line is to use Kmix.
(There is off course QASTools, but this development is floundering – it is a shame that KDE.org did not pick-this up and make it an integral part of the KDE suite.)
What does this mean for Kmix?
a) In the true KDE style make everything configurable, horizontal or vertical controls, gain setting numbers in db, %, or none etc.. .
b) Each control should have a level indicator – to be professional the k-meters used in jkmeter (http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html) are as near perfect as you can get. (The indicators show both the RMS and Peak levels simultaneously.)
c) Each control should have a number indicating the gain setting in db and/or %.
d) Give each control a scale (tick marks) which show the gain steps that are really available for the sound card channel. Sometimes the mic boost is only available in 4 steps, etc..
QASMixer in QAStools does this perfectly, as it reads the ALSA sound card configuration to determine the correct display of each individual control. (See http://xwmw.org/qastools)
e) The different sound cards must be selectable within kmix, especially for Laptops where:
- one moment they are used to skype with the internal sound card / webcam
- the next moment they are connected to a TV (HDMI) to watch a film
- the next moment connect to a midi-controller-keyboard with built in sound card
- etc…
f) Kmix should be readily accessed with just one click on the task bar icon (not right and click and select from menu as now)
I’m sure there are a few more good ideas, but if the above was implemented, many of the shortcomings of the current Kmix would be laid to rest.
With best regards, Simon