
 
***************************
Other projects Comparison :
***************************
                                 SF1           SF2          Gstreamer        MAS          LADSPA
Kind :                         Framework     Framework      Framework                  Plugin system
API in :                          C         C++ (C wrapper)     C                        C and C++
Network distributed  :            Y             Y               N             Y             N
Process blocs are process:        Y             Y               N                           N
Process blocs are threads         N             Y               Y                           N
Process blocs are pipelines       N             N               Y                           Y

Licence                         NIST PL     NIST PL            LGPL          MIT           LGPL
                                                 All are "OpenSource"

Application Field :             All data   All data       mostly A/V         A/V            A
Number of existing clients :     ~30           N/A             50+           ~20           ~10
Documentation :                 Average        N/A            Good           Poor          Poor
Dependancy :                      No            No            Gnome           X11           No
Have GUI schema builder tools     Yes          N/A             Yes            No            No
Network protocol                TCP and UDP    N/A             N/A         RTP or X11       N/A
        

*** Gstreamer : Low-latency process-only pipelining function blocs, A/V oriented. Thread can be used througt a 1toN cooperative thread library : cothread. 
Intersting points to reuse in the Smartflow:
- Have also an "event system" to allow one bloc to send short messages or commands to the others, 
- Good timestamp mecanism,
- Some ideas form the Memory management subsystem,
- XML diagram backup format (A/V oriented unfortunatly),
- An interesting plugin discovering and loading system.
- Other language bindings ( Java in particular )

This project cannot be used as a base for the Smartflow 2 because of the language used ( C with glib GObjects ) and its focus to the local machine area.
However, since the upper level API is very similar in concepts to the SmartFlow2 one, it should be possible to make a compatibility layer to allow GStreamer plugins to be used as Smartflow2 clients.

*** MAS : The Media Application Server is a project for audio and video similar to the X11 project for desktop rendering throught the network, it is destined to be integrated to it in the future.
Here is some interesting points :
- Like in the smartflow, clients are independant process that communicate with the server with a local unix socket.
- Data exchange is done through high-level protocol.

However, the aiming is more on high-latency slow connections rather the a high-end network :
- Exchange take place over the RTP or the X11 protocol only for now
- The server is a daemon ( must run at X11 startup or explicitly loaded ), network discovering is not dynamic.
- There is no direct client to client connection : the local server act as a proxy.

*** LADSPA : Linux Audio Developer's Simple Plugin API is a simple API for developing Audio filters. 
A number of filters are written using this API. It could be used to generate a lot of filters very easely since the same "code template" for an eventual smartflow integration could be reused for all the filters.

*************
Conclusion :
*************
All projects here are based on plugins, however the meaning of this word is different for each :
- In Gstreamer, 1 function bloc = 1 dynamic library (optionally threaded), the types of data are defined at compile-time.
- In MAS, 1 function bloc = 1 client.
- In LADSPA, 1 function bloc = 1 static library to link against.

Also, the kind and metadata for the transported data is different also :
- In Gstreamer, the type of the exanged data is fully known at compile-time ( That fit with the project goals however)
- In MAS, the type is also defined at compile-time for now, but the architecture can support a different approch,
- In LADSPA, the type is known at compile-time, that sounds good for a static library.

The purpose of the Smartflow is to use all the power of the object language to make the following :
- 1 function bloc = 1 process ( or at least a thread ).
- 1 type of data = 1 dynamic library.
Inheritance will then allow a client to manipulate an "Audio Flow" for exemple without knowing exactly all the caracteristics of it ( but that can be retreived from the instance if needed ).

For all project other than the SmartFlow 2, the focus is given to the Audio/Video functionalities, meaning that inside the library itself some type-related constants and functions are present. We wants to keep the type of data separated from the core system.

The possibility of reusing other system plugins directly ( if possible without recompilation ) must definitively be kept as an option for establishing SmartFlow2 as a polyvalent data exchange architecture.
By doing that, the smartflow could be immediatly compatible with a lot of already made plugins, for exemple audio out by OSS/ALSA/ESD/ARTSD/XMMS..., V4L Video Input, a lot of visualisation plugins, all the file readers and writers...
,  
**********************
Other documentation :
**********************
From the Gstreamer API doc :
----------------------------
GStreamer is a framework for creating streaming media applications. 
The fundamental design comes from the video pipeline at Oregon Graduate Institute, 
as well as some ideas from DirectShow.


No infrastructure is present to allow network transparent media handling.
A distributed MPEG encoder will typically duplicate the same encoder algorithms 
found in a non-distributed encoder.

No provisions have been made for emerging technologies such as the 
GNOME object embedding using Bonobo.
The GStreamer cores does not use network transparent technologies at the lowest 
level as it only adds overhead for the local case. That said, it shouldn't be 
hard to create a wrapper around the core components.
