mpv/audio/out/ao_wasapi.c

504 lines
16 KiB
C
Raw Normal View History

/*
* This file is part of mpv.
*
* Original author: Jonathan Yong <10walls@gmail.com>
*
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
* GNU Lesser General Public License for more details.
*
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
*/
#include <math.h>
#include <inttypes.h>
#include <libavutil/mathematics.h>
#include "options/m_option.h"
2017-05-17 13:53:00 +00:00
#include "osdep/threads.h"
#include "osdep/timer.h"
#include "osdep/io.h"
#include "misc/dispatch.h"
#include "ao_wasapi.h"
// naive av_rescale for unsigned
static UINT64 uint64_scale(UINT64 x, UINT64 num, UINT64 den)
{
return (x / den) * num
+ ((x % den) * (num / den))
+ ((x % den) * (num % den)) / den;
}
static HRESULT get_device_delay(struct wasapi_state *state, double *delay_ns)
{
UINT64 sample_count = atomic_load(&state->sample_count);
UINT64 position, qpc_position;
HRESULT hr;
hr = IAudioClock_GetPosition(state->pAudioClock, &position, &qpc_position);
2016-02-19 06:24:15 +00:00
EXIT_ON_ERROR(hr);
// GetPosition succeeded, but the result may be
// inaccurate due to the length of the call
// http://msdn.microsoft.com/en-us/library/windows/desktop/dd370889%28v=vs.85%29.aspx
2016-02-19 06:24:15 +00:00
if (hr == S_FALSE)
MP_VERBOSE(state, "Possibly inaccurate device position.\n");
// convert position to number of samples careful to avoid overflow
UINT64 sample_position = uint64_scale(position,
state->format.Format.nSamplesPerSec,
state->clock_frequency);
INT64 diff = sample_count - sample_position;
*delay_ns = diff * 1e9 / state->format.Format.nSamplesPerSec;
// Correct for any delay in IAudioClock_GetPosition above.
// This should normally be very small (<1 us), but just in case. . .
LARGE_INTEGER qpc;
QueryPerformanceCounter(&qpc);
INT64 qpc_diff = av_rescale(qpc.QuadPart, 10000000, state->qpc_frequency.QuadPart)
- qpc_position;
2016-02-25 13:23:42 +00:00
// ignore the above calculation if it yields more than 10 seconds (due to
// possible overflow inside IAudioClock_GetPosition)
if (qpc_diff < 10 * 10000000) {
*delay_ns -= qpc_diff * 100.0; // convert to ns
} else {
MP_VERBOSE(state, "Insane qpc delay correction of %g seconds. "
"Ignoring it.\n", qpc_diff / 10000000.0);
}
if (sample_count > 0 && *delay_ns <= 0) {
MP_WARN(state, "Under-run: Device delay: %g ns\n", *delay_ns);
} else {
MP_TRACE(state, "Device delay: %g ns\n", *delay_ns);
}
return S_OK;
exit_label:
2015-04-01 09:20:12 +00:00
MP_ERR(state, "Error getting device delay: %s\n", mp_HRESULT_to_str(hr));
return hr;
}
static bool thread_feed(struct ao *ao)
{
2015-03-31 21:12:24 +00:00
struct wasapi_state *state = ao->priv;
HRESULT hr;
UINT32 frame_count = state->bufferFrameCount;
UINT32 padding;
hr = IAudioClient_GetCurrentPadding(state->pAudioClient, &padding);
EXIT_ON_ERROR(hr);
bool refill = false;
if (state->share_mode == AUDCLNT_SHAREMODE_SHARED) {
// Return if there's nothing to do.
if (frame_count <= padding)
return false;
// In shared mode, there is only one buffer of size bufferFrameCount.
// We must therefore take care not to overwrite the samples that have
// yet to play.
frame_count -= padding;
} else if (padding >= 2 * frame_count) {
// In exclusive mode, we exchange entire buffers of size
// bufferFrameCount with the device. If there are already two such
// full buffers waiting to play, there is no work to do.
return false;
} else if (padding < frame_count) {
// If there is not at least one full buffer of audio queued to play in
// exclusive mode, call this function again immediately to try and catch
// up and avoid a cascade of under-runs. WASAPI doesn't seem to be smart
// enough to send more feed events when it gets behind.
refill = true;
}
MP_TRACE(ao, "Frame to fill: %"PRIu32". Padding: %"PRIu32"\n",
frame_count, padding);
double delay_ns;
hr = get_device_delay(state, &delay_ns);
EXIT_ON_ERROR(hr);
// add the buffer delay
delay_ns += frame_count * 1e9 / state->format.Format.nSamplesPerSec;
BYTE *pData;
hr = IAudioRenderClient_GetBuffer(state->pRenderClient,
frame_count, &pData);
EXIT_ON_ERROR(hr);
BYTE *data[1] = {pData};
ao_read_data_converted(ao, &state->convert_format,
(void **)data, frame_count,
mp_time_ns() + (int64_t)llrint(delay_ns));
// note, we can't use ao_read_data return value here since we already
2016-06-25 18:07:38 +00:00
// committed to frame_count above in the GetBuffer call
hr = IAudioRenderClient_ReleaseBuffer(state->pRenderClient,
frame_count, 0);
EXIT_ON_ERROR(hr);
atomic_fetch_add(&state->sample_count, frame_count);
return refill;
exit_label:
2015-04-01 09:20:12 +00:00
MP_ERR(state, "Error feeding audio: %s\n", mp_HRESULT_to_str(hr));
MP_VERBOSE(ao, "Requesting ao reload\n");
ao_request_reload(ao);
return false;
}
static void thread_reset(struct ao *ao)
{
2015-03-31 21:12:24 +00:00
struct wasapi_state *state = ao->priv;
HRESULT hr;
MP_DBG(state, "Thread Reset\n");
hr = IAudioClient_Stop(state->pAudioClient);
2016-02-19 06:24:15 +00:00
if (FAILED(hr))
2015-04-01 09:20:12 +00:00
MP_ERR(state, "IAudioClient_Stop returned: %s\n", mp_HRESULT_to_str(hr));
hr = IAudioClient_Reset(state->pAudioClient);
2016-02-19 06:24:15 +00:00
if (FAILED(hr))
2015-04-01 09:20:12 +00:00
MP_ERR(state, "IAudioClient_Reset returned: %s\n", mp_HRESULT_to_str(hr));
atomic_store(&state->sample_count, 0);
}
static void thread_resume(struct ao *ao)
{
struct wasapi_state *state = ao->priv;
MP_DBG(state, "Thread Resume\n");
thread_reset(ao);
thread_feed(ao);
HRESULT hr = IAudioClient_Start(state->pAudioClient);
if (FAILED(hr)) {
MP_ERR(state, "IAudioClient_Start returned %s\n",
mp_HRESULT_to_str(hr));
}
}
ao_wasapi: address premature buffer fills in exclusive mode Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
2024-02-13 06:32:18 +00:00
static void set_state_and_wakeup_thread(struct ao *ao,
enum wasapi_thread_state thread_state)
{
struct wasapi_state *state = ao->priv;
ao_wasapi: address premature buffer fills in exclusive mode Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
2024-02-13 06:32:18 +00:00
atomic_store(&state->thread_state, thread_state);
SetEvent(state->hWake);
}
ao_wasapi: address premature buffer fills in exclusive mode Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
2024-02-13 06:32:18 +00:00
static void thread_process_dispatch(void *ptr)
{
ao_wasapi: address premature buffer fills in exclusive mode Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
2024-02-13 06:32:18 +00:00
set_state_and_wakeup_thread(ptr, WASAPI_THREAD_DISPATCH);
}
static DWORD __stdcall AudioThread(void *lpParameter)
{
struct ao *ao = lpParameter;
2015-03-31 21:12:24 +00:00
struct wasapi_state *state = ao->priv;
2023-10-21 02:55:41 +00:00
mp_thread_set_name("ao/wasapi");
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
state->init_ok = wasapi_thread_init(ao);
SetEvent(state->hInitDone);
if (!state->init_ok)
goto exit_label;
MP_DBG(ao, "Entering dispatch loop\n");
while (true) {
if (WaitForSingleObject(state->hWake, INFINITE) != WAIT_OBJECT_0)
MP_ERR(ao, "Unexpected return value from WaitForSingleObject\n");
int thread_state = atomic_load(&state->thread_state);
switch (thread_state) {
case WASAPI_THREAD_FEED:
// fill twice on under-full buffer (see comment in thread_feed)
if (thread_feed(ao) && thread_feed(ao))
MP_ERR(ao, "Unable to fill buffer fast enough\n");
break;
ao_wasapi: address premature buffer fills in exclusive mode Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
2024-02-13 06:32:18 +00:00
case WASAPI_THREAD_DISPATCH:
mp_dispatch_queue_process(state->dispatch, 0);
break;
case WASAPI_THREAD_RESET:
thread_reset(ao);
break;
case WASAPI_THREAD_RESUME:
thread_resume(ao);
break;
case WASAPI_THREAD_SHUTDOWN:
thread_reset(ao);
goto exit_label;
default:
MP_ERR(ao, "Unhandled thread state: %d\n", thread_state);
}
// the default is to feed unless something else is requested
atomic_compare_exchange_strong(&state->thread_state, &thread_state,
WASAPI_THREAD_FEED);
}
exit_label:
wasapi_thread_uninit(ao);
CoUninitialize();
MP_DBG(ao, "Thread return\n");
return 0;
}
static void uninit(struct ao *ao)
{
MP_DBG(ao, "Uninit wasapi\n");
2015-03-31 21:12:24 +00:00
struct wasapi_state *state = ao->priv;
if (state->hWake)
ao_wasapi: address premature buffer fills in exclusive mode Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
2024-02-13 06:32:18 +00:00
set_state_and_wakeup_thread(ao, WASAPI_THREAD_SHUTDOWN);
if (state->hAudioThread &&
WaitForSingleObject(state->hAudioThread, INFINITE) != WAIT_OBJECT_0)
{
MP_ERR(ao, "Unexpected return value from WaitForSingleObject "
"while waiting for audio thread to terminate\n");
}
SAFE_DESTROY(state->hInitDone, CloseHandle(state->hInitDone));
SAFE_DESTROY(state->hWake, CloseHandle(state->hWake));
SAFE_DESTROY(state->hAudioThread,CloseHandle(state->hAudioThread));
wasapi_change_uninit(ao);
talloc_free(state->deviceID);
CoUninitialize();
MP_DBG(ao, "Uninit wasapi done\n");
}
static int init(struct ao *ao)
{
MP_DBG(ao, "Init wasapi\n");
CoInitializeEx(NULL, COINIT_MULTITHREADED);
2015-03-31 21:12:24 +00:00
struct wasapi_state *state = ao->priv;
state->log = ao->log;
state->opt_exclusive |= ao->init_flags & AO_INIT_EXCLUSIVE;
#if !HAVE_UWP
state->deviceID = wasapi_find_deviceID(ao);
if (!state->deviceID) {
uninit(ao);
return -1;
}
#endif
if (state->deviceID)
wasapi_change_init(ao, false);
state->hInitDone = CreateEventW(NULL, FALSE, FALSE, NULL);
state->hWake = CreateEventW(NULL, FALSE, FALSE, NULL);
if (!state->hInitDone || !state->hWake) {
MP_FATAL(ao, "Error creating events\n");
uninit(ao);
return -1;
}
state->dispatch = mp_dispatch_create(state);
ao_wasapi: address premature buffer fills in exclusive mode Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
2024-02-13 06:32:18 +00:00
mp_dispatch_set_wakeup_fn(state->dispatch, thread_process_dispatch, ao);
state->init_ok = false;
state->hAudioThread = CreateThread(NULL, 0, &AudioThread, ao, 0, NULL);
if (!state->hAudioThread) {
MP_FATAL(ao, "Failed to create audio thread\n");
uninit(ao);
return -1;
}
WaitForSingleObject(state->hInitDone, INFINITE); // wait on init complete
SAFE_DESTROY(state->hInitDone,CloseHandle(state->hInitDone));
if (!state->init_ok) {
if (!ao->probing)
MP_FATAL(ao, "Received failure from audio thread\n");
uninit(ao);
return -1;
}
MP_DBG(ao, "Init wasapi done\n");
return 0;
}
static int thread_control_exclusive(struct ao *ao, enum aocontrol cmd, void *arg)
{
2015-03-31 21:12:24 +00:00
struct wasapi_state *state = ao->priv;
if (!state->pEndpointVolume)
return CONTROL_UNKNOWN;
switch (cmd) {
case AOCONTROL_GET_VOLUME:
case AOCONTROL_SET_VOLUME:
if (!(state->vol_hw_support & ENDPOINT_HARDWARE_SUPPORT_VOLUME))
return CONTROL_FALSE;
break;
case AOCONTROL_GET_MUTE:
case AOCONTROL_SET_MUTE:
if (!(state->vol_hw_support & ENDPOINT_HARDWARE_SUPPORT_MUTE))
return CONTROL_FALSE;
break;
}
float volume;
BOOL mute;
switch (cmd) {
case AOCONTROL_GET_VOLUME:
IAudioEndpointVolume_GetMasterVolumeLevelScalar(
state->pEndpointVolume, &volume);
*(float *)arg = volume * 100.f;
return CONTROL_OK;
case AOCONTROL_SET_VOLUME:
volume = (*(float *)arg) / 100.f;
IAudioEndpointVolume_SetMasterVolumeLevelScalar(
state->pEndpointVolume, volume, NULL);
return CONTROL_OK;
case AOCONTROL_GET_MUTE:
IAudioEndpointVolume_GetMute(state->pEndpointVolume, &mute);
*(bool *)arg = mute;
return CONTROL_OK;
case AOCONTROL_SET_MUTE:
mute = *(bool *)arg;
IAudioEndpointVolume_SetMute(state->pEndpointVolume, mute, NULL);
return CONTROL_OK;
}
return CONTROL_UNKNOWN;
}
static int thread_control_shared(struct ao *ao, enum aocontrol cmd, void *arg)
{
struct wasapi_state *state = ao->priv;
if (!state->pAudioVolume)
return CONTROL_UNKNOWN;
float volume;
BOOL mute;
switch(cmd) {
case AOCONTROL_GET_VOLUME:
ISimpleAudioVolume_GetMasterVolume(state->pAudioVolume, &volume);
*(float *)arg = volume * 100.f;
return CONTROL_OK;
case AOCONTROL_SET_VOLUME:
volume = (*(float *)arg) / 100.f;
ISimpleAudioVolume_SetMasterVolume(state->pAudioVolume, volume, NULL);
return CONTROL_OK;
case AOCONTROL_GET_MUTE:
ISimpleAudioVolume_GetMute(state->pAudioVolume, &mute);
*(bool *)arg = mute;
return CONTROL_OK;
case AOCONTROL_SET_MUTE:
mute = *(bool *)arg;
ISimpleAudioVolume_SetMute(state->pAudioVolume, mute, NULL);
return CONTROL_OK;
}
return CONTROL_UNKNOWN;
}
static int thread_control(struct ao *ao, enum aocontrol cmd, void *arg)
{
struct wasapi_state *state = ao->priv;
// common to exclusive and shared
switch (cmd) {
case AOCONTROL_UPDATE_STREAM_TITLE:
if (!state->pSessionControl)
return CONTROL_FALSE;
wchar_t *title = mp_from_utf8(NULL, (const char *)arg);
HRESULT hr = IAudioSessionControl_SetDisplayName(state->pSessionControl,
title,NULL);
talloc_free(title);
if (SUCCEEDED(hr))
return CONTROL_OK;
MP_WARN(ao, "Error setting audio session name: %s\n",
mp_HRESULT_to_str(hr));
assert(ao->client_name);
if (!ao->client_name)
return CONTROL_ERROR;
// Fallback to client name
title = mp_from_utf8(NULL, ao->client_name);
IAudioSessionControl_SetDisplayName(state->pSessionControl,
title, NULL);
talloc_free(title);
return CONTROL_ERROR;
}
return state->share_mode == AUDCLNT_SHAREMODE_EXCLUSIVE ?
thread_control_exclusive(ao, cmd, arg) :
thread_control_shared(ao, cmd, arg);
}
static void run_control(void *p)
{
void **pp = p;
struct ao *ao = pp[0];
enum aocontrol cmd = *(enum aocontrol *)pp[1];
void *arg = pp[2];
*(int *)pp[3] = thread_control(ao, cmd, arg);
}
static int control(struct ao *ao, enum aocontrol cmd, void *arg)
{
struct wasapi_state *state = ao->priv;
int ret;
void *p[] = {ao, &cmd, arg, &ret};
mp_dispatch_run(state->dispatch, run_control, p);
return ret;
}
audio/out/pull: remove race conditions There were subtle and minor race conditions in the pull.c code, and AOs using it (jack, portaudio, sdl, wasapi). Attempt to remove these. There was at least a race condition in the ao_reset() implementation: mp_ring_reset() was called concurrently to the audio callback. While the ringbuffer uses atomics to allow concurrent access, the reset function wasn't concurrency-safe (and can't easily be made to). Fix this by stopping the audio callback before doing a reset. After that, we can do anything without needing synchronization. The callback is resumed when resuming playback at a later point. Don't call driver->pause, and make driver->resume and driver->reset start/stop the audio callback. In the initial state, the audio callback must be disabled. JackAudio of course is different. Maybe there is no way to suspend the audio callback without "disconnecting" it (what jack_deactivate() would do), so I'm not trying my luck, and implemented a really bad hack doing active waiting until we get the audio callback into a state where it won't interfere. Once the callback goes from AO_STATE_WAIT to NONE, we can be sure that the callback doesn't access the ringbuffer or anything else anymore. Since both sched_yield() and pthread_yield() apparently are not always available, use mp_sleep_us(1) to avoid burning CPU during active waiting. The ao_jack.c change also removes a race condition: apparently we didn't initialize _all_ ao fields before starting the audio callback. In ao_wasapi.c, I'm not sure whether reset really waits for the audio callback to return. Kovensky says it's not guaranteed, so disable the reset callback - for now the behavior of ao_wasapi.c is like with ao_jack.c, and active waiting is used to deal with the audio callback.
2014-05-29 00:24:17 +00:00
static void audio_reset(struct ao *ao)
{
ao_wasapi: address premature buffer fills in exclusive mode Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
2024-02-13 06:32:18 +00:00
set_state_and_wakeup_thread(ao, WASAPI_THREAD_RESET);
}
static void audio_resume(struct ao *ao)
{
ao_wasapi: address premature buffer fills in exclusive mode Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
2024-02-13 06:32:18 +00:00
set_state_and_wakeup_thread(ao, WASAPI_THREAD_RESUME);
}
static void hotplug_uninit(struct ao *ao)
{
MP_DBG(ao, "Hotplug uninit\n");
wasapi_change_uninit(ao);
CoUninitialize();
}
static int hotplug_init(struct ao *ao)
{
MP_DBG(ao, "Hotplug init\n");
2015-03-31 21:12:24 +00:00
struct wasapi_state *state = ao->priv;
state->log = ao->log;
CoInitializeEx(NULL, COINIT_MULTITHREADED);
HRESULT hr = wasapi_change_init(ao, true);
EXIT_ON_ERROR(hr);
return 0;
exit_label:
MP_FATAL(state, "Error setting up audio hotplug: %s\n", mp_HRESULT_to_str(hr));
hotplug_uninit(ao);
return -1;
2014-10-13 16:21:45 +00:00
}
#define OPT_BASE_STRUCT struct wasapi_state
const struct ao_driver audio_out_wasapi = {
.description = "Windows WASAPI audio output (event mode)",
.name = "wasapi",
.init = init,
.uninit = uninit,
.control = control,
.reset = audio_reset,
.start = audio_resume,
.list_devs = wasapi_list_devs,
.hotplug_init = hotplug_init,
.hotplug_uninit = hotplug_uninit,
.priv_size = sizeof(wasapi_state),
};