[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 #23 from Leonard den Ottolander <leonard-rh-bugzilla at den.ottolander.nl> ---
> 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.

Right... Thanks for clearing that up. This was the essence of my
misunderstanding. I thought pulse was responsible for the remapping and hence
should be able to track the sink input change.

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

Yes, right.

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

Never mind, just misreading what you wrote. I read "all sink inputs from the
same process" as "all simultaneous sink inputs", as if you were thinking that
one mpg123 instance was providing multiple streams, which of course you were
not ;) .

So yes, tracking the pids associated with the sink inputs to establish that a
sink input has been remapped seems like a usable approach to avoid sudden
volume and mute setting changes. That requires a second IDENTIFICATION_PROPERTY
that should only be stored internally.

-- 
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/9effab29/attachment-0001.html>