Commit Graph

44 Commits

Author SHA1 Message Date
wm4 6147bcce35 audio: fix format function consistency issues
Replace all the check macros with function calls. Give them all the
same case and naming schema.

Drop af_fmt2bits(). Only af_fmt2bps() survives as af_fmt_to_bytes().

Introduce af_fmt_is_pcm(), and use it in situations that used
!AF_FORMAT_IS_SPECIAL. Nobody really knew what a "special" format
was. It simply meant "not PCM".
2015-06-26 23:06:37 +02:00
wm4 92b9d75d72 threads: use utility+POSIX functions instead of weird wrappers
There is not much of a reason to have these wrappers around. Use POSIX
standard functions directly, and use a separate utility function to take
care of the timespec calculations. (Course POSIX for using this weird
format for time values.)
2015-05-11 23:44:36 +02:00
wm4 524aa99401 audio/out/push: fix off-by-one error
Needs 1 additional free entry.

Found by Coverity.
2014-11-21 03:50:57 +01:00
wm4 5db0fbd95e audio/out: consistently use double return type for get_delay
ao_get_delay() returns double, but the get_delay callback still
returned float.
2014-11-09 11:45:04 +01:00
wm4 3d2e278029 audio/out/push: when using audio wait fallback, recheck condition
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.
2014-11-06 01:15:44 +01:00
wm4 9ba6641879 Set thread name for debugging
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 gets a special-case for glibc, since doing a full
check here would probably be a waste of effort.
2014-10-19 23:48:40 +02:00
wm4 312531c08c audio/out/push: reset projected EOF time on new data
Seems like this could theoretically happen in low buffer situations, but
I haven't spotted this behavior in the wild.
2014-10-14 22:07:04 +02:00
wm4 7e4491a7a7 audio/out/push: make draining slightly more robust
Don't wait after the audio thread has pushed the remaining audio to the
AO. Avoids hard hangs if the heuristic fails completely (could still
happen if get_delay returns absurd values).

CC: @mpv-player/stable
2014-10-10 13:21:43 +02:00
wm4 bd41fc7723 audio/out/push: fix EOF heuristic
Since the internal AO driver API has no proper way to determine EOF, we
need to guess by querying get_delay. But some AOs (e.g. ao_pulse with
no-latency-hacks set) may never reach 0, maybe because they naively add
the latency to the buffer level. In this case our heuristic can break.

Fix by always using the delay to estimate the EOF time. It's not even
that important - it's mostly used to avoid blocking draining. So this
should be ok.

CC: @mpv-player/stable (maybe)
2014-10-10 13:18:53 +02:00
wm4 9e3e5ca598 audio/out/push: fix some AOs freezing on exit
Caused by a dumb deadlock.
2014-10-05 23:05:54 +02:00
wm4 aeefb8511c audio/out/push: make draining more robust
It was more complicated than it had to be: the audio thread already
determines whether audio has ended, so we can use that. Remove the
separate logic for draining.
2014-10-05 00:31:20 +02:00
wm4 6431e09fb3 audio/out/push: limit fallback sleep time to reasonable limits 2014-10-05 00:13:00 +02:00
wm4 650af29471 audio/out/push: clean up properly on init error
Close the wakeup pipes, free the mutex and condition var.
2014-09-27 04:54:17 +02:00
wm4 e79de41b97 audio/out: check device buffer size for push.c only
Should fix #1125.
2014-09-27 04:52:46 +02:00
wm4 94113e632f audio/out: fix active waiting during pause again
This was fixed in commit 8432eaefa, and commit 39609fc1 of course broke
it again. This was pretty stupid.
2014-09-06 16:25:27 +02:00
wm4 39609fc19a audio/out/push: redo audio waiting
Improve the logic how the audio thread decides how to wait until the AO
is ready for new data. The previous commit makes some of this easier,
although it turned out that it wasn't required, and we still can handle
AOs with bad get_space implementation (although the new code prints an
error message, and it might fail in obscure situations).

