[pulseaudio-tickets] [Bug 93855] Module restore restores volume and mute settings from wrong sink input

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jan 25 12:44:37 PST 2016


https://bugs.freedesktop.org/show_bug.cgi?id=93855

--- Comment #13 from Leonard den Ottolander <leonard-rh-bugzilla at den.ottolander.nl> ---
I'll try to rephrase.

I make 2 assumptions:

1) module-stream-restore.c is supposed to restore a stream, that is a sink
input or a source output, with its original volume and mute settings.

2) To be able to restore the correct volume setting the entry of the original
stream needs to be uniquely identified. Currently there is no mechanism to
uniquely identify such an entry. The entries are labelled with non unique
labels.


In the case where we have multiple instances of the same application (name)
pa_proplist_get_stream_group() will return multiple values because there are
multiple sink input entries with the same name (the application name in this
case).

if ((e = entry_read(u, name))) {

will loop through these values and apply the last value to the stream to be
restored. This causes the volume and mute settings to wander across the
restored streams. (See my original example.)

To remedy this situation it is necessary to be able to identify the one and
only original entry from which the volume and mute settings will be restored.
This can be achieved by setting a unique string for every entry. Because the
sink input id itself is unavailable in the property list I fall back on using
the pid related to the sink input, as this is a unique identifier, and the only
unique identifier in the property list.

It is not necessary to use the pid per se as we are not referencing the
application that runs under that pid in any way. All we want to do is to
identify the correct entry from which to restore the settings. So we need a
unique string, pid or random string, it does not matter. So as a fallback, in
case the pid is not available in the property list I use a randomly generated
string in pa_proplist_get_stream_id().

So the pid is only used to give the entry a unique id. We do not necessarily
have to use the pid, but the string identifying an entry must be unique. Also
mpg123 does not die, only the sink input gets remapped. The pid of mpg 123
actually persists, but this is not important for the issue we're dealing with.

What my patch does is to provide a new function pa_proplist_get_stream_id()
that uniquely identifies the entry. This way the volume and mute values of the
original stream (sink input) can be restored on the new stream.

If you think that this patch interferes with group filter application please
explain how that would work. (I understand it would if I had modified
pa_proplist_get_stream_group() as I did initially, but the last version of the
patch uses a separate function.)

Now in practice the patch works only for the mute value. For the volume it does
not, as there is volume remapping and scaling going on that should not happen
in the case of stream restoration. But this is another matter to be addressed
later. Lets start by making sure that the correct entry is referenced from
which the values are restored.

So although not perfect, at least the attached patch fixes the issue I was
having where remapped sink inputs suddenly got unmuted. It's a place to start
from, not a complete solution.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20160125/47de69ac/attachment.html>


More information about the pulseaudio-bugs mailing list