| Commit message (Collapse) | Author | Age |
|
|
|
| |
This is a fix attempt for #1279 and #1249.
|
| |
|
| |
|
|
|
|
|
| |
Fixes commit 52c51149. It broke multichannel (or possibly everything)
for ao_alsa, ao_oss, ao_sndio.
|
|
|
| |
Should hopefully fix #1249 and #1279
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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().
|
|
|
|
| |
Also fix the comment on the softvol field.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...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.
|
|
|
|
| |
Forgotten in commit 5d5f5b09.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems safer: otherwise, opening the AO could randomly fail if the
audio formats happens to be not float.
Unfortunately, this only works if the user does not select a device.
Since ALSA devices are arbitrary strings, including plugins with complex
parameters, it's not trivial or maybe even impossible to edit the string
in a way the "plug" plugin is added.
With --audio-device, it would be safe for users to select either
"default" or one of the "plughw" devices. Everything else seems
questionable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the ALSA channel map API for querying and selecting supported
channel maps.
Since we (probably?) want to be compatible with ALSA versions before the
change, we still try to select the device name by channel map, and open
that device. There's no way to negotiate a channel map before opening,
so we're stuck with this approach. Fortunately, it seems these devices
allow selecting and setting any other supported channel layout, so maybe
this is not an issue at all. In particular, this avoids selecting the
default (dmix) device, which can only do stereo.
Most code is based on Martin Herkt <lachs0r@srsfckn.biz>'s alsa_ng
branch, with heavy modifications.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't crash if no fallback channel layout could be found (caller can't
handle NULL return from select_chmap()). Apparently this could never
actually happen, though.
Don't treat snd_pcm_hw_params_set_periods_near() failure as fatal error.
Same deal as with snd_pcm_hw_params_set_buffer_time_near().
Actually free channel maps returned by snd_pcm_get_chmap().
Adjust some messages.
|
|
|
|
| |
Simpler overall.
|
|
|
|
|
|
|
|
|
| |
No functional changes.
ALSA_PCM_NEW_HW_PARAMS_API was a pre-ALSA 1.0.0 thing and does nothing
with modern ALSA. It stopped being necessary about 10 years ago.
3 functions are moved to avoid forward references.
|
|
|
|
| |
Simplifies memory management.
|
|
|
|
|
|
|
|
| |
If ALSA reports a channel map, and it looks like it makes sense (i.e.
could be converted to mpv channel map, and the channel count matches),
then use that instead of the channel map we are assuming.
This is based on code written by lachs0r (alsa_ng branch).
|
|
|
|
| |
Also shuts up Coverity.
|
|
|
|
|
|
|
| |
Independent from whether the samplerate was accepted or adjusted, errors
returned by the ioctl are fatal errors.
Found by Coverity.
|
|
|
|
|
|
| |
The caller set up the "start" pointer array using the number of planes,
the encode() function used the number of channels. This copied
uninitialized values for packed formats, which makes Coverity warn.
|
|
|
|
|
|
|
|
| |
From what I understand the division is to align the dimension of the
value from seconds to milliseconds. Hard to tell whether the "rounding"
was intentional or not; I'm tipping on "not".
Found by Coverity.
|
|
|
|
| |
Found by Coverity; also see commit 85fb2af3.
|
|
|
|
|
|
| |
Needs 1 additional free entry.
Found by Coverity.
|
|
|
|
| |
Found by Coverity.
|
|
|
|
|
|
| |
like the MSDN example:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd370875%28v=vs.85%29.aspx
|
|
|
|
|
| |
Without this, the retry will fail if they are not equal or
bufferPeriod is zero.
|
|
|
|
| |
a cast to (unsigned) should do "the right thing".
|