Commit graph

49 commits

Author SHA1 Message Date
Silvio Lazzeretti
3803fa29b2 wasapi: added missing lock release in case of error in gst_wasapi_xxx_reset
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1440>
2020-07-15 20:11:48 +00:00
Seungha Yang
8d0dc4fdd2 plugins: Update for documentation of Windows plugins
* Add Since marks
* Make use of GST_PARAM_CONDITIONALLY_AVAILABLE flag
2020-07-02 17:21:29 +02:00
Seungha Yang
7ab51e85ab wasapi: Fix possible deadlock while downwards state change
IAudioClient::Stop() doesn't seem to wake up the event handle,
then read() or write() could be blocked forever by WaitForSingleObject.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1329>
2020-06-11 11:40:26 +00:00
Aaron Boxer
6d3429af34 documentation: fixed a heap o' typos 2019-11-05 09:11:25 -05:00
Nirbheek Chauhan
733f5b2851 wasapi: Move to CoInitializeEx for COM initialization
CoInitialize is not allowed when targeting UWP and causes a Windows
Application Certification Kit (WACK) error.
2019-08-27 19:10:36 +00:00
Tim-Philipp Müller
d669f89665 wasapi: add Hardware tag to element metadata 2019-02-19 23:45:34 +00:00
Nirbheek Chauhan
d56aec8b0c wasapi: Fix infinite loop when the device disappears
When the audio device goes away during playback or capture, we were
going into an infinite loop of AUDCLNT_E_DEVICE_INVALIDATED. Return -1
and post an error message so the ringbuffer thread exits with an error.
2019-01-15 03:29:58 +05:30
Nirbheek Chauhan
8249763f6c wasapi: Fix double call to Start when resetting the element
When either the source or sink goes from PLAYING -> NULL -> PLAYING,
we call _reset() which sets client_needs_restart, and then we call
prepare() which calls IAudioClient_Start(), so we don't need to call
it again in src_read() or sink_write(). Unlike when we're just going
PLAYING -> PAUSED -> PLAYING.
2019-01-04 18:47:07 +05:30
Sebastian Dröge
2f05ee9ba9 wasapisink: Don't call CoUninitialize() twice in unprepare()
It has to be symmetric with CoInitialize(), otherwise everything else
will fail.
2019-01-03 15:21:39 +00:00
Nirbheek Chauhan
f62b7fd712 wasapi: Remove code that sets thread priority
This is now handled directly in gstaudiosrc/sink, and we were setting
it in the wrong thread anyway. prepare() is not the same thread as
sink_write() or src_read().
2018-09-11 01:00:21 +05:30
Christoph Reiter
3b1c7ef8e4 wasapisink: recover from low buffer levels in shared mode
In case the wasapi buffer levels got low in shared mode we would still wait until
more buffer is available until writing something in it, which means we could never
catch up and recover.

Instead only wait for a new buffer in case the existing one is full and always write
what we can. Also don't loop until all data is written since the base class can handle
that for us and under normal circumstances this doesn't happen anyway.

This only works in shared mode, as in exclusive mode we have to exactly
fill the buffer and always have to wait first.

This fixes noisy (buffer underrun) playback with the wasapisink under load.

https://bugzilla.gnome.org/show_bug.cgi?id=796354
2018-05-25 19:06:37 +05:30
Christoph Reiter
ffb8476a38 wasapisink: fix missing unlock in case IAudioClient_Start fails
https://bugzilla.gnome.org/show_bug.cgi?id=796354
2018-05-25 19:05:57 +05:30
Christoph Reiter
adb1df3bc1 wasapi: Don't pass CoTaskMemFree to g_clear_pointer
CoTaskMemFree has a different calling convention than GDestroyNotify
and things crash at least with MinGW.

https://bugzilla.gnome.org/show_bug.cgi?id=796280
2018-05-23 13:24:00 +05:30
Nirbheek Chauhan
ff17a404b3 wasapi: Call CoIn/Uninitialize() around prepare()
Seems to be required for exclusive mode and also for all
initialization on Windows 7

