upcoming phonon4 changes

[Harald Sitter]

Alohas,

so I don't forget and everyone is in the loop.
VLC is getting API to allow us to stop using pulsesupport. Namely a
way to force a role (i.e. category) and get events on outside volume
and mute changes.

So the plan now is to stop using pulsesupport entirely. This is
somewhat tricky because we are actually doing things in libphonon
(frontend) that we have no knowledge over in the backend. All of this
has ultimately to do with pulsesupport so we need interface expansions
to get rid of this "magic".

# reactive muteness
Currently the frontend audiooutput has "muted" as a property and a
signal for when it changes as well as getter and setter. Previously
this was entirely sync and calling setMuted() would always directly
trigger the relevant mutedChanged() signal (even when PA was used mind
you).

This ultimately needs to go away and setMuted needs to become 100%
async. It needs to mute the backend and the backend tells us when
muteness is reached.
To that extent AOInterface is getting a mutedChanged() signal for
implementation.

# active muteness
Along the same line goes how we mute things currently. While the
frontend has a concept of mute the backend does not what the backend
gets is inferred meaning where volume 0.0 == mute and volume >= 0.0
!mute. This is generally a reasonable thing since certain pipelines
cannot actively support muteness (digital passthrough I think?) and in
those cases volume 0.0 is certainly the best possible mute that can be
achieved.
BUT
Volume 0.0 is not the same as mute in terms of outside API. e.g. in
Pulse there is a distinct mute property, as is in our frontend API, as
is in every player UI. So, by only telling our backend about the
volume but not the mute value the backend only can infer that 0.0 ==
mute which is a problem because we cannot fake the volume to the
outside (such as pulseaudio) -> http://i.imgur.com/zFagana.jpg

Up until now this wasn't that big a deal since PulseSupport actively
intercepts the mute call into the backend and actually mutes the
output. In a world without PulseSupport however this cannot go on.

So, I think the best solution is to also offer setMuted as an
interface function and let the backend figure out how to best mute.
I'd expect the best version to be an active mute and if that doesn't
yield muteness in <=0.5 seconds set the volume to 0.0 and simulate
muteness that way.

HS
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia