Bug#996880: unconditionally unpauses media playback after call

[Dennis Filder]

X-Debbugs-CC: Timo Weingärtner <timo at tiwe.de>

On Wed, Oct 20, 2021 at 09:19:14AM +0200, Timo Weingärtner wrote:
> Package: linphone-desktop
> Version: 4.2.5-3
> Severity: normal
>
> steps to reproduce:
> * have any positive number of paused youtube videos opened in firefox
> * maybe wait hours or days after pausing the last one
> * call someone using linphone
> * end the call
> * be surprised that one of the videos resumes playback
>
> suggested solution:
> * remember whether there was media playback running when the call starts
> * only resume playback if it was running before the call

I have very strong doubts that linphone-desktop (or rather
libmediastreamer2) is the culprit here.  A pulseaudio client
disconnecting should leave other clients untouched, and clients
usually have no way of affecting other clients anyway.  This leaves
pulseaudio itself and Firefox as suspects.

Linphone creates its pulseaudio streams with the property
media.role="phone" which pulseaudio internally gives higher priority
so that when you get a phone call while watching a movie, the movie
stream gets automatically corked for the duration of the call and then
uncorked.  The event-handling code in Firefox probably does not deal
with that correctly leading to the unpausing.  This would also make
sense because the decision to pause/resume playback happens entirely
in the code of a pulseaudio client.

The pulseaudio backend code in Firefox currently is under:
91.2.0esr-1/third_party/rust/cubeb-pulse/src/backend/

Upstream at: github.com/mozilla/cubeb-pulse-rs/

What version of Firefox are you running?  It would also help a ton if
you could state if this bug happens with the Firefox nightly builds
from mozilla.org, too.

If you want this to ever get even close to being fixed you'll have to
find a way to reproduce the issue quicker somehow (restarting
pulseaudio, disconnecting and reconnecting network/Internet connection
etc.).  After that you should start Firefox like this:

  MOZ_LOG="cubeb:4" firefox --new-instance 2>&1 | tee /tmp/ff-cubeb.log

then reproduce the issue and post that log file here.  That will
hopefully generate enough clues to figure out what is happening.

I'll reassign the bug to firefox-esr unless I hear convincing
arguments for why the cause is to be sought elsewhere.

Regards.