kmix PulseAudio support

[Colin Guthrie]

'Twas brillig, and Christian Esken at 07/01/10 01:09 did gyre and gimble:
>> Well I currently show one category - the "Events" one. This is done also
>> in gnome and as event sounds are short lived it can be tricky to catch
>> them individually so they are hidden and only the common slider is
>> shown. I'll probably get round to showing other categories too, but this
> 
> A control that only appears for a short time would confuse me.

It seems to be a pretty standard feature these days. We've been doing it
for years in pavucontrol and gnome-volume-control also has had per-app
volume sliders for a while.

All of those sliders that come and go are kept under the "Playback
Streams" tab, so it's pretty obvious to the user what they are. The
application name is shown too, and I hope to put the application icon
into it eventually too.

>> There is no dedicated backend, but both the xine and gstreamer backends
> 
> Looks like I misunderstood. I thought it would be a Phonon Backend in KMix. 

That's certainly possible, but I'm not sure how it would know what
applications are current running when those applications are not going
via phonon (e.g. pure alsa apps). If PA is the accepted underlying
platform, then the phonon integration and the kmix backend give the
users control over *all* apps which is certainly nice.

>>> No, it doesn't happen for ALSA. Nor for OSS. Why should it?
>>>
>>> Anyhow, this is a showstopper.
>>
>> Actually I think it does show up for alsa (I saw it happen before with
>> pristine kmix). That said the dialog in question I now realise is
>> related to the notification daemon impementation I was running. My
> 
> So we can summarize:
> - Notification: Yes (If you "unplug" the card with the current global master)
> - Dialog: No

Yeah. It think it's a by product of how I define the "mixers" and the
concept of a "globalmaster". In theory, for my playback tabs I don't
want any globalmaster but the contructs force me to do so and they
automatically pick the one at(0). I've not looked at the code in much
depth yet, but I'm sure this is the way forward.

Sadly I have to keep coming up with new applications to test this as it
only shows up the very first time an app plays. I'll try and find the
relevant file to trash/edit to make them show up again :D

> Sorry to be unclear. I meant: Do not activate Pulse support by default. Let 
> the user make an active choice to do so.
> 
>> Again I'm confused. I don't "activate" anything. If the system is
>> configured to use PA then I'll use it. This is surely the correct approach?
> 
> It could be correct - depending on what you mean with "configured".  Is it 
> enough that PA is installed? Or does a PA process have to be started? Or some 
> Backend configured to use PA?
> 
> I can only tell what I experienced: As long as PA was installed, sooner or 
> later some smart program (not necessarily a KDE or Phonon program) would try 
> to use it and I got problems. 

PA has two accepted ways of starting: autospawn when a client tries to
use it, or via the XDG Autostart system triggered at login.

If a user wants to keep PA installed but disable it, all they need to do
is tell it's client config (/etc/pulse/client.conf) to not autospawn,
and disable the XDG autostart.

In Mandriva we have a preference to enable or disable PA usage and it
takes care of the enabling and disabling of these things for the user.
It's really rather simple.

If other distros don't do that, then it's an integration issue. Having
pulse installed does not imply it's usage and I never make that assumption.

So what I do is try to use pulse. If it's already started, then the user
meant that to happen and I honour that. If it autospawns because I'm
trying to use it, again this is how the user has configured it and I
honour that too. I've very confident that this is the right way to do
things while providing the necessary fall back.

>>> 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.
>>
>> Having not jumped into the Kmix code before, I can say that the mixers
>> and such it exposes are very restrictive. The channels and mappings are
>> fixed and nailed down to pre-defined concepts rather than giving a
> 
> I don't understand: Fixed channels? Are you talking about layout?
> And what are mappings?

Yes, I cannot have a device or application that has a bizarre channel
map - practically, this isn't an real issue but there's no real reason
the channels have to be so fixed. A simple slider + label is all that's
really needed and the backend can tie it to the approach physical
control. Also when I have a 7.1 setup I just see 8 sliders but I have no
idea which is which (hence why a label is needed). Ultimately, I don't
see why the Volume code is intimately aware of channel maps.

IMO (and forgive me if I've overlooked something), the Volume class
should just deal with x number of channels and a channel map that says
channel 0 is this, channel 1 is that. "This" and "That" would be a
simple object that has a symbolic name (e.g. mono, front-left,
front-right, or aux) and a label. For the standard types you can have
default labels (e.g. "Mono", "Front Left" etc.) and for more outlandish
ones you can set your own label). When setting the volume from the GUI,
it would just care that you were setting channel 0. It would not be
aware that this was front-left. When doing stuff via dbus, it would
expose the channel number, the symbolic name and the label. The symbolic
name could be used by the consumer, but most of the time it would just
be "take channel, display slider+label, show to user, await feedback"
(e.g. for a plasmoid on the desktop) and be ignorant of the actual
meaning of the slider which is nice and abstract.

I guess the crux of what I'm suggesting here is to ditch the concept of
the channel mask. I think it's artificial and just limits what can be done.

> Do you have any good examples where other apps use embedded plasma bits 
> (except for the desktop?).

Not really, but a plasmafied widget for kmix could be quite nice on the
desktop. I guess one example would be for e.g. konq to have a volume
slider for it's per-application volume - this would allow it to show a
widget to turn down the volume of flash animations/movies/adverts...
it's a bit contrived perhaps, but quite a nice thought.

> I haven't understand why everybody is so keen to limit themselves to the 
> limited set of plasma widgets.

I'm not really intimately aware of the inner working so plasma to be
honest, so I probably shouldn't have hinted in that direction and left
it for someone more clued up :)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]