Commit graph

18 commits

Author SHA1 Message Date
Seungha Yang
a668de747f wasapisrc: Make sure that wasapisrc produces data in loopback mode
An oddness of wasapi loopback feature is that capture client will not
produce any data if there's no outputting sound to corresponding
render client. In other words, if there's no sound to render,
capture task will stall. As an option to solve such issue, we can
add timeout to wake up from capture thread if there's no incoming data
within given time interval. But it seems to be glitch prone.
Another approach is that we can keep pushing silence data into
render client so that capture client can keep capturing data
(even if it's just silence).

This patch will choose the latter one because it's more straightforward
way and it's likely produce glitchless sound than former approach.

A bonus point of this approach is that loopback capture on Windows7/8
will work with this patch. Note that there's an OS bug prior to Windows10
when loopback capture client is running with event-driven mode.
To work around the bug, event signalling should be handled manually
for read thread to wake up.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1588>
2020-09-30 12:57:34 +00: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
Nirbheek Chauhan
6cbff552fe wasapisrc: Fix capturing from some buggy audio drivers
Some audio drivers return varying amounts of data per ::GetBuffer
call, instead of following the device period that they've told us
about in `src_prepare()`.

Previously, we would just drop those extra buffers hoping that the
extra buffers were temporary (f.ex., a startup 'burst' of audio data).
However, it seems that some audio drivers, particularly on older
Windows versions (such as Windows 10 1703 and older) consistently
return varying amounts of data.

Use GstAdapter to smooth that out, and hope that the audio driver is
locally varying but globally periodic.

Initially reported in https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/808
2019-11-28 08:59:41 +00:00
Marcos Kintschner
dd7839ca43 Fixed segtotal value being always 2 due to an unused variable
The 'MAX' expression used to set segtotal always returned 2 because the unused and unitialized variable buffer_frame_count was always 0
2019-04-30 21:25:12 -03: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
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
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
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
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
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
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
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
Sebastian Dröge
363aa90a10 wasapisrc: Port to GstAudioSrc 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
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
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