summaryrefslogtreecommitdiffstats
path: root/audio/out/push.c
Commit message (Collapse)AuthorAgeFilesLines
* audio: fix format function consistency issueswm42015-06-261-1/+1
| | | | | | | | | | | 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".
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-111-3/+6
| | | | | | | 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.)
* audio/out/push: fix off-by-one errorwm42014-11-211-1/+1
| | | | | | Needs 1 additional free entry. Found by Coverity.
* audio/out: consistently use double return type for get_delaywm42014-11-091-2/+2
| | | | | ao_get_delay() returns double, but the get_delay callback still returned float.
* audio/out/push: when using audio wait fallback, recheck conditionwm42014-11-061-1/+2
| | | | | | | | | | | 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.
* Set thread name for debuggingwm42014-10-191-0/+1
| | | | | | | | | | 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.
* audio/out/push: reset projected EOF time on new datawm42014-10-141-1/+4
| | | | | Seems like this could theoretically happen in low buffer situations, but I haven't spotted this behavior in the wild.
* audio/out/push: make draining slightly more robustwm42014-10-101-1/+1
| | | | | | | | 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
* audio/out/push: fix EOF heuristicwm42014-10-101-18/+14
| | | | | | | | | | | | | 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)
* audio/out/push: fix some AOs freezing on exitwm42014-10-051-1/+1
| | | | Caused by a dumb deadlock.
* audio/out/push: make draining more robustwm42014-10-051-20/+15
| | | | | | 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.
* audio/out/push: limit fallback sleep time to reasonable limitswm42014-10-051-2/+4
|
* audio/out/push: clean up properly on init errorwm42014-09-271-9/+16
| | | | Close the wakeup pipes, free the mutex and condition var.
* audio/out: check device buffer size for push.c onlywm42014-09-271-0/+5
| | | | Should fix #1125.
* audio/out: fix active waiting during pause againwm42014-09-061-1/+2
| | | | | This was fixed in commit 8432eaefa, and commit 39609fc1 of course broke it again. This was pretty stupid.
* audio/out/push: redo audio waitingwm42014-09-061-45/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* audio/out: make EOF handling properly event-basedwm42014-09-051-5/+40
| | | | | | | | | | | | | | | | | 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)
* audio: make buffer size configurablewm42014-09-051-2/+2
| | | | Really only for testing.
* audio/out: prevent burning CPU when seeking while pausedwm42014-08-311-1/+2
| | | | | | | | | 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
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-1/+1
| | | | | | | | | 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.
* audio: limit on low (and not high) buffer sizewm42014-08-211-1/+1
| | | | | | | 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.
* audio/out: fix initialization failure with win32wm42014-07-261-2/+1
| | | | | | | 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.
* audio, client API: check mp_make_wakeup_pipe() return valuewm42014-07-251-5/+7
| | | | Could fail e.g. due to FD exhaustion.
* audio: don't wait for draining if pausedwm42014-07-131-1/+6
| | | | | | | | | | | | | 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
* audio: more detailed debugging outputwm42014-06-121-0/+2
| | | | Dump what the AO does on driver->play().
* audio: don't wait when draining and pausedwm42014-06-121-1/+1
| | | | | A corner case that could possibly lead to infinite waiting. Though I'm not aware that this actually happened in practice.
* audio/out/push: don't attempt to fill AO buffer when pausedwm42014-06-031-2/+3
| | | | Doing so will implicitly resume playback. Broken in commit 5929dc45.
* audio/out/push: keep some extra bufferwm42014-05-311-6/+4
| | | | | | | | | | | | | | | | | | | 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.
* ao_alsa: reduce spurious wakeupswm42014-05-301-2/+4
| | | | | | 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.
* audio/out/push: handle draining correctlywm42014-05-301-7/+22
| | | | | | | | | 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.
* audio: change handling of an EOF corner casewm42014-05-301-5/+9
| | | | | | 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.
* audio/out/push: add a way to wait for the audio device with poll()wm42014-05-301-3/+64
| | | | Will be used for ALSA.
* audio/out/push: add mechanism for event-based waitingwm42014-05-301-74/+87
| | | | | | | | | | | | | | | | 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).
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-1/+1
| | | | | | 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.
* audio/out: fix previous commitwm42014-05-111-9/+11
| | | | | | | | | 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.)
* audio/out: avoid wakeup feedback loopwm42014-05-111-2/+7
| | | | | | | | | | | | | 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.)
* audio/out: more debugging info for --dump-statswm42014-05-111-1/+5
|
* audio: fix the exact value that is used for the wait timewm42014-05-041-3/+2
| | | | | | | | | 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.
* audio: minor simplification in wait codewm42014-04-231-2/+1
|
* audio: add hack against broken pulseaudio EOF conditionwm42014-04-171-1/+16
| | | | | | | | | | | | 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.
* audio: wake up the core when audio buffer is running lowwm42014-04-151-15/+60
| | | | | | | | | | | | | | | | | 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.
* audio/out: reduce amount of audio bufferingwm42014-03-101-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* audio/out: make draining a separate operationwm42014-03-091-3/+15
| | | | | | | | | | | | 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.
* audio/out: feed AOs from a separate threadwm42014-03-091-0/+266
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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-20 15:37:22 +0000