Some ideas for the aRts-replacement

[Dik Takken]

On Mon, 23 Feb 2004, Neil Stevens wrote:

> On Monday February 23, 2004 8:40 am, Dik Takken wrote:
> > Hi All,
> >
> > I have been following the discussions on this list about the future of
> > Arts in KDE, and have been thinking about what we could do.
> >
> > Please read my idea about replacing the current sound API with something
> > new that is not Arts, not GStreamer or anything else.
> >
> > This API has the following properties:
> >
> > * Applications that just need a 'play this' command will get it.
> > * Applications that want to fiddle with equalisers, mixing and so on
> > will also find all they need.
> > * The API is a complete abstraction of the underlying technology. Using
> > Arts, GStreamer or just plain ALSA does not change anything for the
> > application programmer.
> > * The API and it's implementation can be made very flexible. When there
> > is no Arts or GStreamer available, it will still work.
> > * Give the user more control of what happens to sound output of
> > applications and what sound system is used by KDE
> > (Arts,GStreamer,whatever).
>
> If you do this, you're just writing GStreamer on top of GStreamer!

Well, a part of it, perhaps. We have to choose. Either we pick one
multimedia solution, use it for KDE and drop everything else, or we create
a (simple) framework that allows us to dynamically use any external software
we want. If we pick one and use that, we are running the risk that we will
have to face the same problem in a few years time as we are facing now.
What if something much better than GStreamer pops up in the near future?
What do we do then?

For example, say we have an application that needs an equaliser. It uses
GStreamer's, because we chose GStreamer as our multimedia platform. But
then, KDE switches to QStreamer. Our application still needs an equaliser.
If KDE would offer an abstraction of the equaliser, our application would
never know the difference. If the abstraction would not be there, we would
have to port the application.


> The fact is, KDE needs to *depend* upon a standard set of decoders and
> sound output.

For the more advanced multimedia applications: Yes they need a basic set
of decoders and stuff. But I don't think we should tie applications to a
standard set of tools. Since such a basic set will probably be quite
limited, the applications that have to use it will be just as limited.
Applications need to be allowed to use non-standard tools as well.

> Unless this support is *guaranteed*, applications will be
> forced to go reinvent the wheel over and over again, getting the support
> that is lacking in kdelibs.

Applications are not guaranteed that anyone has TagLib on his computer.
Yet, applications don't have to invent their own TagLib. Same here. The
user will have to provide the tools that the application requires. Perhaps
we need to guarantee some basic stuff, but we should not limit ourselves
to it.

> More abstraction isn't what's needed.   Standardization is what is needed.
> Without a standard, guaranteed set of features, featureful application
> development is hindered.

Abstraction is a means of standardization. From the
application programmer's view. Standardization implies less
flexibility.

> The lowest common denominator isn't the answer either, becuase then every
> app who wants higher than that will just reinvent it anyway!

That's exactly why I propose a dual-level API.

Cheers,

Dik