Using the streaming API, a client can use the service in (almost) real-time manner, thus being able to process audio streams and receive results with the minimum latency possible. Unlike the Oliver REST API which assumes that audio data is already available in a file, the streaming API does not require all the audio to be available at the beginning of processing (although it can very well handle audio data as files too). It can process audio segments that are sent from the client’s end in a constant or variable rate. The results are sent using the same connection back to the client at the moment they are available, so the client enjoys minimum latency and a constant stream-flow of processing outputs.
The underlying network protocol that is utilized by the streaming API is Websocket to enable this kind of full-duplex data flow between the client and the Oliver service. The workflow of a streaming request is depicted in the following step by step overview:
- Open a new streaming session using Websocket protocol
- Start a new processing request and setup the engine
- Send audio data through the established connection
- Receive results in realtime using the same connection
- End the processing request when audio transmission is complete
- Receive final results and close the session
These steps are analysed in detail in the following pages. Also you can find the interim results specification definition that is available to the client during the processing of an audio input. The interim results can be used in an application to provide users with a realtime (or near-realtime) Oliver experience.
Updated less than a minute ago