[gst-devel] plugin directory/hierarchy

[Thomas Nyberg]

On Wed, Mar 07, 2001 at 07:08:30PM -0800, Simon Per Soren Kagedal wrote:
> On Wed, Mar 07, 2001 at 11:39:07PM +0100, Thomas Nyberg wrote:
> 
> > If you are writing an application, you should not assume that a given
> > plugin exists on the system. Perhaps you want to use an alas_sink if it
> > exists - else an oss_sink. Perhaps someonee has renamed the oss_sink into
> > audio_output-sink. This is a real problem I believe.
> 
> Wouldn't it be a good idea to have a general audio sink for audio
> applications to use, and then this sink would be ghosted to whatever
> kind of sink the user has selected (through, I don't know, environment
> variable maybe) - OSS, ALSA, ESD, aRts, DAW systems, Solaris audio,
> uhm, NAS - you get the picture. :) This way, GStreamer could also
> easily work as common API for disgruntled audio prorgammers who are
> getting sick of the number of sound systems they need to support. 
> 

Well, that would be nice. However, imagine using multiple soundcards at
the same time. In this case, the user will need to select which card
which streams should go to. There are some more or less pretty ways
to do this. If one looks in the plugins/filters/ladspa/gstladspa.c
you see that it creates a factory for each type of ladspa-plugin present
on the system. In this case, the user will _want_ to select the plugin
to use. There is no way to autoplug this one.

If the application could gå through all availible factories and pick out
all that is marked "Audio/Filters"(or something like that) then it
would be easy to put those found in a nice menu. The user gets a nice
interface, the application suddenly supports all filters installed on
the system. If this wasn't possible, the only way would be for the
app-programmer to write snippets of code to handle each possible filter
existing on earth! That is not possible. ;)


Ofcourse, it would be nice to have a common factory in the line with
audiosrc and audiosink. They could exist, and only act as a dummy-factory
for the other possible output-elements. By setting a nice environment-var
it would then be possible to redirect the soundoutput to disk, bypassing
applications. But as I said earlier, applications may want to be able ot
override this behaviour by selecting from the output's availible.

The only way to do this, as I see, is to have a common standard for these
types - allowing the app-programmer to be certain that what he has done
should work with everything on the system.

-- 
Thomas Nyberg                    thomas.nyberg at codefactory.se
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 10       Cell: +46 (0)70 335 61 64