xine backend equalizer plugin [patch] [resend]

[Ian Monroe]

On Thu, May 21, 2009 at 2:17 PM, Artur Szymiec <artur.szymiec at gmail.com> wrote:
> Dnia 2009-05-21, czw o godzinie 14:05 -0500, Ian Monroe pisze:
>
> I guess one concern I have is that you use headers with ominious names
> like "xine_internal.h".
>
> I wouldn't doubt you that your equalizer is better's then Xine's
> (since Xine's always made things quiet sounding), but perhaps an
> improved equalizer would be better pushed upstream to Xine then? I'd
> rather just use what Xine provides and not have to worry about
> something breaking with different versions of Xine.
>
> Ian
>
> Well regarding pushing it to upstream (means xine devel) - a year ago I
> prepared a patch that
> gave a xine better equalizer (2nd order IIR) but it was so though to
> convince the head developer
> of xine that it really makes the difference if you use floating point data
> instead of fixed point that I gave up.
> I will not count on pushing it into xine stream - it's very conservative
> development stream.

Ok, this doesn't surprise me either. :) I'm glad you tried to send it
upstream first.

> I hope this equalizer is opportunity to give a phonon (and by that also to
> Amarok) a better sound and that will not fall into void.
> Xine also doesn't provide fade plugin - I think while it's implemented as
> xine plugin (kvolumefader) for phonon use - so it can be equalizer.

True.

> Regarding use of xine_internal.h - I'll review it asap and let you know.

Well that was mostly an example. Like the Amarok 1.4 visualizations
rely on a custom xine plugin that would've had to be rewritten if Xine
ever made a new major release (not sure how likely that is).

Ian