When the monitor goes to sleep, the OpenAL context was not properly
handled, resulting in a null pointer dereference and a crash. This
fix ensures that the OpenAL context is created and set correctly,
avoiding crashes under these conditions.
Fixes: #15648
The server's protocol version is not available until a connection is
properly established. Currently the value of `PA_INVALID_INDEX` is printed
due to calling `pa_context_get_server_protocol_version()` before connecting.
Fix this by doing the call after the connection has been set up.
Fixes: f744aadb77 ("ao_pulse: dump library version etc.")
The problem here is likely ao_alsa specific and has the same symptons as
what the previous commit fixed (audio not playing when the file changes
but the details are a bit different here and the sample rate does not
matter. When using gapless audio (the default), the core player
immediately marks the audio status as EOF after it starts draining and
allows the remaining audio buffers to play while it marches on. This
works fine. When not using gapless audio, it doesn't immediately set EOF
and instead waits for the audio to finish playing before it does
anything else. The problem is that ao_is_playing is always true so the
core waits forever thinking audio is still playing when it actually
isn't.
ao_play_data is what is in charge of setting the mp_pcm_state with it
calling out to the backend for additional help. Unfortunately, this
doesn't work for alsa because it's too dumb to signal the desired states
in this edge case so we have to help it a bit. The main thing to notice
here is that even though we can get EOF from a frame, there can still be
additional valid samples that compe after it. So we can't just
immediately quit after EOF is seen. The approach here is to simply save
if we got eof sometime in the past, wait until we get no more samples,
mark state.playing as false and then jump over to the eof code. This
will set p->playing to false as desired which allows the core code to
set EOF and finally we can go through the reset logic and actually play
audio for the next file.
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.
