[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 #20 from Tanu Kaskinen <tanuk at iki.fi> ---
(In reply to Leonard den Ottolander from comment #18)
> I understand that the group mapping is a useful thing for when an (audio)
> application is started and its stream is linked to a sink input for the
> first time. In that case you might want to restore a (group) setting that
> you used before.
> 
> The problem is that streams that automatically get remapped to another sink
> input - this happens "spontaneously" from the user perspective, probably as
> a result of a "stuttering" steam - also have these group settings applied.
> So the remapped stream now suddenly has different mute and volume settings,
> with a startling result.
> 
> So what the software should do is distinguish between these two situations:
> When a stream is first linked to a sink input (when the stream is
> created/started) it is fine to apply group settings, but when a stream is
> merely remapped to the next sink input no changes to volume and mute
> settings should be made.

"Stream" as something spanning multiple sink inputs is a concept you have
invented, and there's no reliable way to synthesize "streams" when all we have
is a series of sink inputs. 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. I agree, however, that using that heuristic would be a net benefit
compared to the current behaviour, at least as long as the application doesn't
create multiple simultaneous sink inputs.

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.
That would make the change described above ineffectual. My preferred solution
to your problem therefore remains that if you want separate volumes for three
mpg123 instances, the streams shouldn't be associated with the "mpg123 group"
to begin with. They should be assigned to separate groups by manually setting
module-stream-restore.id to a custom value.

> I don't claim to have a complete solution or even a partial one, only the
> suggestion: Make the software distinguish between initial mapping and
> remapping of input sinks so the restoration module can make a choice whether
> to apply the group settings or not.
> 
> I've only been studying the code since a few days and will certainly not
> claim to understand all the ins and outs or know how to implement the
> suggestion I make. It's just that I am looking for a solution to a situation
> where I suddenly hear (a possibly quite loud) stream coming from my speakers
> without having touched the volume settings.
> 
> I guess for now I have to live with providing a unique
> module-stream-restore.id via PULSE_PROPS to every stream I start to remedy
> this situation.

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.

-- 
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/20160127/4cf06f93/attachment.html>