summaryrefslogtreecommitdiffstats
path: root/audio/out/ao_wasapi_utils.c
Commit message (Collapse)AuthorAgeFilesLines
* ao/wasapi: use IsEqualGUID and IsEqualPropertyKeyKevin Mitchell2014-12-161-25/+6
| | | | before we were reinventing this wheel
* ao/wasapi: set the ao with the waveformat channelmapKevin Mitchell2014-12-151-1/+10
| | | | hopefully this fixes #1350
* ao/wasapi: make set_ao_format EX/EXTENSIBLE agnosticKevin Mitchell2014-12-011-14/+28
| | | | | | | | | There is no guarantee that closestMatch returned by IsFormatSupported is actually a WAVEFORMATEXTENSIBLE. http://msdn.microsoft.com/en-us/library/windows/desktop/dd370876%28v=vs.85%29.aspx We should therefore not blindly treat it as such.
* ao/wasapi: fix set_ao_formatKevin Mitchell2014-12-011-23/+10
| | | | | | | | | | | Before it used whatever was in ao->format and changed the bits even though this might have nothing to do with the actual WAVEFORMAT negotiated with WASAPI. For example, if the initial ao->format was a float and we had set the WAVEFORMAT to s24, this would create a non-existent float24 format. Worse, it might put an u16 into ao->format when WAVEFORMAT described s16. WASAPI doesn't support unsigned at all as far as I can tell.
* ao/wasapi: show actual waveformat triedKevin Mitchell2014-12-011-8/+30
| | | | also remove bogus ao_format
* ao/wasapi: don't assume 32-bits == floatKevin Mitchell2014-12-011-45/+43
| | | | | | | | | | This was based on old WAVEFORMATEX restrictions http://msdn.microsoft.com/en-us/library/windows/hardware/ff538799%28v=vs.85%29.aspx With the new WAVEFORMATEXTENSIBLE, this is no longer a problem. and we can have s32 or float32 so we need to actually check / set these correctly. fixes #1287
* ao/wasapi: make sure that < 16-bit pcm never happensKevin Mitchell2014-12-011-6/+16
| | | | it just sucks. noone should have to listen to that.
* ao/wasapi: get rid of WAVEFMT unionKevin Mitchell2014-12-011-29/+13
| | | | | It only confused the issue. Replace it's functionality with waveformat_copy function where needed.
* ao/wasapi: handle VistaBlob failure more gracefullyKevin Mitchell2014-11-281-5/+17
|
* ao/wasapi: more consistent/reliable method of computing extra ↵Kevin Mitchell2014-11-281-2/+1
| | | | WAVEFORMATEXTENSIBLE size
* ao/wasapi: make functions return bool that were acting like itKevin Mitchell2014-11-281-34/+34
| | | | | | | this involved inverting the logic of find_formats, enumerate_devies and wasapi_fill_VistaBlob. The latter two were trivial as their return values were not actually checked (to be fixed in a later commit).
* ao/wasapi: check full GUID of KSDATAFORMAT to determine floatKevin Mitchell2014-11-281-8/+8
|
* ao/wasapi: expose GUID and PKEY convenience functionsKevin Mitchell2014-11-281-0/+39
| | | | Give them the prefix mp_ and make them nonstatic.
* ao/wasapi: remove unused variableKevin Mitchell2014-11-281-3/+0
|
* ao/wasapi: safely define PKEY constantsKevin Mitchell2014-11-281-16/+13
| | | | | | | | | Before these definitions were incorrectly guarded by and #ifdef but since they aren't macros, this would never be true so that if they were ever added to mingw headers we would have problems. rename KSDATAFORMAT constants with the same mp prefix for consistency. also use DEFINE_GUID rather than defining the bare structure
* ao/wasapi: avoid redundant passing of ao and wasapi_state as argumentsKevin Mitchell2014-11-281-19/+19
| | | | also drop some useless const declaraitons
* ao/wasapi: fix unmatched CoUninitialize() on init failureKevin Mitchell2014-11-281-8/+0
|
* ao/wasapi: more debugging messagesKevin Mitchell2014-11-281-12/+20
|
* ao/wasapi: simplify the init retryKevin Mitchell2014-11-281-10/+8
|
* ao_wasapi: don't treat SetDisplayName() failure as fatalwm42014-11-271-1/+2
| | | | Same for SetIconPath().
* ao/wasapi: only retry resizing the buffer onceKevin Mitchell2014-11-181-8/+10
| | | | | | like the MSDN example: http://msdn.microsoft.com/en-us/library/windows/desktop/dd370875%28v=vs.85%29.aspx
* ao/wasapi: keep bufferPeriod in sync on retryKevin Mitchell2014-11-181-1/+4
| | | | | Without this, the retry will fail if they are not equal or bufferPeriod is zero.
* ao/wasapi: periodicity in shared mode must be zeroKevin Mitchell2014-11-181-3/+6
| | | | | | IAudioClient::Initialize hnsPeriodicity argument is nonzero only for exclusive mode http://msdn.microsoft.com/en-us/library/windows/desktop/dd370805%28v=vs.85%29.aspx
* ao/wasapi: increase buffer size to 50 msKevin Mitchell2014-11-181-12/+25
| | | | | Before it was the default device period, which was too small causing glitches on on entering/exiting fullscreen.
* ao/wasapi: fix leaked marshaled interface streamsJonathan Yong2014-11-181-0/+9
| | | | Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
* ao/wasapi: silence format string warningsJames Ross-Gowan2014-11-181-1/+1
|
* ao/wasapi: add retry loop on AUDCLNT_E_DEVICE_IN_USEKevin Mitchell2014-11-171-0/+12
| | | | this works around reinitializing too fast on device property changes
* ao/wasapi: request reset on appropriate eventsKevin Mitchell2014-11-171-29/+21
| | | | | | | | 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
* ao/wasapi: look for "multimedia" default device instead of "console"Kevin Mitchell2014-11-171-2/+2
| | | | | | console is more for system notifications / voice command, mpv is most certainly multimedia http://msdn.microsoft.com/en-us/library/windows/desktop/dd370842%28v=vs.85%29.aspx
* ao/wasapi: put loading of default device in it's own functionKevin Mitchell2014-11-171-17/+30
|
* ao/wasapi: fix possible null dereference of pDeviceKevin Mitchell2014-11-171-0/+1
| | | | | | IMMDeviceEnumerator::GetDefaultAudioEndpoint may set pDevice to null on failure. http://msdn.microsoft.com/en-us/library/windows/desktop/dd371401%28v=vs.85%29.aspx
* ao/wasapi: tidy up better on failureKevin Mitchell2014-11-171-2/+13
| | | | | | | Before, failures, particularly in the thread loop init, could lead to a bad state for the duration of mpvs execution. Make sure that everything that was initialized gets properly and safely uninitialized.
* ao/wasapi: improve error messages and add more debug statementsKevin Mitchell2014-11-171-75/+104
| | | | | | also enforce more consistency in the exit codes and error handling thanks to Jonathan Yong <10walls@gmail.com>
* ao/wasapi: make calling of thread_init consistent with thread_uninitKevin Mitchell2014-11-171-1/+3
|
* ao/wasapi: fix leaked deviceIDJonathan Yong2014-11-171-0/+1
|
* ao_wasapi: implement device listingwm42014-10-131-8/+23
|
* audio: cleanup spdif format definitionswm42014-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, there was AF_FORMAT_AC3 (the original spdif format, used for AC3 and DTS core), and AF_FORMAT_IEC61937 (used for AC3, DTS and DTS-HD), which was handled as some sort of superset for AF_FORMAT_AC3. There also was AF_FORMAT_MPEG2, which used IEC61937-framing, but still was handled as something "separate". Technically, all of them are pretty similar, but may use different bitrates. Since digital passthrough pretends to be PCM (just with special headers that wrap digital packets), this is easily detectable by the higher samplerate or higher number of channels, so I don't know why you'd need a separate "class" of sample formats (AF_FORMAT_AC3 vs. AF_FORMAT_IEC61937) to distinguish them. Actually, this whole thing is just a mess. Simplify this by handling all these formats the same way. AF_FORMAT_IS_IEC61937() now returns 1 for all spdif formats (even MP3). All AOs just accept all spdif formats now - whether that works or not is not really clear (seems inconsistent due to earlier attempts to make DTS-HD work). But on the other hand, enabling spdif requires manual user interaction, so it doesn't matter much if initialization fails in slightly less graceful ways if it can't work at all. At a later point, we will support passthrough with ao_pulse. It seems the PulseAudio API wants to know the codec type (or maybe not - feeding it DTS while telling it it's AC3 works), add separate formats for each codecs. While this reminds of the earlier chaos, it's stricter, and most code just uses AF_FORMAT_IS_IEC61937(). Also, modify AF_FORMAT_TYPE_MASK (renamed from AF_FORMAT_POINT_MASK) to include special formats, so that it always describes the fundamental sample format type. This also ensures valid AF formats are never 0 (this was probably broken in one of the earlier commits from today).
* ao_wasapi: fix fragile format-mapping codewm42014-09-231-28/+19
| | | | | | | | | | | | | This code tried to play with the format bits, and potentially could create invalid formats, or reinterpret obscure formats in unexpected ways. Also there was an abort() call if the winapi or mpv used a format with unexpected bit-width. This could probably easily happen; for example, mpv supports at least one 64 bit format. And what would happen on 8 bit formats anyway? Untested.
* audio: drop swapped-endian audio formatswm42014-09-231-3/+2
| | | | | | | | | | | | | | | | | | | | Until now, the audio chain could handle both little endian and big endian formats. This actually doesn't make much sense, since the audio API and the HW will most likely prefer native formats. Or at the very least, it should be trivial for audio drivers to do the byte swapping themselves. From now on, the audio chain contains native-endian formats only. All AOs and some filters are adjusted. af_convertsignendian.c is now wrongly named, but the filter name is adjusted. In some cases, the audio infrastructure was reused on the demuxer side, but that is relatively easy to rectify. This is a quite intrusive and radical change. It's possible that it will break some things (especially if they're obscure or not Linux), so watch out for regressions. It's probably still better to do it the bulldozer way, since slow transition and researching foreign platforms would take a lot of time and effort.
* ao_wasapi: simplify nAvgBytesPerSec calculationMarcoen Hirschberg2014-05-281-4/+3
| | | | | Calculate nBlockAlign seperately to reuse in the calculation of nAvgBytesPerSec.
* atomics: switch to C11 stdatomic.hwm42014-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* ao_wasapi: make code shorterwm42014-03-301-65/+36
| | | | | | | | | Also fix a format string mistake in a log call using it. I wonder if this code shouldn't use FormatMessage, but it looks kind of involved [1], so: no, thanks. [1] http://support.microsoft.com/kb/256348/en-us
* ao_wasapi: Use the character set conversion functions from io.hDiogo Franco (Kovensky)2014-03-111-25/+16
| | | | | ...rather than rolling out our own. The only possible advantage is that the "custom" ones didn't use talloc.
* ao_wasapi: Implement AOCONTROL_UPDATE_STREAM_TITLEDiogo Franco (Kovensky)2014-03-111-34/+55
|
* ao_wasapi: Implement per-application mixingDiogo Franco (Kovensky)2014-03-111-8/+49
| | | | | | | | | | | | | 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.
* ao_wasapi: Move non-critical code outside of the event threadDiogo Franco (Kovensky)2014-03-111-24/+128
| | | | | | | | | | | | | | | 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.
* ao_wasapi: Split into 2 filesDiogo Franco (Kovensky)2014-03-111-0/+867
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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-27 17:47:51 +0000