| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This was all dead code. Commit 995c47da9a (over 3 years ago) removed all
uses of the controls.
It would be nice if AOs could apply a linear gain volume, that only
affects the AO's audio stream for low-latency volume adjust and muting.
AOCONTROL_HAS_SOFT_VOLUME was supposed to signal this, but to use it,
we'd have to thoroughly check whether it really uses the expected
semantics, so there's really nothing useful left in this old code.
|
|
|
|
|
|
|
|
| |
Any bad HRESULTs should have been printed already and lots of failure modes
don't have an HRESULT leading to awkward hr = E_FAIL business.
This also checks the exit status of GetBufferSize in the align hack. A final
fatal message is added if either of the retry hacks fail.
|
|
|
|
|
|
|
|
|
|
|
| |
Do conversion directly, using the infrastructure that was added before.
This also rewrites part of format negotation, I guess.
I couldn't test the format that was used for S24 - my hardware does not
report support for it. So I commented it, as it could be buggy. Testing
this with the wasapi_formats[] entry for 24/24 uncommented would be
appreciated.
|
|
|
|
|
|
|
|
|
|
|
| |
UWP does not support the whole IMMDevice API. Instead, you need to use a
new API (available starting from Windows 8), which is in addition not in
MinGW, and extremely unpleasant to use.
The wasapiuwp2.dll wrapper is a small custom MSVC DLL, which does this
instead, and returns a normal IAudioClient.
Before this, ao_wasapi did not initialize on UWP.
|
|
|
|
| |
These break on UWP. Based on a patch by Pedro Pombeiro.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See: https://msdn.microsoft.com/en-us/library/windows/desktop/dd743946.aspx
Microsoft example code often uses a SAFE_RELEASE macro like the one in
the above link. This makes it easier to avoid errors when releasing COM
interfaces. It also reduces noise in COM-heavy code.
ao_wasapi.h also had a macro called SAFE_RELEASE, though unlike the
version above, its SAFE_RELEASE macro accepted a second parameter which
allowed it to destroy arbitrary objects other than just COM interfaces.
This renames ao_wasapi's SAFE_RELEASE to SAFE_DESTROY, which should more
accurately reflect what it does and prevent confusion with the Microsoft
version.
|
|
|
|
|
|
|
|
| |
Long planned. Leads to some sanity.
There still are some rather gross things. Especially g_groups is ugly,
and a hack that can hopefully be removed. (There is a plan for it, but
whether it's implemented depends on how much energy is left.)
|
|
|
|
|
|
|
| |
And introduce a global option which does this. Or more precisely, this
deprecates the global wasapi and coreaudio options, and adds a new one
that merges their functionality. (Due to the way the sub-option
deprecation mechanism works, this is simpler.)
|
|
|
|
|
| |
We have --audio-device, which can force the device. Also add something
describing to this extent to the manpage.
|
| |
|
| |
|
|
|
|
|
|
| |
Since the main thread is shared by other things in the player, using STA (single
threaded aparement) may have caused problems. Instead initialize in MTA
(multithreaded apartment).
|
|
|
|
|
| |
The time-out was a terrible hack for marginally better behaviour when
encountering #1773, which appears to have been resolved by a previous commit.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This was previously duplicated between the reset/resume functions, and
not properly handled in the "impossible" invalid thread state case.
|
|
|
|
|
|
|
|
|
|
| |
A COM message loop is apparently totally inappropriate for a low latency
thread. It leads to audio glitches because the thread doesn't wake up fast
enough when it should. It also causes mysterious correlations between the vo
and ao thread (i.e., toggling fullscreen delays audio feed events). Instead use
an mp_dispatch_queue to set/get volume/mute/session display name from the audio
thread. This has the added benefit of obviating the need to marshal the
associated interfaces from the audio thread.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't wait for WASAPI to send another feed event if we detect an underfull
buffer. It seems that WASAPI doesn't always send extra feed events if
something causes rendering to fall behind. This causes every subsequent playback
buffer to under-run until playback is reset. The fix is simply to do a one-shot
double feed when this happens, which allows rendering to catch up with playback.
This was observed to happen when using MsgWaitForMultipleObjects to wait for the
feed event and toggling fullscreen with vo=opengl:backend=win. This commit
improves the behaviour in that specific case and more generally makes exclusive
mode significantly more robust.
This commit also moves the logic to avoid *over*filling the exclusive mode
buffer into thread_feed right next to the above described underfil logic.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Previously used opt_exclusive option to decide which volume control code to run.
The might not always reflect the actual state, for example if passthrough
is used. Admittedly, none of the volume controls will work anyway with
passthrough, but this is the right thing to do.
|
|
|
|
|
| |
All the wasapi files were including both ao_wasapi.h and ao_wasapi_utils.h.
Just merge them into a single file.
|
|
|
|
| |
This is something else that has nothing to do with audio rendering.
|
|
|
|
| |
This makes it clearer that state->device is being allocated.
|
|
|
|
| |
In attempt to simplify the audio event thread, this can now be moved out.
|
|
|
|
| |
This is no longer required by anything else
|
|
|
|
|
|
|
|
| |
Apparently it's only wine where the qpc_position returned by
IAudioClock_GetPosition can be overflowed. So actually do the rescaling
correctly, but throw away the result if it looks unreasonable.
this fixes a regression in 5afa68835ade9f21f9c709f791319bf9d2e35265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure that subtraction of performance counters is done correctly.
Follow the *exact* instructions for converting performance counter to something
comparable to the QPCposition returned by IAudioClient::GetPosition
https://msdn.microsoft.com/en-us/library/windows/desktop/dd370889%28v=vs.85%29.aspx
Also make sure that subtraction of unsigned integers is stored into a signed
integer to avoid nastiness. Also be more careful about overflow in the
conversion of the device position into number of samples.
Avoid casting mp_time_us() to a double, and use llrint to convert the
double precision delay_us back to integer for ao_read_data.
Finally, actually check the return value of ao_read_data and add a verbose
message if it is not the expected value. Unfortunately,
there is no way to tell WASAPI when this happens since the frame_count in
ReleaseBuffer must match GetBuffer.
|
|
|
|
|
| |
Also make sure that CoReleaseMarshalData is called if errors occur before
unmarshalling.
|
|
|
|
|
| |
also remove a log message in AOCONTROL_UPDATE_STREAM_TITLE since
none of the other controls have one.
|
| |
|
|
|
|
|
| |
Make sure that the proxy has been created before using it. This will be
used when a future commit makes proxy setup optional.
|
|
|
|
|
|
|
|
|
| |
Do not try and set/get master volume in exclusive if there is no
hardware support. This would just uselessly change the master slider,
but have no effect on the actual volume.
Furthermore if getting hardware volume support information fails, then assume
it has none.
|
|
|
|
|
| |
the ao_control_vol_t cast was happening outside AOCONTROL_GET/SET_VOLUME
which is the only place that would be valid
|
|
|
|
|
|
| |
It was complicated and not even very intuitive to the user.
If you are controlling the master volume, you just have to be
prepared to deal with the consequences.
|
|
|
|
|
| |
this avoids having to check if we're exclusive or
shared for every control
|
|
|
|
|
| |
This was required to work around XP linking issues and is no longer
required.
|
|
|
|
|
| |
otherwise we were incorrectly adjusting the hardware master volume
in exclusive mode with softvol=auto
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"
Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually
use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context,
using WCHAR instead is more portable.
This affects only non-MinGW parts, so not all uses of wchar_t need to
be changed. For example, terminal-win.c won't be used on Midipix at
all. (Most of io.c won't either, so the search & replace here is more
than necessary, but also not harmful.)
(Midipix is not useable yet, so this is just preparation.)
|
|
|
|
|
| |
On init error, the mp_msg macros are actually called. They could cause
a crash because state->log was NULL.
|
|
|
|
|
|
|
|
|
| |
Unfortunately, because we have proxy objects (pAudioVolumeProxy,
pEndpointVolumeProxy, pSessionControlProxy) it looks like we still
have to use MsgWaitForMultipleObjects and watch for and dispatch
pending messages:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680112%28v=vs.85%29.aspx
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* unify passthrough and pcm exclusive mode format setting/testing
* set passthrough format parameters correctly
* support all of mpv's existing passthrough formats
* automatically test passthrough with exclusive mode and enable
exclusive if it succeeds, even if it was not explictly requested.
this obviates the need for --ao=wasapi,wasapi=exclusive
* if passthrough fails (such as the device doesn't support the
format), fallback to either exclusive pcm or shared mode depending
on what the user specified. Right now this isn't very useful as
it still fails due to the decoder path remainin stuck on spdif.
fixes #1742
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Take advantage of the fact that list_devs is called with a
hotplug_inited ao. Also eliminate unnecessary nested function
abstraction of hotplug_(un)init and list_devs. However, keep list_devs
in ao_wasapi_utils.c since it uses the private functions get_device_id,
get_device_name and exposing these would require including headers for
IMMDevice in ao_wasapi_utils.h.
|
|
|
|
|
| |
remove depricated and convoluted validation. refer instead to the
--audio-device option.
|
|
|
|
|
|
|
| |
Create a second copy of the change_notify structure for the hotplug
ao. change_notify->is_hotplug distinguishes the hotplug version from
the regular one monitoring the currently playing ao. Also make the
change notification less verbose now that there might be two of them around.
|
|
|
|
|
|
|
| |
More clearly separate the exclusive and shared mode format discovery.
Make the exclusive mode search more systematic in particular about
channel maps (i.e., use chmap_sel). Assume that the same sample format
/ sample rates work for all channels to narrow the search space.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This echanges the two events hForceFeed/hFeedDone for hResume. This
like the last commit makes things more deterministic.
Importantly, the forcefeed is only done if there is not already a full
buffer yet to be played by the device. This should fix some of the
problems with exclusive mode.
This commit also removes the necessity to have a proxy to the
AudioClient object in the main thread.
fixes #1529
|
|
|
|
|
|
|
|
|
| |
This makes things a bit more deterministic. It ensures that the audio
thread isn't doing anything between IAudioClient_Stop(),
IAudioClient_Reset() and setting the sample_count to 0.
Buffer overfilling on resume is still a problem in exclusive mode (see
next commit).
|
|
|
|
|
| |
Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into
the build system, instead of defining them over and over in the code.
|
| |
|
|
|
|
| |
it would have caused a deadlock if it fired anyway.
|
| |
|
|
|
|
|
| |
Only issue a warning for failure of wasapi_enumerate_devices and
wasapi_fill_VistaBlob.
|
|
|
|
|
| |
We weren't actually checking this value anyway. We only really
cared about init failure, which was checked another way.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Before it was the default device period, which was too small
causing glitches on on entering/exiting fullscreen.
|
|