summaryrefslogtreecommitdiff
path: root/sys/wasapi
Commit message (Collapse)AuthorAgeFilesLines
* wasapi: fix reinit of audioclient in prepare()Jakub Janků2021-07-121-1/+9
| | | | | | | | | | | | | When the sink goes from PLAYING to READY and then back to PLAYING, the initialization of the audioclient in prepare() fails with the error AUDCLNT_E_ALREADY_INITIALIZED. As a result, the playback stops. To fix this, we need to drop the AudioClient in unprepare() and grab a new one in prepare() to be able to initialize it again with the new buffer spec. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2096>
* wasapi: split gst_wasapi_util_get_device_client()Jakub Janků2021-07-124-20/+42
| | | | | | | | | | | The functionality now resides in gst_wasapi_util_get_device() and gst_wasapi_util_get_audio_client(). This is a preparatory patch. It will be used in the following patch to init/deinit the AudioClient separately from the device. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2096>
* gst: don't use volatile to mean atomicMatthew Waters2021-03-221-1/+1
| | | | | | | | | | | | volatile is not sufficient to provide atomic guarantees and real atomics should be used instead. GCC 11 has started warning about using volatile with atomic operations. https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719 Discovered in https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/868 Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2098>
* wasapisrc: Make sure that wasapisrc produces data in loopback modeSeungha Yang2020-09-302-0/+189
| | | | | | | | | | | | | | | | | | | | | | | 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>
* plugins: Use g_win32_error_message for HRESULT to string conversionSeungha Yang2020-07-181-21/+10
| | | | | | | | | | | | We don't need to duplicate a method for HRESULT error code to string conversion. This patch is intended to * Remove duplicated code * Ensure FormatMessageW (Unicode version) and avoid FormatMessageA (ANSI version), as the ANSI format is not portable at all. Note that if "UNICODE" is not defined, FormatMessageA will be aliased as FormatMessage by default. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1442>
* wasapi: added missing lock release in case of error in gst_wasapi_xxx_resetSilvio Lazzeretti2020-07-152-4/+6
| | | | Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1440>
* plugins: Update for documentation of Windows pluginsSeungha Yang2020-07-022-0/+4
| | | | | * Add Since marks * Make use of GST_PARAM_CONDITIONALLY_AVAILABLE flag
* wasapi: Fix possible deadlock while downwards state changeSeungha Yang2020-06-114-6/+61
| | | | | | | 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>
* wasapisrc: Correctly handle BUFFERFLAGS_SILENTNirbheek Chauhan2019-11-281-5/+6
| | | | | | | We need to ignore the data we get from WASAPI in this case and write out silence (zeroes). Initially reported at https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/808
* wasapisrc: Try harder to avoid debug output in the hot loopNirbheek Chauhan2019-11-281-5/+7
| | | | | | | | | | | | The whole `src_read()` function is a hot loop since the ringbuffer thread is waiting on us, and printing to the console from inside it can easily cause us to miss our deadline. F.ex., if you had GST_DEBUG=3 and we accidentally missed a device period, we'd trigger the "reported glitch" warning, which would cause us to miss another device period, and so on. Let's reduce the log level so that GST_DEBUG=3 is more usable, and only print buffer flag info when it's actually relevant.
* wasapisrc: Fix capturing from some buggy audio driversNirbheek Chauhan2019-11-282-18/+40
| | | | | | | | | | | | | | | | | 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
* wasapisrc: Clarify that nBlockAlign is actually bpfNirbheek Chauhan2019-11-281-8/+8
| | | | bpf = bytes per frame.
* wasapisrc: Fix glitching and clock skew issuesNirbheek Chauhan2019-11-281-1/+3
| | | | | | | | | | | | | | | | | | We were miscalculating the device period, i.e. the number of frames we'll get from WASAPI in each IAudioClient::GetBuffer call, due to a calculation mistake (truncate instead of round). For example, on my machine when the aux input is set to 44.1KHz, the reported device period is 101587, which comes out to 447.998 frames per ::GetBuffer call. In reality we will, of course, get 448 frames per call, but we were truncating, so we expected 447 and were discarding one frame every time. This led to glitching, and skew over time. Interestingly, I can only see this with 44.1Khz. 48Khz/96Khz are fine, because the device period is a more 'even' number. Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/806
* wasapi: minor cleanupIgnacio Casal Quinteiro2019-11-061-4/+2
|
* documentation: fixed a heap o' typosAaron Boxer2019-11-051-1/+1
|
* wasapi: Fix build warningsSeungha Yang2019-10-141-0/+4
| | | | | gstwasapiutil.c(173) : warning C4715: 'gst_wasapi_device_role_to_erole': not all control paths return a value gstwasapiutil.c(188) : warning C4715: 'gst_wasapi_erole_to_device_role': not all control paths return a value
* wasapi: Don't cast GstDeviceProvider to GstElementSeungha Yang2019-10-143-5/+5
| | | | | | | The GstDeviceProvider isn't subclass of GstElement. (gst-device-monitor-1.0:49356): GLib-GObject-WARNING **: 20:21:18.651: invalid cast from 'GstWasapiDeviceProvider' to 'GstElement'
* Remove autotools build systemTim-Philipp Müller2019-10-141-19/+0
|
* wasapi: Move to CoInitializeEx for COM initializationNirbheek Chauhan2019-08-273-5/+5
| | | | | CoInitialize is not allowed when targeting UWP and causes a Windows Application Certification Kit (WACK) error.
* wasapi: fix symbol redefinition build errorIgnacio Casal Quinteiro2019-08-122-3/+8
|
* docs: Build documentation with hotdocThibault Saunier2019-05-131-0/+1
|
* Fixed segtotal value being always 2 due to an unused variableMarcos Kintschner2019-04-302-3/+1
| | | | The 'MAX' expression used to set segtotal always returned 2 because the unused and unitialized variable buffer_frame_count was always 0
* wasapi: add Hardware tag to element metadataTim-Philipp Müller2019-02-192-2/+2
|
* misc: Fix warnings on Cerbero MinGWNirbheek Chauhan2019-02-061-1/+2
| | | | | | | | | | | | | | | | | | gstladspa.c:360:5: error: zero-length ms_printf format string [-Werror=format-zero-length] vad_private.c:108:3: error: this decimal constant is unsigned only in ISO C90 [-Werror] gstdecklinkvideosink.cpp:478:32: error: comparison between 'BMDTimecodeFormat {aka enum _BMDTimecodeFormat}' and 'enum GstDecklinkTimecodeFormat' [-Werror=enum-compare] win/DeckLinkAPI_i.c:72:8: error: extra tokens at end of #endif directive [-Werror] win/DeckLinkAPIDispatch.cpp:35:10: error: unused variable 'res' [-Werror=unused-variable] gstwasapiutil.c:733:3: error: format '%x' expects argument of type 'unsigned int', but argument 8 has type 'DWORD' [-Werror=format] gstwasapiutil.c:733:3: error: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'guint64' [-Werror=format] kshelpers.c:446:3: error: missing braces around initializer [-Werror=missing-braces] kshelpers.c:446:3: error: (near initialization for 'known_property_sets[0].guid.Data4') [-Werror=missing-braces]
* wasapi: Fixed corner-cases in mapping of channel maskJacek Tomaszewski2019-01-211-6/+15
| | | | | | | | | | | | | | 'channel-mask' field should not be put in caps if channel mask is 0x0 Mapping WASAPI channel mask to GST equivalent was going only over first nChannels elements of wasapi_to_gst_pos array, translating, for example, WASAPI's 0x63f to GST's 0x3f instead of 0xc3f. When 'channel-mask' is specified as NULL, it signifies that there's need to do downmix or upmix and it makes caps negotiation with audioconvert element impossible. Just omit it. Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>
* wasapi: Fix infinite loop when the device disappearsNirbheek Chauhan2019-01-153-27/+67
| | | | | | 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.
* wasapi: Fix double call to Start when resetting the elementNirbheek Chauhan2019-01-042-0/+2
| | | | | | | | 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.
* wasapisink: Don't call CoUninitialize() twice in unprepare()Sebastian Dröge2019-01-031-2/+0
| | | | | It has to be symmetric with CoInitialize(), otherwise everything else will fail.
* wasapi: Remove code that sets thread priorityNirbheek Chauhan2018-09-116-84/+4
| | | | | | 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().
* wasapi: Fix build with Windows 8.1 SDKNirbheek Chauhan2018-08-082-2/+8
| | | | | | | | | | With the Windows 8.1 SDK, the v1 of the AUDCLNT_STREAMOPTIONS enum is defined which only has NONE and RAW, so it's not only defined when AudioClient3 is available. Add a meson check for the symbol. This is not needed for Autotools because there we build against the MinGW audioclient.h which is still at v1 of the AudioClient interface.
* wasapisrc: Correctly disable provide-clockNirbheek Chauhan2018-08-021-3/+3
| | | | `#ifdef` will, of course, evaluate to 1 in this case. We want `#if`.
* wasapisink: fix regression in shared mode segment sizeChristoph Reiter2018-08-021-3/+9
| | | | | | | | | | | | | In commit fd806628a8 (839cc3926 in the stable branch) I changed the segment size to match exactly the buffer size. I missed that this is only valid in exclusive mode and in shared mode the buffer size is a multiple of the device period. Revert the logic for the shared mode. https://bugzilla.gnome.org/show_bug.cgi?id=796354 https://bugzilla.gnome.org/show_bug.cgi?id=796858
* Add feature options for almost all pluginsNirbheek Chauhan2018-07-271-4/+16
| | | | | | | The only plugins remaining are those that haven't been ported to Meson yet, and msdk. Also, the tests are still automagic. https://bugzilla.gnome.org/show_bug.cgi?id=795107
* wasapisink: recover from low buffer levels in shared modeChristoph Reiter2018-05-251-27/+47
| | | | | | | | | | | | | | | | | 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
* wasapisink: fix a rounding error when calculating the buffer frame countChristoph Reiter2018-05-251-3/+5
| | | | | | | | | | | | | | | | The calculation for the frame count in the non-aligned case resulted in a one too low buffer frame count. This resulted in: 1) exclusive mode not working as the frame count has to match exactly there. 2) Buffer underruns in shared mode as the current write() code doesn't handle catching up to low buffer levels (fixed in the next commit) To fix just use the wasapi API to get the buffer size which will always be correct. https://bugzilla.gnome.org/show_bug.cgi?id=796354
* wasapisink: fix missing unlock in case IAudioClient_Start failsChristoph Reiter2018-05-251-1/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=796354
* wasapi: use FAILED to detect errorsChristoph Reiter2018-05-231-1/+1
| | | | | | | | | | S_FALSE is a valid return value which does not indicate an error. For example IAudioClient_Stop() returns S_FALSE when it is already stopped. Use the FAILED macro instead which just checks if an error occured or not. This fixes spurious warnings when using the wasapisink element. https://bugzilla.gnome.org/show_bug.cgi?id=796280
* wasapi: Don't pass CoTaskMemFree to g_clear_pointerChristoph Reiter2018-05-232-2/+4
| | | | | | | CoTaskMemFree has a different calling convention than GDestroyNotify and things crash at least with MinGW. https://bugzilla.gnome.org/show_bug.cgi?id=796280
* Meson: Generate pc file for all plugins in badXavier Claessens2018-04-251-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794568
* wasapisrc: Don't provide a clock based on WASAPI's clockNirbheek Chauhan2018-04-181-0/+12
| | | | | | | | The clock seems to have a lot of drift (or we're using it incorrectly) which causes buffers to be late on the sink and get dropped. Disable till someone can investigate whether our usage of the API is incorrect (it looked correct to me) or if something is wrong.
* wasapi: Call CoIn/Uninitialize() around prepare()Nirbheek Chauhan2018-04-163-11/+9
| | | | | | | Seems to be required for exclusive mode and also for all initialization on Windows 7 https://bugzilla.gnome.org/show_bug.cgi?id=795274
* wasapi: Handle return value of WaitForSingleObjectNirbheek Chauhan2018-04-102-2/+16
| | | | The wait could've failed for whatever reason, we should handle that.
* wasapi: Call _Start if the client was _ResetNirbheek Chauhan2018-04-104-2/+34
| | | | | | | 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
* wasapi: Don't open the device in get_caps()Nirbheek Chauhan2018-04-092-12/+18
| | | | | | | | | | 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
* wasapi: Only use audioclient3 when low-latencyNirbheek Chauhan2018-04-061-5/+26
| | | | | | | 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
* wasapi: Don't derive device period from latency timeNirbheek Chauhan2018-04-061-12/+6
| | | | | | | This seems to cause glitches on devices with low CPU availability, such as virtual machines. Maybe even actual machines under high load. https://bugzilla.gnome.org/show_bug.cgi?id=794497
* wasapi: Squelch warning about %x and HRESULTNirbheek Chauhan2018-04-041-1/+1
| | | | HRESULT is always a 32-bit value, as is guint.
* wasapisrc: Implement loopback recordingNirbheek Chauhan2018-04-045-23/+50
| | | | | | | 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.
* wasapi: Print the hresult hex value on errorNirbheek Chauhan2018-03-271-1/+1
| | | | | This helps figure out precisely what error enum value was returned, which can be necessary when the description is too generic
* wasapi: try to satisfy both mingw and msvcTim-Philipp Müller2018-03-182-0/+3
| | | | Fix-up for previous commit, hopefully.
View Lorry Controller Status