Update for 2.2.3 release

Author: dolbyio-gh-bot

docs/.buildinfo

@@ -1,4 +1,4 @@
 # Sphinx build info version 1
 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: 80fbc7d4b328dec9759e2c05cbd42e1a
+config: 2454e2cfe77c04d304c84ea5556c17f8
 tags: 645f666f9bcd5a90fca523b33c5a78b7

docs/.doctrees/api/recording/example.doctree

@@ -3,10 +3,17 @@
 Asynchronous Operations
 =======================
 
-The SDK provides a thread-safe, asynchronous, and reentrant public API. This means that these public API methods can return results produced asynchronously in the form of :cpp:type:`async_result <dolbyio::comms::async_result>`. The :cpp:type:`async_result <dolbyio::comms::async_result>` object represents an eventual completion or a failure of an asynchronous operation and its resulting value. All calls to the SDK are queued onto the SDKs event loop and processed in the FIFO (First In, First Out) order. After making a call, the SDK user application is responsible for either blocking until the operation completes and result is available or setting a function object to execute when the asynchronous operation resolves using the :cpp:class:`async_result and <dolbyio::comms::detail::async_result>` methods. We highly recommend the latter to fully utilize the asynchronous capabilities of the SDK.
+The SDK provides a thread-safe, asynchronous, and reentrant public API. This means that these public API methods can return results produced asynchronously
+in the form of :cpp:type:`async_result <dolbyio::comms::async_result>`. The :cpp:type:`async_result <dolbyio::comms::async_result>` object represents
+an eventual completion or a failure of an asynchronous operation and its resulting value. All calls to the SDK are queued onto the SDKs event loop
+and processed in the FIFO (First In, First Out) order. After making a call, the SDK user application is responsible for either blocking the :cpp:func:`wait <dolbyio::comms::wait>`
+results or setting a function object execute when the asynchronous operation returns using the
+:cpp:class:`async_result and <dolbyio::comms::detail::async_result>` methods.
 
 When a user application invokes an asynchronous method of the SDK, the SDK creates two objects: :cpp:type:`solver <dolbyio::comms::solver>`,
-which is used by the asynchronous operation to notify about its completion, and :cpp:type:`async_result <dolbyio::comms::async_result>`, which is used by the application to get the completion notifications. Both of these objects share the same internal state. The user application must set function object callbacks to be executed when the operation succeeds or fails on the async_result. When the asynchronous operation completes the callbacks set by the user, it invokes the application.
+which is used by the asynchronous operation to notify about its completion, and :cpp:type:`async_result <dolbyio::comms::async_result>`, which is used by the application to get the completion notifications. Both of these objects share the same internal state. The user application must set function
+object callbacks to be executed when the operation succeeds or fails on the async_result. If the :cpp:func:`wait <dolbyio::comms::wait>` helper is used,
+this is done automatically. When the asynchronous operation completes the callbacks set by the user, it invokes the application.
 If the asynchronous operation ends before the callbacks are set by the user application, then the callbacks are invoked as soon as they are
 set, on the application's thread. Otherwise, the callbacks are invoked when the operation is finished on the SDK's event loop.
 
@@ -40,6 +47,7 @@ sections below. The helper method allows for synchronous usage of the asynchrono
 .. doxygenfunction:: dolbyio::comms::wait
         :project: C++ SDK
 
+
 .. _async_resultt:
 
 Async Result Class

docs/.doctrees/api/sdk/common/async_ops.doctree

@@ -94,7 +94,7 @@ In the **Media IO Mode** the sample app can:
   2) :cpp:func:`Set Audio Sink <dolbyio::comms::services::media_io::set_audio_sink>` for the conference to receive PCM audio from conference participants. This means Opus Codec will be used and thus to use the :cpp:class:`Audio Sink <dolbyio::comms::audio_sink>` must be set prior to conference creation.
   3) :cpp:func:`Set Encoded Video Sink <dolbyio::comms::services::media_io::set_encoded_video_sink>` for the conference to receive video frames before they are decoded. This must be called before the conference is created, but it does not prevent applications from receiving the decoded video frames as well.
 
-The sample application makes use of the Default Media Recorder module. If you would like to write your own Media Recorder, see the :ref:`recording_example` section. The sample application also uses the Default Media Injector module and the sample Media Source File library. If you would like to write your own Media Injector, see the 
+The sample application makes use of the :cpp:func:`dolbyio::comms::wait` call for all asynchronous operations. Additionally, the sample application makes use of the Default Media Recorder module. If you would like to write your own Media Recorder, see the :ref:`recording_example` section. The sample application also uses the Default Media Injector module and the sample Media Source File library. If you would like to write your own Media Injector, see the 
 :ref:`injection_example` section. If you would like to write your own Media Source for the injector, see the :ref:`Media Source File <media_source_file>` section, as well as the sample library itself.
 
 .. _build_run_sample: