1739326 - WebRTC - Unable to record audio input

Status: RESOLVED WORKSFORME

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

Description

[bugzilla.mozilla.org.10y7j]

Attachment: about-support.txt

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

Steps to reproduce:

Linux Gentoo Firefox 94.

Using microphone on the Mozilla gUM test page or other pages that try to record audio. It should be noted that running "pacat -r" from the command line records audio normally.

Actual results:

The audio recording seems to start but no sound is delivered. Audio output from videos etc. works.

Having cubeb.sandbox enabled, the whole browser freezes after changing tabs or waiting for a while. Disabling cubeb.sandbox does not cause a freeze, but does not help with audio recording.

Expected results:

The audio should be recorded normally.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: cubeb' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Paul Adenot (:padenot)]

Reporter, do you know of anything special on your setup? cubeb.sandbox.enabled is supposed to always be enabled, because the child process sandbox is likely to prevent the system calls necessary for audio to work on child processes (which is intended: we don't want child processes to be able to perform those system calls).

Additionally, has that always happened, or maybe after a Firefox update, an update to your distro?

It is surprising that it makes the whole browser freeze like this. Would you mind getting us logs so we can have a look, since we can't replicate the problem on our setup?

After closing all Firefox instances, running the following in a terminal will produce a series of files starting with logs-firefox in the current working directory, if you could zip them up and attach them here or send at <[e-mail]>, it would be a good start. Please substitute the final part of the command with the path to the binary on your file-system.

MOZ_DISABLE_CONTENT_SANDBOX=1 RUST_LOG=audioipc=debug MOZ_LOG=cubeb:4,MediaManager:4,timestamp MOZ_LOG_FILE=logs-firefox /usr/bin/firefox

If you could simply use https://mozilla.github.io/webrtc-landing/gum_test.html, and click Microphone, it would be good, since this is a very simple website that allows ruling out any other cause (it just opens the mic and plays it back locally).

Comment 3

[bugzilla.mozilla.org.10y7j]

Attachment: equery-uses-firefox.txt

Comment 4

[bugzilla.mozilla.org.10y7j]

Attachment: logs.zip

Comment 5

[bugzilla.mozilla.org.10y7j]

(In reply to Paul Adenot (:padenot) from comment #2)

Reporter, do you know of anything special on your setup? cubeb.sandbox.enabled is supposed to always be enabled, because the child process sandbox is likely to prevent the system calls necessary for audio to work on child processes (which is intended: we don't want child processes to be able to perform those system calls).

Additionally, has that always happened, or maybe after a Firefox update, an update to your distro?

It is surprising that it makes the whole browser freeze like this. Would you mind getting us logs so we can have a look, since we can't replicate the problem on our setup?

After closing all Firefox instances, running the following in a terminal will produce a series of files starting with logs-firefox in the current working directory, if you could zip them up and attach them here or send at <[e-mail]>, it would be a good start. Please substitute the final part of the command with the path to the binary on your file-system.

MOZ_DISABLE_CONTENT_SANDBOX=1 RUST_LOG=audioipc=debug MOZ_LOG=cubeb:4,MediaManager:4,timestamp MOZ_LOG_FILE=logs-firefox /usr/bin/firefox

If you could simply use https://mozilla.github.io/webrtc-landing/gum_test.html, and click Microphone, it would be good, since this is a very simple website that allows ruling out any other cause (it just opens the mic and plays it back locally).

My setup is Firefox compiled from sources on Gentoo. I added the USE flags list for Firefox, which should give an idea on which compile flags are being used.

I recently upgraded media-sound/pulseaudio to 15.0 from 13.0 and Firefox from 93 to 94 at the same time. I also got a power outage (not during the compilation or installing) which got me thinking if there was some temporary thing left in bad state. I tried removing pulse cookie, refreshed Firefox, ran Firefox in troubleshoot mode, deleted my $HOME/.mozilla directory. None of those helped.

I ran Firefox with logging and tested with the gum_test page as you requested. Funny thing is that if I compile Firefox with debug USE flag set, the microphone starts working. I also added logs from running with debug flag enabled.

What should be noted is that the freeze does not happen directly from trying to record audio, it happens when I try to open a new tab.

Comment 6

[Paul Adenot (:padenot)]

Real weird. Is the crash in about:crashes ? Maybe you could link a couple here to check? Are you able to see the permission prompt in a non-debug build, or is it stuck after clicking the "Microphone" button on the page above?

Matthew, in the log above, there is no activity at all in the parent (with audioipc debug logging enabled), but only in release mode, debug seem to work fine, is that something known? Maybe some other logging level or module is needed?

Comment 7

[bugzilla.mozilla.org.10y7j]

Okay, I think I found the issue.

I did some digging around, looking at the logs and so on and noticed that sometimes cubeb got hung at E/cubeb stream.rs:639: Stream stop: waiting for drain.

I found this after some searching: https://github.com/mozilla/cubeb-pulse-rs/commit/9695281319fcb3e40db6a32cc0661548d6192f4d

I installed rust-1.55.0, recompiled Firefox and the audio recording works fine! I think messing around with the debug flag made something happen slow enough that the race condition did not happen.

Thanks for your help! Hopefully the audio will work with newer rust version soon.

Comment 8

[Karl Tomlinson (:karlt)]

Thanks for the analysis. I'll mark this WFM assuming the deadlock is resolved with bug 1735905.
Please feel free to reopen if the deadlock returns with Firefox 95 or newer.

Comment 9

[Matthew Gregan [:kinetik]]

(In reply to Paul Adenot (:padenot) from comment #6)

Matthew, in the log above, there is no activity at all in the parent (with audioipc debug logging enabled), but only in release mode, debug seem to work fine, is that something known? Maybe some other logging level or module is needed?

I believe that's bug 1611990. It might be worth switching audioipc over to cubeb_log; I'm not sure there's a lot of value having a separate audioipc log target - filed bug 1740141.