https://bugzilla.gnome.org/show_bug.cgi?id=795274
2018-04-16 19:35:07 +05:30
Nirbheek Chauhan
5409cd4920 wasapi: Handle return value of WaitForSingleObject
The wait could've failed for whatever reason, we should handle that.
2018-04-10 05:16:54 +05:30
Nirbheek Chauhan
0a518c9be1 wasapi: Call _Start if the client was _Reset
Otherwise we will wait forever in WaitForSingleObject because we forgot
to start the client again after _Stop is called in reset().

https://bugzilla.gnome.org/show_bug.cgi?id=795114
2018-04-10 05:16:54 +05:30
Nirbheek Chauhan
c427860a20 wasapi: Don't open the device in get_caps()
We can just return the template caps till the device is opened when
going from READY -> PAUSED. This fixes a CRITICAL when calling
ELEMENT_ERROR before the ringbuffer is allocated.

Also fixes a couple of leaks in error conditions.

https://bugzilla.gnome.org/show_bug.cgi?id=794611
2018-04-09 17:28:11 +05:30
Nirbheek Chauhan
b7653925db wasapi: Only use audioclient3 when low-latency
Causes glitches on very slow CPU machines or VMs, and our
out-of-the-box experience should be good.

https://bugzilla.gnome.org/show_bug.cgi?id=794497
2018-04-06 23:11:18 +05:30
Nirbheek Chauhan
affb0182c6 wasapisrc: Implement loopback recording
Now, when you set loopback=true on wasapisrc, the `device` property
should refer to a sink (render) device for loopback recording.

If the `device` property is not set, the default sink device is used.
2018-04-04 01:12:23 +05:30
Nirbheek Chauhan
05a37d3791 wasapi: Clarify usage of low-latency property, add myself as author
The low-latency property is *always* safe to enable, so applications
that do realtime communication should set it, and the elements will
automatically configure WASAPI to use the lowest possible device
period, and the audioringbuffer in audiobasesink will also be
configured accordingly.

Applications can also use exclusive mode during capture and playback
for the lowest possible latency if they know that the device will not
be used by any other application.

In this mode, the latency-time and buffer-time properties will be
completely ignored.
2018-02-26 16:23:11 +05:30
Nirbheek Chauhan
995059dc87 wasapi: Add a property for trying the AudioClient3 API
The AudioClient3 API is only available on Windows 10, and we will
automatically detect when it is available and use it.

However, using it for capturing audio with low latency and without
glitches seems to require setting the realtime priority of the entire
pipeline to "critical", which we cannot do from inside the element.

Hence, we can only enable that by default for wasapisink since
apps should be able to safely set the low-latency property to TRUE if
they need low-latency capture or playback.
2018-02-26 16:23:11 +05:30
Nirbheek Chauhan
f7d0ce2477 wasapi: Set realtime thread priority at runtime
Use LoadLibrary() to set the thread characteristics at runtime so it
works automagically regardless of where or how the plugin was built.
2018-02-26 16:23:11 +05:30
Nirbheek Chauhan
0cb11c15ed wasapi: Use IAudioClient3 interface when available
This allows us to request ultra-low-latency device periods even in
shared mode. However, this requires good drivers and Windows 10, so
we only enable this when we detect that we are running on Windows 10
at runtime.

You can forcibly disable this feature on Windows 10 by setting
GST_WASAPI_DISABLE_AUDIOCLIENT3=1 in the environment.
2018-02-26 16:23:11 +05:30
Nirbheek Chauhan
14b2d6b27a wasapi: Use a macro for HRESULT failure paths
Saves a lot of boilerplate across all files.
2018-02-26 16:23:11 +05:30
Nirbheek Chauhan
8f61785485 wasapisrc: Re-align device period if necessary
Same changes as done for wasapisink in cbe2fc40a. Turns out this is
sometimes also needed for capture. Reported by Mathieu_Du.

Also improve logging in that case for easier debugging.
2018-02-09 02:09:04 +05:30
Nirbheek Chauhan
69b90224fa wasapi: Unprepare when src/sink_prepare fails
unprepare() is not called automatically on failure.

https://bugzilla.gnome.org/show_bug.cgi?id=793289
2018-02-08 14:30:38 +05:30
Nirbheek Chauhan
cbe2fc40a4 wasapisink: Re-align device period if necessary
Sometimes the minimum period advertised by a card results in an
unaligned buffer size error during initialization in exclusive mode.
In that case, we can fetch the actual buffer size in frames and
calculate the period from that.

