1362220 - [meta] Remote cubeb API

Status: ASSIGNED

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

Description

[u480271]

To support sandboxing of Audio playback and recording (Bug 1104619) the cubeb API needs to be split between content and server process.  This bug is a meta-bug to track the design and implementation.

Comment 1

[Bulk Bug Changes for mreavy's org]

Mass change P1->P2 to align with new Mozilla triage process

Comment 2

[Jim Mathies [:jimm]]

Hey Dan, can we close this out now? Still some cleanup work tracked here but blocking work appears complete.

Comment 3

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #2)
> Hey Dan, can we close this out now? Still some cleanup work tracked here but
> blocking work appears complete.

Also, curious about status of OSX and Windows. Can you give us a status update there?

Comment 4

[u480271]

(In reply to Jim Mathies [:jimm] from comment #3)
> (In reply to Jim Mathies [:jimm] from comment #2)
> > Hey Dan, can we close this out now? Still some cleanup work tracked here but
> > blocking work appears complete.
> 
> Also, curious about status of OSX and Windows. Can you give us a status
> update there?

Hi Jim,

We've landed all the blocking work before December break. In Bug 1405877#c21, :jld says that the Linux sandboxing work is good with webrtc.  The audioipc is current enabled on nightly only.  I'm working with Softvision to get some testing coverage of various flavors of Linux before removing the nightly only flag.

:kinetik also enabled audioipc for OSX before December break.  

There is an outstanding crash that is happening when a cubeb context is created before the IPC mechanism has started up (Bug 1426867) that :kinetik is currently working on.  Once that bug is fixed he'll start on the Windows version of audioipc.

Comment 5

[Jim Mathies [:jimm]]

Thanks for the update! Good news on Linux and OSX. Do you have a sense of what release the Windows work might land in?

Comment 6

[u480271]

(In reply to Jim Mathies [:jimm] from comment #5)
> Thanks for the update! Good news on Linux and OSX. Do you have a sense of
> what release the Windows work might land in?

Until we start on the Windows work, I don't have a good handle for when it would land. The pieces that are needed are small. We need a way to duplicate file handles cross-process (which in Win32 is DuplicateHandle) and a replacement for Unix Domain Sockets. Once we have those it should be quick.

Comment 7

[u480271]

Matthew, do you want to keep this meta bug or close it?