List Moderator: Please attach this mail to the "What Sound System for KDE 
4" thread. Thank you.

>On Sunday 15 August 2004 22:28, Allan Sandfeld Jensen wrote:
>> I think that would result in overengineering. Applications that wants
>> advanced features like that, would have to detect the backends
>> specifically. This is for simple open file, play it type of applications. I
>> would expect Amarok or JuK to use the backends directly (or refuse to start
>> if an incompatible backend is used).
>>
>> `Allan
>
>Yes, I very much agree.
>Basic desktop apps (kdelibs + kdebase) usually don't need fancy effects and
>equalizers and stuff.
>Advanced multimedia apps need it, and I'm not sure KDE should try to invent
>yet another multimedia framework, there are already enough of them.

I also agree with the KDE media API to be very basic. I only would like to 
point out one small thing we could consider adding to the API. This 
addition will allow KDE applications to do 'advanced' media stuff without 
even knowing it. Here's how it can be done:

KDE applications need to be given the possibility to choose which KDE 
Sound Channel to use (I use sound as an example, but it applies to video 
as well). KDE should provide one or more named KDE Sound Channels, which 
are nothing more than definitions that describe what will happen to the 
sound produced by KDE applications. It's a simple addition to the new KDE 
4 API, but it offers a lot of possibilities that can be implemented after 
KDE 4 is out.

Eventually, the user should be able to create his/her own KDE Sound 
Channel definitions that can be used by all KDE applications. For example, 
the user could create a sound channel that applies a certain GStreamer 
effect, or a channel that records the sound to an MP3 file on disk. 
The user can have any KDE application use any desired effect by 
configuring the application to output to a specific channel. The 
application itself does not need to know anything about the effect and it 
does not need to provide a GUI for it (though we can always write a 
channel definition editor that does). All the KDE application needs to do 
is:

* Query the names of the available KDE Sound Channels before playing
* Allow the user to choose the name of the desired output channel to use

After KDE 4 is out, anyone could write new KDE Sound Channel definitions 
that take sound as input and do anything with it imaginable. Note that 
this does not introduce another multimedia framework into KDE, it just
enables any future KDE application to access external multimedia 
frameworks through a typical basic sound API that is easy to maintain.

A few remarks:

* All of this applies to video handling as well.

* We could also define input channels that applications can record from. 
The user could define input channels that fetch sound from various 
sources, like line-in, a MP3 file, the output of another KDE application.

* All of this is no alternative for full-featured media players like 
Amarok, it's a way to add more possibilities to media playing 
applications that don't want to add a complex GUI for it, like Juk.

* In case we do want KDE applications to have the possibility to offer 
integrated GUI's for channel effects, we could have the channel definitions include 
KPart GUI's that can be integrated into media playing applications.

Any thoughts on this?

Dik