The detailed issue is here:
#15212
problem: Since The AudioTrack is not an mpv instance level but a global object, it cannot support multiple mpv instances at the same time. For example, if you create two instances and then destroy one of them, the other instance may crash.
Add jni usage count to fix this.
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
Kacper Michajłow
davince
der richter
Misaki Kasumi
llyyr
Dudemanguy
nanahi
Christoph Heinrich