Roc is a toolkit for real-time audio streaming over the network.
Basically, Roc is a network transport, highly specialized for the real-time streaming use case. The user writes the stream to the one end and reads it from another end, and Roc deals with all the complexity of the task of delivering data in time and with no loss. Encoding, decoding, adjusting rates, restoring losses – all these are performed transparently under the hood.
The project is conceived as a swiss army knife for real-time streaming. It is designed to support a variety of network protocols, encodings, FEC schemes, and related features. The user can build custom configurations dedicated for specific use cases and choose an appropriate compromise between the quality, robustness, bandwidth, and compatibility issues.
Note that the project is still at an early stage of development, and the list of the supported features is not very long. But there’s more to come, of course. Contributions are also welcome!
Why real-time streaming needs a special approach?
First, if both sender input and receiver output have real-time clocks, we should somehow deal with the (small) difference between their frequencies because every device has its own clock domain. A real-time streaming library should solve this problem, or otherwise, the sender and receiver streams will quickly get out of sync.
Second, if the network is not reliable, we should cope with losses. We can’t just retry lost packets until they are delivered because it may be too late when we’re done retrying. A real-time streaming library should solve this problem as well, or otherwise either latency or quality of service will suffer.
Third, the real-time requirement usually leads to a compromise between various factors like quality, robustness, latency, bandwidth, and resource consumption. The right configuration depends on the specific use case. On the other hand, different encodings are suitable for different quality requirements, different FEC schemes are suitable for different latency and CPU requirements, and so on. Therefore, a real-time streaming library should support a variety of protocols, media encodings, FEC codes, and allow the user to select the most suitable configuration.
Fourth, applications that need real-time streaming usually also need some related features like service announcement and discovery, session negotiation, stream feedback and control, and so on. Such features are not directly related to real-time, but still would be expected to be found in a real-time streaming library.
All of the issues listed above belong to the scope of this project. Some of them are addressed already, and others will be addressed in future releases.
real-time — allow the user to create real-time streams with guaranteed latency;
good media quality — cope even with medium- and high-quality audio streams;
good service quality — provide good quality of service even on unreliable networks;
high-level — implement a simple high-level API that hides all the complexity of the network transport;
comprehensive toolset — support multiple protocols, encodings, schemes, and give the user the full control of them;
portability — support multiple operating systems and hardware architectures;
interoperability — rely on open, standard protocols.
The following list can help to determine whether Roc is suitable for a specific use case.
low latency — yes
higher latency — yes
not real-time — not very helpful, better use protocols like HTTP
lossless — yes; CD-quality currently
lossy — not yet supported, but will be
HD — not yet supported, but will be
wireless LAN — yes
wired LAN — yes, still useful even though the network is reliable
Internet — yes, but no encryption is implemented yet
audio — yes
video — not yet supported, but will be
other — not supported; maybe in future, but no plans yet
server — yes
desktop – yes, but we should separate desktop integrations from core
mobile — not yet supported, but will be
embedded — only Linux is supported currently
network I/O — yes
real-time streaming protocols — yes; only RTP-based protocols are implemented so far
control protocols — not yet supported, but will be
Sound processing features:
sound I/O — not yet (except command-line tools); use other libraries
DSP — limited; Roc is not a general-purpose DSP library
Below is the list of example applications where Roc could be useful.
Some of the applications will be possible only after adding relevant features like service discovery or video support, which are not ready yet. If you are thinking about using Roc in an open-source or closed-source project and want to join the efforts or need some improvements in Roc, feel free to contact us.
live broadcasting software
home audio systems and home cinema
mobile audio/video sharing
remote controls with cameras