The Panel seriously needs a plugin for volume control. It should allow several backends like alsa or the bsd audio system.
Originally posted by VdoP ( vdop ).
there is qasmixer, a piure qt4 based app, as a workaround available. The GUI is probably too complex but backend can be reused - maybe we can share some code one day.
Yeap, there is qasmixer but for many users (including me) it's too complex. I'm thinking about something similar to Volume Icon - I think it's really good app and would be an good plugin.
for OSSv4 (Alsa not works with my soundcard in arch linux) we have osso https://github.com/antico/osso/commits/master
For alsa we have two of options
For pulse, I use a python (pyside) plugin I made a while back because kmix annoyed me. However it's stupidly simple, uses an ugly/hacky pulse backend from gnome-volume-control, and only controls the volume with the mousewheel.
So the project needs a volume control app with:
Nice features to have:
I don't recommend the volume control to be a plugin; seeing the previous features it should be a separate app.
The odd bit is that new users are going to expect razor to have a volume control, so the app could be shipped with razor, or strongly recommended, or something like that.
Kmix is a quite mature application, why not fork it,refactor it, integrate it with razor and ship it?
It seems more appropriate to use Qmix in that case.
QMix only supports ALSA to my knowledge.
It would still be easier to implement other backends than fork KMix.
Maato has published volumeicon on github:
It's gtk only but should be very easy to write a Qt frontend, see https://github.com/Adys/rattle/blob/master/rattle/main.py. Maato has said he would refuse to include a Qt frontend in the repository but is not opposed to forks.
As far as i understand it is enough to "yum install volumeicon" and razor will load it by default. (In Fedora)
Perhaps then volumeicon should be a dependency in qt-desktop so that it gets installed automagically?
I do understand the desire to have Qt only apps, but for now that work should be focused where it is most needed. Replacing an excellent app like volumeicon is not a priority.
Putting a gtk app in qt-desktop is a stupid move. People who pull this kind of package don't want dependencies on gtk libraries.
I'll see if I can work on a quick qt port of volumeicon, I've been meaning to but never got to it.
Personally i dont really care about dependencies. I run qt razor because it is neat, and evolving much faster then LXDE. Qt is what i consider a RAD development tool which make me think it will continue to evolve fast.
It is lean and user friendly (=less confusing non power-users) then KDE and Gnome in their current states.
If you make a qt volumeicon make sure that razor do not also load the gtk version... having "volumeicon" in autostart probably means we want only one of them... :)
This is a suggestion to port http://code.google.com/p/volti i have used with sucess in fluxbox and xfce, i dont know if is hard to pass to qt.
It wouldn't be, but it's in python, so it would require PySide. I'm all for PySide, but given that Razor attempts to be a thin distro by default I think it's a bad idea to pull in a dependency on it.
Assigning the issue to myself...
If I can remember someone try write such plugin/app but I'm not sure.
Adys, thank you for help. I'm sorry I didn't get it done...
I am quite sure KDE have both a volume applet and a full mixer applet. I suggest that porting KDE stuff to Qt is probably easier than porting a GTK app.
As far as I see we can reuse all KDE code we want, as long as we do not create dependencies to KDE.
pavucontrol is probably the best pulseaudio mixer out there, we should either us it or port it.
Actually I think PulseAudio code should go in a lib that expose generic audio mixer functionality to a backend-agnostic GUI, as we probably wanna run it on platforms with other audio API:s.
KDE uses Kmix which is a very large volumeicon with a builtin mixer. It's a much better idea to keep the mixer functionality separate.
I both agree and disagree. The keyword is re-factoring. Kmix should be re-factored into a (or several) mixer library(-ies), a volume control and a mixer application. Also dependencies to KDE should obviously be cut.
However it might be better to port pavucontrol to Qt and refactor it into the three components given above.
The important thing is that we need both a volume control and a mixer, and there should be no overlapping code - common code goes in to a lib. Also both apps need to be portable to non-PA platforms.
A volume icon is a very easy piece of software to write. A mixer is more complex. One can call the other.
Way too complex and doesn't support pulseaudio gets it a -1 from me. I'm not opposed to blessing it though, but the author needs to open a git repo somewhere if possible.
Quote "Way too complex and doesn't support pulseaudio gets it a -1 from me."
Great, I like systems without pulseaudio - just gets in the way...
So don't install pulseaudio. But people who do like pulseaudio will want a volume control that supports it, simple as that.
In any case, an alsa backend is usually enough for a volume icon but qasmixer is a mixer, not a volume control.
Thanks for your quick responses.
In my above comments, I was always referring to QasMixer and not the other two tools in the QasTools package which are definitely for very advances users. And yes there is no pulseaudio (except for the libs package) on my jacked up system.
But seriously, pulseaudio or not, the most notable comment on sound in any distribution's forum is that the volume control or sound does not work as expected. This is usually due to the fact that the user does not know what the true capabilities of his/her sound card are . Often the channels have a limited number of gain steps, sometimes as little as 4. The mic preamp may only have a maximum of 20 db (x10) gain. And in the KDE / Gnome desktops hide all this behind a 0-100% linear slider.
That's why QASMixer is becoming popular even in this early development stage, because you can immediately see what the sound card's capabilities are and there are no hidden mute controls.
So yes, within razor-qt's concept keep the volume control lightweight, but please don't over simplify like KDE or Gnome. This only leads to a misunderstanding of the sound system on Linux and gives Linux an undeserved bad name.
@quietpinguin You raise some good points, but I need to clear some stuff up first:
The end goal of razor is still to let the user be in control, so anyone is free to install qasmixer. We talked about package management plans as well (with distro integration of course), but these are still very far off.
In the end, volumeicon achieves all this, and the only thing we need is a port of volumeicon to Qt. I want to work on this but I'm simply not finding the time, if you want to pick it up we should talk -- I'm on IRC as Adys, #razor-qt on freenode.
Hi, I am working on a panel plugin for volume control: https://github.com/nebulon1234/razor-qt/tree/volume
Any feedback appreciated, it supports only pulseaudio so far, but its planned to also add alsa support.
As soon as this is there and the alsa/pulseaudio classes work for the plugin, I will try to build a pavucontrol alternative.
When building I got 2 errors.
error: ‘qRegisterMetaType’ was not declared in this scope
need to include QMetaType
error: ‘PA_VOLUME_UI_MAX’ was not declared in this scope
in pulseaudio 0.9.21 this constant not defined in volume.h so I advise to add definition (but maybe you know better solution).
So please add next lines to the pulseaudioengine.cpp
#define PA_VOLUME_UI_MAX (pa_sw_volume_from_dB(+11.0))
Thanks! I added both of the fixes.
anyway - volume plug is included in git so closing.