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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #15 from Tanu Kaskinen <tanuk at iki.fi> ---
(In reply to Leonard den Ottolander from comment #13)
> 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.

A single sink input or source output is an ephemeral object. A sink input gets
created once and when it dies, it will never appear again, so there is nothing
to restore later. Since there is nothing to restore, I still don't understand
what you mean when you are restoring the volume "of a single unique stream".

module-stream-restore defines the grouping by which sink inputs are associated
with each other, and then restores the last user-configured volume for all sink
inputs in the group. If you use the pid as the group id, all streams created by
the same process are grouped together, and if you use a random string, no
grouping happens at all, and as a result module-stream-restore doesn't have any
effect on anything, and therefore using a random id is equivalent with not
having module-stream-restore loaded at all (except that the hard disk fills
with ever-growing set of stream entries that are never going to be used again).

> 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).

No, there is only one entry per stream group.

> 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.)

It doesn't "wander" (if by that you mean that the process is somehow
undeterministic). The last user-configured volume is consistently restored for
new streams.

-- 
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/20160126/37651522/attachment.html>