kmix PulseAudio support

Colin Guthrie gmane at
Sun Jan 10 12:05:58 GMT 2010

'Twas brillig, and Christian Esken at 09/01/10 22:47 did gyre and gimble:
> Am Donnerstag, 7. Januar 2010 11:24:58 schrieb Colin Guthrie:
>> 'Twas brillig, and Christian Esken at 06/01/10 19:09 did gyre and gimble:
>>> You guys get me quite confused in this mail thread. Please do not say "it
>>> is bad" or "lets change things" without indicating what you mean.
>> Just as a small example regarding the mixer widgets:
>> They have until now been used to represent hardware. I'm now using the
>> represent applications and as such I'd like to display a bit more
>> information and implement a few extra features.
>> I'd like to show that application X is currently using device Y. e.g.
>> I'd like to see whether Amarok is using my USB Speakers or my Bluetooth
>> Headset and ultimately show some way of changing this... (I originally
>> did not intend to allow any moving of apps to different devices via kmix
>> - leaving that job to the categories in the Phonon settings - but the
>> number of comments on my blog saying "Please consider adding stream
>> moving support" makes me rethink this!)
> I agree. It sounds reasonable from the users perspective. Is this alread 
> doable right now (are there interfaces from the apps like amarok?!?)?

No, I just do this in PulseAudio. The API allows me to list all playing
Apps (with their Icons and other nice metadata) and allows me to move
the playing stream to any output device. This has already been
implemented in pavucontrol (for many years now) and adding it to kmix
would let users use a native KDE app which would be nice.

> Colin, will you attend the MM meeting? I would be very worth discussing these 
> things. Hammering out the details might be very difficult on a ML.

Yup, I put my name down a while back, so I'll be there :) My primary
goal of attending will be on improving PA integration (and the relevant
structural changes neede to support that).

>> All I'd really need to do is show a (probably vertical) hyperlink next
>> to the slider which could pop up a window to allow me to pick another
>> device. The fact that the tabs basically limit to showing sliders and
>> enums means I can't easily achieve this right now.
> Kmix's infrastructure should be able to easily do it. For example there are 
> switches implemented, and I can easily implement more 
> MixDeviceWidget types - for example I have thought about a "Capture selector". 

OK, so I think I get the logic here.

Actually as I'm "getting" the code a bit more I realise that I'm using
"capture" MixDevices for the capture streams/devices but in actual fact
I think I want to use playback ones as this allows the hasSwitch and
mute button to be used... (the Capture selector is not really needed in PA).

Speaking of these widgets, are you aware of:

I'm not sure if some of my changes will break the diff applying but I'm
happy to rediff it after I commit to trunk (just got one bug to solve
before landing it there).

>> This is an example of the kind of capability I'd like to add but the
>> fixed UI code is preventing me from easily achieving (unless I've missed
>> something obvious!!)
> Depending on what we actually need, adding a (optional) hyperlink to the 
> current slider class (or doing a different MixDeviceWidget subclass) can be 
> done. it sounds like a trivial extension.

Nice to know. Thanks for the insight :)



Colin Guthrie

Day Job:
  Tribalogic Limited []
Open Source:
  Mandriva Linux Contributor []
  PulseAudio Hacker []
  Trac Hacker []

More information about the kde-core-devel mailing list