Closed Bug 783827 Opened 10 years ago Closed 7 years ago

Rewrite remote audio backend

Categories

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

defect

Tracking

()

RESOLVED WONTFIX
blocking-kilimanjaro ?
blocking-basecamp -

People

(Reporter: cjones, Unassigned)

References

Details

+++ This bug was initially created as a clone of Bug #776069 +++

When the remote audio backend was implemented, some patches had been sitting in review for 6 months that would have let us implement something sane, using dedicated audio IPC channel(s).  Instead we had to layer hack upon hack upon hack, and the result is fragile.

I disabled this for now in bug 776069, which is terrible because it increases the OS attack surface from content processes.
I think this is a dupe of bug 770753, but this has the deps and CCs now.
Duplicate of this bug: 770753
Indeed, sorry about that.
No longer depends on: 776069
Blocks: 612799
Renoming based on a discussion with dougt.  I'm not sure we should block on this--cjones may disagree; if so I defer to him.  I hadn't planned to work on it in the near future, but if we do end up blocking on it I can take it.

Per comment 0, we disabled the existing (buggy) audio remoting code, so we're no longer exposed to those bugs.  In exchange, we increase the attack surface of content<->chrome.  It's important to fix that, but the native audio API we're calling is a fairly small and restricted interface.
blocking-kilimanjaro: + → ?
blocking-basecamp: --- → -
No longer blocks: 612799
Component: Audio/Video → Audio/Video: MSG/cubeb/GMP
Component: Audio/Video: MediaStreamGraph → Audio/Video: cubeb
Is this still relevant, or is it overtaken by events with the sandboxing work?
Rank: 25
Flags: needinfo?(gpascutto)
Priority: -- → P2
None of the code referred to seems to exist any more, so not much to rewrite.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(gpascutto)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.