Phonon xine backend future

Ian Monroe ian at monroe.nu
Tue Feb 22 15:36:15 CET 2011


On Tue, Feb 22, 2011 at 08:31, Harald Sitter <sitter at kde.org> wrote:
> On Tue, Feb 22, 2011 at 3:13 PM, Ian Monroe <ian at monroe.nu> wrote:
>> How do you plan to have this implemented? How do we make this cross-platform?
>
> I imagine it would be like the volume stuff etc. PulseSupport would
> just intercept the call to the appropriate API interfaces and thus
> override the backend's EQ. That is pretty much a nobrainer, just a
> couple of ifdefs around the PulseSupport interception code.

ifdefs? That kind of sucks.

>> I know what we want from the end-user perspective: that the same
>> client code with PA would work without PA if the multimedia backend
>> has support for  the eg equalizer.
>
> Which would be the case. PA would just override an implementation in
> the framework/library.
>
> Example:
> * app queries for effects
> * (new and improved) API returns a list of enum values of effects
> * PulseSupport checks if list contains EQ, if not -> adds it
> * app wants to use EQ
> * PulseSupport intercepts call within libphonon and processes it in
> place of the backend
> * app manipulates EQ settings
> * PulseSupport intercepts call within libphonon and once more
> processes it in place of the backend
> ...
>
> This scales very well, PA just sits between API consumer and the
> backend when Phonon is built with PA support.

This makes sense. But I wonder if we shouldn't make a less-C-macro way
of doing all of the above though. Basically we'd have a new sort of
plugin that would be queried before volume changes or the effect list
is returned. It would like you have it, just with plugins instead of
PA/no-PA.

Ian


More information about the Phonon-backends mailing list