The new code is pretty similar to the old one, and the main thing that
changes is that complicated conditions are tweaked. AO waiting is now
used better (mainly instead of max>0, r>0 is used). Whether to wakeup
is reevaluated every time, instead of somehow doing the wrong thing
and compensating for it with a flag.

This fixes the specific situation when the device buffer is full, and
we don't want to buffer more data. In the old code, this wasn't handled
correctly: the AO went to sleep forever, because it prevented proper
wakeup by the AO driver, and as consequence never asked the core for new
data. Commit 4fa3ffeb was a hack-fix against this, and now that we have
a proper solution, this hack is removed as well.

Also make the refill threshold consistent and always use 1/4 of the
buffer. (The threshold is used for situations when an AO doesn't
support proper waiting or chunked processing.)

This commit will probably cause a bunch of regressions again.
2014-09-06 12:59:04 +02:00
wm4 bdf49d137e audio/out: make EOF handling properly event-based
With --gapless-audio=no, changing from one file to the next apparently
made it hang, until the player was woken up by unrelated events like
input. The reason was that the AO doesn't notify the player of EOF
properly. the played was querying ao_eof_reached(), and then just went
to sleep, without anything waking it up.

Make it event-based: the AO wakes up the playloop if the EOF state
changes.

We could have fixed this in a simpler way by synchronously draining the
AO in these cases. But I think proper event handling is preferable.

Fixes: #1069
CC: @mpv-player/stable (perhaps)
2014-09-05 23:45:54 +02:00
wm4 a7d737a698 audio: make buffer size configurable
Really only for testing.
2014-09-05 01:53:10 +02:00
wm4 8432eaefa0 audio/out: prevent burning CPU when seeking while paused
The audio/video sync code in player/audio.c calls ao_reset() each time
audio decoding is entered, but the player is paused, and there would be
more than 1 sample to skip to make audio start match with video start.
This caused a wakeup feedback loop with push.c.

CC: @mpv-player/stable
2014-08-31 14:48:58 +02:00
wm4 68ff8a0484 Move compat/ and bstr/ directory contents somewhere else
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.

The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
2014-08-29 12:31:52 +02:00
wm4 218ace2b02 audio: limit on low (and not high) buffer size
The original intention was probably to avoid unnecessarily high numbers
of wakeups. Change it to wait at most 25% of buffer time instead of 75%
until refilling. Might help with the dsound problems in issue #1024, but
I don't know if success is guaranteed.
2014-08-21 22:45:58 +02:00
wm4 ac62244983 audio/out: fix initialization failure with win32
mp_make_wakeup_pipe() always fails on win32. If this call fails on Linux
(and e.g. ao_alsa is used), this will probably burn CPU since poll()
won't work on the invalid file descriptor, but whatever, the failure
case is obscure enough.
2014-07-26 20:26:27 +02:00
wm4 ef600041ba audio, client API: check mp_make_wakeup_pipe() return value
Could fail e.g. due to FD exhaustion.
2014-07-25 14:32:45 +02:00
wm4 fb54a1436a audio: don't wait for draining if paused
Logic for this was missing from pull.c. For push.c it was missing if the
driver didn't support it. But even if the driver supported it (such as
with ao_alsa), strange behavior was observed by users. See issue #933.

Always check explicitly whether the AO is in paused mode, and if so,
don't drain.

Possibly fixes #933.

CC: @mpv-player/stable
2014-07-13 20:06:33 +02:00
wm4 9a0baa4c53 audio: more detailed debugging output
Dump what the AO does on driver->play().
2014-06-12 00:55:13 +02:00
wm4 d07cd11b14 audio: don't wait when draining and paused
A corner case that could possibly lead to infinite waiting. Though
I'm not aware that this actually happened in practice.
2014-06-12 00:55:13 +02:00
wm4 35f87dc692 audio/out/push: don't attempt to fill AO buffer when paused
Doing so will implicitly resume playback. Broken in commit 5929dc45.
2014-06-03 15:58:25 +02:00
wm4 4fa3ffebfe audio/out/push: keep some extra buffer
So the device buffer can be refilled quickly. Fixes dropouts in certain
cases: if all data is moved from the soft buffer to the audio device
buffer, the waiting code thinks it has to enter the mode in which it
waits for new data from the decoder. This doesn't work, because the
get_space() logic tries to keep the total buffer size down. get_space()
will return 0 (or a very low value) because the device buffer is full,
and the decoder can't refill the soft buffer. But this means if the AO
buffer runs out, the device buffer can't be refilled from the soft
buffer. I guess this mess happened because the code is trying to deal
with both AOs with proper event handling, and AOs with arbitrary
behavior.

