Phonon xine backend future

[Colin Guthrie]

'Twas brillig, and Ian Monroe at 22/02/11 14:36 did gyre and gimble:
> 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.

The #ifdefs are only needed as it's possible to compile phonon without
pulse-devel stuff installed (both on Linux sans-PA and on Windows/OSX etc).

I actually try very hard to keep the #ifdefs contained inside
pulsesupport.cpp (and pulsestream.cpp) rather than them leaking outside
to other files (although I think a couple of files do necessitate them).

In this case I'd hope to just check
PulseSupport::getInstance()->isActive() rather than using ifdefs directly.

>>> 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.

It could be made more generic indeed with PA just being one of
potentially many plugins. I'm just not sure it's really worth it...


Col


-- 

+------------------------+
|     Colin Guthrie      |
+------------------------+
| http://colin.guthr.ie/ |
+------------------------+