We can't do this pre-emptively because we can't call GetBufferSize
till Initialize has been called at least once.

https://bugzilla.gnome.org/show_bug.cgi?id=793289
2018-02-08 14:29:58 +05:30
Nirbheek Chauhan
7f1d60da5b wasapisink: pre-load the buffer with silence
This reduces the chances of startup glitches, and also reduces the
chances that we'll get garbled output due to driver bugs.

Recommended by the WASAPI documentation.

https://bugzilla.gnome.org/show_bug.cgi?id=793289
2018-02-08 14:29:58 +05:30
Nirbheek Chauhan
4dbca8df09 wasapi: Try to use latency-time and buffer-time
So far, we have been completely discarding the values of latency-time
and buffer-time and trying to always open the device in the lowest
latency mode possible. However, sometimes this is a bad idea:

1. When we want to save power/CPU and don't want low latency
2. When the lowest latency setting causes glitches
3. Other audio-driver bugs

Now we will try to follow the user-set values of latency-time and
buffer-time in shared mode, and only latency-time in exclusive mode (we
have no control over the hardware buffer size, and there is no use in
setting GstAudioRingBuffer size to something larger).

The elements will still try to open the devices in the lowest latency
mode possible if you set the "low-latency" property to "true".

https://bugzilla.gnome.org/show_bug.cgi?id=793289
2018-02-08 14:29:58 +05:30
Nirbheek Chauhan
624de04fdb wasapi: Cover more HRESULT error messages
This requires using allocated strings, but it's the best option. For
instance, a call could fail because CoInitialize() wasn't called, or
because some other thing in the stack failed.

https://bugzilla.gnome.org/show_bug.cgi?id=793289
2018-02-08 14:29:58 +05:30
Nirbheek Chauhan
62b6224e37 wasapi: Increase thread priority to reduce glitches
This is particularly important when running in exclusive mode because
any delays will immediately cause glitching.

The MinGW version in Cerbero is too old, so we can only enable this when
building with MSVC or when people build GStreamer for MSYS2 or other
MinGW-based distributions.

To force-enable this code when building with MinGW, build with
CFLAGS="-DGST_FORCE_WIN_AVRT -lavrt".

https://bugzilla.gnome.org/show_bug.cgi?id=793289
2018-02-08 12:04:20 +05:30
Nirbheek Chauhan
6ecbb7556a wasapi: Allow opening devices in exclusive mode
This provides much lower latency compared to opening in shared mode,
but it also means that the device cannot be opened by any other
application. The advantage is that the achievable latency is much
lower.

In shared mode, WASAPI's engine period is 10ms, and so that is the
lowest latency achievable.

In exclusive mode, the limit is the device period itself, which in my
testing with USB DACs, on-board PCI sound-cards, and HDMI cards is
between 2ms and 3.33ms.

We set our audioringbuffer limits to match the device, so the
achievable sink latency is 6-9ms. Further improvements can be made if
needed.

https://bugzilla.gnome.org/show_bug.cgi?id=793289
2018-02-08 12:04:20 +05:30
Nirbheek Chauhan
4b388814af wasapi: Rename struct element for device name
We will use ->device for storing a pointer to the IMMDevice structure
which is needed for fetching the caps supported by devices in
exclusive mode.

https://bugzilla.gnome.org/show_bug.cgi?id=793289
2018-02-08 12:04:20 +05:30
Nirbheek Chauhan
3f1e039007 wasapi: Fix indentation issues missed by the commit hook
These were missed because the relevant commits were made on Windows
where `indent` wasn't installed.
2018-02-08 11:46:01 +05:30
Nirbheek Chauhan
538ccb6093 wasapi: Correctly set ringbuffer segsize/segtotal
This will set the actual-latency-time and actual-buffer-time of the sink
and source.

We completely ignore the latency-time/buffer-time values set
on the element because WASAPI is happiest when it is reading/writing at
the default period. Improving this will likely require the use of the
IAudioClient3 interfaces which are not available in MinGW yet.