Unfortunately this increases latency, as the total buffered audio
becomes larger. There are other ways to fix this again, but not today.

Fixes #818.
2014-05-31 01:26:50 +02:00
wm4 9c9f23eee9 ao_alsa: reduce spurious wakeups
Apparently this can happen. So actually only return from waiting if ALSA
excplicitly signals that new output is available, or if we are woken up
externally.
2014-05-30 23:54:11 +02:00
wm4 8ba346a554 audio/out/push: handle draining correctly
This did not flush remaining audio in the buffer correctly (in case an
AO has an internal block size). So we have to make the audio feed thread
to write the remaining audio, and wait until it's done.

Checking the avoid_ao_wait variable should be enough to be sure that all
data that can be written was written to the AO driver.
2014-05-30 02:17:15 +02:00
wm4 c79689206c audio: change handling of an EOF corner case
This code handles buggy AOs (even if all AOs are bug-free, it's good for
robustness). Move handling of it to the AO feed thread. Now this check
doesn't require magic numbers and does exactly what's it supposed to do.
2014-05-30 02:16:43 +02:00
wm4 5dcfc4f604 audio/out/push: add a way to wait for the audio device with poll()
Will be used for ALSA.
2014-05-30 02:16:25 +02:00
wm4 5929dc458f audio/out/push: add mechanism for event-based waiting
Until now, we've always calculated a timeout based on a heuristic when
to refill the audio buffers. Allow AOs to do it completely event-based
by providing wait and wakeup callbacks.

This also shuffles around the heuristic used for other AOs, and there is
a minor possibility that behavior slightly changes in real-world cases.
But in general it should be much more robust now.

