make_it_cool: kdelibs/kdemm

Fri Mar 18 23:16:30 GMT 2005

Hi Ryan,

thanks for giving feedback. OK, first to check that I know what you're talking 
about I try to summarize (the further you get with reading the more I start 
asking questions rather than telling you what I understood)

- you're currently working on extending the Helix DNA Client so that media 
players using it support alternative media engines

- you want to have that functionality because the Helix DNA Client media code 
might not always be the best code to handle some specific format (or it 
doesn't know how to handle the media format at all)

- you want to achieve that by starting dbus services that register as media 
engine and that can then be instructed by Helix to play some certain files 
(or will you pipe the whole media data over dbus, or URLs and hope the media 
engine can handle it?)

- I'm not entirely sure what you want to do with the XEmbed stuff: do you want 
the "media engines" to show some widget inside the media player? If yes, what 
widgets? Video window? effects dialog? complete media player GUI?

- When talking about permissions for the media engines, does that mean they 
might run as root (or some user with higher permissions). Doesn't that create 
security problems when you can "remote control" those services over dbus?

- How do you want to make it integrate "well" into the application? Say, I 
have a media player that uses Helix DNA, now I want to play a media file 
that's only supported by an external media engine. Do I only get to use a 
subset of the Helix API (not knowing the API at all I have no clue what I'm 
talking about ;-) ) or how do you map media player functionality from the 
media engine to your API?

- One big disadvantage with out of process media handling has always been 
debugging. This has hit us pretty hard with MCOP/aRts, but I have to admit 
with MCOP this was probably worse than it can get with sending instructions 
over dbus.

On Friday 18 March 2005 22:56, Ryan Gammon wrote:
> Anyway, as we're both working on similar things, it would be cool if we
> could collaborate here in some way.

Yes. Though I'm not sure if it's really similar enough. The main goal of the 
kdemm API is, after all, to have a simply to use Qt/KDE style API to do all 
your common and some not so common media tasks.
AFAIU you already have that API (not Qt/KDE style, though) and want to extend 
the implentation behind it to use other engines.
For kdemm we want to support more than only one engine because the 
functionality we ask for in our API should be available with most media 
frameworks and because some users have "special needs". I think this is 
especially true if you want to make KDE a good platform for pro audio tools 
that does not get in the way like it currently does with aRts. You rather 
want it to integrate. (but I guess I'm getting a little off topic here)

> I think the goals of kdemm are a bit more broader than what I was
> thinking about on my side, in particular:
>
> (on Section 2.1, Actors)
>
> One actor worth considering is a system integrator -- ie, someone at a
> linux distribution who says "we're supporting (polypaudio/jack/alsa
> asym/usound/anything but esound), our multimedia applications on kde
> will all work with sound server X out of the box".
>
> I was thinking of leaving the configuring of media engines to
> distribution integrators & advanced users, punting on the creation of an
> easy admin-configurable unified media engine configuration interface for
> now.

What would be the difference between your "system integrator" and my "KDE 
admin"? Is it just another name or does he also have another "user task"?

> (on change audio output volume)
>
>     The user wants to change the volume of some program because it is
>     too loud compared to the sound of another program.
>
> I was thinking of leaving this unspecified in what I'm doing... If the
> user has a sound server installed that can do this, great.

Yes, but kdemm is about a DE, so we want the desktop experience to be 
"perfect" ;-) I found that changing the audio volume of some specific program 
is a rather common task for me - it's often just too complicated to do, so 
that I won't bother, but if I could...
How to achieve that without a specific sound server? If the soundserver cannot 
do it, or if the user doesn't use a sound server at all, this can be done 
using IPC. The kdemm prototype already has this functionality even though a 
simple way to access all those volume controls is missing. And it's rather 
cool. Of course this will only work for apps using kdemm.

> (on domain constraints)
>
>     It must be possible to run the desktop over the network, not only
>     the GUI, but also audio output. If it is possible, the system should
>     try to play the audio on the computer where the GUI is shown by
> default.
>
> I was also planning to leave this unspecified, as something sound server
> dependant.

Right. This is something the sound server does. What this domain constraint is 
about is to tell us, that somehow it needs to be possible to do it. If that 
somehow means the admin has to configure audio output to a sound server than 
so be it. If it would not be possible at all to forward the audio stream to 
another computer I'd say kdemm has failed. So much for the rationale to put 
this constraint in there...

> (on create reusable audio path)
>
> In general, I wasn't planning on assuming a graph-based architecture in
> the underlying media engine, and in fact was going to punt on effects
> for now (like eq, reverb, equalizer).
>
> I'd probably implement this down the road by creating a basic effects
> interface that actually has methods to configure cross fading, eq,
> reverb, etc. rather than doing pipleline manipulation. I think this is
> going to be tough to do in a cross-media engine way...

I don't want to assume a graph-based architecture either. That's why I didn't 
model a flow graph. All I did was put some mysterious "path" in there. How 
that maps to the media framework should not matter.

What is really more complicated is to map effects from the media framework to 
interfaces and GUIs. I'm currently working on this.

> Is there any way that the work I'm doing could be useful to you guys?

I'm not sure. I guess one day kdemm would like to have a Helix DNA Client 
backend. But this does not have anything to do with the current discussion...

I would be very interested, though, in how exactly you're planning to use 
dbus. Whether you want to only send instructions are whether you want to send 
media data over the wire (I guess this is not a task dbus was meant for). And 
how much communication you think you need to fully integrate the external 
media engine into your API.

The interesting part about your approach is that you can use several media 
engines at the same time, while kdemm in it's current design would always be 
fixed to exactly one media framework.

Sorry for the long email, I hope I'm making sense (after all, it's been a long 
day and time to go to bed).

-- 
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20050319/2f927840/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia