1567389 - cubeb-alsa causes sandbox violation in rdd

Status: RESOLVED FIXED

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

Description

[Jan Alexander Steffens [:heftig]]

Since the addition of rdd-opus, my Nightly has not been able to play YouTube videos (e.g. https://www.youtube.com/watch?v=COU5T-Wafa4).

The rdd process is crashing. Here's one such crash: https://crash-stats.mozilla.org/report/index/d82dc155-74a3-40b3-9631-ae97a0190718

The Nightly has been built with --enable-alsa. It seems that cubeb-alsa is causing a sandbox violation. STDERR contains:

Sandbox: seccomp sandbox violation: pid 32218, tid 32226, syscall 72, args 6 3 524289 50 140085654716448 0.  Killing process.

Comment 1

[Jan Alexander Steffens [:heftig]]

To clarify, I'm actually using pulse. Simply having ALSA support built-in is enough.

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

If I understand correctly, the Opus decoder needs to know if its output is going to be downmixed from stereo to mono… so it connects directly to the default audio output device and, in the process, starts up every configured backend, even though I wouldn't expect any of them to actually work in this context. I think it would make more sense to send the expected channel count down with the other decoder parameters.

mjf: Any ideas about this? (Or pointers to who'd know more about Opus?)

Comment 3

[Michael Froman [:mjf]]

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #2)

If I understand correctly, the Opus decoder needs to know if its output is going to be downmixed from stereo to mono… so it connects directly to the default audio output device and, in the process, starts up every configured backend, even though I wouldn't expect any of them to actually work in this context. I think it would make more sense to send the expected channel count down with the other decoder parameters.

mjf: Any ideas about this? (Or pointers to who'd know more about Opus?)

Tim, any thoughts here?

Comment 4

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Changing component because there seems to be rough consensus that the media code should be doing something different here.

Comment 5

[Michael Froman [:mjf]]

Pushing a patch to review soon.

Comment 6

[Michael Froman [:mjf]]

Attachment: Bug 1567389 - change OpusDataDecoder to check for CreateDecoderParams::Option::DefaultPlaybackDeviceMono instead of calling IsDefaultPlaybackDeviceMono(). r?bryce!

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7236b5a4468f
change OpusDataDecoder to check for CreateDecoderParams::Option::DefaultPlaybackDeviceMono instead of calling IsDefaultPlaybackDeviceMono(). r=bryce

Comment 9

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/7236b5a4468f

Comment 10

[Ryan VanderMeulen [:RyanVM]]

I'm a bit confused by the different regressing bugs attached to this bug. Does this affect versions older than 70? If so, is this something we should consider for uplift?

Comment 11

[Michael Froman [:mjf]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #10)

I'm a bit confused by the different regressing bugs attached to this bug. Does this affect versions older than 70? If so, is this something we should consider for uplift?

I don't think we need uplift. This bug is caused specifically by turning on decoding Opus on RDD which we turned on in 70. It just happens that decoding Opus on RDD can cause a sandbox crash because it was attempting to access audio hardware to determine whether the default playback device was mono.