ao_pulse.c now makes use of event-based waiting. It already did before,
but the code for time-based waiting was also involved. This commit also
removes one awkward artifact of the PulseAudio API out of the generic
code: the callback asking for more data can be reentrant, and thus
requires a separate lock for waiting (or a recursive mutex).
2014-05-30 02:15:47 +02:00
wm4 f47a4fc3d9 threads: use mpv time for mpthread_cond_timedwait wrapper
Use the time as returned by mp_time_us() for mpthread_cond_timedwait(),
instead of calculating the struct timespec value based on a timeout.
This (probably) makes it easier to wait for a specific deadline.
2014-05-18 19:20:32 +02:00
wm4 c78b8b2c0c audio/out: fix previous commit
This didn't quite work. The main issue was that get_space tries to be
clever to reduce overall buffering, so it will cause the playloop to
decode and queue only as much audio as is needed to refill the AO in
reasonable time. Also, even if ignoring the problem, the logic of the
previous commit was slightly broken. (This required a few retries,
because I couldn't reproduce the issue on my own machine.)
2014-05-11 20:51:49 +02:00
wm4 665c8b59be audio/out: avoid wakeup feedback loop
When the audio buffer went low, but could not be refilled yet, it could
happen that the AO playback thread and the decode thread could enter a
wakeup feedback loop, causing up to 100% CPU usage doing nothing. This
happened because the decoder thread would wake up the AO thread when
writing 0 bytes of newly decoded data, and the AO thread in reaction
wakes up the decoder thread after writing 0 bytes to the AO buffer.

Fix this by waking up the decoder thread only if data was actually
played or queued. (This will still cause some redundant wakeups, but
will eventually settle down, reducing CPU usage close to ideal.)
2014-05-11 19:00:05 +02:00
wm4 09ecf7a68a audio/out: more debugging info for --dump-stats 2014-05-11 16:41:19 +02:00
wm4 040c050f2d audio: fix the exact value that is used for the wait time
The comment says that it wakes up the main thread if 50% has been
played, but in reality the value was 0.74/2 => 37.5%. Correct this. This
probably changes little, because it's a very fuzzy heuristic in the
first place.

Also move down the min_wait calculation to where it's actually used.
2014-05-04 20:41:00 +02:00
wm4 04c4927140 audio: minor simplification in wait code 2014-04-23 21:16:52 +02:00
wm4 40a072480c audio: add hack against broken pulseaudio EOF condition
This was reported with PulseAudio 2.1. Apparently it still has problems
with reporting the correct delay. Since ao_pulse.c still has our custom
get_delay implementation, there's a possibility that this is our fault,
but this seems unlikely, because it's full of workarounds for issues
like this. It's also possible that this problem doesn't exist on
PulseAudio 5.0 anymore (I didn't explicitly retest it).

The check is general and works for all push based AOs. For pull based
AOs, this can't happen as pull.c implements all the logic correctly.
2014-04-17 22:50:49 +02:00
wm4 e2184fcbfb audio: wake up the core when audio buffer is running low
And also add a function ao_need_data(), which AO drivers can call if
their audio buffer runs low.

This change intends to make it easier for the playback thread: instead
of making the playback thread calculate a timeout at which the audio
buffer should be refilled, make the push.c audio thread wakeup the core
instead.

ao_need_data() is going to be used by ao_pulse, and we need to
workaround a stupid situation with pulseaudio causing a deadlock because
its callback still holds the internal pulseaudio lock.

For AOs that don't call ao_need_data(), the deadline is calculated by
the buffer fill status and latency, as before.
2014-04-15 22:38:16 +02:00
wm4 d842b017e4 audio/out: reduce amount of audio buffering
Since the addition of the AO feed thread, 200ms of latency (MIN_BUFFER)
was added to all push-based AOs. This is not so nice, because even AOs
with relatively small buffering (e.g. ao_alsa on my system with ~170ms
of buffer size), the additional latency becomes noticable when e.g.
toggling mute with softvol.

Fix this by trying to keep not only 200ms minimum buffer, but also 200ms
maximum buffer. In other words, never buffer beyond 200ms in total. Do
this by estimating the AO's buffer fill status using get_space and the
initially known AO buffer size (the get_space return value on
initialization, before any audio was played). We limit the maximum
amount of data written to the soft buffer so that soft buffer size and
audio buffer size equal to 200ms (MIN_BUFFER).

To avoid weird problems with weird AOs, we buffer beyond MIN_BUFFER if
the AO's get_space requests more data than that, and as long as the soft
buffer is large enough.

Note that this is just a hack to improve the latency. When the audio
chain gains the ability to refilter data, this won't be needed anymore,
and instead we can introduce some sort of buffer replacement function in
order to update data in the soft buffer.
2014-03-10 01:13:40 +01:00
wm4 e16c91d07a audio/out: make draining a separate operation
Until now, this was always conflated with uninit. This was ugly, and
also many AOs emulated this manually (or just ignored it). Make draining
an explicit operation, so AOs which support it can provide it, and for
all others generic code will emulate it.

For ao_wasapi, we keep it simple and basically disable the internal
draining implementation (maybe it should be restored later).

Tested on Linux only.
2014-03-09 01:27:41 +01:00
wm4 a477481aab audio/out: feed AOs from a separate thread
This has 2 goals:
- Ensure that AOs have always enough data, even if the device buffers
  are very small.
- Reduce complexity in some AOs, which do their own buffering.

One disadvantage is that performance is slightly reduced due to more
copying.

Implementation-wise, we don't change ao.c much, and instead "redirect"
the driver's callback to an API wrapper in push.c.

Additionally, we add code for dealing with AOs that have a pull API.
These AOs usually do their own buffering (jack, coreaudio, portaudio),
and adding a thread is basically a waste. The code in pull.c manages
a ringbuffer, and allows callback-based AOs to read data directly.
2014-03-09 01:27:41 +01:00