What Sound System for KDE 4
D.H.J.Takken at phys.uu.nl
Tue Aug 17 23:14:09 BST 2004
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).
>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
* 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?
More information about the kde-core-devel