Vote for a MM system (Was: Re: summary of the aKademy meetings)

[Christian Esken]

On Wednesday 08 September 2004 14:13, Marco Lohse wrote:
> Alexander Neundorf wrote:
> [..]
> 
> >A simple KDE API for simple purposes and a recommended framework for advanced 
> >purposes is IMO a really good solution. And I guess most KDE developers 
> >writing advanced MM apps will write some kind of bindings for their preferred 
> >framework. Maybe this will naturally lead to one preferred framework with its 
> >bindings, which can then (maybe in 2..5 years) become the defacto KDE 
> >standard MM framework.
> >
> >  
> >
> I think I mostly agree with your opinion. And I am afraid, I did not 
> make my ideas very clear in the beginning:
> 
> The 'simple KDE API' (aka the 'abstract player interface'? aka 
> 'meta-architecture'?) : Simplicity is fine. However, I am sure we can 
> create a simple yet powerful API. For example: let's just say this API 
> should only be used for file playback. So, the simplest API would allow 
> to set a media source, automatically create a flow graph for audio/video 
> rendering, start, stop, pause, ff, rew.

OK, I feel we need to come back to our senses. Lets face reality:

Have you ever seen the DirectX (DirectSound) API?
Actually there are trivial sound players and there is high-end audio-software on Windows.
And "it works". So we can somehow agree that you can do "anything" with that API, right?

So now take a look at the Windows DirectSound API and stop dreaming. How the hell can those Win-developers program good MM apps with a crappy API?
So it looks like the artistic beautiness of the API is definitely NOT our problem. And doing 2 artisitcally beautiful API's is totally out-of-scope. We can discuss a perfect API for years, but that does not solve any problem.

And actually a KDE API is nice for KDE, but totally irrelevant to UNIX in general.
Yes, we do not even have a generic UNIX MM API - there is no X11 for sound.



OK. enough rambling. 

So, what do I want to communicate:
1) We need an API
2) We need an Linux/*NIX API ... starting with the most trivial stuff like play(), pause(), ...
   The API is not perfect? So what? API's can and do change. Even after years. There is a X11R6, there is DirectX 9 ... so what?
   Don't dream about doing the perfect API from scratch in 2 months ... that is absurd.
3) We need something NOW (waiting another 2 years for somehting that might creep up does not make any sense).
4) The API must not impose limits on usability on "other" languages. This means, bindings for "other" languages should be
 possible to do without to much hazzle  (e.g. C, C++, JNI, any-other-executed-language, possibly also Script-languages like Perl).
5) We need to untangle the current mess of 20 different sound systems:
   The first step here is to allow applications to find out which soundsystem to use and to allow an easy migration path.

Thus my vote will go to a MM API, that supports a MM backend system that fulfills all of the following properties:
a) Can NOW play audio and video
b) Is quite stable (running and API-wise)
c) Is available NOW
d) Is available NOW on multiple Operating Systems (at least Linux, Solaris, *BSD [preferably FreeBSD] ).
e) Is NOW maintained by a large developer base
f) has an OpenSource license
g) has an open development mentality (stuff like "open" development lists, "open" bug system, ...)



Chris