RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-22 06:42:03 +00:00
Code Issues Releases Wiki Activity
9317071bc3
mpv/audio/out/ao_wasapi.h

123 lines
4.0 KiB
C
Raw Normal View History

ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
/*
* This file is part of mpv.
*
* Original author: Jonathan Yong <10walls@gmail.com>
*
* mpv is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 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
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with mpv. If not, see <http://www.gnu.org/licenses/>.
*/
#ifndef MP_AO_WASAPI_H_
#define MP_AO_WASAPI_H_
#define COBJMACROS 1
#define _WIN32_WINNT 0x600
#include <audioclient.h>
ao_wasapi: Implement AOCONTROL_UPDATE_STREAM_TITLE
2014-03-11 06:46:22 +00:00
#include <audiopolicy.h>
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
#include <mmdeviceapi.h>
#include <avrt.h>
Move compat/ and bstr/ directory contents somewhere else bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
2014-08-29 10:09:04 +00:00
#include "osdep/atomics.h"
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
ao/wasapi: new wasapi device monitoring interface Implement skeleton IMMNotificationClient to watch for changes in the sound device. This will make recovery possible from changes shared mode sample rate, bit depth, "enhancements"/effects and even graceful device removal. http://msdn.microsoft.com/en-us/library/windows/desktop/dd371417%28v=vs.85%29.aspx Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
2014-11-17 11:37:51 +00:00
typedef struct change_notify {
ao/wasapi: request reset on appropriate events on changes to PKEY_AudioEngine_DeviceFormat, device status, and default device. call ao_reload directly in the change_notify "methods". this requires keeping a device enumerator around for the duration of execution, rather than just for initially querying devices
2014-11-13 09:09:47 +00:00
IMMNotificationClient client; /* this must be first in the structure! */
ao/wasapi: new wasapi device monitoring interface Implement skeleton IMMNotificationClient to watch for changes in the sound device. This will make recovery possible from changes shared mode sample rate, bit depth, "enhancements"/effects and even graceful device removal. http://msdn.microsoft.com/en-us/library/windows/desktop/dd371417%28v=vs.85%29.aspx Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
2014-11-17 11:37:51 +00:00
LPWSTR monitored; /* Monitored device */
ao/wasapi: request reset on appropriate events on changes to PKEY_AudioEngine_DeviceFormat, device status, and default device. call ao_reload directly in the change_notify "methods". this requires keeping a device enumerator around for the duration of execution, rather than just for initially querying devices
2014-11-13 09:09:47 +00:00
struct ao *ao;
ao/wasapi: new wasapi device monitoring interface Implement skeleton IMMNotificationClient to watch for changes in the sound device. This will make recovery possible from changes shared mode sample rate, bit depth, "enhancements"/effects and even graceful device removal. http://msdn.microsoft.com/en-us/library/windows/desktop/dd371417%28v=vs.85%29.aspx Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
2014-11-17 11:37:51 +00:00
} change_notify;
ao/wasapi: request reset on appropriate events on changes to PKEY_AudioEngine_DeviceFormat, device status, and default device. call ao_reload directly in the change_notify "methods". this requires keeping a device enumerator around for the duration of execution, rather than just for initially querying devices
2014-11-13 09:09:47 +00:00
HRESULT wasapi_change_init(struct ao* ao);
void wasapi_change_uninit(struct ao* ao);
#define EXIT_ON_ERROR(hres) \
do { if (FAILED(hres)) { goto exit_label; } } while(0)
#define SAFE_RELEASE(unk, release) \
do { if ((unk) != NULL) { release; (unk) = NULL; } } while(0)
ao/wasapi: new wasapi device monitoring interface Implement skeleton IMMNotificationClient to watch for changes in the sound device. This will make recovery possible from changes shared mode sample rate, bit depth, "enhancements"/effects and even graceful device removal. http://msdn.microsoft.com/en-us/library/windows/desktop/dd371417%28v=vs.85%29.aspx Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
2014-11-17 11:37:51 +00:00
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
typedef struct wasapi_state {
struct mp_log *log;
HANDLE threadLoop;
/* Init phase */
ao/wasapi: improve error messages and add more debug statements also enforce more consistency in the exit codes and error handling thanks to Jonathan Yong <10walls@gmail.com>
2014-11-17 10:48:02 +00:00
HRESULT init_ret;
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
HANDLE init_done;
int share_mode;
HANDLE hUninit;
/* volume control */
DWORD vol_hw_support, status;
float audio_volume;
ao_wasapi: Implement per-application mixing The volume controls in mpv now affect the session's volume (the application's volume in the mixer). Since we do not request a non-persistent session, the volume and mute status persist across mpv invocations and system reboots. In exclusive mode, WASAPI doesn't have access to a mixer so the endpoint (sound card)'s master volume is modified instead. Since by definition mpv is the only thing outputting audio in exclusive mode, this causes no conflict, and ao_wasapi restores the last user-set volume when it's uninitialized.
2014-03-11 05:50:49 +00:00
float previous_volume;
float initial_volume;
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
/* Buffers */
size_t buffer_block_size; /* Size of each block in bytes */
UINT32 bufferFrameCount; /* wasapi buffer block size, number of frames, frame size at format.nBlockAlign */
/* WASAPI handles, owned by other thread */
IMMDevice *pDevice;
IAudioClient *pAudioClient;
IAudioRenderClient *pRenderClient;
ao_wasapi: Implement per-application mixing The volume controls in mpv now affect the session's volume (the application's volume in the mixer). Since we do not request a non-persistent session, the volume and mute status persist across mpv invocations and system reboots. In exclusive mode, WASAPI doesn't have access to a mixer so the endpoint (sound card)'s master volume is modified instead. Since by definition mpv is the only thing outputting audio in exclusive mode, this causes no conflict, and ao_wasapi restores the last user-set volume when it's uninitialized.
2014-03-11 05:50:49 +00:00
ISimpleAudioVolume *pAudioVolume;
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
IAudioEndpointVolume *pEndpointVolume;
ao_wasapi: Implement AOCONTROL_UPDATE_STREAM_TITLE
2014-03-11 06:46:22 +00:00
IAudioSessionControl *pSessionControl;
ao/wasapi: request reset on appropriate events on changes to PKEY_AudioEngine_DeviceFormat, device status, and default device. call ao_reload directly in the change_notify "methods". this requires keeping a device enumerator around for the duration of execution, rather than just for initially querying devices
2014-11-13 09:09:47 +00:00
IMMDeviceEnumerator *pEnumerator;
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
HANDLE hFeed; /* wasapi event */
ao_wasapi: Move non-critical code outside of the event thread Due to the COM Single-Threaded Apartment model, the thread owning the objects will still do all the actual method calls (in the form of message dispatches), but at least this will be COM's problem rather than having to set up several handles and adding extra code to the event thread. Since the event thread still needs to own the WASAPI handles to avoid waiting on another thread to dispatch the messages, the init and uninit code still has to run in the thread. This also removes a broken drain implementation and removes unused headers from each of the files split from the original ao_wasapi.c.
2014-03-11 03:47:33 +00:00
HANDLE hForceFeed; /* forces writing a buffer (e.g. before audio_resume) */
HANDLE hFeedDone; /* set only after a hForceFeed */
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
HANDLE hTask; /* AV thread */
DWORD taskIndex; /* AV task ID */
WAVEFORMATEXTENSIBLE format;
ao_wasapi: Move non-critical code outside of the event thread Due to the COM Single-Threaded Apartment model, the thread owning the objects will still do all the actual method calls (in the form of message dispatches), but at least this will be COM's problem rather than having to set up several handles and adding extra code to the event thread. Since the event thread still needs to own the WASAPI handles to avoid waiting on another thread to dispatch the messages, the init and uninit code still has to run in the thread. This also removes a broken drain implementation and removes unused headers from each of the files split from the original ao_wasapi.c.
2014-03-11 03:47:33 +00:00
/* WASAPI proxy handles, for Single-Threaded Apartment communication.
One is needed for each object that's accessed by a different thread. */
IAudioClient *pAudioClientProxy;
ao_wasapi: Implement per-application mixing The volume controls in mpv now affect the session's volume (the application's volume in the mixer). Since we do not request a non-persistent session, the volume and mute status persist across mpv invocations and system reboots. In exclusive mode, WASAPI doesn't have access to a mixer so the endpoint (sound card)'s master volume is modified instead. Since by definition mpv is the only thing outputting audio in exclusive mode, this causes no conflict, and ao_wasapi restores the last user-set volume when it's uninitialized.
2014-03-11 05:50:49 +00:00
ISimpleAudioVolume *pAudioVolumeProxy;
ao_wasapi: Move non-critical code outside of the event thread Due to the COM Single-Threaded Apartment model, the thread owning the objects will still do all the actual method calls (in the form of message dispatches), but at least this will be COM's problem rather than having to set up several handles and adding extra code to the event thread. Since the event thread still needs to own the WASAPI handles to avoid waiting on another thread to dispatch the messages, the init and uninit code still has to run in the thread. This also removes a broken drain implementation and removes unused headers from each of the files split from the original ao_wasapi.c.
2014-03-11 03:47:33 +00:00
IAudioEndpointVolume *pEndpointVolumeProxy;
ao_wasapi: Implement AOCONTROL_UPDATE_STREAM_TITLE
2014-03-11 06:46:22 +00:00
IAudioSessionControl *pSessionControlProxy;
ao_wasapi: Move non-critical code outside of the event thread Due to the COM Single-Threaded Apartment model, the thread owning the objects will still do all the actual method calls (in the form of message dispatches), but at least this will be COM's problem rather than having to set up several handles and adding extra code to the event thread. Since the event thread still needs to own the WASAPI handles to avoid waiting on another thread to dispatch the messages, the init and uninit code still has to run in the thread. This also removes a broken drain implementation and removes unused headers from each of the files split from the original ao_wasapi.c.
2014-03-11 03:47:33 +00:00
/* Streams used to marshal the proxy objects. The thread owning the actual objects
needs to marshal proxy objects into these streams, and the thread that wants the
proxies unmarshals them from here. */
IStream *sAudioClient;
ao_wasapi: Implement per-application mixing The volume controls in mpv now affect the session's volume (the application's volume in the mixer). Since we do not request a non-persistent session, the volume and mute status persist across mpv invocations and system reboots. In exclusive mode, WASAPI doesn't have access to a mixer so the endpoint (sound card)'s master volume is modified instead. Since by definition mpv is the only thing outputting audio in exclusive mode, this causes no conflict, and ao_wasapi restores the last user-set volume when it's uninitialized.
2014-03-11 05:50:49 +00:00
IStream *sAudioVolume;
ao_wasapi: Move non-critical code outside of the event thread Due to the COM Single-Threaded Apartment model, the thread owning the objects will still do all the actual method calls (in the form of message dispatches), but at least this will be COM's problem rather than having to set up several handles and adding extra code to the event thread. Since the event thread still needs to own the WASAPI handles to avoid waiting on another thread to dispatch the messages, the init and uninit code still has to run in the thread. This also removes a broken drain implementation and removes unused headers from each of the files split from the original ao_wasapi.c.
2014-03-11 03:47:33 +00:00
IStream *sEndpointVolume;
ao_wasapi: Implement AOCONTROL_UPDATE_STREAM_TITLE
2014-03-11 06:46:22 +00:00
IStream *sSessionControl;
ao_wasapi: Move non-critical code outside of the event thread Due to the COM Single-Threaded Apartment model, the thread owning the objects will still do all the actual method calls (in the form of message dispatches), but at least this will be COM's problem rather than having to set up several handles and adding extra code to the event thread. Since the event thread still needs to own the WASAPI handles to avoid waiting on another thread to dispatch the messages, the init and uninit code still has to run in the thread. This also removes a broken drain implementation and removes unused headers from each of the files split from the original ao_wasapi.c.
2014-03-11 03:47:33 +00:00
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
/* WASAPI internal clock information, for estimating delay */
IAudioClock *pAudioClock;
UINT64 clock_frequency; /* scale for the "samples" returned by the clock */
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
atomic_ullong sample_count; /* the amount of samples per channel written to a GetBuffer buffer */
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
LARGE_INTEGER qpc_frequency; /* frequency of windows' high resolution timer */
int opt_exclusive;
int opt_list;
char *opt_device;
ao/wasapi: handle VistaBlob failure more gracefully
2014-11-28 18:43:48 +00:00
/* Don't use these functions directly in case
they are unimplemented for some reason.
(XP shouldn't be an issue since it doesn't support wasapi, maybe wine?)
Blob is owned by the main thread */
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
struct {
HMODULE hAvrt;
HANDLE (WINAPI *pAvSetMmThreadCharacteristicsW)(LPCWSTR, LPDWORD);
WINBOOL (WINAPI *pAvRevertMmThreadCharacteristics)(HANDLE);
} VistaBlob;
ao/wasapi: request reset on appropriate events on changes to PKEY_AudioEngine_DeviceFormat, device status, and default device. call ao_reload directly in the change_notify "methods". this requires keeping a device enumerator around for the duration of execution, rather than just for initially querying devices
2014-11-13 09:09:47 +00:00
change_notify change;
ao_wasapi: Split into 2 files ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
2014-03-09 23:13:36 +00:00
} wasapi_state;
ao_wasapi: Move non-critical code outside of the event thread Due to the COM Single-Threaded Apartment model, the thread owning the objects will still do all the actual method calls (in the form of message dispatches), but at least this will be COM's problem rather than having to set up several handles and adding extra code to the event thread. Since the event thread still needs to own the WASAPI handles to avoid waiting on another thread to dispatch the messages, the init and uninit code still has to run in the thread. This also removes a broken drain implementation and removes unused headers from each of the files split from the original ao_wasapi.c.
2014-03-11 03:47:33 +00:00
#endif
Reference in New Issue Copy Permalink