Currently the MSG uses the system's audio callback thread to perform its task. This thread can change over time on some platform as the audio device is changed (through the GraphDriver/AudioCallbackDriver). This design was adopted in the past for performance reason: typically the audio callback thread runs at a higher priority than any other threads. That assumption will no longer be relevant as we move to an out of process audio design: the audio callback will live in another process, communicating via IPC to get the content from the MSG. Using TaskQueues / SharedThreadPool will greatly simply the threading design of the MSG and its users, removing the need for the extensive use of monitors and mutexes. It will also simplify the shutting down mechanism, removing all potentials of blocked/deadlocked shutdown as seen often. It would also allow moving to a MozPromise / asynchronous design for some tasks. The bug will track moving to a taskqueue based design, as started in bug 1404997

I'm guessing on rank, feel free to update.

Note that doing this would be at odds with the possibility of moving audio capture and MSG to a separate process -- in that case, we retain the advantage of running MSG at higher priority (at least on linux; not sure entirely about mac but I suspect it's similar. On windows paul tells me that we can ask for higher priority for audio-handling threads, though anything involving a task switch is inherently more expensive and puts you more at the mercy of the scheduler.) The MSG-sandboxing idea (triggered by sandboxing's wish to move audio in/out out of Content) is part of what spawned the entire investigation of increased Process Isolation; you'd likely move audio in/out (cubeb), MSG, WebAudio (with some footwork to allow JS access from Content to webaudio data). If MSG is there, then Media Elements get interesting, though much of the processing/display side may be movable. There didn't seem to be hard blockers, though the investigation of this didn't go deep. (There were a bunch of variants, including moving or not-moving webrtc as well to that Process).

(In reply to Randell Jesup [:jesup] from comment #2) > Note that doing this would be at odds with the possibility of moving audio > capture and MSG to a separate process -- in that case, we retain the > advantage of running MSG at higher priority (at least on linux; not sure > entirely about mac but I suspect it's similar. On windows paul tells me > that we can ask for higher priority for audio-handling threads, though > anything involving a task switch is inherently more expensive and puts you > more at the mercy of the scheduler.) > for now that concept is moot with the new out of process audio architecture coming up. Callbacks on linux (and soon mac) are now going over an IPC channels, if that's not a worry, why would the latency of a task dispatch be? At this stage we don't have any threads with higher priority anymore. And if it comes to it, we can always have the MSG taskqueue running on a thread at a higher priority. Having the MSG on its own taskqueue isn't incompatible with higher priority thread. What it would guarantee however is removing all that sillyness of cubeb calling the callback even when it's not supposed to, having to wait for an audio callback (which may never come) to continue processing the MSG message queue, removing the force shutdown logic (as we have no control over when the audio callback will be called), and the various races we've been fighting for years (and the associated security crashes), or the "MSG is running on its own thread, except if the driver doesn't exist, then running on the main thread is okay, oh, but wait it can also happen when we're in the middle of a shutdown, but also if mState is at that particular value". We can't keep resisting progress just because of "if"s or "maybe"s

My point was that the OOP Audio architecture doesn't have to involve any IPC, and that might change some of the tradeoffs. You make points here; the problems you detail are mostly fallout of the driven-by-input design for GraphDriver that we switched to several years ago (which on the plus side dealt with a bunch of problems we had been dealing with, and was before the e10s project was restarted). I don't think Paul expected the amount of "fun" around the startup/shutdown/switching of graph drivers that we ended up with; if you ignore that it works very well. Trying to maintain full-duplex when input or output may change adds to the complexity right now. On linux, we can't really make threads higher priority, only lower. (With root access you can use realtime threads... :-( ) But on Windows we could make threads in any pool higher priority. BTW, the "MSG runs on it's own thread, except in certain shutdown cases where it's on mainthread" and mState stuff predates graphdriver (though may be more complex now, perhaps). That's part of roc's original shutdown design.