1632093 - Firefox Nightly 77.0a1 (2020-04-21) Audio doesn't work

Status: RESOLVED FIXED

(Core :: Audio/Video: cubeb, defect, P1)

Description

[kokispro1]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Updated Firefox Nightly today and attempted to watch YouTube.

Actual results:

Audio didn't work. I tried Twitch.tv as well but I encountered the same issue. No sound came through on any sites.

Expected results:

Audio should've been heard.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Nico Grunbaum [:ng, @chew:mozilla.org]]

@kokiscpro1, thanks for filing this bug. Could you play some audio in Firefox and check your system sound settings to see if the system reset the per-application sound level for Firefox to zero? If so, does increasing that slider fix your issue? Additionally, would you mind sharing which Linux distro you are using?

This is what I experienced upgrading on the morning of this comment.

Comment 3

[Nico Grunbaum [:ng, @chew:mozilla.org]]

@chunmin, do you think that something we are doing could be causing the default application mixer volume to be zero in 77.0a1?

Comment 4

[Sid Vishnoi :sidvishnoi]

Can confirm. Audio has stopped working on all sites. I'm using Ubuntu 16.

Comment 5

[Alex Chronopoulos [:achronop]]

Anyone reproducing this, we need to know when it started happening. There is mozregression tool that can show that easily. Can you please try it and let us know if you find the offending patch? How many devices do you have in your system? Can you please copy here the Media section of about:support.

Comment 6

[Sid Vishnoi :sidvishnoi]

Unfortunately, I was not able to reproduce this with mozregression, maybe because I had manually changed my default application mixer volume after reading above and mozregression builds didn't reset it again. Can try to run it in a VM later unless someone else verifies it before me.

Pasting the media section from about:support here, though I doubt if it's useful anymore.

Audio Backend	pulse-rust
Max Channels	2
Preferred Sample Rate	48000
Output Devices
Name 	Group 	Vendor 	State 	Preferred 	Format 	Channels 	Rate 	Latency
Built-in Audio Analog Stereo	/devices/pci0000:00/0000:00:1f.3/sound/card0	Intel Corporation	Enabled	All	default: S16LE, support: S16LE S16BE F32LE F32BE	2	default: 48000, support: 1 - 384000	0 - 0
Input Devices
Name 	Group 	Vendor 	State 	Preferred 	Format 	Channels 	Rate 	Latency
Monitor of Built-in Audio Analog Stereo	/devices/pci0000:00/0000:00:1f.3/sound/card0	Intel Corporation	Enabled	None	default: S16LE, support: S16LE S16BE F32LE F32BE	2	default: 48000, support: 1 - 384000	0 - 0
Built-in Audio Analog Stereo	/devices/pci0000:00/0000:00:1f.3/sound/card0	Intel Corporation	Enabled	All	default: S16LE, support: S16LE S16BE F32LE F32BE	2	default: 44100, support: 1 - 384000	0 - 0

Comment 7

[Alex Chronopoulos [:achronop]]

We have landed something volume-specific in Nightly 20200421222503. We are trying to verify that this is the problem. If anyone has an indication that sound was working before and it has stopped working on this Nightly please let us know.

Comment 8

[Mats Palmgren (inactive)]

I was having the same issue, so I downloaded a build just before 20200421222503 to check and it worked. Then I tried a few later builds including the latest Nightly (that I was having issues with in the first place) and now it suddenly works! Hmm... I wonder if the issue will return after I reboot...

Comment 9

[Alex Chronopoulos [:achronop]]

Thank a lot this is very helpful. The problem with that bug is that once it is fixed (from the earlier version), it cannot be reproduced again to any later version. Thus the next step, for anyone that would like to help, is to narrow down the commit range. This can be done with the steps below.

1. Verify that Nightly 20200421222503 still has the problem.
   I copy the link here to make it easier: https://ftp.mozilla.org/pub/firefox/nightly/2020/04/2020-04-21-22-25-03-mozilla-central/firefox-77.0a1.en-US.linux-x86_64.tar.bz2

2. Verify that previous Nightly fixes the error.
   Link of previous Nightly: https://ftp.mozilla.org/pub/firefox/nightly/2020/04/2020-04-21-09-42-20-mozilla-central/firefox-77.0a1.en-US.linux-x86_64.tar.bz2

Since step 2 is successful you can expect that the problem has been solved for any following version.

Thank you in advance

Comment 11

[Alex Chronopoulos [:achronop]]

Attachment: Bug 1632093 - Update cubeb-pulse-rs. r?padenot

Comment 12

[Alex Chronopoulos [:achronop]]

Attachment: Bug 1632093 - mach vendor rust. r?padenot

Depends on D72729

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/95e2e3ed2d3e
Update cubeb-pulse-rs. r=padenot
https://hg.mozilla.org/integration/autoland/rev/a2309afba631
mach vendor rust. r=padenot

Comment 14

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Alex, I was unable to reproduce this using mozregression.

Comment 15

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/95e2e3ed2d3e
https://hg.mozilla.org/mozilla-central/rev/a2309afba631

Comment 16

[Karl Tomlinson (:karlt)]

Plausibly something was remembering a volume that Firefox had set on a previous stream and applying that to new streams.

That could be consistent with my experience that bug 1422637 did not demonstrate until an OS update; after the OS update, bug 1422637 demonstrates even on previous Firefox versions. This is also reported in bug 1515549 comment 18.

Comment 17

[C.M.Chang[:chunmin]]

Keep a regression record so we can have a better understanding for bug 1422637