summaryrefslogtreecommitdiffstats
path: root/audio
Commit message (Collapse)AuthorAgeFilesLines
* ao/audiounit: include AVAudioSession buffer in latency calcAman Gupta2019-04-051-1/+1
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* ao/audiounit: improve a/v syncAman Gupta2019-04-053-4/+18
| | | | | | | This more closely mimics ao_coreaudio, on which this driver was originally based. Signed-off-by: Aman Gupta <aman@tmm1.net>
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-053-5/+33
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * player: get rid of mpv_global.optswm42018-05-241-2/+4
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
| * ao: use a local option structwm42018-05-242-3/+29
| | | | | | | | Instead of accessing MPOpts.
* | ad_spdif: cosmetic alignmentJan Ekström2018-10-301-1/+1
| |
* | ad_spdif: fix DTS-HD HRA handlingJan Ekström2018-10-301-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | Apparently, for bit streaming DTS-HD MA is specified to be handled as an eight channel (7.1) bit stream, while DTS-HD HRA is specified to be handled as a stereo bit stream. Define a variable for this, and utilize it to set the correct values for both the DTS-HD bit streaming rate, as well as the channel count for the SPDIF encoder. Fixes #6148
* | ao_audiounit: rename pause function to resetJosh Lehman2018-09-301-1/+1
| | | | | | | | | | AudioUnit output driver uses the pull based api so it should have a reset function instead of a pause function.
* | ao_alsa: log the ALSA state if we get a non-XRUN errorJan Ekström2018-09-291-2/+4
| | | | | | | | | | The ALSA state generally can tell us more information in case we get an unexpected error.
* | ao_alsa: handle XRUNs separately from other errorsJan Ekström2018-09-291-2/+7
| | | | | | | | | | | | | | | | | | According to ALSA doxy, EPIPE is a synonym to SND_PCM_STATE_XRUN, and that is a state that we should attempt to automatically recover from. In case recovery fails, log an error and return zero. A warning message will still be output for each XRUN since those are not something we should generally be receiving.
* | ao_alsa: early exit get_space if paused or ALSA is not readyJan Ekström2018-09-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | This has been way too long coming, and for me to notice that a whole lot of ao_alsa functions do an early return if the AO is paused. For the STATE_SETUP case, I had this reproduced once, and never since. Still, seems like we can start calling this function before the ALSA device has been fully initialized so we might as well early exit in that case.
* | ao_jack: only auto-connect to audio portsNiklas Haas2018-09-261-1/+2
| | | | | | | | | | This prevents ao_jack from auto-connecting to MIDI ports (or other, hypothetical future port types).
* | ao_pulse: fix tlength calculationTom Yan2018-09-013-17/+3
| | | | | | | | also remove the now unused non-sensical af_fmt_seconds_to_bytes.
* | Revert "ao_openal: enable building on OSX"Michael Hoang2018-08-261-14/+0
| | | | | | | | | | | | This reverts commit af6126adbe61fb2b6cc780025246d33df93072e6. Apple's OpenAL support is ridiculously out of date, revert back to just using OpenAL Soft on macOS (fixes #4645).
* | af_rubberband: reset delay to 0 on resetHector Martin2018-08-251-0/+2
| | | | | | | | This fixes A-V drift on seeking
* | ao_opensles: set numBuffers to 8Tom Yan2018-08-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently some Android builds/forks require this for Bluetooth audio to work as they unexpectedly accept fast flag for it. Shouldn't cause any side-effect (e.g. buffer requirement increased when on wired audio). It's a hardcoded default in the upstream AAudio implementation anyway. Ref.: https://android.googlesource.com/platform/frameworks/av/+/android-8.0.0_r1/media/libaaudio/src/legacy/AudioStreamTrack.cpp#109 https://android.googlesource.com/platform/frameworks/wilhelm/+/android-8.0.0_r1/src/android/AudioPlayer_to_android.cpp#1680 https://android.googlesource.com/platform/frameworks/av/+/android-8.0.0_r1/media/libaudioclient/AudioTrack.cpp#488
* | audio/format: decouple af_fmt_is_planar from af_fmt_to_planarTom Yan2018-08-111-16/+15
| | | | | | | | | | so that af_fmt_to_planar (and hence af_fmt_from_planar) can just return the input when it is not an interleaved (planar) format.
* | ao_opensles: rework the heuristic of buffer/enqueue size settingTom Yan2018-08-051-18/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ao->device_buffer will only affect the enqueue size if the latter is not specified. In other word, its intended purpose will solely be setting/guarding the soft buffer size. This guarantees that the soft buffer size will be consistent no matter a specific enqueue size is set or not. (In the past it would drop to the default of the generic audio-buffer option.) opensles-frames-per-buffer has been renamed to opensles-frames-per -enqueue, as it was never purposed to set the soft buffer size. It will only make sure the size is never smaller than itself, just as before. opensles-buffer-size-in-ms is introduced to allow easy tuning of the relative (i.e. in time) soft buffer size (and enqueue size, unless the aforementioned option is set). As "device buffer" never really made sense in this AO, this option OVERRIDES audio-buffer whenever its value (including the default) is larger than 0. Setting opensl-buffer-size-in-ms to 1 allows you to equate the soft buffer size to the absolute enqueue size set with opensl-frames-per -enqueue conveniently (unless it is less than 1ms). When both are set to 0, audio-buffer will be the ultimate fallback. If audio-buffer is also 0, the AO errors out.
* | ao_opensles: allow s32 and float outputTom Yan2018-08-051-27/+15
| | | | | | | | | | OpenSLES (and its AudioTrack backend) in Android can take 32-bit fixed and floating point input since Android L (API 21).
* | audio/format: minor fix for af_fmt_from_planarTom Yan2018-08-051-2/+4
| | | | | | | | See af_fmt_to_planar.
* | ao_alsa: simplify get_space()Jan Ekström2018-06-041-6/+10
| |
* | ao_alsa: replace snd_pcm_status() with snd_pcm_avail() in get_space()Muhammad Faiz2018-06-041-5/+4
|/ | | | | | | | | | Fixes a bug with alsa dmix on Fedora 29. After several minutes, audio suddenly becomes bad and muted. Actually, I don't know what causes this. Probably this is a bug in alsa. In any case, as snd_pcm_status() returns not only 'avail', but also other fields such as tstamp, htstamp, etc, this could be considered a good simplification, as only avail is required for this function.
* build: make encoding mode non-optionalwm42018-05-031-2/+0
| | | | Makes it easier to not break the build by confusing the ifdeffery.
* encode: get rid of the output packet queuewm42018-05-035-3/+33
| | | | | | | | | | | | Until recently, ao_lavc and vo_lavc started encoding whenever the core happened to send them data. Since audio and video are not initialized at the same time, and the muxer was not necessarily opened when the first encoder started to produce data, the resulting packets were put into a queue. As soon as the muxer was opened, the queue was flushed. Change this to make the core wait with sending data until all encoders are initialized. This has the advantage that we don't need to queue up the packets.
* encode: remove old timestamp handlingwm42018-05-031-46/+6
| | | | | This effectively makes --ocopyts the default. The --ocopyts option itself is also removed, because it's redundant.
* encode: rewrite half of itwm42018-04-291-185/+55
| | | | | | | | | | | | | The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
* encode: cosmeticswm42018-04-201-25/+29
| | | | Mostly whitespace changes; some semantic preserving transformations.
* ao_alsa: actually report underruns to userwm42018-04-151-5/+5
| | | | | | | | | Print them as a warning. Note that there may be some cases where it underruns, without being a bad condition. This could possibly happen e.g. if the last chunk is written, and then it resumes playback some time after that. Eventually I want to add more code to avoid such spurious warnings.
* ao_pulse: reduce requested device buffer sizewm42018-04-151-1/+1
| | | | | | Same deal as with the previous commit for ALSA. Untested.
* ao_alsa: reduce requested buffer sizewm42018-04-151-2/+2
| | | | | | There is a dedicated thread for feeding audio to the ALSA API from a buffer with a larger size. There is little reason to have such a large device buffer.
* ao_alsa: add options for controlling period/buffer sizewm42018-04-151-8/+16
|
* ao_openal: document the muted↔gain conversionJan Ekström2018-04-151-0/+3
| | | | This struck me as odd for a moment, so adding a comment.
* ao/openal: Add option to set buffering characteristicsLAGonauta2018-04-151-23/+62
| | | | | | | | | One can now set the number of buffers and the buffer size. This can reduce the CPU usage and the total latency stays mostly the same. As there are sync mechanisms the A/V sync continue intact and working. It also modifies 6.1 channel order, as per OpenAL spec and add AOPLAY_FINAL_CHUNK support
* ao/openal: Add better sample format and channel layout selectionLAGonauta2018-04-151-139/+73
| | | | Also re-added floating-point support.
* ao/openal: Add OpenAL Soft extension to get the correct latencyLAGonauta2018-04-151-1/+16
| | | | | | | | OpenAL Soft's AL_SOFT_source_latency extension allows one to correctly get the device output latency, facilitating the syncronization with video. Also added a simpler generic fallback that does not take into account latency of the device.
* ao/openal: Add support for direct channels outputLAGonauta2018-04-151-0/+10
| | | | | | | Uses OpenAL Soft's AL_DIRECT_CHANNELS_SOFT extension and can be controlled through a new CLI option, --openal-direct-channels. This allows one to send the audio data direrctly to the desired channel without effects applied.
* ao/openal: Add hardware mute supportLAGonauta2018-04-151-0/+12
| | | | | While the volume is set on the listener, mute is set on the sound source. Seemed easier that way.
* ao/openal: Use only one source for audio outputLAGonauta2018-04-151-52/+153
| | | | Floating point audio not supported on this commit.
* ao_opensles: let cfg_frames_per_buffer accept buffer size up to 0.5s at 192kHzTom Yan2018-04-051-1/+1
|
* ao_opensles: remove useless cfg_sample_rateTom Yan2018-04-051-5/+0
| | | | We should always use the ao-neutral --audio-samplerate option.
* ao_opensles: bump device buffer size to 250msTom Yan2018-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although half (non-fast track on sink rate) or one-third (non-fast track not on sink rate) of the buffer size of the created AudioTrack instance as the SL Enqueue buffer size is basically enough for dropout-free playback, only using the full size can avoid stutter upon (re)start of playback. Here are the various buffer sizes on different track/sink rate when on Bluetooth audio on Android O: aptX @ 48kHz: Sink rate: 48000 Hz 44100 Hz: 10632 frames (241.09 ms) 48000 Hz: 11544 frames (240.50 ms) 88200 Hz: 21216 frames (240.54 ms) 96000 Hz: 23088 frames (240.50 ms) 176400 Hz: 42384 frames (240.27 ms) 192000 Hz: 46128 frames (240.25 ms) SBC/AAC/aptX @ 44.1kHz: Sink rate: 44100 Hz 44100 Hz: 10776 frames (244.35 ms) 48000 Hz: 11748 frames (244.75 ms) 88200 Hz: 21552 frames (244.35 ms) 96000 Hz: 23448 frames (244.25 ms) 176400 Hz: 43056 frames (244.08 ms) 192000 Hz: 46848 frames (244.00 ms) The above results were produced with the following code: import android.media.AudioAttributes; import android.media.AudioFormat; import android.media.AudioTrack; class AudioInfo { public static void main(String[] args) { int nosr = AudioTrack.getNativeOutputSampleRate(3); System.out.printf("Sink rate: %d Hz\n", nosr); int[] rates = {44100,48000,88200,96000,176400,192000}; for (int rate: rates) { AudioAttributes aa = new AudioAttributes.Builder().setFlags(256).build(); AudioFormat af = new AudioFormat.Builder().setSampleRate(rate).build(); AudioTrack at = new AudioTrack(aa, af, 4, 1, 0); int sr = at.getSampleRate(); int bs = at.getBufferSizeInFrames(); float ms = bs * (float) 1000 / sr; at.release(); System.out.printf("%d Hz: %d frames (%.2f ms)\n", sr, bs, ms); } } } Therefore bumping the device buffer size to 250ms.
* ao_opensles: do one buffer onlyTom Yan2018-04-051-15/+8
| | | | Doing two buffers causes stutters upon (re)start of playback on Android O for all kinds of sinks.
* ao_opensles: re-flow interface/configuration retrievalJan Ekström2018-03-241-9/+18
| | | | | This manages to make the code more readable. Thanks to MakeGho@IRCnet for the snippet on which this was based.
* ao_opensles: fix audio sync using device latency extensionAman Gupta2018-03-231-3/+20
|
* ao_sdl: fix default buffer sizewm42018-03-081-5/+6
| | | | | | | | If you set desired.samples to 0, SDL will return a default buffer size on obtained.samples. This was broken, because ceil_power_of_two(0) returns 1. Since 0 is usually not considered a power of two, this is probably correct, but we still want to set desired.samples to 0 in this case.
* ao: do not allow actual buffer size of 0wm42018-03-081-0/+1
| | | | | | | | | You can use --audio-buffer=0 to minimize the audio buffer size. But if the AO reports no device buffer size (like e.g. ao_jack does), then the buffer size is actually 0, and playback can never work properly. Make it fallback to a size of 1, which is unlikely to work properly, but you get what you asked for, instead of a freeze.
* ao_opensles: bump device buffer size to 200mstomty892018-03-071-1/+1
| | | While the soft buffer size is already by default 200ms, it is not enough to guarantee dropout-free playback on Bluetooth audio. Bumping the device buffer size to the same value seems to suffice.
* ao_opensles: remove set_play_state()tomty892018-03-071-10/+1
| | | Set play state to playing in init() instead. We no longer touch the play state afterwards.
* ao_opensles: clear buffer queue in reset()tomty892018-03-071-1/+2
| | | Avoid resume() from causing SL_RESULT_BUFFER_INSUFFICIENT ("Failed to Enqueue: 7" when seek or resume from pause).
* audio: don't touch spdif frames in mp_aframe_clip_timestamps()wm42018-02-131-0/+3
| | | | It can't work for this type of format.
* build: drop support for SDL1wm42018-02-131-1/+1
| | | | | For some reason it was supported for ao_sdl because we've only used SDL1 API.
* af_scaletempo: output minimally sized audio framewm42018-02-031-57/+76
| | | | | | | | | | | | | | | | | | | | This helps the filter to adapt much faster to speed changes. Before this commit, the filter just converted and output the full input frame, which could cause problems with large input frames. This was made worse by certain filters like dynaudnorm or loudnorm outputting pretty large frames. This commit changes the filter from trying to convert all input at once to only outputting a single internally filtered frame. Internally, this filter already output data in units of 60ms by default (controlled by the "stride" sub-option), and concatenated as many output frames as necessary to consume all input. Behavior is still kind of bad when inserting the filter. This is because the large frames can be buffered up after the insertion point, so the speed change will be performed with a larger latency. The scaletempo filter can't do anything against this, although it can be fixed by inserting scaletempo as user filter as part of --af.
* codecs: remove unused family fieldwm42018-02-011-1/+1
| | | | | | | | | | MPlayer used this to distinguish multiple decoder wrappers (such as libavcodec vs. binary codec loader vs. builtin decoders). It lost meaning in mpv as non-libavcodec things were dropped. Now it doesn't serve any purpose anymore. Parsing was removed quite a while ago, and the recent filter change removed any use of the internal family field. Get rid of it.
* audio: move to decoder wrapperwm42018-01-305-549/+163
| | | | | | | | | | | | | | | | Use the decoder wrapper that was introduced for video. This removes all code duplication the old audio decoder wrapper had with the video code. (The audio wrapper was copy pasted from the video one over a decade ago, and has been kept in sync ever since by the power of copy&paste. Since the original copy&paste was possibly done by someone who did not answer to the LGPL relicensing, this should also remove all doubts about whether any of this code is left, since we now completely remove any code that could possibly have been based on it.) There is some complication with spdif handling, and a minor behavior change (it will restrict the list of codecs to spdif if spdif is to be used), but there should not be any difference in practice.
* ao_null: add --ao-null-format option for debuggingwm42018-01-301-0/+5
| | | | Helpful especially to test spdif fallback and so on.
* audio: rewrite filtering glue codewm42018-01-3017-3805/+1119
| | | | Use the new filtering code for audio too.
* ao_alsa: reduce verbosity at -vwm42018-01-251-10/+10
| | | | | | | Always make the hw params dump function use MSGL_DEBUG, and remove the MSGL_V use. That means you need -v -v to see them. The detailed information is usually not very interesting, so this reduces the log noise.
* audio: fix annyoing af_get_best_sample_formats() definitionwm42018-01-258-9/+10
| | | | | | | | | | | | | | | | The af_get_best_sample_formats() function had an argument of int[AF_FORMAT_COUNT], which is slightly incorrect, because it's 0 terminated and should in theory have AF_FORMAT_COUNT+1 entries. It won't actually write this many formats (since some formats are fundamentally incompatible), but it still feels annoying and incorrect. So fix it, and require that callers pass an AF_FORMAT_COUNT+1 array. Note that the array size has no meaning in C function arguments (just another issue with C static arrays being weird and stupid), so get rid of it completely. Not changing the af_lavcac3enc use, since that is rewritten in another branch anyway.
* Fix undefined