Commit Graph

40 Commits

Author SHA1 Message Date
Misaki Kasumi aebe58203b ao: add ao_stop_streaming 2024-05-25 22:52:45 +02:00
Misaki Kasumi bfadd31957 ao: add eof, pad_silence, and blocking arguments for ao_read_data 2024-05-25 22:52:45 +02:00
Misaki Kasumi 4d03efb4b0 ao: don't call driver->set_paused after reset
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.
2024-05-20 18:22:31 +02:00
nanahi 467c1e860a Revert "ao: in ao_play_data, wakeup core for untimed AO as well"
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.
2024-05-08 11:14:01 +02:00
Misaki Kasumi 0cfd52074b ao: in ao_play_data, wakeup core for untimed AO as well 2024-05-08 03:12:28 +02:00
Kacper Michajłow 18ef834ef4 various: move unistd.h inclusion to common.h 2024-05-06 22:01:17 +02:00
nanahi 06f88dfb3a ao: rename playthread to ao_thread
"playthread" is a confusing name which doesn't describe what it really
is. Rename it to ao_thread, and ao_wakeup_playthread to ao_wakeup,
in the same style as VO threads. This makes call stack function names
less confusing.
2024-04-10 19:00:22 +02:00
Misaki Kasumi 93a924a553 ao: set_pause for pull based ao 2024-04-03 23:40:05 +02:00
Thomas Weißschuh 8ecb462a9c audio: rename ao_read_data_unlocked
As mentioned in [0] the suffix "_locked" would have been the appropriate
naming in line with similar uses inside mpv.
See `mp_abort_recheck_locked()`, `mp_abort_trigger_locked()`,
`retrigger_locked()`, `wakeup_locked()`...

[0] https://github.com/mpv-player/mpv/pull/12811#discussion_r1477518525
2024-02-05 09:25:48 -08:00
Kacper Michajłow a6fb9321ea audio: fix UB when casting INFINITY to integer
Fixes busy wait, because in practice inf would be casted to 0.

Fixes: 174df99
2023-11-15 14:57:18 +00:00
Thomas Weißschuh a96d26e63a audio: avoid unnecessary silence padding in read_buffer()
Not all callers of read_buffer() require the buffer to be padded with
silence.
2023-11-08 20:26:23 +01:00
Thomas Weißschuh 4a134f441d audio: introduce ao_read_data_nonblocking()
This behaves similar to ao_read_data() but does not block and may return
partial data.
2023-11-08 20:26:23 +01:00
Kacper Michajłow 174df99ffa ALL: use new mp_thread abstraction 2023-11-05 17:36:17 +00:00
sfan5 3af25edfa5 Revert "audio: don't block on lock in ao_read_data"
It was found that this causes issues with at least ao_coreaudio,
essentially revealing a way bigger issue:
Some AOs don't check for 0 and/or have no way to deal with short writes.
Someone will have to figure out a fix later but get rid of the direct
cause for now.

This reverts commit ae908a70ce.
2023-10-24 10:38:07 +02:00
Thomas Weißschuh ae908a70ce audio: don't block on lock in ao_read_data
ao_read_data() is used by pull AOs potentially from threads managed by
external libraries.  These threads can be sensitive to blocking.
For example the pipewire ao is using a realtime thread for the
callbacks.
2023-10-20 21:33:46 +02:00
Dudemanguy 50025428b1 ao: convert all timing code to nanoseconds
Pull AOs work off of a callback that relies on mpv's internal timer. So
like with the related video changes, convert all of these to nanoseconds
instead. In many cases, the underlying audio API does actually provide
nanosecond resolution as well.
2023-10-16 15:38:59 +00:00
Dudemanguy 41c0321208 audio: drain ao before setting pause
There's an edge cause with gapless audio and pausing. Since, gapless
audio works by sending an EOF immediately, it's possible to pause on the
next file before audio actually finishes playing and thus the sound gets
cut off. The fix is to simply just always do an ao_drain if the ao is
about to set a pause on EOF and we still have audio playing.
Fixes #8898.
2023-08-11 22:28:50 +00:00
Dudemanguy 9a9039deb2 audio: fix crash during uninit on ao_lavc
The buffer state can be null when using --ao=lavc, so just check it
first. Fixes #10175.
2023-01-13 16:02:38 +00:00
Thomas Weißschuh 657fd2804c audio: reset pull AO at end of file
When a pull AO reaches reaches EOF then ao_read_data() will set
p->playing = false.
Because the ao is marked as not playing ao_set_pause(true) will not
reset the AO.
This keeps the output stream unintentionally open.

