User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Steps to reproduce: I opened firefox, the youtube, clicked on a video which resulted in no sound. In order to find the cause i did as follows: 1. Open firefox from terminal 2. Attempt to play sound. Actual results: No sound was played and the following was seen in the terminal: Sandbox: seccomp sandbox violation: pid 9267, tid 10331, syscall 16, args 42 2147767296 139954395301288 0 0 0. [Child 9267, MediaPlayback #1] WARNING: 7f49991f5100 OpenCubeb() failed to init cubeb: file /builddir/firefox-58.0.1/dom/media/AudioStream.cpp, line 387 [Child 9267, MediaPlayback #2] WARNING: Decoder=7f49a03f4c00 [OnMediaSinkAudioError]: file /builddir/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, line 3642 Expected results: Sound should have played.

Do you have pulseaudio installed? We require that for sound output.

Matthew, is the cubeb error message consistent with not having pulseaudio? Any idea what else might be wrong?

> Sandbox: seccomp sandbox violation: pid 9267, tid 10331, syscall 16, args 42 2147767296 139954395301288 0 0 0. This is likely the root cause, the sandbox is denying an ioctl(). AFAIK this shouldn't be triggered by a client connecting to PulseAudio, so either the PA server is trying to start on-demand from within the sandboxed environment, or ALSA is involved somehow (if this is a non-official build). Is this an official mozilla.org build, a distro build, or something else? What does about:support report for the audio backend?

(In reply to Ralph Giles (:rillian) | needinfo me from comment #1) > Do you have pulseaudio installed? We require that for sound output. (In reply to Matthew Gregan [:kinetik] from comment #3) > > Sandbox: seccomp sandbox violation: pid 9267, tid 10331, syscall 16, args 42 2147767296 139954395301288 0 0 0. > > This is likely the root cause, the sandbox is denying an ioctl(). AFAIK > this shouldn't be triggered by a client connecting to PulseAudio, so either > the PA server is trying to start on-demand from within the sandboxed > environment, or ALSA is involved somehow (if this is a non-official build). > > Is this an official mozilla.org build, a distro build, or something else? > What does about:support report for the audio backend? I do have pulseaudio installed. I am using the build provided by void linux. When checking audio backend it says it uses alsa.

Thanks! It looks like Void builds optionally enable PulseAudio and ALSA based on the template (https://github.com/voidlinux/void-packages/blob/f45a61dab06471714b229b3baed6fc945e2b6ee4/srcpkgs/firefox/template), but I haven't found the binary build so I'm not sure what the default configuration is. Either PulseAudio is disabled in your build (run `ldd` on the Firefox binary and see if it links against libpulse), or we're falling back to ALSA after Firefox failed to connect to the PulseAudio server (enable logging in the PA server and watch the logs as you start Firefox and try to play audio). One common failure we're seeing is that the PulseAudio server is not running before Firefox is started, and the PA client tries to autospawn the PA server, which fails due to sandbox restrictions. The fix for that is to configure the PA server to run as part of your X session during login. The ALSA backend isn't officially supported, but the sandboxing team have tried to leave it in a working state by punching holes in the sandbox for ALSA... however that only works for simple/default configurations, and there are probably many configurations that fail the same way you observe. I think the Void packaging team need to consider disabling the sandbox when enabling the ALSA build (it looks like they're effectively recommending this in https://github.com/voidlinux/void-packages/issues/9223#issuecomment-344610102 by disabling E10S, which would also result in the sandbox being disabled AFAIK).

I *think* bug 1405891 is the sandbox change in Firefox 58 that broken PulseAudio spawning. The content sandbox level was the same from 56 onwards, so it must've been a change to the restrictions within the current level. The ioctl change looks the most likely, but I haven't confirmed it. This was then fixed by bug 1434156 in Firefox 60 by enabling audio remoting (this was also enabled in earlier nightly builds (59)), which moves any potential PulseAudio spawning into the chrome process which is not restricted by the content sandbox. For those running 58, the best solution is to run PulseAudio as part of your display session so that the PulseAudio client in Firefox doesn't need to spawn the server. If that's not possible, another solution is to lower the content sandbox level or disable it entirely until you upgrade to 60, but I don't recommend that. Anyone seeing issues where the PulseAudio server quits or dies after Firefox has used it, please post logs to bug 1434392. I'll close this as fixed by bug 1434156.

I think this regression is from bug 1405877. The original reason for pre-starting cubeb (in bug 1259508) was the case where PulseAudio starts the daemon — which it can't do while sandboxed, even if we allowed the necessary syscalls, because the child process would inherit the content process's seccomp-bpf policy.

(In reply to Natskyge from comment #0) > Sandbox: seccomp sandbox violation: pid 9267, tid 10331, syscall 16, args 42 2147767296 139954395301288 0 0 0. This should have been fixed in bug 1408493, but there was a mistake in the patch that wasn't caught until bug 1430274. So this part of the bug should be fixed in 59 (and distros building with `--enable-alsa` could backport the fix).

(In reply to Jed Davis [:jld] (⏰UTC-7) from comment #8) > I think this regression is from bug 1405877. The original reason for > pre-starting cubeb (in bug 1259508) was the case where PulseAudio starts the > daemon — which it can't do while sandboxed, even if we allowed the necessary > syscalls, because the child process would inherit the content process's > seccomp-bpf policy. That sounds plausible, since I removed the pre-start, except that people are reporting this problem against 58 and my changes landed in 59...

See bug 1434392 comment #10 for why this breaks on 58.