1467982 - Enable cubeb remoting on OpenBSD

Status: NEW

(Core :: Audio/Video: cubeb, enhancement, P5)

Description

[Landry Breuil (:gaston)]

Currently blocked by bug #1467872 / https://github.com/tokio-rs/tokio-uds/commit/0852f593dba403b5d9dd7fc55471fb44a1271c14 being integrated, but here are the build bits to enabled cubeb remoting on OpenBSD, provided that i can test it at some point. Will help work in bug #1457092

Comment 1

[Landry Breuil (:gaston)]

Attachment: Enable cubeb remoting on OpenBSD

Not putting up for review yet, as i have to test it first...

Comment 2

[Landry Breuil (:gaston)]

Woops, so that packaging works the modules/libpref/init.all.js chunk it should be

-#ifdef XP_LINUX
+#if defined(XP_LINUX) || defined (OS_OPENBSD)

andnot

-#ifdef XP_LINUX
+#ifdef XP_LINUX || defined (OS_OPENBSD)

with that and the manual backporting of the tokio-uds commit, cubeb remoting builds. Now to test it..

Comment 3

[Landry Breuil (:gaston)]

So, it doesnt work *yet*. remoting is enabled, I have 'audio backend: remote' in about:support, but trying to play a video in youtube fails:

(pid=38743) pledged content process with promises: 'stdio rpath wpath cpath inet recvfd sendfd prot_exec unix drm ps'
WebGL(0x1997234b7800)::ForceLoseContext
WebGL(0x199742805000)::ForceLoseContext

###!!! [Parent][DispatchAsyncMessage] Error: PClientSourceOp::Msg___delete__ Route error: message sent to unknown actor ID

thread 'AudioIPC Client RPC' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 9, kind: Other, message: "Bad file descriptor" }', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Redirecting call to abort() to mozalloc_abort

[Parent 49985, Gecko_IOThread] WARNING: pipe error: Broken pipe: file /usr/obj/ports/firefox-61.0beta12/firefox-61.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 709
[Parent 49985, Gecko_IOThread] WARNING: pipe error: Broken pipe: file /usr/obj/ports/firefox-61.0beta12/firefox-61.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 709

###!!! [Parent][MessageChannel] Error: (msgtype=0x890001,name=PVsync::Msg_Notify) Channel error: cannot send/recv


###!!! [Parent][MessageChannel] Error: (msgtype=0x16007F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv


Is the cubeb remote process spawned as a 'regular content process' ?

Comment 4

[Landry Breuil (:gaston)]

Toggling media.cubeb.sandbox to false fixes the audio, so at least that means we can *build* the cubeb remoting parts for runtime testing/debugging.

Comment 5

[Landry Breuil (:gaston)]

The rust trace from audioipc thread panic :

thread 'AudioIPC Client RPC' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 9, kind: Other, message: "Bad file descriptor" }', libcore/result.rs:945:5
stack backtrace:
   0: Rust_Test_Member_nsCString_mClassFlags
   1: Rust_Test_Member_nsCString_mClassFlags
   2: Rust_Test_Member_nsCString_mClassFlags
   3: Rust_Test_Member_nsCString_mClassFlags
   4: Rust_Test_Member_nsCString_mClassFlags
   5: rust_eh_personality
   6: sdp_session_timing
   7: sdp_session_timing
   8: sdp_session_timing
   9: sdp_session_timing
  10: sdp_session_timing
  11: sdp_session_timing
  12: sdp_session_timing
  13: sdp_session_timing
  14: Rust_Test_Member_nsCString_mClassFlags
  15: pthread_create
Redirecting call to abort() to mozalloc_abort

What can i add in the env to help debugging this further ?

Comment 6

[Matthew Gregan [:kinetik]]

It might be easier (by reducing the number of moving parts) to start by cloning https://github.com/djg/audioipc-2 and getting ipctest running standalone.

My first guess would be that the cmsghdr handling for sendmsg/recvmsg (in media/audioipc/audioipc/src/cmsg.rs) has portability issues.  It has only been tested on Linux x64/amd64 and macOS, and I know other platforms have different layout and alignment requirements for struct cmsghdr (I spent a bunch of time trying to get it right in https://github.com/nix-rust/nix/pull/648, then the audioipc code ended up not using nix).

Comment 7

[Matthew Gregan [:kinetik]]

(In reply to Matthew Gregan [:kinetik] from comment #6)
> It might be easier (by reducing the number of moving parts) to start by
> cloning https://github.com/djg/audioipc-2 and getting ipctest running
> standalone.

And check that `cargo test` passes, too.

Comment 8

[Landry Breuil (:gaston)]

(In reply to Matthew Gregan [:kinetik] from comment #6)
> It might be easier (by reducing the number of moving parts) to start by
> cloning https://github.com/djg/audioipc-2 and getting ipctest running
> standalone.

Can do, but first it has to be adapted to work with tokio-uds 0.2.0 (cf bug #1467872)- right now this isnt the case, sadly it doesnt build.. and with tokio-uds 0.1.7 it fails to build on OpenBSD.

Comment 9

[Matthew Gregan [:kinetik]]

(In reply to Landry Breuil (:gaston) from comment #8)
> Can do, but first it has to be adapted to work with tokio-uds 0.2.0 (cf bug
> #1467872)- right now this isnt the case, sadly it doesnt build.. and with
> tokio-uds 0.1.7 it fails to build on OpenBSD.

It also turns out the cmsghdr tests were hardcoded for a particular platform, so I've changed it to be portable in a branch: https://github.com/djg/audioipc-2/tree/ctest

Comment 10

[Landry Breuil (:gaston)]

Attachment: Enable cubeb remoting on OpenBSD

So now that tokio-uds has been updated to a version with better support for OpenBSD, let's give this another shot.. but with that, about:support either shows 'remote error' for 'audio backend' or blows, and same thing for a youtube tab.

Comment 11

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

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 12

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.