Comparison: MAS, GStreamer, NMM - ARTS?

Roger Larsson roger.larsson at skelleftea.mail.telia.com
Wed Aug 25 23:37:19 BST 2004


On Wednesday 25 August 2004 14.49, Marco Lohse wrote:
> Hi there,
>
> from the feedback we got at the KDE conference I think one important
> thing for KDE multimedia developers (as well as for other multimedia
> developers) would be to have some comparison between MAS, GStreamer,
> and NMM.

What about ARTS?

And why should we kick out the current KDE interfaces?
Can playing a mp3 be simpler than it currently is?

My problem with ARTS is that it is difficult to fix internal problems, due to 
duplicated code and functionallity:
- several pluggins handles Ogg - or did not long time ago.
- two different flow systems for sound (my feeling, arts own and gstreamer)
- unoptimal use of hardware resources (don't mix/resample when the lower
  level driver or hardware can do it)
- what about syncronization of audio/video (with audio pluggins)
- support of "standard" stuff; LADSPA, Jack, ... (have improved recently)

>
> We would like to start this comparison with a look at two things:
>
> (1) the programming models (i.e. what code you have to write down to
> achieve certain things) and
> (2) the APIs provided by the different frameworks (in correspondance
> to Matthias Ettrich's statement "the API is to the programmer what a
> GUI is to the end user").
>
> Therefore, we would suggest that for every project the source code for
> a number of helloworld programs is provided. The first program
> (helloworld I) should demonstrate how following features can be
> accessed:
>
> (1) Allow the playback of an encoded audio file (e.g. MP3). This will
> result in similar setups: a component for reading data from a
> file connected to a component for decoding connected to a component
> for audio output. (Together, this is called "pipeline" or "flow
> graph").
> (2) Set the filename of the file to be read.


KAudioPlayer::play("path/file");


> (3) Manually request/setup this functionality, i.e. no automatic setup
> of flow graphs.

For a programmer this is the equivalent of CLI...

> (4) Include some error handling.

- file does not exist?
- no device?
- device busy?

And some optimizations
- Caching of files, possibly decoded (to play the same file several times)

> In a second step, we would like to extend the helloworld program with
> following feature (helloworld II):
>
> (1) Add a listener that gets notified if the currently playing file
> has ended, i.e. this listener is to be triggered after the last byte
> was played by the audio device.

How precise can you do this?
(audio devices has a buffer of different length, alsa and oss might buffer 
too...)

>
> In a final step, we would like to extened the helloworld program
> (helloworld I) to allow for distributed playback (helloworld III):
>
> (1) The component for reading data from a file should be located on the
> local host. The component for decoding, and playing the audio data should
> be located on remote host.

(1b)  remote file, local decode, local play
(1c) remote file, local decode, remote play

>
> Notice that this third example should also demonstrate how easy (or
> painful) it is to develop networked multimedia applications using the
> particular framework. We hope that this will finally show that
> developing distributed multimedia applications means more than "well,
> simply write a component for streaming data and put that into your
> pipeline".
>
> We think that these three examples provide typical features needed for
> developing multimedia applications. Furthermore, these features are
> simple enough to be provided for all three frameworks. Therefore, we
> hope that the developers of MAS and Gstreamer are willing to
> participate in this comparison.
>
> For NMM, see following links:
>
> helloworld I
> http://graphics.cs.uni-sb.de/NMM/current/Docs/helloworld/x62.html
>
> helloworld II
> http://graphics.cs.uni-sb.de/NMM/current/Docs/helloworld/x122.html
>
> helloworld III
> http://graphics.cs.uni-sb.de/NMM/current/Docs/helloworld/x145.html

I would like to add:

	Replacement classes for backward compatibility.
	Start really simple with KAudioPlayer only.

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden



More information about the kde-multimedia mailing list