| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 skeleton IMMNotificationClient to watch for changes in the
sound device. This will make recovery possible from changes shared
mode sample rate, bit depth, "enhancements"/effects and even graceful
device removal.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd371417%28v=vs.85%29.aspx
Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
IMMDeviceEnumerator::GetDefaultAudioEndpoint may set pDevice to null on failure.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd371401%28v=vs.85%29.aspx
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
also enforce more consistency in the exit codes and error handling
thanks to Jonathan Yong <10walls@gmail.com>
|
| |
|
|
|
|
|
|
| |
the race condition that necessitated disabling
this was fixed in
e4403523131a69a92a8418bb3714090a408680c7
|
| |
|
| |
|
|
|
|
| |
Normally, these should be valid anyway, so this is just being cautious.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When initialization failed, vo_lavc may cause an irrecoverable state in
the ffmpeg-related structs. Therefore, we reject additional
initialization attempts at least until we know a better way to clean up
the mess.
ao_lavc currently cannot be initialized more than once, yet it's good to
do consistent changes there as well.
Also, clean up uninit-after-failure handling to be less spammy.
|
|
|
|
|
|
|
|
|
|
|
| |
The mp_audio_from_avframe() function requires the AVFrame to be
refcounted, and merely increases its refcount while referencing the same
data. For non-refcounted frames, it simply did nothing and potentially
would make the caller pass around a frame with dangling pointers.
(libavcodec should always return refcounted frames, but it's not clear
what other code does; and also the function should simply work, instead
of having weird requirements on its arguments.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rewrites the audio decode loop to some degree. Audio filters don't
do refcounted frames yet, so af.c contains a hacky "emulation".
Remove some of the weird heuristic-heavy code in dec_audio.c. Instead of
estimating how much audio we need to filter, we always filter full
frames. Maybe this should be adjusted later: in case filtering increases
the volume of the audio data, we should try not to buffer too much
filter output by reducing the input that is fed at once.
For ad_spdif.c and ad_mpg123.c, we don't avoid extra copying yet - it
doesn't seem worth the trouble.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use a pseudo-filter when changing speed with resampling, instead of
somehow changing a samplerate somewhere. This uses the same underlying
mechanism, but is a bit more structured and cleaner. It also makes some
of the following changes easier.
Since we now always use filters to change audio speed, move most of the
work set_playback_speed() does to recreate_audio_filters().
|
| |
|
|
|
|
|
| |
This is somewhat duplicated from ad_lavc.c and af_lavfi.c, but will
eventually be used by both.
|
|
|
|
|
|
| |
A helper to allocate refcounted audio frames from a pool. This will
replace the static buffer many audio filters use (af->data), because
such static buffers are incompatible with refcounting.
|
|
|
|
|
|
|
| |
A first step towards refcounted audio frames.
Amazingly, the API just does what we want, and the code becomes
simpler. We will need to NIH allocation from a pool, though.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the audio callback suddenly stops, and the AO provides no "reset"
callback, then reset() could deadlock by waiting on the audio callback
forever.
The waiting was needed to enter a consistent state, where the audio
callback guarantees it won't access the ringbuffer. This in turn is
needed because mp_ring_reset() is not concurrency-safe.
This active waiting is unavoidable. But the way it was implemented, the
audio callback had to call ao_read_data() at least once when reset() is
called. Fix this by making ao_read_data() set a flag upon entering and
leaving, which basically turns p->state into some sort of spinlock.
The audio callback actually never needs to spin, because there are only
2 states: playing audio, or playing silence. This might be a bit
surprising, because usually atomic_compare_exchange_strong() requires a
retry-loop idiom for correct operation.
This commit is needed because ao_wasapi can (or will in the future)
randomly stop the audio callback in certain corner cases. Then the
player would hang forever in reset().
|
|
|
|
|
| |
ao_get_delay() returns double, but the get_delay callback still
returned float.
|
|
|
|
|
|
|
|
|
|
| |
This is what you would expect. Before this commit, each
ao_request_reload() call would just queue a reload command, and then
recreate the AO for the number of times the function was called.
Instead of sending a command, introduce some sort of event retrieval
mechanism. At least for the reload case, use atomics, because we're too
lazy to setup an extra mutex.
|
|
|
|
|
|
| |
The main need I see for this is with libmpv - it would be confusing if
some application showed up as "mpv" on whateverthehell PulseAudio uses
it for (generally it does show up on various PA GUI tools).
|
|
|
|
|
|
|
|
|
|
| |
The intention is to avoid using the timeout-based fallback.
There's some minor hope that this will help with OpenBSD (see #1239),
although it probably won't.
Some chance that this will cause trouble with obscure OSS
implementations or emulations.
|
|
|
|
|
|
|
|
|
|
|
| |
If calling ao->driver->wait() fails, we need to fallback to timeout-
based waiting. But it could be that at this point, the mutex was already
released (and then re-acquired). So we need to recheck the condition in
order to avoid missed wakeups.
This probably wasn't an actually occurring problem, but still could
cause a small race-condition window if the dynamic fallback is actually
used.
|
|
|
|
|
| |
Apparently we actually need this. At least the following commit would
break without this.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently this can "sometimes" return an error. In my opinion, this
should never return an error: neither the semantics of the function,
nor the ALSA documentation or ALSA sample code seem to indicate that
a failure is to be expected. I'm not perfectly sure about this though
(I blame ALSA being a weird, big, underdocumented API).
Since it causes problems for some users, and since there is really no
reason why we should abort on such an error, turn it into a warning.
Fixes #1231.
|
|
|
|
| |
This sounds much more intuitive, while "empty" was a bit of a WTF.
|
| |
|
|
|
|
|
| |
Anticipated use: simple solution for dealing with audio APIs which
request configuration changes via events.
|
|
|
|
|
| |
Why not. (I thought I needed this, but my other experiments failed. So
this is merely a minor cleanup.)
|
|
|
|
| |
This is so that the source file name matches the AO name
|
| |
|
|
|
|
|
| |
Looks like this will help us with making --audio-device and spdif work
as expected on OSX. To be used ina following commit.
|
|
|
|
| |
Oops.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the list associated with --audio-device is supposed to enable
simple user-selection, it doesn't make much sense to include overly
special things like ao_pcm or ao_null in the list. Specifically,
ao_pcm is harmful, because it will just dump all audio to a file
named audiodump.wav in the current working directory. The user can't
choose the filename (it can be customized, but not through this
option), and the working directory might be essentially random,
especially if this is used from a GUI.
Exclude "strange" entries. We reuse the fact that there's already a
simple list ordered by auto-probe priority in order to avoid having to
add an additional flag. This is also why coreaudio_exclusive was moved
above ao_null: ao_null ends auto-probing and marks the start of
"special" outputs, which don't show up on the device, but we want
coreaudio_exclusive to be selectable (I think).
|
|
|
|
|
|
|
| |
Move it above ao_null, so that it can be selected during auto-probing
(even if it's only last). I see no reason why it should not be included,
and it makes the following commit slightly more elegant. (See
explanations there.)
|
|
|
|
|
|
|
|
|
|
| |
Especially with other components (libavcodec, OSX stuff), the thread
list can get quite populated. Setting the thread name helps when
debugging.
Since this is not portable, we check the OS variants in waf configure.
old-configure just g |