Phonon xine backend future

[Harald Sitter]

Hi Artur,

On Mon, Feb 21, 2011 at 10:37 PM, Artur Szymiec <artur.szymiec at gmail.com> wrote:
> I wasn't watching last changes in the phonon development,
> however I heard that xine backend is going to be removed
> from phonon backends and gstreamer will be a main linux backend.
> Can anyone confirm that ?

No. Phonon Xine is not maintained and thus will not see releases.
GStreamer always was a main Linux backend as no one ever tested it on
other platform. Though I believe what you mean is that it will be
default on Linux which is also not exactly true as there is no default
but an initial preference based on how capable the backend is and how
well maintained it is. This intial preference currently rates
GStreamer highest, followed by VLC as there is some feature
difference. Though in turn I expect both to get the same initial
preference and chance will decided what gets chosen, or the user, or
the distributor...

> I'm afraid about the phonon equalizer in xine backend which is used
> by amarok. After switch to gstreamer the amarok will lost his equalizer.

If Amarok checked for the right name it would be working... Though
really the problem comes from a mis-designed part of the Phonon API
which is getting fixed in 4.4.5 (or so I hope).

> This also leads to maybe more deeper concern : do the audio processing
> plugins should be fixed in backend ? Could we make a interface which
> is backend independent - adding a possibility to the frontend app to handle
> the effects ? Wouldn't be this more flexible ?

We could, if someone thought up a design that actually made this
possible and at the same time allowed to scale from dumb to
sophisticated media frameworks, I personally do not see how though.
That is if I understood you correctly, that the application is then
capable of manipulating the audio/video streams directly. Which is a
difficult thing as the phonon backends would have to steal the raw
data from the underlying frameworks, hand it to the application and
then feed it back into the framework once the app is done with
whatever it may want to do. This can not work as less frameworky
backends (think MPlayer or VLC) cannot do such complex things. Even
for those frameworks that can do it, it is extremely difficult as
there is no sensible way to ensure time accuracy of the data across
the framework, phonon and the application. That said, we already
provide interfaces that do not need to care about feeding things back
to the framework. Like AudioDataOutput with which one can operate on
raw audio data, but cannot feed it back into the backend, which is
useful for analyzers for example.

regards,
Harald