... based on MediaFoundation work queue API.
By this commit, wasapi2 plugin will make use of pull mode scheduling
with audioringbuffer subclass.
There are several drawbacks of audiosrc/audiosink subclassing
(not audiobasesrc/audiobasesink) for WASAPI API, which are:
* audiosrc/audiosink classes try to set high priority to
read/write thread via MMCSS (Multimedia Class Scheduler Service)
but it's not allowed in case of UWP application.
In order to use MMCSS in UWP, application should use MediaFoundation
work queue indirectly.
Since audiosrc/audiosink scheduling model is not compatible with
MediaFoundation's work queue model, audioringbuffer subclassing
is required.
* WASAPI capture device might report larger packet size than expected
(i.e., larger frames we can read than expected frame size per period).
Meanwhile, in any case, application should drain all packets at that moment.
In order to handle the case, wasapi/wasapi2 plugins were making use of
GstAdapter which is obviously sub-optimal because it requires additional
memory allocation and copy.
By implementing audioringbuffer subclassing, we can avoid such inefficiency.
In this commit, all the device read/write operations will be moved
to newly implemented wasapi2ringbuffer class and
existing wasapi2client class will take care of device enumeration
and activation parts only.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2306>
Some capture devices might not provide channel mask value which will
result in capturing failure because of unknown channel mask in case
that device generates more than 2 channels. Although it might not
be correct, we can assume channel mask with the given number of channels.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2177>
In case of UWP, documentation from MS is saying that
ActivateAudioInterfaceAsync() method should be called from UI thread.
And the resulting callback might not happen until user interaction
has been made.
So we cannot wait the activation result on constructed() method.
and therefore we should return gst_wasapi2_client_new()
immediately without waiting the result if wasapi2 elements are
running on UWP application.
In addition to async operation fix, this commit includes COM object
reference counting issue around ActivateAudioInterfaceAsync() call.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1466>
Add a new wasapi implementation mainly to support UWP application.
Basically the core logic of this plugin is almost identical to
existing wasapi plugin, but main target is Windows 10 (+ UWP).
Since this plugin uses WinRT APIs, this plugin most likely might not
work Windows 8 or lower.
Compared with existing wasapi plugin, additional features of this plugin are
* Fully compatible with both Windows 10 desktop and UWP application
* Supports automatic stream routing (auto fallback when device was removed)
* Support device level mute/volume control
But some features of existing wasapi plugin are not implemented
in this plugin yet
* Exclusive streaming mode is not supported
* Loopback feature is not implemented
* Cross-compile is not possible with current mingw toolchain
(meaning that MSVC and Windows 10 SDK are required to build this plugin)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1264>
