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

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

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..

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' ?

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.

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 ?

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).

(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.

(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.

(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