Fixes #9835
2022-12-22 15:14:08 -08:00
Philip Langdale ed7717298b audio: fix lack of reinitialization on format change with pull AOs
uau did some investigation and noticed that we do not send a wakeup
event when we encounter end-of-stream in ao_read_data(), in contrast to
the equivalent logic for push AOs in ao_play_data().

Inserting that wakeup fixes the original problem of lack of
reinitialization on a format change without the problems we saw with
the previous attempted fix.

Fixes #10566
2022-08-23 11:01:52 -07:00
Aman Karmani ac3d567bd3 audio: stop corrupting audio on underreads
regression introduced in b74c09efbf

Signed-off-by: Aman Karmani <aman@tmm1.net>
2021-11-20 12:08:32 -08:00
sfan5 d2a56227df Revert "audio: fix ao_reset() not clearing paused state leading to stuck AO"
In hindsight this is obviously broken.
This reverts commit fb5d976cb0.
2021-07-18 12:21:15 +02:00
sfan5 fb5d976cb0 audio: fix ao_reset() not clearing paused state leading to stuck AO
This would happen when switching from playback stuck in cache wait
(underrun) to another file.
2021-07-16 20:58:54 +02:00
sfan5 63ffa07b44 audio: take paused state into account in ao_start()
It makes no sense to instruct the AO to start the pull callbacks
when we know there's nothing to play (only affects pull AOs).
2020-09-20 18:52:54 +02:00
sfan5 c1db4630e6 audio: move start() calls outside of lock
Pull based AOs might want to call ao_read_data() inside start().
This fixes ao_opensles deadlocking.
2020-09-20 18:52:54 +02:00
wm4 1643cb865f audio: fix stream-silence with push AOs (somewhat)
--audio-stream-silence is a shitty feature compensating for awful
consumer garbage, that mutes PCM at first to check whether it's
compressed audio, using formats advocated and owned by malicious patent
troll companies (who spend more money on their lawyers than paying any
technicians), wrapped in a wasteful way to make it constant bitrate
using a standard whose text is not freely available, and only rude users
want it. This feature has been carelessly broken, because it's
complicated and stupid. What would Jesus do? If not getting an aneurysm,
or pushing over tables with expensive A/V receivers on top of them, he'd
probably fix the feature. So let's take inspiration from Jesus Christ
himself, and do something as dumb as wasting some of our limited
lifetime on this incredibly stupid fucking shit.

This is tricky, because state changes like end-of-audio are supposed to
be driven by the AO driver, while playing silence precludes this. But it
seems code paths for "untimed" AOs can be reused.

But there are still problems. For example, underruns will just happen
normally (and stop audio streaming), because we don't have a separate
heuristic to check whether the buffer is "low enough" (as a consequence
of a network stall, but before the audio output itself underruns).
2020-09-03 22:39:23 +02:00
wm4 478d39c574 audio: fix inefficient behavior with ao_alsa, remove period_size field
It is now the AO's responsibility to handle period size alignment. The
ao->period_size alignment field is unused as of the recent audio
refactor commit. Remove it.

It turns out that ao_alsa shows extremely inefficient behavior as a
consequence of the removal of period size aligned writes in the
mentioned refactor commit. This is because it could get into a state
where it repeatedly wrote single samples (as small as 1 sample), and
starved the rest of the player as a consequence. Too bad. Explicitly
align the size in ao_alsa. Other AOs, which need this, should do the
same.

One reason why it broke so badly with ao_alsa was that it retried the
write() even if all reported space could be written. So stop doing that
too. Retry the write only if we somehow wrote less.

I'm not sure about ao_pulse.
2020-08-29 16:27:56 +02:00
wm4 b74c09efbf audio: refactor how data is passed to AO
This replaces the two buffers (ao_chain.ao_buffer in the core, and
buffer_state.buffers in the AO) with a single queue. Instead of having a
byte based buffer, the queue is simply a list of audio frames, as output
by the decoder. This should make dataflow simpler and reduce copying.

It also attempts to simplify fill_audio_out_buffers(), the function I
always hated most, because it's full of subtle and buggy logic.

