ALSA API reports -EPIPE even when the the device is lost, which we
currently always assume to be an XRUN. If we assumed XRUN 10 times and
didn't manage to recover, just consider the device lost and try to
reconnect. Allows ao_alsa to recover from alsa server being killed then
reinitialized. And even in the worst case, this should be better than
the status quo of mpv attempting to prepare a PCM device indefinitely
until the user restarts mpv.
This is admittedly not ideal, and I don't think the -EPIPE hack is
necessary anymore, but I can only test on my setup and removing the
'assume -EPIPE is an XRUN' hack might break some setups for whatever
mysterious reasons.
c522d0dfbd added parser to avoid opening
decoder and left decoder only for DTS. Since then more audio codec needs
decoder, so open decoder always when it might be needed. Exclude only
AC3, other codec have profile to be extracted.
Fixes: c522d0dfbd
This commit adds a state `hw_paused` for pull-based AO.
`driver->set_paused(false)` is only called if `hw_paused` is true.
`hw_paused` is cleared after `ao_reset`, so `set_paused` will
not be called after a reset; instead, `driver->start()` will
be called, which properly starts the AO.
Same as ffmpeg uses. Such big values does not make sense probably, but
let's not overflow values and maybe one day it will be useful.
Fixes signed integer overflow.
This problem does not exist with --demuxer=lavf. --demuxer=mkv just never
signals EOF for the problematic sample, so it needs to be fixed there, not
in AO.
This reverts commit 0cfd52074b.
scaletempo2 has this optimization where it first uses a step size of 5
together with a quadratic interpolation to quickly get the approximate
position of the best overlap and then does a more thorough search aroun
that area.
Doing the same thing in scaletempo brought a 4.8x performance
improvement, however in my measurements a step size of 3 more
consistently finds good overlaps and it's still a 2.9x improvement for
this function.
I should note that while a step size of 3 produced better numbers,
I was not actually able to hear any difference in my test.
A step size of 3 was chosen just in case it actually makes an audible
difference in some cases and the cpu usage isn't really a problem
anymore, but that can be revisited in the future.
scaletempo2 is still faster then scaletempo with a step size of 5,
which I suspect is mostly because it uses some vectorized functions and
scaletempo does not.
This might seem counter intuitive at first, but we want to change the
sound in total as little as possible, not only the middle part of the
overlap.
This also removes the loop unrolling from the integer path to keep it as
close to the float path as possible. The difference in performance is
fairly small and if such an optimization is deemed desirable in the
future it should be implemented for both float and integer
Fixes corrupted audio after resize_input_buffer; realloc_2d did not move
data to new location. Rather than reimplementing more allocator logic,
migrate internals to use talloc and grow buffer with realloc.
6863eefc3d handled this situation by using
an atomic variable to express the state for which the wakeup is caused
by AO control, and the dispatch queue is only processed at this state.
However, this can cause permanent lockup of the player core when the
following happens:
- AO control sets the thread state to WASAPI_THREAD_DISPATCH, and
sets the wakeup handle.
- WASAPI thread reads the WASAPI_THREAD_DISPATCH state and processes
the dispatch queue.
- Another AO control happens. A dispatch item is enqueued, and the
state stays at WASAPI_THREAD_DISPATCH.
- WASAPI thread resets the thread state to WASAPI_THREAD_FEED since
the state has not changed.
- WaitForSingleObject() returns in the WASAPI thread, sees this state,
and does not process the dispatch queue.
- The player core locks permanently because it is waiting for the dispatch
to be processed.
This has been experimentally verified on a system under high contention:
The easiest way to trigger this lockup is to continuously hold down "i",
which rapidly issues AO get volume/mute controls.
To properly handle this, use separate handles for system and user wakeup
requests. Only feed audio when woke up by system and only process the
dispatch queue when woke up by user.
Fixes: 6863eefc3d
