1362223 - Split cubeb API in client/server

Status: RESOLVED FIXED

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

Comment 1

[u480271]

Current plan:

The following, non-exhaustive list, changes need to be made:

1. Split the API across the client and server using a custom IPC mechanism in rust
2. Extend cubeb to allow connection to server in client
3. Aim to reduce buffer copies to zero to help latency

:kinetik spoke to :jld to understand the available Unix APIs that will be available from content sandbox. The plan is to use a named file in firefox private tmp directory to initiate the connection and implement IPC over serde/bincode in rust. To begin with, the majority of the API will be made synchronous except for the data callback which will be async. Each end of the connection will run on its own thread.

:kinetik is currently working a rapid, disposable prototype to shake out issues with the design.  Other rust IPC mechanisms were considered but a custom mechanism is proposed because:
* Servo IPCChannel doesn't support many-to-one connection (Although patches are welcome),
* The cubeb API is small and requirements are simple,
* Concerned about latency for WebRTC

It was discussed if we can share PulseAudio's data buffer with content via shmem.  This might not be possible in all cases (if the pulseaudio server is over-the-network) so currently plan to aim for 1 buffer copy.

Comment 2

[Bulk Bug Changes for mreavy's org]

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