Comparison: MAS, GStreamer, NMM - ARTS?

[Marco Lohse]

Roger Larsson wrote:

>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?
>
you are perfectly right, and I did not mention aRts in my first email. I 
appologize and I will add arts to this webpage I posted the link to.(Or 
does anyone want to provide the source code for helloworld I, II, and 
III for aRts?) However, I assumed that KDE developers (and other 
multimedia developers) as well are more familiar with arts then NMM for 
example.

>
>And why should we kick out the current KDE interfaces?
>
Oh my goodness, I did not make any suggestions in this direction. I do 
know much too little about KDE to make any statements like that (and 
never did).

The idea for doing this comparison was to get other people started using 
MAS, GStreamer, and NMM easily. That is what a lot of people asked for 
at the conference. From my experience, a couple of helloworld programs 
usually does a good job. If this also allows to compare the programming 
model and the API of the frameworks, that is fine, isn't it?

>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...
>
Can you provide some source code for that?

>
>  
>
>>(4) Include some error handling.
>>    
>>
>
>- file does not exist?
>- no device?
>- device busy?
>  
>
Yes, I knew that this point would raise some questions since error 
handling can be done in many ways. Let's just say 'error handling' 
means: when something goes wrong, print out the reason for that, do a 
proper clean-up, terminate.

>And some optimizations
>- Caching of files, possibly decoded (to play the same file several times)
>  
>
I am not sure if all frameworks do provide that feature.

>  
>
>>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...)
>  
>
Yes, I also knew that this point would raise questions, basically 
because I didn't make it really clear. Let's just say: when the last 
media buffer was handled by that sink plug-in (e.g. written to the audio 
device).

>  
>
>>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
>  
>
yeah, great :) This is very easy to achieve using NMM: you only need to 
set other locations for the particular plug-ins. If this is feature that 
can be provided by the other frameworks as well, let's include it.

>  
>
>>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.
>  
>
Could you be more precise, please? Or maybe provide some source code? 
That would be great, thanks,

have fun, Marco.

>  
>