roc_sender and roc_receiver provide a simple single-stream single-endpoint synchronous API. While it covers many cases, the user may want to go further:
create a server with multiple endpoints
be notified when clients connect to the server and disconnect from it and handle client streams individually
This will be solved by a more complicated roc_transceiver API. It will have the following properties:
similar to roc_sender and roc_receiver, it has bind and connect methods and may act as a server or as a client
similar to roc_sender and roc_receiver, it has write and read methods and can handle streams of both directions
unlike roc_sender and roc_receiver, it can handle multiple endpoints
unlike roc_sender and roc_receiver, it can handle multiple endpoint sets, i.e. allow to connect sender to multiple receivers and bind receiver to multiple pairs of source + repair endpoints
unlike roc_sender and roc_receiver, it can handle multiple streams; one stream for every endpoint or one stream for every client connected to an endpoint; streams can be created and destroyed dynamically when clients connect or disconnect
unlike roc_sender and roc_receiver, it's API is asynchronous; the user registers callbacks for various events like: a stream is created, a stream is readable, a stream is writable
unlike roc_sender and roc_receiver, it will allow to connect sender and receiver not only to user-provided sinks and sources, but also to local audio devices
At the API level, roc_sender and roc_receiver features are a subset of roc_transceiver. The first API is simpler, and the second is more feature-rich.
At the protocol level, roc_sender and roc_receiver and roc_transceiver will be fully compatible and can be transparently used together.
roc_sender and roc_receiver provide a simple single-stream single-endpoint synchronous API. While it covers many cases, the user may want to go further:
This will be solved by a more complicated roc_transceiver API. It will have the following properties:
similar to roc_sender and roc_receiver, it has bind and connect methods and may act as a server or as a client
similar to roc_sender and roc_receiver, it has write and read methods and can handle streams of both directions
unlike roc_sender and roc_receiver, it can handle multiple endpoints
unlike roc_sender and roc_receiver, it can handle multiple endpoint sets, i.e. allow to connect sender to multiple receivers and bind receiver to multiple pairs of source + repair endpoints
unlike roc_sender and roc_receiver, it can handle multiple streams; one stream for every endpoint or one stream for every client connected to an endpoint; streams can be created and destroyed dynamically when clients connect or disconnect
unlike roc_sender and roc_receiver, it's API is asynchronous; the user registers callbacks for various events like: a stream is created, a stream is readable, a stream is writable
unlike roc_sender and roc_receiver, it will allow to connect sender and receiver not only to user-provided sinks and sources, but also to local audio devices
At the API level, roc_sender and roc_receiver features are a subset of roc_transceiver. The first API is simpler, and the second is more feature-rich.
At the protocol level, roc_sender and roc_receiver and roc_transceiver will be fully compatible and can be transparently used together.