[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 #21 from Leonard den Ottolander <leonard-rh-bugzilla at den.ottolander.nl> ---
> "Stream" as something spanning multiple sink inputs is a concept you have
> invented,

Just trying to describe what I see. The mpg123 streams I have running
occassionally get remapped to a new sink input (see the sink input ids (first
field in the volinlistall output) change in my original example). So it's still
the same mpg123 instance (with the same pid - you cannot see this in the
output, but the three associated pids remain the same while the sink input ids
keep increasing -), now linked to the next sink input. And on the remapping to
the next sink input the group volume and mute settings gets applied, thus
changing these settings for an already running stream.

So in that sense, yes, the stream is "spanning" multiple sinks, in that it gets
remapped to the next and the next etc without user interaction while the mpg123
pids remain the same. How and where exactly in the code this is happening I
haven't figured out yet, but it happens.


> and there's no reliable way to synthesize "streams" when all we
> have is a series of sink inputs.

Well that is sort of the point, we can only work on series of sink inputs. A
mechanism to distinguish individual sink inputs is required to make it possible
to distinguish between actions on sink input groups and individual sinks.

Making available the sink input id and/or source output id in the property list
seems like an easy enough approach. I only used the pid in my patch because it
was the only property available that distinguishes the sink input uniquely.
Using the sink input id directly would of course be much cleaner, but for what
I tried to accomplish this would have required a much more intrusive and thus
larger patch.


As I tried to explain in my last comments there are two different situations
that should be handled differently, but the stream restore module does the same
thing in both cases:

1) A stream gets linked to a sink input initially. Applying group settings at
this point is fine.

2) A stream gets remapped to the next sink input (this is not a user action but
something pulse does on what for lack of a better word I call a "stuttering"
stream). In this case we only want to reapply the same volume and mute settings
the stream that gets remapped was initially using.

So we need a way to distinguish individual sink inputs and still be able to
access sink inputs as a group and the restore stream module needs to be able to
distinguish between the initial linking of a stream to a sink input and a
"spontaneous" remapping (as in caused by the software, not by user
interaction).

Settings for "live" individual sinks of course need not be cached on disk, just
to be available in the running application.


> The best heuristic I can think of is to consider all sink inputs from the
> same process to be part of the same stream, but that's not perfect.

Not sure if I understand what you say here. In this particular example there
are three /different/ mpg123 processes that all remain running under the same
pid. So they are all different processes, unless you mean something else with
"process" here...


> I still think, however, that volume changes to the group volume should update
> the volume of not only future streams, but all existing streams in that group.

It shouldn't be impossible to have both individual controls and group controls
and a way to let the user add members to a group (being it all applications
with the same name or individual (live) sink inputs). The problem is that pulse
currently only understands groups and not individual sink inputs and this seems
a major drawback to me.


> Why do you have three mpg123 instances running at the same time, by the way?
> If it's some permanent or repeating setup where each instance has its own
> defined role, you should define a group id for each role instead of
> generating a brand new id every time you start mpg123. That way the
> stream-restore database doesn't grow unnecessarily, and each mpg123 instance
> inherits the role-specific state.

Yes, I got this from your earlier explanation. The settings for every group get
cached on disk so using unique ids every time just fills up this cache with
stale entries.

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