Re: [xine-devel] Re: Equalizer [was: [xine-cvs] CVS: xine-lib/include xine.h.in,1.76,1.77]

[Miguel F. <mi...@ce...>]

hi guenter,

On Mon, 2003-04-21 at 19:07, Guenter Bartsch wrote:
> > well, you are right about that: so far, post plugins must be wired by
> > the frontend explicitly. however this is probably no more than about 5
> > lines of code.
> 
> i think that will be at least an _additional_ 5 lines of code (you still
> have to set gain levels). how do you handle activation of the plugin?
> live rewiring? - doesn't work reliably and certainly adds another 10
> lines of code - and all that just to get a simple equalizer?


not true. any frontend that wants equalizer can wire it only once and
leave it there for the entire live of the xine_stream_t instance.

also, interface to set levels can be exactly the same or better than
what you already implemented.


> again: if
> you want to implement this, go ahead, don't let me stop you - just let
> my equalizer where it is and i'll be happy :)


very democratic. ;-)
no thanks, i won't write another equalizer.

however i have a similar case that i'd like to work in the long run:
move deinterlacing algorithms to post plugins were they belong, and try
to make the transition as transparent as possible to frontends. that
will make possible to use deinterlacing not only for xv, but with other
video drivers as well.

 
> why not have it load automatically? why not give frontends an
> easy-to-use, obvious interface here?


actually this is something i'm thinking about, because it will be needed
for the deinterlacer plugin (specially for keeping compatibility with
existing frontends).

how should we proceed? have a flag on post plugins that make then be
registered to new streams automatically? i don't like much that option
because simple frontends, libxine bindings, or apps like enix, wouldn't
be able to create a plain xine_stream_t with no post plugins attached.

one option i'm thinking is: while moving algorithms to a separated
plugin, xv driver will keep it's own deinterlacing mechanism. this way
XINE_PARAM_VO_DEINTERLACE would still work even without post plugin
loaded. in order to have more advanced algorithms the frontend would
need to load the plugin.


> a small compromise: if you're really that unhappy with the bands from
> wmp, we can switch to the ones from xmms so it's presets will work
> flawlassly (actually i believe they would still work with the currently
> implemented bands as the difference is rather small and those presets
> are nothing more than rough approximations and don't really emulate
> what is written in their name - to really get arena sound or club sound
> it takes much more than a simple equalizer)


well, if i were to choose between wmp and xmms/winamp to keep
compatibility with i would certainly take the later. but don't consider
just my opinion here, i'd like to hear from other developers as well...

 
regards,

Miguel