Phonon xine backend future

[Ian Monroe]

On Tue, Feb 22, 2011 at 09:15, Colin Guthrie <phonon at colin.guthr.ie> wrote:
> '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...
>

Yes, perhaps not. The use case would be if someone wants to use PA on
a distro that doesn't normally use PA or vise-versa. Just moving the
decision on whether to use PA from compile-time to run-time.

It does sound like you are isolating the PA code well enough that if
later we wanted to do switch to make it plugin-based we could.

Ian