Currently, in order to deliver audio between processes, either for output or input, we employ a rather complex shared memory + "sync socket" mechanism. Tracing the time taken for this, at runtime, shows rather significant overhead for using this mechanism.

A lockless FIFO in shared memory can be a much simpler/cleaner design:

1. It's super easy to deal with start-up/shutdown sequences around this because either process can just drop its shared memory mapping whenever it wants to quit. Control messages can then propagate in their own due course to engage asynchronous shutdown.

2. There is no need for strict synchronization around every AudioBus being sent between the processes. Since the rate at which audio is produced is known ahead of time, and is constant (sans clock drift), a consumer can just poll the queue when the next buffer should be there and will get a hit near 100% of the time.

3. A lockless FIFO can serve as either a low-latency buffer, or a large buffer, or anything in-between, as each use case demands. For example, audio output usually requires a low-latency buffer, while the transport of audio input (e.g., from microphones or loopback) can be queued until a thread in the render process is unblocked and able to consume the audio.

4. The infrastructure behind the lockless FIFO can become a re-usable mojo library component. There are many cases in Chromium where data needs to be streamed between processes. Some of these use their own mechanism, while others use mojo data pipes (which often requires extra "chunking" and "order-of-operations" logic). Most of these use cases would also be better satisfied by using the lockless FIFO.