2013-06-13 13:15:39 +00:00
|
|
|
/*
|
|
|
|
* This file is part of mpv.
|
|
|
|
*
|
2013-10-23 17:07:27 +00:00
|
|
|
* 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.
|
2013-06-13 13:15:39 +00:00
|
|
|
*
|
|
|
|
* 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.
|
2013-06-13 13:15:39 +00:00
|
|
|
*
|
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/>.
|
2013-06-13 13:15:39 +00:00
|
|
|
*/
|
|
|
|
|
2015-12-21 17:45:32 +00:00
|
|
|
#include <math.h>
|
2013-07-19 02:16:42 +00:00
|
|
|
#include <inttypes.h>
|
2016-01-02 16:10:52 +00:00
|
|
|
#include <libavutil/mathematics.h>
|
2013-06-13 13:15:39 +00:00
|
|
|
|
2016-01-05 03:47:38 +00:00
|
|
|
#include "options/m_option.h"
|
2017-05-17 13:53:00 +00:00
|
|
|
#include "osdep/threads.h"
|
2014-03-09 22:05:43 +00:00
|
|
|
#include "osdep/timer.h"
|
2014-03-11 18:50:09 +00:00
|
|
|
#include "osdep/io.h"
|
2016-02-26 14:58:09 +00:00
|
|
|
#include "misc/dispatch.h"
|
2016-01-05 03:47:38 +00:00
|
|
|
#include "ao_wasapi.h"
|
2013-06-13 13:15:39 +00:00
|
|
|
|
2016-01-02 16:10:52 +00:00
|
|
|
// naive av_rescale for unsigned
|
2015-12-21 17:45:32 +00:00
|
|
|
static UINT64 uint64_scale(UINT64 x, UINT64 num, UINT64 den)
|
|
|
|
{
|
|
|
|
return (x / den) * num
|
|
|
|
+ ((x % den) * (num / den))
|
|
|
|
+ ((x % den) * (num % den)) / den;
|
|
|
|
}
|
|
|
|
|
2023-10-11 18:45:40 +00:00
|
|
|
static HRESULT get_device_delay(struct wasapi_state *state, double *delay_ns)
|
|
|
|
{
|
2014-05-20 23:04:47 +00:00
|
|
|
UINT64 sample_count = atomic_load(&state->sample_count);
|
2014-03-09 22:05:43 +00:00
|
|
|
UINT64 position, qpc_position;
|
|
|
|
HRESULT hr;
|
|
|
|
|
2014-11-23 08:15:53 +00:00
|
|
|
hr = IAudioClock_GetPosition(state->pAudioClock, &position, &qpc_position);
|
2016-02-19 06:24:15 +00:00
|
|
|
EXIT_ON_ERROR(hr);
|
2015-12-21 00:43:23 +00:00
|
|
|
// 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)
|
2016-01-02 16:10:52 +00:00
|
|
|
MP_VERBOSE(state, "Possibly inaccurate device position.\n");
|
2014-03-09 22:05:43 +00:00
|
|
|
|
2015-12-21 17:45:32 +00:00
|
|
|
// 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;
|
2023-10-11 18:45:40 +00:00
|
|
|
*delay_ns = diff * 1e9 / state->format.Format.nSamplesPerSec;
|
2015-12-21 17:45:32 +00:00
|
|
|
|
|
|
|
// 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);
|
2016-01-02 16:10:52 +00:00
|
|
|
INT64 qpc_diff = av_rescale(qpc.QuadPart, 10000000, state->qpc_frequency.QuadPart)
|
2015-12-21 17:45:32 +00:00
|
|
|
- qpc_position;
|
2016-02-25 13:23:42 +00:00
|
|
|
// ignore the above calculation if it yields more than 10 seconds (due to
|
2016-01-02 16:10:52 +00:00
|
|
|
// possible overflow inside IAudioClock_GetPosition)
|
|
|
|
if (qpc_diff < 10 * 10000000) {
|
2023-10-11 18:45:40 +00:00
|
|
|
*delay_ns -= qpc_diff * 100.0; // convert to ns
|
2016-01-02 16:10:52 +00:00
|
|
|
} else {
|
|
|
|
MP_VERBOSE(state, "Insane qpc delay correction of %g seconds. "
|
|
|
|
"Ignoring it.\n", qpc_diff / 10000000.0);
|
|
|
|
}
|
2015-12-21 17:45:32 +00:00
|
|
|
|
2023-10-11 18:45:40 +00:00
|
|
|
if (sample_count > 0 && *delay_ns <= 0) {
|
|
|
|
MP_WARN(state, "Under-run: Device delay: %g ns\n", *delay_ns);
|
2016-02-19 19:04:29 +00:00
|
|
|
} else {
|
2023-10-11 18:45:40 +00:00
|
|
|
MP_TRACE(state, "Device delay: %g ns\n", *delay_ns);
|
2016-02-19 19:04:29 +00:00
|
|
|
}
|
2014-03-09 22:05:43 +00:00
|
|
|
|
2014-11-23 08:15:53 +00:00
|
|
|
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));
|
2014-11-23 08:15:53 +00:00
|
|
|
return hr;
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
|
|
|
|
2016-02-19 19:04:29 +00:00
|
|
|
static bool thread_feed(struct ao *ao)
|
2013-06-13 13:15:39 +00:00
|
|
|
{
|
2015-03-31 21:12:24 +00:00
|
|
|
struct wasapi_state *state = ao->priv;
|
2013-07-20 01:53:08 +00:00
|
|
|
HRESULT hr;
|
|
|
|
|
|
|
|
UINT32 frame_count = state->bufferFrameCount;
|
2016-02-19 19:04:29 +00:00
|
|
|
UINT32 padding;
|
|
|
|
hr = IAudioClient_GetCurrentPadding(state->pAudioClient, &padding);
|
|
|
|
EXIT_ON_ERROR(hr);
|
|
|
|
bool refill = false;
|
2013-07-20 01:53:08 +00:00
|
|
|
if (state->share_mode == AUDCLNT_SHAREMODE_SHARED) {
|
2016-02-19 19:04:29 +00:00
|
|
|
// 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.
|
2013-07-20 01:53:08 +00:00
|
|
|
frame_count -= padding;
|
2016-02-19 19:04:29 +00:00
|
|
|
} 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;
|
2013-07-20 01:53:08 +00:00
|
|
|
}
|
2016-02-19 19:04:29 +00:00
|
|
|
MP_TRACE(ao, "Frame to fill: %"PRIu32". Padding: %"PRIu32"\n",
|
|
|
|
frame_count, padding);
|
|
|
|
|
2023-10-11 18:45:40 +00:00
|
|
|
double delay_ns;
|
|
|
|
hr = get_device_delay(state, &delay_ns);
|
2014-11-23 08:15:53 +00:00
|
|
|
EXIT_ON_ERROR(hr);
|
2015-12-21 17:45:32 +00:00
|
|
|
// add the buffer delay
|
2023-10-11 18:45:40 +00:00
|
|
|
delay_ns += frame_count * 1e9 / state->format.Format.nSamplesPerSec;
|
2013-07-20 01:53:08 +00:00
|
|
|
|
2014-03-09 22:05:43 +00:00
|
|
|
BYTE *pData;
|
2013-07-20 01:53:08 +00:00
|
|
|
hr = IAudioRenderClient_GetBuffer(state->pRenderClient,
|
|
|
|
frame_count, &pData);
|
2013-07-21 03:25:05 +00:00
|
|
|
EXIT_ON_ERROR(hr);
|
2014-03-06 18:50:22 +00:00
|
|
|
|
2014-03-09 22:05:43 +00:00
|
|
|
BYTE *data[1] = {pData};
|
2014-11-23 08:15:53 +00:00
|
|
|
|
2017-07-07 15:41:16 +00:00
|
|
|
ao_read_data_converted(ao, &state->convert_format,
|
|
|
|
(void **)data, frame_count,
|
2023-10-11 18:45:40 +00:00
|
|
|
mp_time_ns() + (int64_t)llrint(delay_ns));
|
2014-03-06 18:50:22 +00:00
|
|
|
|
2015-12-21 17:45:32 +00:00
|
|
|
// 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
|
2013-06-13 13:15:39 +00:00
|
|
|
hr = IAudioRenderClient_ReleaseBuffer(state->pRenderClient,
|
2013-07-20 01:53:08 +00:00
|
|
|
frame_count, 0);
|
2013-07-21 03:25:05 +00:00
|
|
|
EXIT_ON_ERROR(hr);
|
2014-03-06 18:50:22 +00:00
|
|
|
|
2014-05-20 23:04:47 +00:00
|
|
|
atomic_fetch_add(&state->sample_count, frame_count);
|
2014-03-06 18:50:22 +00:00
|
|
|
|
2016-02-19 19:04:29 +00:00
|
|
|
return refill;
|
2013-06-13 13:15:39 +00:00
|
|
|
exit_label:
|
2015-04-01 09:20:12 +00:00
|
|
|
MP_ERR(state, "Error feeding audio: %s\n", mp_HRESULT_to_str(hr));
|
2014-11-17 11:15:13 +00:00
|
|
|
MP_VERBOSE(ao, "Requesting ao reload\n");
|
|
|
|
ao_request_reload(ao);
|
2016-02-19 19:04:29 +00:00
|
|
|
return false;
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
|
|
|
|
2015-02-23 02:47:50 +00:00
|
|
|
static void thread_reset(struct ao *ao)
|
|
|
|
{
|
2015-03-31 21:12:24 +00:00
|
|
|
struct wasapi_state *state = ao->priv;
|
2015-02-23 02:47:50 +00:00
|
|
|
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));
|
2015-02-23 02:47:50 +00:00
|
|
|
|
|
|
|
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));
|
2015-02-23 02:47:50 +00:00
|
|
|
|
|
|
|
atomic_store(&state->sample_count, 0);
|
|
|
|
}
|
|
|
|
|
2016-02-26 18:36:40 +00:00
|
|
|
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)
|
2016-02-26 14:58:09 +00:00
|
|
|
{
|
|
|
|
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);
|
2016-02-26 14:58:09 +00:00
|
|
|
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)
|
2016-02-26 14:58:09 +00:00
|
|
|
{
|
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);
|
2016-02-26 14:58:09 +00:00
|
|
|
}
|
|
|
|
|
2015-03-29 00:12:48 +00:00
|
|
|
static DWORD __stdcall AudioThread(void *lpParameter)
|
2013-06-13 13:15:39 +00:00
|
|
|
{
|
|
|
|
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");
|
2014-11-15 06:47:28 +00:00
|
|
|
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
|
2014-11-17 10:48:02 +00:00
|
|
|
|
2017-07-13 06:37:45 +00:00
|
|
|
state->init_ok = wasapi_thread_init(ao);
|
2015-03-29 00:12:48 +00:00
|
|
|
SetEvent(state->hInitDone);
|
2017-07-13 06:37:45 +00:00
|
|
|
if (!state->init_ok)
|
2013-06-13 13:15:39 +00:00
|
|
|
goto exit_label;
|
2014-11-15 06:47:28 +00:00
|
|
|
|
2014-11-17 10:48:02 +00:00
|
|
|
MP_DBG(ao, "Entering dispatch loop\n");
|
2016-02-26 14:58:09 +00:00
|
|
|
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");
|
2015-02-23 02:27:58 +00:00
|
|
|
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;
|
2016-02-26 14:58:09 +00:00
|
|
|
case WASAPI_THREAD_RESET:
|
|
|
|
thread_reset(ao);
|
2013-06-13 13:15:39 +00:00
|
|
|
break;
|
2016-02-26 14:58:09 +00:00
|
|
|
case WASAPI_THREAD_RESUME:
|
|
|
|
thread_resume(ao);
|
|
|
|
break;
|
|
|
|
case WASAPI_THREAD_SHUTDOWN:
|
|
|
|
thread_reset(ao);
|
2014-11-17 10:48:02 +00:00
|
|
|
goto exit_label;
|
2016-02-26 14:58:09 +00:00
|
|
|
default:
|
|
|
|
MP_ERR(ao, "Unhandled thread state: %d\n", thread_state);
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
2016-02-26 18:31:54 +00:00
|
|
|
// the default is to feed unless something else is requested
|
|
|
|
atomic_compare_exchange_strong(&state->thread_state, &thread_state,
|
|
|
|
WASAPI_THREAD_FEED);
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
|
|
|
exit_label:
|
2014-11-15 06:47:28 +00:00
|
|
|
wasapi_thread_uninit(ao);
|
2014-11-17 10:48:02 +00:00
|
|
|
|
2014-11-15 06:47:28 +00:00
|
|
|
CoUninitialize();
|
2014-11-28 18:12:35 +00:00
|
|
|
MP_DBG(ao, "Thread return\n");
|
|
|
|
return 0;
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
|
|
|
|
2014-03-08 23:49:39 +00:00
|
|
|
static void uninit(struct ao *ao)
|
2013-06-13 13:15:39 +00:00
|
|
|
{
|
2014-11-17 10:48:02 +00:00
|
|
|
MP_DBG(ao, "Uninit wasapi\n");
|
2015-03-31 21:12:24 +00:00
|
|
|
struct wasapi_state *state = ao->priv;
|
2015-03-29 00:12:48 +00:00
|
|
|
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);
|
2015-03-29 00:12:48 +00:00
|
|
|
|
|
|
|
if (state->hAudioThread &&
|
2016-02-26 23:16:56 +00:00
|
|
|
WaitForSingleObject(state->hAudioThread, INFINITE) != WAIT_OBJECT_0)
|
2015-03-29 00:12:48 +00:00
|
|
|
{
|
2016-02-26 23:16:56 +00:00
|
|
|
MP_ERR(ao, "Unexpected return value from WaitForSingleObject "
|
|
|
|
"while waiting for audio thread to terminate\n");
|
2014-11-18 07:46:38 +00:00
|
|
|
}
|
2015-03-29 00:12:48 +00:00
|
|
|
|
2017-01-29 12:59:24 +00:00
|
|
|
SAFE_DESTROY(state->hInitDone, CloseHandle(state->hInitDone));
|
|
|
|
SAFE_DESTROY(state->hWake, CloseHandle(state->hWake));
|
|
|
|
SAFE_DESTROY(state->hAudioThread,CloseHandle(state->hAudioThread));
|
2016-01-05 02:16:40 +00:00
|
|
|
|
|
|
|
wasapi_change_uninit(ao);
|
|
|
|
|
2016-01-05 01:43:22 +00:00
|
|
|
talloc_free(state->deviceID);
|
2016-01-05 02:16:40 +00:00
|
|
|
|
2014-11-28 02:44:06 +00:00
|
|
|
CoUninitialize();
|
2014-11-17 10:48:02 +00:00
|
|
|
MP_DBG(ao, "Uninit wasapi done\n");
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
|
|
|
|
2013-07-22 20:57:51 +00:00
|
|
|
static int init(struct ao *ao)
|
2013-06-13 13:15:39 +00:00
|
|
|
{
|
2014-11-17 10:48:02 +00:00
|
|
|
MP_DBG(ao, "Init wasapi\n");
|
2016-06-01 04:39:23 +00:00
|
|
|
CoInitializeEx(NULL, COINIT_MULTITHREADED);
|
2014-11-28 02:44:06 +00:00
|
|
|
|
2015-03-31 21:12:24 +00:00
|
|
|
struct wasapi_state *state = ao->priv;
|
2013-12-21 17:34:42 +00:00
|
|
|
state->log = ao->log;
|
2013-07-19 12:40:14 +00:00
|
|
|
|
2016-09-05 19:07:34 +00:00
|
|
|
state->opt_exclusive |= ao->init_flags & AO_INIT_EXCLUSIVE;
|
|
|
|
|
2017-06-27 12:45:30 +00:00
|
|
|
#if !HAVE_UWP
|
2016-01-28 08:45:38 +00:00
|
|
|
state->deviceID = wasapi_find_deviceID(ao);
|
2016-01-05 02:09:03 +00:00
|
|
|
if (!state->deviceID) {
|
2016-01-05 01:43:22 +00:00
|
|
|
uninit(ao);
|
|
|
|
return -1;
|
|
|
|
}
|
2017-06-27 12:45:30 +00:00
|
|
|
#endif
|
2016-01-05 01:43:22 +00:00
|
|
|
|
2017-06-27 12:45:30 +00:00
|
|
|
if (state->deviceID)
|
|
|
|
wasapi_change_init(ao, false);
|
2016-01-05 02:16:40 +00:00
|
|
|
|
2015-03-29 00:12:48 +00:00
|
|
|
state->hInitDone = CreateEventW(NULL, FALSE, FALSE, NULL);
|
|
|
|
state->hWake = CreateEventW(NULL, FALSE, FALSE, NULL);
|
|
|
|
if (!state->hInitDone || !state->hWake) {
|
2016-02-26 18:44:55 +00:00
|
|
|
MP_FATAL(ao, "Error creating events\n");
|
2014-11-28 15:31:05 +00:00
|
|
|
uninit(ao);
|
2013-06-13 13:15:39 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2014-11-15 06:47:28 +00:00
|
|
|
|
2016-02-26 14:58:09 +00:00
|
|
|
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);
|
2016-02-26 14:58:09 +00:00
|
|
|
|
2017-07-13 06:37:45 +00:00
|
|
|
state->init_ok = false;
|
2015-03-29 00:12:48 +00:00
|
|
|
state->hAudioThread = CreateThread(NULL, 0, &AudioThread, ao, 0, NULL);
|
|
|
|
if (!state->hAudioThread) {
|
2016-02-26 18:44:55 +00:00
|
|
|
MP_FATAL(ao, "Failed to create audio thread\n");
|
2014-11-28 15:31:05 +00:00
|
|
|
uninit(ao);
|
2013-06-13 13:15:39 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2014-11-15 06:47:28 +00:00
|
|
|
|
2015-12-21 00:43:23 +00:00
|
|
|
WaitForSingleObject(state->hInitDone, INFINITE); // wait on init complete
|
2017-01-29 12:59:24 +00:00
|
|
|
SAFE_DESTROY(state->hInitDone,CloseHandle(state->hInitDone));
|
2017-07-13 06:37:45 +00:00
|
|
|
if (!state->init_ok) {
|
2014-11-15 06:47:28 +00:00
|
|
|
if (!ao->probing)
|
2016-02-26 18:44:55 +00:00
|
|
|
MP_FATAL(ao, "Received failure from audio thread\n");
|
2014-11-18 07:30:49 +00:00
|
|
|
uninit(ao);
|
2014-11-17 10:48:02 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2014-03-11 03:47:33 +00:00
|
|
|
|
2014-11-15 06:47:28 +00:00
|
|
|
MP_DBG(ao, "Init wasapi done\n");
|
2014-11-17 10:48:02 +00:00
|
|
|
return 0;
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
|
|
|
|
2016-02-26 14:58:09 +00:00
|
|
|
static int thread_control_exclusive(struct ao *ao, enum aocontrol cmd, void *arg)
|
2013-06-13 13:15:39 +00:00
|
|
|
{
|
2015-03-31 21:12:24 +00:00
|
|
|
struct wasapi_state *state = ao->priv;
|
2016-02-26 19:40:49 +00:00
|
|
|
if (!state->pEndpointVolume)
|
|
|
|
return CONTROL_UNKNOWN;
|
2013-06-13 13:15:39 +00:00
|
|
|
|
2015-12-20 12:22:16 +00:00
|
|
|
switch (cmd) {
|
|
|
|
case AOCONTROL_GET_VOLUME:
|
|
|
|
case AOCONTROL_SET_VOLUME:
|
2016-02-26 19:40:49 +00:00
|
|
|
if (!(state->vol_hw_support & ENDPOINT_HARDWARE_SUPPORT_VOLUME))
|
2015-12-20 12:22:16 +00:00
|
|
|
return CONTROL_FALSE;
|
2016-02-26 19:40:49 +00:00
|
|
|
break;
|
2015-12-20 12:22:16 +00:00
|
|
|
case AOCONTROL_GET_MUTE:
|
|
|
|
case AOCONTROL_SET_MUTE:
|
2016-02-26 19:40:49 +00:00
|
|
|
if (!(state->vol_hw_support & ENDPOINT_HARDWARE_SUPPORT_MUTE))
|
2015-12-19 04:45:51 +00:00
|
|
|
return CONTROL_FALSE;
|
2016-02-26 19:40:49 +00:00
|
|
|
break;
|
2015-12-19 04:45:51 +00:00
|
|
|
}
|
2016-02-26 19:40:49 +00:00
|
|
|
|
|
|
|
float volume;
|
|
|
|
BOOL mute;
|
|
|
|
switch (cmd) {
|
|
|
|
case AOCONTROL_GET_VOLUME:
|
|
|
|
IAudioEndpointVolume_GetMasterVolumeLevelScalar(
|
|
|
|
state->pEndpointVolume, &volume);
|
2024-02-13 07:32:04 +00:00
|
|
|
*(float *)arg = volume * 100.f;
|
2016-02-26 19:40:49 +00:00
|
|
|
return CONTROL_OK;
|
|
|
|
case AOCONTROL_SET_VOLUME:
|
2022-12-31 03:46:44 +00:00
|
|
|
volume = (*(float *)arg) / 100.f;
|
2016-02-26 19:40:49 +00:00
|
|
|
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;
|
2015-12-20 12:22:16 +00:00
|
|
|
}
|
|
|
|
|
2016-02-26 14:58:09 +00:00
|
|
|
static int thread_control_shared(struct ao *ao, enum aocontrol cmd, void *arg)
|
2015-12-20 12:22:16 +00:00
|
|
|
{
|
|
|
|
struct wasapi_state *state = ao->priv;
|
2016-02-26 14:58:09 +00:00
|
|
|
if (!state->pAudioVolume)
|
2015-12-20 12:22:16 +00:00
|
|
|
return CONTROL_UNKNOWN;
|
|
|
|
|
|
|
|
float volume;
|
|
|
|
BOOL mute;
|
|
|
|
switch(cmd) {
|
|
|
|
case AOCONTROL_GET_VOLUME:
|
2016-02-26 14:58:09 +00:00
|
|
|
ISimpleAudioVolume_GetMasterVolume(state->pAudioVolume, &volume);
|
2024-02-13 07:32:04 +00:00
|
|
|
*(float *)arg = volume * 100.f;
|
2015-12-20 12:22:16 +00:00
|
|
|
return CONTROL_OK;
|
|
|
|
case AOCONTROL_SET_VOLUME:
|
2022-12-31 03:46:44 +00:00
|
|
|
volume = (*(float *)arg) / 100.f;
|
2016-02-26 14:58:09 +00:00
|
|
|
ISimpleAudioVolume_SetMasterVolume(state->pAudioVolume, volume, NULL);
|
2015-12-20 12:22:16 +00:00
|
|
|
return CONTROL_OK;
|
|
|
|
case AOCONTROL_GET_MUTE:
|
2016-02-26 14:58:09 +00:00
|
|
|
ISimpleAudioVolume_GetMute(state->pAudioVolume, &mute);
|
2015-12-20 12:22:16 +00:00
|
|
|
*(bool *)arg = mute;
|
|
|
|
return CONTROL_OK;
|
|
|
|
case AOCONTROL_SET_MUTE:
|
|
|
|
mute = *(bool *)arg;
|
2016-02-26 14:58:09 +00:00
|
|
|
ISimpleAudioVolume_SetMute(state->pAudioVolume, mute, NULL);
|
2015-12-20 12:22:16 +00:00
|
|
|
return CONTROL_OK;
|
|
|
|
}
|
2016-02-26 19:40:49 +00:00
|
|
|
return CONTROL_UNKNOWN;
|
2015-12-20 12:22:16 +00:00
|
|
|
}
|
|
|
|
|
2016-02-26 14:58:09 +00:00
|
|
|
static int thread_control(struct ao *ao, enum aocontrol cmd, void *arg)
|
2015-12-20 12:22:16 +00:00
|
|
|
{
|
|
|
|
struct wasapi_state *state = ao->priv;
|
2014-03-11 05:50:49 +00:00
|
|
|
|
2015-12-19 04:45:51 +00:00
|
|
|
// common to exclusive and shared
|
|
|
|
switch (cmd) {
|
2015-12-19 07:45:25 +00:00
|
|
|
case AOCONTROL_UPDATE_STREAM_TITLE:
|
2016-02-26 14:58:09 +00:00
|
|
|
if (!state->pSessionControl)
|
2015-12-19 07:45:25 +00:00
|
|
|
return CONTROL_FALSE;
|
|
|
|
|
2023-06-19 17:43:12 +00:00
|
|
|
wchar_t *title = mp_from_utf8(NULL, (const char *)arg);
|
|
|
|
HRESULT hr = IAudioSessionControl_SetDisplayName(state->pSessionControl,
|
|
|
|
title,NULL);
|
2014-03-11 18:50:09 +00:00
|
|
|
talloc_free(title);
|
2023-06-19 17:43:12 +00:00
|
|
|
|
|
|
|
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;
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
2015-12-20 12:22:16 +00:00
|
|
|
|
2016-01-06 02:40:35 +00:00
|
|
|
return state->share_mode == AUDCLNT_SHAREMODE_EXCLUSIVE ?
|
2016-02-26 14:58:09 +00:00
|
|
|
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;
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
|
|
|
|
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)
|
2013-06-13 13:15:39 +00:00
|
|
|
{
|
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);
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
|
|
|
|
2014-03-11 03:47:33 +00:00
|
|
|
static void audio_resume(struct ao *ao)
|
2013-06-13 13:15:39 +00:00
|
|
|
{
|
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);
|
2013-06-13 13:15:39 +00:00
|
|
|
}
|
|
|
|
|
2015-03-31 08:56:17 +00:00
|
|
|
static void hotplug_uninit(struct ao *ao)
|
|
|
|
{
|
|
|
|
MP_DBG(ao, "Hotplug uninit\n");
|
2015-03-31 19:53:05 +00:00
|
|
|
wasapi_change_uninit(ao);
|
2015-03-31 08:56:17 +00:00
|
|
|
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;
|
2015-06-17 11:42:31 +00:00
|
|
|
state->log = ao->log;
|
2016-06-01 04:39:23 +00:00
|
|
|
CoInitializeEx(NULL, COINIT_MULTITHREADED);
|
2015-12-29 09:13:17 +00:00
|
|
|
HRESULT hr = wasapi_change_init(ao, true);
|
2015-03-31 19:53:05 +00:00
|
|
|
EXIT_ON_ERROR(hr);
|
2015-03-31 08:56:17 +00:00
|
|
|
|
2015-03-31 19:53:05 +00:00
|
|
|
return 0;
|
|
|
|
exit_label:
|
2016-02-26 18:44:55 +00:00
|
|
|
MP_FATAL(state, "Error setting up audio hotplug: %s\n", mp_HRESULT_to_str(hr));
|
2015-03-31 19:53:05 +00:00
|
|
|
hotplug_uninit(ao);
|
|
|
|
return -1;
|
2014-10-13 16:21:45 +00:00
|
|
|
}
|
|
|
|
|
2013-07-20 23:33:49 +00:00
|
|
|
#define OPT_BASE_STRUCT struct wasapi_state
|
|
|
|
|
2013-07-20 17:13:39 +00:00
|
|
|
const struct ao_driver audio_out_wasapi = {
|
2015-04-03 05:16:57 +00:00
|
|
|
.description = "Windows WASAPI audio output (event mode)",
|
|
|
|
.name = "wasapi",
|
|
|
|
.init = init,
|
|
|
|
.uninit = uninit,
|
|
|
|
.control = control,
|
|
|
|
.reset = audio_reset,
|
audio: redo internal AO API
This affects "pull" AOs only: ao_alsa, ao_pulse, ao_openal, ao_pcm,
ao_lavc. There are changes to the other AOs too, but that's only about
renaming ao_driver.resume to ao_driver.start.
ao_openal is broken because I didn't manage to fix it, so it exits with
an error message. If you want it, why don't _you_ put effort into it? I
see no reason to waste my own precious lifetime over this (I realize the
irony).
ao_alsa loses the poll() mechanism, but it was mostly broken and didn't
really do what it was supposed to. There doesn't seem to be anything in
the ALSA API to watch the playback status without polling (unless you
want to use raw UNIX signals).
No idea if ao_pulse is correct, or whether it's subtly broken now. There
is no documentation, so I can't tell what is correct, without reverse
engineering the whole project. I recommend using ALSA.
This was supposed to be just a simple fix, but somehow it expanded scope
like a train wreck. Very high chance of regressions, but probably only
for the AOs listed above. The rest you can figure out from reading the
diff.
2020-05-31 13:00:35 +00:00
|
|
|
.start = audio_resume,
|
2015-04-03 05:16:57 +00:00
|
|
|
.list_devs = wasapi_list_devs,
|
|
|
|
.hotplug_init = hotplug_init,
|
2015-03-31 08:56:17 +00:00
|
|
|
.hotplug_uninit = hotplug_uninit,
|
2015-04-03 05:16:57 +00:00
|
|
|
.priv_size = sizeof(wasapi_state),
|
2013-06-13 13:15:39 +00:00
|
|
|
};
|