API proposal: Phonon BackendInfo

[Harald Sitter]

On Mon, Sep 10, 2012 at 4:12 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
> Couldn't the pulseaudio stuff be considered platform integration?

Yes.

> I
> would be happy enough with a string indication which platform phonon
> and it's backends are using. example: "linux (pulseaudio)", "linux
> (ALSA)", "Windows (DirectSound)", ... And yes, I do want the OS in
> that string. Our diagnostics dialog is easy to copy paste by
> inexperienced users and it's good confirmation that they are actually
> using the platform they are talking about.
> Since we are building for windows and apple OSX as well, don't want to
> ifdef in the diagnostics dialog when it's not really needed, so
> provide a platform independent function returning platform specific
> info please.

On a technical level backend-using-pulseaudio does not need to imply
frontend-using-pulseaudio. In particular in pgst we try to force pulse
on the backend when libphonon has pulsesupport, however when the
frontend has no pulsesupport the backend may select a sink at
semi-will which may still result in pulseaudio being used in the
backend, even though libphonon has no explicit support for it.

But, this is not actual backend information but AudioOutput dependent
(e.g. if you set AO1 to use device1 and AO2 to use device2, AO1 may be
using ALSA whereas AO2 is using OSS). Proposed interface addition:

/** \returns used output type (e.g. directx, alsa, ...) */
QString AudioOutput::outputType() const;

You would then query each of your AOs for the output type and list
that in your diagnostics. To query libphonon's ability to support
pulse you'd still use PulseSupport::isActive(). Incidentally enough it
saves everyone a headache if you simply assume every platform can
support pulse and list it regardless in your diagnostics dialog.

As for the operating system names:
http://qt-project.org/doc/qt-4.8/qsysinfo.html that ought better be
handled in the apps, not Phonon.

HS