https://bugzilla.gnome.org/show_bug.cgi?id=792897
2018-01-31 14:58:21 +05:30
Nirbheek Chauhan
d6d31064b4 wasapi: Implement support for >2 channels
We need to parse the WAVEFORMATEXTENSIBLE structure, figure out what
positions the channels have (if they are positional), and reorder them
as necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=792897
2018-01-31 14:58:21 +05:30
Nirbheek Chauhan
c8c32a7200 wasapi: Fix some leaks, bugs, and compiler warnings
Also improve logging.
2018-01-25 17:57:23 +05:30
Nirbheek Chauhan
1450851095 wasapi: Rewrite most of the code to make it work
Both the source and the sink elements were broken in a number of ways:

* prepare() was assuming that the format was always S16LE 2ch 44.1KHz.
  We now probe the preferred format with GetMixFormat().
* Device initialization was done with the wrong buffer size
  (buffer_time is in microseconds, not nanoseconds).
* sink_write() and src_read() were just plain wrong and would never
  write or read anything useful.
* Some functions in prepare() were always returning FALSE which meant
  trying to use the elements would *always* fail.
* get_caps() and delay() were not implemented at all.

TODO: support for >2 channels
TODO: pro-audio low-latency
TODO: SPDIF and other encoded passthroughs

Three new properties are now implemented: role, mute, and device.

* 'role' designates the stream role of the initialized device, see:
   https://msdn.microsoft.com/en-us/library/windows/desktop/dd370842(v=vs.85).aspx
* 'device' is a system-wide GUIDesque string for a specific device.
* 'mute' is a sink property and simply mutes it.

On my Windows 8.1 system, the lowest latency that works is:

  wasapisrc buffer-time=20000
  wasapisink buffer-time=10000

aka, 20ms and 10ms respectively. These values are close to the lowest
possible with the IAudioClient interface. Further improvements require
porting to IAudioClient2 or IAudioClient3.

https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio
2018-01-22 14:18:53 +05:30
Thibault Saunier
78022a6e0c docs: Port all docstring to gtk-doc markdown 2017-04-12 12:57:57 -03:00
Vineeth TM
8cdfb13658 bad: use new gst_element_class_add_static_pad_template()
https://bugzilla.gnome.org/show_bug.cgi?id=763081
2016-03-24 14:56:51 +02:00
Sebastian Dröge
363aa90a10 wasapisrc: Port to GstAudioSrc 2013-04-23 18:57:04 +02:00
Sebastian Dröge
1445438a8b wasapi: Port wasapisink to GstAudioSink 2013-04-23 18:57:04 +02:00
Sebastian Dröge
e7a69bb8de wasapi: Initial port to 1.0
This should really use GstAudioSink and GstAudioSrc.
2013-03-26 15:43:51 +01:00
Sebastian Dröge
d5d37fafa7 wasapi: Include config.h before anything else 2013-03-26 15:01:08 +01:00
Tim-Philipp Müller
9e1b75fda3 Fix FSF address
https://bugzilla.gnome.org/show_bug.cgi?id=687520
2012-11-04 00:09:59 +00:00
Tim-Philipp Müller
32ba17cd0f Use gst_element_class_set_static_metadata()
where possible. Avoids some string copies. Also re-indent
some stuff. Also some indent fixes here and there.
2012-10-17 17:46:34 +01:00
Mark Nauwelaerts
578861abea replace gst_element_class_set_details_simple with gst_element_class_set_metadata 2012-09-14 17:27:49 +02:00
Benjamin Otte
775c7584fd gst_element_class_set_details => gst_element_class_set_details_simple 2010-03-18 22:46:41 +01:00
Ole André Vadla Ravnås
69fad589ac sys/: New plugin for audio capture and playback using Windows Audio Session
Original commit message from CVS:
* sys/Makefile.am:
* sys/wasapi/Makefile.am:
* sys/wasapi/gstwasapi.c:
* sys/wasapi/gstwasapisink.c:
* sys/wasapi/gstwasapisink.h:
* sys/wasapi/gstwasapisrc.c:
* sys/wasapi/gstwasapisrc.h:
* sys/wasapi/gstwasapiutil.c:
* sys/wasapi/gstwasapiutil.h:
New plugin for audio capture and playback using Windows Audio Session
API (WASAPI) available with Vista and newer (#520901).
Comes with hardcoded caps and obviously needs lots of love. Haven't
had time to work on this code since it was written, was initially just
a quick experiment to play around with this new API.
2008-09-30 11:19:10 +00:00