Unfortunately, I got assaulted by corner cases, dumb features (attempt
at seamless looping, really?), and other crap, so it got pretty
complicated again. fill_audio_out_buffers() is still full of subtle and
buggy logic. Maybe it got worse. On the other hand, maybe there really
is some progress. Who knows.

Originally, the data flow parts was meant to be in f_output_chain, but
due to tricky interactions with the playloop code, it's now in the dummy
filter in audio.c.

At least this improves the way the audio PTS is passed to the encoder in
encoding mode. Now it attempts to pass frames directly, along with the
pts, which should minimize timestamp problems. But to be honest, encoder
mode is one big kludge that shouldn't exist in this way.

This commit should be considered pre-alpha code. There are lots of bugs
still hiding.
2020-08-29 13:12:32 +02:00
Kevin Mitchell 5e323333cf
audio: don't lock ao_control for pull mode drivers
The pull mode APIs were previously required to have thread-safe
ao_controls. However, locks were added in b83bdd1 for parity with push
mode. This introduced deadlocks in ao_wasapi.

Instead, only lock ao_control for the push mode APIs.

fixes #7787

See also #7832, #7811. We'll wait for feedback to see if those should
also be closed.
2020-06-17 02:22:51 -07:00
wm4 c67f36dd18 audio: fix deadlock on draining
The playback thread may obviously still fill the AO'S entire audio
buffer, which means it unset p->draining, which makes no sense and broke
ao_drain(). So just don't unset it here.

Not sure if this really fixes this, it was hard to reproduce. Regression
due to the recent changes. There are probably many more bugs like this.
Stupid asynchronous nightmare state machine. Give me a language that
supports formal verification (in presence of concurrency) or something.
2020-06-04 12:42:36 +02:00
wm4 baa7b5c8dd audio: adjust wait duration
I feel like this makes slightly more sense. At least it doesn't include
the potentially arbitrary constant latency that is generally included in
the delay value. Also, the buffer status doesn't matter - either we've
filled the entire buffer (then we can wait this long), or there's not
enough data anyway (then the core will wake up the thread if new data is
available).

But ultimately, we have to guess, unless the AO does notify us with
ao_wakeup_playthread().

Draining may now wait for no reason up to 1/4th of the total buffer
time. Shouldn't be a disimprovement in practice.
2020-06-03 15:22:18 +02:00
wm4 68ade4e5a5 audio: avoid possible deadlock regression for some AOs
It's conceivable that ao->driver->reset() will make the audio API wait
for ao_read_data() (i.e. its audio callback) to return. Since we
recently moved the reset() call inside the same lock that ao_read_data()
acquires, this could deadlock. Whether this really happens depends on
how exactly the AO behaves. For example, ao_wasapi does not have this
problem. "Push" AOs are not affected either.

Fix by moving it outside of the lock. Assume ao->driver->start() will
not have this problem.

Could affect ao_sdl, ao_coreaudio (and similar rotten fruit AOs). I'm
unsure whether anyone experienced the problem in practice.
2020-06-02 20:43:49 +02:00
wm4 08b198aab4 audio: further simplify internal audio API somewhat
Instead of the relatively subtle underflow handling, simply signal
whether the stream is in a playing state. Should make it more robust.

Should affect ao_alsa and ao_pulse only (and ao_openal, but it's
broken).

For ao_pulse, I'm just guessing. How the hell do you query whether a
stream is playing? Who knows. Seems to work, judging from very
superficial testing.
2020-06-02 20:43:49 +02:00
wm4 0d3474c6c0 audio: slightly better condition for still_playing
Just a detail. If wrong (not unlikely because I'm just guessing my own
messy state machine), this will make the player freeze due to waiting
for something that never happens. Enjoy.
2020-06-02 20:43:49 +02:00
wm4 c5158b057c audio: reduce extra wakeups caused by recent changes
The feeder thread basically woke up the core and itself too often, and
caused some CPU overhead. This was caused by the recent buffer.c
changes.

