summaryrefslogtreecommitdiffstats
path: root/audio
Commit message (Collapse)AuthorAgeFilesLines
* ao_coreaudio: fix some incorrect channel mappingsrcombs/macos-fixesrcombs2021-11-281-6/+6
|
* ao_coreaudio: fix getting non-ASCII device descriptionsrcombs2021-11-281-1/+1
|
* audio: stop corrupting audio on underreadsAman Karmani2021-11-201-1/+2
| | | | | | regression introduced in b74c09efbf7c6969fc053265f72cc0501b840ce1 Signed-off-by: Aman Karmani <aman@tmm1.net>
* ao_opensles: add guards for sample rate to useTom Yan2021-11-191-0/+2
| | | | | | Upstream "Wilhelm" (the Android OpenSLES implementation) supports only 8000 <= rate <= 192000. Make sure mpv resamples the audio when necessary.
* options: remove always true m_obj_list::allow_unknown_entriesEmil Velikov2021-11-151-1/+0
| | | | | | | Ever instance of m_obj_list is a constant and for all of them, the field is true. Just remove the field all together. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* ao_oss: define PATH_DEV_MIXER as it is an internal defineJan Ekström2021-11-101-0/+1
| | | | | | | | This fixes a mismatch between configure working and build time failing with Linux + OSSv4, enabling compilation on Debian based Linux systems with the oss4-dev package. Fixes #9378
* audio: replace deprecated av_mallocz_arraysfan52021-11-051-1/+1
|
* ao_audiotrack: change buffer sizing logicAman Karmani2021-10-211-2/+2
| | | | | | | | Previously number of channels was being ignored. The buffer will now be between 75ms and 150ms Signed-off-by: Aman Karmani <aman@tmm1.net>
* ao_audiotrack: allocate chunk buffer based on negotiated sizeAman Karmani2021-10-211-2/+3
| | | | Signed-off-by: Aman Karmani <aman@tmm1.net>
* ao_audiotrack: support delay up to 2s as normalAman Karmani2021-10-211-2/+2
| | | | | | Fixes issues streaming to echo speaker pair from firetv devices. Signed-off-by: Aman Karmani <aman@tmm1.net>
* ao_audiotrack: set device_buffer based on underlying buffer size when availableAman Karmani2021-10-211-0/+10
| | | | Signed-off-by: Aman Karmani <aman@tmm1.net>
* ao_audiotrack: use new style initializer for AudioTrack when availableAman Karmani2021-10-211-11/+114
| | | | | | Fixes deprecation warnings printed when using this driver. Signed-off-by: Aman Karmani <aman@tmm1.net>
* Revert "audio: fix ao_reset() not clearing paused state leading to stuck AO"sfan52021-07-181-1/+0
| | | | | In hindsight this is obviously broken. This reverts commit fb5d976cb070020e35501685c9f84b9435b248e6.
* audio: fix ao_reset() not clearing paused state leading to stuck AOsfan52021-07-161-0/+1
| | | | | This would happen when switching from playback stuck in cache wait (underrun) to another file.
* af_scaletempo2: use gcc vectors to speed up inner loopNiklas Haas2021-05-261-3/+72
| | | | | | | | | | This brings my scaletempo2 benchmark down from ~22s to ~7s on my machine (-march=native), and down to ~11s with a generic compile. Guarded behind an appropriate #ifdef to avoid being ableist against people who have the clinical need to run obscure platforms. Closes #8848
* build: address AVCodec, AVInputFormat, AVOutputFormat const warningssfan52021-05-013-3/+3
| | | | FFmpeg recently changed these to be const on their side.
* ao/pulse: fix incorrect state reported after resetsfan52021-04-291-0/+1
| | | | fixes #8768
* audio/aframe: reuse data buffer if less than 8 channelssfan52021-04-081-6/+12
| | | | | | | | This fixes audio encoding crashing under ASan. When extended_data != data, FFmpeg copies more pointers from extended_data (= the number of channels) than there really are for non-planar formats (= exactly 1), but that's not our fault. Regardless, this commit makes it work in all common cases.
* ao_oss: add this audio output againrim2021-03-152-0/+414
| | | | | | | | | | | Changes: - code refactored; - mixer options removed; - new mpv sound API used; - add sound devices detect (mpv --audio-device=help will show all available devices); - only OSSv4 supported now; Tested on FreeBSD 12.2 amd64.
* ao/pulse: signal the mainloop when ops are doneThomas Weißschuh2021-03-111-2/+5
| | | | | | | | Without the explicit signal the call to pa_threaded_mainloop_wait() will not return as soon as possible. Fixes 4f07607888541e6eb40fc5c3a1edfeb84aacb0f7 See #8633
* ao/pulse: wait for command completion when setting volume or muteThomas Weißschuh2021-03-091-13/+8
| | | | | | | | | | | | | | | | This makes the behavior of all control messages consistent, fixing an inconsistency that has been with us since 4d8266c739915184d3787d7ab727ac03378b341b - which is the initial rework of the polyaudio AO into the pulseaudio AO. Muting the stream also directly triggers an update to the OSD. When not waiting for the command completion this read of the mute property may read the old state. A stale read. Note that this somehow was not triggered on native Pulseaudio, but it is an issue on Pipewire. See https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/868
* af_scaletempo2: fix crash for speed >= 16Dorian Rudolph2021-02-151-9/+13
| | | | | | | The input buffer size was fixed, but the required size depends on the speed. Now the buffer will be resized dynamically. Fixes #8081
* ao_alsa: handle -EPIPE XRUNs from snd_pcm_statusJan Ekström2020-11-091-2/+11
| | | | | | | | | Set pcm state to SND_PCM_STATE_XRUN in case -EPIPE is received, and handle this state as per the usual logic. This way snd_pcm_prepare gets called, and the loop continued. Inspired by a patch posted by malc_ on #mpv.
* ao_alsa: always initialize state if passedJan Ekström2020-11-091-9/+7
| | | | | Based on ao_play_data's assert, we are always expected to give non-default values back from an AO's get_state.
* audio: take paused state into account in ao_start()sfan52020-09-201-1/+1
| | | | | 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).
* audio: move start() calls outside of locksfan52020-09-201-3/+10
| | | | | Pull based AOs might want to call ao_read_data() inside start(). This fixes ao_opensles deadlocking.
* ao_alsa: make partial writes an error messagewm42020-09-031-2/+2
| | | | And I think "partial write" is easier to understand than "short write".
* audio: fix stream-silence with push AOs (somewhat)wm42020-09-031-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | --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).
* ao_lavc: slightly simplify filter usewm42020-09-031-12/+12
| | | | | | Create a central function which pumps data through the filter. This also might fix bogus use of the filter API on flushing. (The filter is just used for convenience, but I guess the overall result is still simpler.)
* ao_alsa: log more information on short writeswm42020-09-021-2/+4
|
* audio: fix AVFrame allocation (crash with opus encoding)wm42020-09-011-0/+2
| | | | | | | | | | | | AVFrame doesn't have public code for pool allocation, so mpv does it manually. AVFrame allocation is very tricky, so we added a bug. This crashed with libopus encoding, but not some other audio codecs, because the libopus libavcodec wrapper accesses AVFrame.data. Most code tries to avoid accessing AVFrame.data and uses AVFrame.extended_data, because using the former would subtly corrupt memory on more than 8 channels. The fact that this problem manifested only now shows that most AVFrame consuming FFmpeg code indeed uses extended_data for audio.
* ao_openal: restore working condition with new push APILAGonauta2020-08-311-8/+10
|
* ao: remove unused fieldwm42020-08-311-1/+0
|
* audio: fix inefficient behavior with ao_alsa, remove period_size fieldwm42020-08-297-24/+13
| | | | | | | | | | | | | | | | | | | | 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.
* audio_buffer: remove thiswm42020-08-292-199/+0
| | | | | | Unused, was terrible garbage. It was (or at least its implementation was) always a make-shift solution, and just gross bullshit. It is unused now, so delete it.
* audio: refactor how data is passed to AOwm42020-08-294-371/+304
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* audio: clarify set_pause() documentationwm42020-08-271-0/+1
|
* audio: adjust frame clipping for spdif formatswm42020-08-271-2/+4
| | | | | | Allow mp_aframe_clip_timestamps() to discard a spdif frame if it's entirely out of the timestamp range. Just a minor thing that might make handling these dumb formats easier.
* audio: remove unused ring.h includeswm42020-08-272-2/+0
| | | | | From what I can tell, this has been copy-pasted from times when ao_coreaudio still used its own ringbuffer, instead of the common code.
* ao/pulse: create the stream corkedsfan52020-08-261-1/+1
| | | | | | | | | Previously get_state() would keep setting the cork status while paused, but it only does for that after underflows now. Correct this oversight by creating the stream corked for start() to uncork it at a later time. fixes #8026
* ao/lavc: add channels and channel_layout to AVFrameekisu2020-08-071-0/+2
| | | | | | FFmpeg expects those fields to be set on the AVFrame when encoding audio, not doing so will cause the avcodec_send_frame call to return EINVAL (at least in recent builds).
* af_scaletempo2: fix bug where speed was not setDorian Rudolph2020-07-271-1/+0
| | | | | | the --speed parameter did not work with mpv --no-config whatever.mp3 --video=no --speed=2 --af=scaletempo2 (https://github.com/mpv-player/mpv/pull/7865#issuecomment-664243401)
* af_scaletempo2: M_PI is always definedwm42020-07-271-4/+0
| | | | I forgot why/how (C99?), but other code also uses it.
* audio: add scaletempo2 filter based on chromiumDorian Rudolph2020-07-273-0/+1095
| | | | | | | | scaletempo2 is a new audio filter for playing back audio at modified speed and is based on chromium commit 51ed77e3f37a9a9b80d6d0a8259e84a8ca635259. It sounds subjectively better than the existing implementions scaletempo and rubberband.
* ao/pulse: fix reporting of playing statesfan52020-07-121-2/+7
| | | | | | | When get_state() corks the stream after an underrun happens priv->playing is incorrectly reset to true, which can cause the player to miss the underrun entirely. Stop resetting priv->playing during corking (but not uncorking) to fix this.
* ao/pulse: flush stream on underrunsfan52020-07-121-1/+1
| | | | | | | | | | The underflow callback introduced in d27ad96 can be called when the buffer is still full, causing playback to never resume afterwards since get_state() reports free_samples == 0. Fix this by fully resetting on underrun, which flushes the stream and ensures free buffer space. fixes #7874
* audio: don't lock ao_control for pull mode driversKevin Mitchell2020-06-171-2/+7
| | | | | | | | | | | | | 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.
* audio: require certain AOs to set device_bufferwm42020-06-092-3/+3
| | | | | | | | | | AOs which use the "push" API must set this field now. Actually, this was sort of always required, but happened to work anyway. The future intention is to use device_buffer as the pre-buffer amount, which has to be available right before audio playback is started. "Pull" AOs really need this too conceptually, just that the API is underspecified. From what I can see, only ao_null did not do this yet.
* ao/pulse: properly set device_bufferNicolas F2020-06-071-0/+8
| | | | | | | | | Previously, device_buffer defaulted to 0 on pulse. This meant that commit baa7b5c would always wait with a timeout of 0, leading to high CPU usage for PulseAudio users. By setting device_buffer to the number of samples per channel that PulseAudio sets as its target, this commit fixes this behaviour.
* audio: fix deadlock on drainingwm42020-06-041-1/+1
| | | | | | | | | | | 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.
* audio: adjust wait durationwm42020-06-031-6/+4
| | | | | | | | | | | | | | | 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.
* audio: avoid possible deadlock regression for some AOswm42020-06-021-2/+17
| | | | | | | | | | | | | | | 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.
* audio: further simplify internal audio API somewhatwm42020-06-025-47/+41
| | | | | | | | | | | | 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.
* audio: slightly better condition for still_playingwm42020-06-021-1/+1
| | | | | | 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.
* af_scaletempo: handle obscure integer overflowwm42020-06-021-4/+4
| | | | | Saw it once, not really reproducible. This should fix it, and in any case it's harmless.
* audio: reduce extra wakeups caused by recent changeswm42020-06-011-5/+4
| | | | | | | | | | | | | | | | 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.
* audio: redo internal AO APIwm42020-06-0118-821/+633
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* audio: fix unpausing with some AOswm42020-05-311-1/+1
| | | | | | | | | 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
* ao_null: remove unreferenced functionwm42020-05-271-8/+0
| | | | Forgot in the previous commit to this file.
* audio: stop applying volume twice for some AOswm42020-05-271-1/+0