| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MSDN documentation for IsFormatSupported says a return code of
AUDCLNT_E_UNSUPPORTED_FORMAT means the function "succeeded but the
specified format is not supported in exclusive mode." This seems to
imply that the format is supported in shared mode, and that's what the
old code assumed, however try_format would incorrectly return success
with some drivers.
The remarks section of the documentation contradicts that assumption. It
says that in shared mode, if the audio engine does not support the
caller-specified format or any similar format, ppClosestMatch is set to
NULL and the function returns AUDCLNT_E_UNSUPPORTED_FORMAT. This is the
same as in exclusive mode, so treat AUDCLNT_E_UNSUPPORTED_FORMAT the
same regardless of opt_exclusive. In shared mode, the format selection
code will fall back to the mix format, which should always be supported.
|
|
|
|
|
|
|
|
|
| |
Apparently, physically disconnecting the audio device (consider USB
audio) breaks the ALSA device handle forever. It will signal ENODEV.
Fortunately, it's easy for us to handle this, and we can just use
existing mechanisms that will make the playback core close and reopen
the AO. Whether the immediate reopening will actually succeeds really is
ALSA's problem, though.
|
|
|
|
|
|
|
|
|
|
| |
In general, you need to check errno when using strtol(), but as far as I
know, strtol() won't reset errno on success. This has to be done
manually. The code could have failed sporadically if strtol() succeeded,
and errno was already set to one of the checked values.
(This strtol() still isn't fully error checked, but I don't know if it's
intentional, e.g. for parsing a numeric prefix only.)
|
| |
|
|
|
|
|
|
|
| |
We must not try to remap channels with this. Whethever ALSA gives us,
and whatever we do with it, the result will probably be nonsense.
Untested, as I don't have the required hardware.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This used to be required to workaround PulseAudio bugs. Even later, when
the bugs were (partially?) fixed in PulseAudio, I had the feeling the
hacks gave better behavior. On the other hand, I couldn't actually
reproduce any bad behavior without the hacks lately. On top of this, it
seems our hacks sometimes perform much worse than PulseAudio's native
implementation (see #1430).
So disable the hacks by default, but still leave the code and the option
in case it still helps somewhere. Also, being able to blame PulseAudio's
code by using its native API is much easier than trying to debug our own
(mplayer2-derived) hacks.
|
|
|
|
|
|
|
|
|
| |
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.
Conflicts:
video/out/w32_common.c
waftools/checks/custom.py
|
|
|
|
| |
Also, don't use av_log() for mpv output.
|
| |
|
|
|
|
| |
before we were reinventing this wheel
|
|
|
|
| |
hopefully this fixes #1350
|
|
|
|
| |
fixes #1376
|
|
|
|
|
|
|
|
| |
* bits instead of bytes
* add valid_bits argument
* just pass in the mp_chmap and get the number and wavext channel map from that
* indicate valid bits in waveformat_to_str
* make appropriate accomodations in try_format
|
|
|
|
| |
someone on irc reported seeing this error
|
|
|
|
|
|
|
|
|
|
| |
This message is printed when the audio device advertised a channel map,
but couldn't set it - which is probably a dmix bug (we'll never know,
ALSA doesn't take bug reports).
Print the requested map, so that the user (maybe) can make a connection
when seeing the message and the actually used channel map, which might
be less confusing. Or at least less useless.
|
|
|
|
| |
This could be helpful with bug reports.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of just failing during channel map selection, try to select a close
layout that makes most sense and upmix/downmix to that instead of failing AO
initialization. The heuristic is rather simple, and uses the following steps:
1) If mono is required always prefer stereo to a multichannel upmix.
2) Search for an upmix that is an exact superset of the required channel map.
3) Search for a downmix that is the exact subset of the required channel map.
4) Search for either an upmix or downmix that is the closest (minimum difference
of channels) to the required channel map.
|
|
|
|
| |
This is common on Apple systems so it's handy to have a label for it.
|
|
|
|
| |
useless after 069016fd6c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There where 3 major errors in the previous code:
1) The kAudioDevicePropertyPreferredChannelLayout selector returns a single
layout not an array.
2) The check for AudioChannelLayout allocation size was wrong (didn't account
for variable sized struct).
3) Didn't query the kAudioDevicePropertyPreferredChannelsForStereo selector
since I didn't know about it's existence.
All of these are fixed.
Might help with #1367
|
| |
|
| |
|
|
|
|
| |
Should help remote debugging #1367 with --msg-level=ao=debug
|
|
|
|
|
|
|
|
| |
AudioChannelLayout uses a trailing variable sized array so we need to
query CoreAudio for the size of the struct it is going to need (or the
conversion of that particular layout would fail).
Fixes #1366
|
|
|
|
|
|
| |
Needed after af3bbb800d since now we use channel mapping all the time.
Fixes #1357
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...because everything is terrible.
strerror() is not documented as having to be thread-safe by POSIX and
C11. (Which is pretty much bullshit, because both mandate threads and
some form of thread-local storage - so there's no excuse why
implementation couldn't implement this in a thread-safe way. Especially
with C11 this is ridiculous, because there is no way to use threads and
convert error numbers to strings at the same time!)
Since we heavily use threads now, we should avoid unsafe functions like
strerror().
strerror_r() is in POSIX, but GNU/glibc deliberately fucks it up and
gives the function different semantics than the POSIX one. It's a bit of
work to convince this piece of shit to expose the POSIX standard
function, and not the messed up GNU one.
strerror_l() is also in POSIX, but only since the 2008 standard, and
thus is not widespread.
The solution is using avlibc (libavutil, by its official name), which
handles the unportable details for us, mostly. We avoid some pain.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
also remove bogus ao_format
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
it just sucks. noone should have to listen to that.
|
|
|
|
|
| |
It only confused the issue. Replace it's functionality with
waveformat_copy function where needed.
|
| |
|
|
|
|
| |
it would have caused a deadlock if it fired anyway.
|
|
|
|
| |
WAVEFORMATEXTENSIBLE size
|
| |
|
|
|
|
|
| |
Only issue a warning for failure of wasapi_enumerate_devices and
wasapi_fill_VistaBlob.
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
Give them the prefix mp_ and make them nonstatic.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
also drop some useless const declaraitons
|
|
|
|
|
| |
We weren't actually checking this value anyway. We only really
cared about init failure, which was checked another way.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Same for SetIconPath().
|
| |
|
|
|
|
|
|
| |
This can for example reproduced by killing the pulseaudio server. If
this happens, just try to reload the AO, instead of breaking everything
forever.
|
|
|
|
| |
Apparently this was a mistake.
|
|
|
|
| |
The resume code was accidentally fully removed from this code path.
|
|
|
|
|
|
|
|
|
|
|
| |
snd_pcm_prepare() was not always called, which could result in an
infinite loop.
Whether snd_pcm_prepare() was actually called depended on whether the
device was a hw device (or other characteristics; depending on
snd_pcm_hw_params_can_pause()), and required real suspend (annoying for
testing), so it was somewhat tricky to reproduce without knowing these
things.
|
|
|
|
|
|
|
| |
When setting the ALSA channel map, we never actually set the map we got
from ALSA directly, but convert it to mpv's, and then back to ALSA's.
mpv and ALSA use different conventions for mono, and there is already an
exception for ALSA->mpv, but not mpv->ALSA.
|
|
|
|
|
| |
This would have always forced mono first (if supported by the AO),
instead of stereo.
|
|
|
|
| |
This makes it fallback to stereo properly.
|
| |
|
|
|
|
|
|
|
| |
Based on patch by Yuriy Kaminskiy [yumkam gmail].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37330 b3059339-0415-0410-9bf9-f77b7e298cf2
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
ALSA returns "FL" as channel layout when trying to play mono. mpv and
libavresample don't like this; in particular, using libavresample to
convert stereo to "FL" fails.
|
|
|
|
| |
for #1279 and #1249
|
| |
|
|
|
|
| |
For #1279
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ALSA is crap. It's impossible to make multichannel playback just do the
right thing. dmix (the default on most distros) can do stereo only, and
will refuse to play multichannel. On the other hand, if you try like mpv
(and mplayer) to open a multichannel device (like "surround51" etc.),
this will actually open a hardware device, which will either fail if
dmix is active, or block out dmix if opening succeeds.
This commit falls back to "default" (i.e. dmix) if opening a
multichannel device fails, which is a tiny step towards the right
behavior. (Although fixing it fully is impossible.)
|
|
|
|
| |
This is a fix attempt for #1279 and #1249.
|
| |
|
| |
|
|
|
|
| |
Should hopefully fix #1249 and #1279
|
|
|
|
| |
Also fix the comment on the softvol field.
|
|
|
|
|
| |
Fixes commit 52c51149. It broke multichannel (or possibly everything)
for ao_alsa, ao_oss, ao_sndio.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This could trigger an assertion when using ao_alsa or ao_coreaudio. The
code was simply assuming the number of channel maps was bounded
statically (which was true at first in both AOs).
Fix by using dynamic memory allocation. It needs to be explicitly
enabled by the AOs by setting a temp context, because otherwise the
memory couldn't be freed. (Or at least this seems to be the most elegant
solution.)
Fixes #1306.
|
|
|
|
| |
Forgotten in commit 5d5f5b09.
|