For one, do not let ao_read_data() wake up the core, and instead rely on
the feeder thread's own buffer management. This is a bit strange, since
the change intended to unify the buffer management, but being more
consequent about it is better deferred to later, when the buffer
management changes again anyway. And also, the "more" condition in the
feeder thread seems outdated, or at least what made it make sense has
been destroyed, so do something that may or may not be better. In any
case, I'm still not getting underruns with ao_alsa, but the wakeup
hammering is gone.
2020-06-01 15:48:45 +02:00
wm4 d27ad96542 audio: redo internal AO API
This affects "pull" AOs only: ao_alsa, ao_pulse, ao_openal, ao_pcm,
ao_lavc. There are changes to the other AOs too, but that's only about
renaming ao_driver.resume to ao_driver.start.

ao_openal is broken because I didn't manage to fix it, so it exits with
an error message. If you want it, why don't _you_ put effort into it? I
see no reason to waste my own precious lifetime over this (I realize the
irony).

ao_alsa loses the poll() mechanism, but it was mostly broken and didn't
really do what it was supposed to. There doesn't seem to be anything in
the ALSA API to watch the playback status without polling (unless you
want to use raw UNIX signals).

No idea if ao_pulse is correct, or whether it's subtly broken now. There
is no documentation, so I can't tell what is correct, without reverse
engineering the whole project. I recommend using ALSA.

This was supposed to be just a simple fix, but somehow it expanded scope
like a train wreck. Very high chance of regressions, but probably only
for the AOs listed above. The rest you can figure out from reading the
diff.
2020-06-01 01:08:16 +02:00
wm4 d448dd5bf2 audio: fix unpausing with some AOs
wasapi/coreaudio/sdl were affected, alsa/pusle were not.

The confusion here was that resume() has different meaning with pull and
push AOs.

Fixes: #7772
2020-05-31 14:43:13 +02:00
wm4 a4b7fcc183 audio: stop applying volume twice for some AOs
Regression since the recent refactor. How did nobody notice?

This happened because the push code now calls the function for the pull
code. Both the former and latter apply the volume, so oops.
2020-05-27 21:11:46 +02:00
wm4 9885952c2a audio: remove ao_driver.drain
The recent change to the common code removed all calls to ->drain. It's
currently emulated via a timed sleep and polling ao_eof_reached(). That
is actually fallback code for AOs which lacked draining. I could just
readd the drain call, but it was a bad idea anyway. My plan to handle
this better is to require the AO to signal a underrun, even if
AOPLAY_FINAL_CHUNK is not set. Also reinstate not possibly waiting for
ao_lavc.c. ao_pcm.c did not have anything to handle this; whatever.
2020-05-27 21:04:32 +02:00
wm4 b83bdd1d17 audio: merge pull/push ring buffer glue code
This is preparation to further cleanups (and eventually actual
improvements) of the audio output code.

AOs are split into two classes: pull and push. Pull AOs let an audio
callback of the native audio API read from a ring buffer. Push AOs
expose a function that works similar to write(), and for which we start
a "feeder" thread. It seems making this split was beneficial, because of
the different data flow, and emulating the one or other in the AOs
directly would have created code duplication (all the "pull" AOs had
their own ring buffer implementation before it was cleaned up).
Unfortunately, both types had completely separate implementations (in
pull.c and push.c). The idea was that little can be shared anyway. But
that's very annoying now, because I want to change the API between AO
and player.

This commit attempts to merge them. I've moved everything from push.c to
pull.c, the trivial entrypoints from ao.c to pull.c, and attempted to
reconcile the differences. It's a mess, but at least there's only one
ring buffer within the AO code now. Everything should work mostly the
same. Pull AOs now always copy the audio data under a lock; before this
commit, all ring buffer access was lock-free (except for the decoder
wakeup callback, which acquired a mutex). In theory, this is "bad", and
people obsessed with lock-free stuff will hate me, but in practice
probably won't matter. The planned change will probably remove this
copying-under-lock again, but who knows when this will happen.

One change for the push AOs now makes it drop audio, where before only a
warning was logged. This is only in case of AOs or drivers which exhibit
unexpected (and now unsupported) behavior.

This is a risky change. Although it's completely trivial conceptually,
there are too many special cases. In addition, I barely tested it, and
I've messed with it in a half-motivated state over a longer time, barely
making any progress, and finishing it under a rush when I already should
have been asleep. Most things seem to work, and I made superficial tests
with alsa, sdl, and encode mode. This should cover most things, but
there are a lot of tricky things that received no coverage. All this
text means you should be prepared to roll back to an older commit and
report your problem.
2020-05-25 01:54:37 +02:00