| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
Whether we print it as warning or error doesn't really matter; we
continue anyway. (I don't actually know what the implications of running
in non-blocking mode are; for what's it worth, when I tested with
explicitly changing to non-blocking, it seemed to work fine anyway, so
don't change that part.)
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
If no-block was given, the device would be opened with SND_PCM_NOBLOCK.
Also, after opening, blocking mode was unconditionally enabled anyway
with snd_pcm_nonblock(). Further, if opening with SND_PCM_NOBLOCK
failed, opening was retried without this flag.
This doesn't make any sense to me, and I've never heard of someone using
this suboption. I suspect it has to do with ancient ALSA bugs or API
caveats. Remove it and simplify the code.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
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".
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Before it was the default device period, which was too small
causing glitches on on entering/exiting fullscreen.
|
| |
|
|
|
|
| |
Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
|
|
|
|
|
| |
In the unlikely event of a timeout waiting for the audio thread to return,
don't free stuff that it may still be using.
|
|
|
|
| |
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453%28v=vs.85%29.aspx
|
| |
|
|
|
|
|
|
|
|
|
| |
When the audio thread fails to properly init, it signals failure
to the main thread, AND THEN starts to clean up. For this to work,
ao_init callback must not return until the thread's cleanup is finished.
This is correctly handled in the ao_uninit callback by waiting for
the thread to exit, so just call that to clean up the main thread.
I have no idea why I didn't do this in the first place.
|
| |
|
|
|
|
|
|
|
| |
Simply retry on EAGAIN.
I've seen this in several other projects; it might be just cargo-culting
though.
|
|
|
|
|
|
| |
dsound was set as default, because there were some hard to fix problems
with wasapi. These problems were probably fixed now, so let's try with
wasapi as default again.
|
|
|
|
|
|
| |
Even with change notifications, there are still (rare) cases when the
feed thread gets AUDCLIENT_DEVICE_INVALIDATED. So handle failures in
thread_feed by requesting ao_reload.
|
|
|
|
| |
this works around reinitializing too fast on device property changes
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Implement skele |