[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 #22 from Tanu Kaskinen <tanuk at iki.fi> ---
(In reply to Leonard den Ottolander from comment #21)
> > "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.

When the old sink input dies and the new one is created, it means that mpg123
closed and reopened the alsa device (the pulse plugin in this case). PulseAudio
doesn't destroy/create sink inputs behind mpg123's back.

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

Putting the sink input index in the proplist would achieve nothing. When the
previous sink input dies and mpg123 creates a new one, the two sink inputs have
different indexes, and therefore the index provides no link between the two
sink inputs.

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

As far as pulseaudio is concerned, a stream and a sink input is the same thing.
There's no "linking" outside your own mental model that treats the two things
as separate concepts.

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

There's no way to reliably distinguish "spontaneous remapping" from other kinds
of sink input creation. Only heuristics can be used, such as treating all sink
inputs from the same process as being part of the same "stream". A reliable
mechanism would be to require the application to attach a "stream id" to every
sink input it creates, then pulseaudio could compare the stream ids of two sink
inputs and treat them as the same stream if the ids match. But no such
identifier is provided by any existing 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 use "process" and "pid" in the meaning that the kernel uses those terms.
"PID" is short for "process identifier". In that meaning it's not possible to
have three simultaneous processes with the same pid, so I wonder what meaning
you assign to those terms.

-- 
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/20160128/53b7c4df/attachment.html>