summaryrefslogtreecommitdiffstats
path: root/audio
Commit message (Collapse)AuthorAgeFilesLines
* ao/avfoundation: optimise preprocessors for included coreaudio codeRobert Kopaczewski5 days5-23/+8
|
* ao/audiounit: fix building for iOSRobert Kopaczewski5 days3-3/+3
|
* ao_coreaudio: add a comment for ignoring returned sample countMisaki Kasumi5 days1-0/+1
| | | | Co-authored-by: sfan5 <sfan5@live.de>
* Revert "ao_coreaudio: signal buffer underruns"Misaki Kasumi5 days1-8/+1
| | | | | This reverts commit 0341a6f1d39801160322d3fe16245f8387735f4b. Fixes #13348.
* ao_wasapi: set 0 buffer duration on initialization for shared modesunpenghao6 days1-7/+8
| | | | | | | | Microsoft requires that both `hnsBufferDuration` and `hnsPeriodicity` should be 0 when initializing a shared mode stream using event-driven buffering. Do as they say. Ref: https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-initialize
* ao_wasapi: add `--wasapi-exclusive-buffer` optionsunpenghao6 days3-9/+27
| | | | | | | | | | | This allows users to set buffer duration in exclusive mode. We have been using the default device period as the buffer size and it is robust enough in most cases. However, on some devices there are horrible glitches after a stream reset. Unfortunately, the issue is not consistently reproducible, but using a smaller buffer size (e.g., the minimum device period) seems to resolve the problem. Fixes #13715.
* Revert "ao_coreaudio: switch to ao_read_data_nonblocking()"m154k17 days1-1/+1
| | | | This reverts commit 36d5b5261282dd964f80cd2bb04bb53a7c6d895b.
* player/command: add video-codec-info and audio-codec-infoKacper Michajłow9 days1-0/+7
| | | | | | | | | | | Adds support for extracting codec profile. Old properties are redirected to new one and removed from docs. Likely will stay like that forever as there is no reason to remove them. As a effect of unification of properties between audio and video, video-codec will now print codec (format) descriptive name, not decoder long name as it were before. In practice this change fixes what docs says. If you really need decoder name, use the `track-list/N/decoder-desc`.
* af_scaletempo2: prioritize louder channels for similarity measureferreum12 days1-4/+4
| | | | | | | | | | | | | | | | Playback with many audio channels could be distorted when using scaletempo2. This was most noticeable when there were a lot of quiet channels and few louder channels. Fix this by increasing the weight of louder channels in relation to quieter channels. Each channel's target block energy is factored into the usual similarity measure. This should have little effect on very correlated channels (such as most stereo media), where the factors are very similar for all channels. See-Also: #8705 See-Also: #13737
* various: make filter internal function names more descriptivenanahi2024-04-108-54/+54
| | | | | | | | | Lots of filters have generic internal function names like "process". On a stack trace, all of the different filters use this name, which causes confusion of the actual filter being processed. This renames these internal function names to carry the filter names. This matches what had already been done for some filters.
* ao: rename playthread to ao_threadnanahi2024-04-105-17/+17
| | | | | | | "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.
* ao_pipewire: fix delay calculationMisaki Kasumi2024-04-051-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A figure from pipewire documentation: ``` stream time domain graph time domain /-----------------------\/-----------------------------\ queue +-+ +-+ +-----------+ +--------+ ----> | | | |->| converter | -> graph -> | kernel | -> speaker <---- +-+ +-+ +-----------+ +--------+ dequeue buffers \-------------------/\--------/ graph internal latency latency \--------/\-------------/\-----------------------------/ queued buffered delay ``` We calculate `end_time` in the following steps: 1. get current timestamp in mpv ``` int64_t end_time = mp_time_ns(); ``` 2. add duration of samples to enqueue ``` end_time += MP_TIME_S_TO_NS(nframes) / ao->samplerate; ``` 3. add delay of the pipewire graph ``` end_time += MP_TIME_S_TO_NS(time.delay) * time.rate.num / time.rate.denom; ``` 4. add duration of queued and buffered samples. ``` end_time += MP_TIME_S_TO_NS(time.queued) / ao->samplerate; end_time += MP_TIME_S_TO_NS(time.buffered) / ao->samplerate; ``` New in this commit. `time.queued` is usually zero as `SPA_PARAM_BUFFERS_buffers` is default to 1; however it is not always. `time.buffered` is non-zero if there is a resampler involved. 5. add elapsed duration from when `time` is captured ``` end_time -= pw_stream_get_nsec(p->stream) - time.now; ``` New in this commit. `time` is captured at `time.now`. From then, time has passed so we need to exclude the elapsed time, by calculating the diff of `pw_stream_get_nsec()` and `time.now`.
* audio/ad_spdif: utilize defined freeing function for AVIOContextJan Ekström2024-04-041-1/+1
| | | | | This has been around since FFmpeg/FFmpeg@b12e4d3bb8df994f042ff1216fb8de2b967aab9e from 2017. Thanks to @mkver for noticing this.
* audio/ad_spdif: specify media type and sample rate in output codecparJan Ekström2024-04-041-1/+4
| | | | | | | | | | No idea how things previously worked without having these set, but apparently they did... If this was a normal encoder to muxer case, we would utilize `avcodec_parameters_to_context`, but alas this is not. Fixes: #13794
* ao_coreaudio: register hotplug_cb in normal init() as wellMisaki Kasumi2024-04-031-4/+36
| | | | | | | `hotplug_cb` was registered only in `hotplug_init()`. This commit make it registered in `init()` as well, so that the ao can listen for latency change in playback.
* ao_pipewire: support set_pauseMisaki Kasumi2024-04-031-1/+10
|
* ao_wasapi: support set_pauseMisaki Kasumi2024-04-032-10/+38
|
* ao_avfoundation: support set_pauseMisaki Kasumi2024-04-031-0/+14
|
* ao: set_pause for pull based aoMisaki Kasumi2024-04-032-10/+29
|
* ao_pipewire: fix buffer size calculationMisaki Kasumi2024-03-311-1/+1
| | | | | `ao->sstride` is alrady initialized to the same value in `init()` but in addition it can also handle planar formats.
* ao_pipewire: fix nframes calculationMisaki Kasumi2024-03-311-2/+1
| | | | | | `buf` contains a `struct spa_data` for each channel. Therefore the number of channels does not matter to calculate the frame capacity of one `struct spa_data`. In practice this shouldn't make a difference as `b->requested` would reduce nframes even more.
* ao_alsa: fix snd_config memory leaknanahi2024-03-301-1/+2
| | | | | | | | During AO init, snd_pcm_open() is called, which calls snd_config_update() to allocate a global config node and stores it in the snd_config global variable. This is never freed on uninit. Fix this by freeing the global config node on uninit.
* ao_coreaudio: handle latency change on hotplugMisaki Kasumi2024-03-291-2/+13
| | | | | | | The device latency may change during hotplugging. This commit updates p->hw_latency_ns each time hotplug_cb is called so that it can reflect updated device latency.
* ao_avfoundation: initial avfoundation ao supportMisaki Kasumi2024-03-297-25/+576
|
* af_scaletempo2: fix false reporting of frame availabilitynanahi2024-03-281-1/+2
| | | | | | | | | | | | | | | With certain speed settings, the following can happen at the start of the playback: - can_perform_wsola returns false, so no frames are written - mp_scaletempo2_frames_available returns true when p->input_buffer_final_frames is 0 and target_block_index < 0 This results in infinite loop and completely stalls audio filter processing and playback. Fix this by only checking this condition after the final frame is set. Fixes: 8080d00d7f31a0e1ba25418e0f08474f1a2f1f61
* ao_pulse: reenable latency hacks by defaultsfan52024-03-241-0/+1
| | | | | | | | | | | | | | As far as I can tell PulseAudio introduced a bug in 16.0 where if a stream is (un)paused too often the reported latency will momentarily spike by 3000% or more. Apparently in certain cases just pausing once and waiting can also cause this. Save the remaining users of PA the trouble of debugging the various obscure issues that can arise from this (desync is a harmless example) by enabling the latency hack code again. ref: <https://github.com/mpv-player/mpv/issues/12057> <https://github.com/mpv-player/mpv/issues/10333>
* af_lavcac3enc: fix memory leak on 2ch audiomistraid1212024-03-191-3/+3
| | | | If processing is not required, the frame would be leaked as it is not used.
* various: use thread safe mp_strerror()nanahi2024-03-192-4/+6
|
* ao_lavc: fix warning: ISO C forbids forward references to 'enum' typesnanahi2024-03-191-0/+1
|
* various: fix -Wold-style-declaration warningnanahi2024-03-192-10/+10
| | | | warning: `static' is not at beginning of declaration
* various: use static assertions where appropriatesfan52024-03-171-1/+1
|
* ao_coreaudio: stop audio unit after idle timeoutVilius2024-03-161-2/+79
| | | | | | | | | | | | | | | | | | | | | | | | | Commit 39f7f83 changed ao_driver.reset to use AudioUnitReset instead of AudioOutputUnitStop. The problem with calling AudioOutputUnitStop was that AudioOutputUnitStart takes a significant amount of time after a stop when a wireless audio device is being used. This resulted in lagging that was noticeable to users during seeking and short pause/resume cycles. Switching to AudioUnitReset eliminated this lagging. However with the switch to AudioUnitReset the macOS daemon coreaudiod continued to consume CPU time and did not release a powerd assertion that it created on behalf of mpv, preventing macOS from sleeping. This commit will change ao_coreaudio.reset to call AudioOutputUnitStop after a delay if playback has not resumed. This preserves the faster restart of playback for seeking and short pause/resume cycles and avoids preventing sleep and needless CPU consumption. Fixes #11617 The code changes were authored by @orion1vi and @lhc70000. Co-authored-by: Collider LI <lhc199652@gmail.com>
* ad_spdif: update deprecated FF_PROFILE_DTS_HD_HRA definitionAlex Mitzsch2024-03-101-1/+1
| | | One deprecated FF_PROFILE_DTS_HD_HRA definition was left unaltered - fix that.
* ad_spdif: handle const buf pointee in avio_alloc_contextDudemanguy2024-03-071-0/+4
| | | | | | | ffmpeg recently changed this field to be const which causes our CI to fail on newer versions. See: https://github.com/FFmpeg/FFmpeg/commit/2a68d945cd74265bb71c3d38b7a2e7f7d7e87be5
* ad_spdif: handle deprecated FF_PROFILE_* definitionsDudemanguy2024-03-051-7/+13
| | | | See: https://github.com/FFmpeg/FFmpeg/commit/8238bc0b5e3dba271217b1223a901b3f9713dc6e
* misc/jni: reduce duplication in mapping structsfan52024-02-281-66/+66
| | | | | 'name' was in fact unused when reading fields or methods, so it can be merged with 'method'. Also changed the type of 'mandatory' to bool.
* misc/jni: introduce macros for deleting referencessfan52024-02-281-43/+24
|
* ao_audiotrack: refactor JNI class retrievalsfan52024-02-281-68/+77
| | | | | | - split mapping from field struct - mark field struct static - define list of classes to reduce more repetitive code
* ao_audiotrack: remove two dead variablessfan52024-02-281-9/+0
|
* ao_audiotrack: fix missing check for passthrough supportsfan52024-02-281-0/+4
|
* osdep/mac: make mac naming of files, folders and function consistentder richter2024-02-281-1/+1
| | | | | rename all macOS namings (osx, macosx, macOS, macos, apple) to mac, to make naming consistent.
* ao: don't clip floating point formats at non-unity gainnanahi2024-02-251-1/+1
| | | | | | | | | | | | | | | | | Currently, the softvol gain control attempts to clip floating point ao formats within -1 and +1. However, this is "optimized out" at unity gain, where no clipping is applied. This results in inconsistent behavior when the source audio is already out of -1 and +1 range, where a gain of 0.99 results in clipping, but not at exactly 1. Since a big advantage of floating point audio data is that they do not lose information through out-of-range data because the ao sink can apply suitable negative gain to prevent clipping before converting them to integer formats, clipping should not be performed on these data. Fix this by removing the existing clipping behavior. It now results in a simple multiplication, which faciliates compiler auto-vectorization of this operation over audio data.
* ao_wasapi: scale queried AO volume to (0, 100)sunpenghao2024-02-241-2/+2
| | | | This was done for `AOCONTROL_SET_VOLUME` but not `AOCONTROL_GET_VOLUME`.
* ao_wasapi: address premature buffer fills in exclusive modesunpenghao2024-02-242-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, running AO control wakes up the WASAPI renderer thread in the `WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However, it seems that in recent Windows versions (tested on Windows 10 build 19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe to feed more audio data in event-driven exclusive mode: - `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`, even if *NO* data has ever been written. This means we don't know how much free space we have that is available for writing. This is not the case in shared mode, where the return value correctly reflects the size of data waiting to be processed. As a sidenote, MS did not document the precise definition of the return value for an event-driven, exclusive stream [1]. - `IAudioRenderClient_GetBuffer` never fails. We can call it for 10 times in a roll, each time requesting an entire buffer (the unit at which data is exchanged in exclusive mode using event-driven buffering; there are 2 such buffers) and get a successful return code everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we request a buffer larger than that currently available. As a result, `thread_feed` will always write `bufferFrameCount` frames of audio in exclusive mode. There will therefore be glitches each time `thread_control` is called due to the subsequent `thread_feed` overwriting frames yet to be processed. Also, an irreversible error is accumulated to `sample_count` as long as there is no AO reset, leading to eventual, unbounded A/V desync. As a fix to the issue, add a dedicated state for dispatch queue processing so that `thread_feed` is only called when signaled by the OS. The buffer checks in `thread_feed` that use `GetCurrentPadding` in exclusive mode are kept in case there are older versions where the two APIs behave differently. Closes #12615. [1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
* various: make mentions of macOS consistentder richter2024-02-211-2/+2
| | | | | change all mentions and variations of OSX, OS X, MacOSX, MacOS X, etc consistent. use the official naming macOS.
* af_lavcac3enc: don't use deprecated `avcodec_close`llyyr2024-02-191-1/+9
| | | | | | | | Deprecated upstream https://github.com/FFmpeg/FFmpeg/commit/1cc24d749569a42510399a29b034f7a77bdec34e We need to reallocate the context here because `avcodec_free_context` also frees the context, and we want to reuse the context with some reconfig.
* ao_pipewire: add support for SPDIF formatsThomas Weißschuh2024-02-151-15/+46
|
* ao_pipewire: don't interpret unknown formatsThomas Weißschuh2024-02-151-7/+5
| | | | | | Interpreting data in the wrong sample format has unpredictable results and may damage hardware and hurt users. Instead error out.
* ao_sndio: add missing config.h includeKacper Michajłow2024-02-071-0/+2
|
* audio: rename ao_read_data_unlockedThomas Weißschuh2024-02-051-4/+4
| | | | | | | | | 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
* ad_spdif: fix DTS 44.1khz passthrough playbackAlex Mitzsch2024-01-241-1/+1
| | | | Fix DTS passthrough playback of 44.1 khz content. Also, take into account that there are some DTS variants with a samplerate of 96khz (e.g. DTS 24/96), somehow they are recognized wrongly as 48khz by the code. Don´t rely on this "bug", do it correctly. Now every samplerate above 44.1Khz is correctly treated as 48khz, and 44.1khz files are treated as 44.1khz for bitstreaming.
* chmap: mp_image_pool: drop stale mentions of Libav in commentsllyyr2024-01-201-4/+4
|
* ao_null: fix reset() implementationsfan52024-01-121-1/+2
| | | | | | | | Stopping output implies that it can't be paused anymore. This is consistent with the documented API in internal.h as well as the behavior of other AOs. resolves #13267
* various: use correct PATH_MAX for win32sfan52023-12-271-2/+3
| | | | | | | | In commit c09245cdf2491211f3e0bfe47f28cc0e0a2e05c8 long-path support was enabled for mpv without actually making sure that there was no code left that used the old limit (260 Unicode chars) for buffer sizes. This commit fixes all but one case.
* ao_wasapi: clean GUID definitionsKacper Michajłow2023-12-031-28/+41
| | | | | Add ifndefs to define only when needed and remove some already defined ones in mingw.
* ao_wasapi: fix MP3 GUIDKacper Michajłow2023-12-031-1/+1
| | | | | | | While CEA-861 defines MP2 as 0x5 and MP3 as 0x4, the GUIDs defined in ksmedia.h are in reverse order. See: https://github.com/MicrosoftDocs/windows-driver-docs/pull/3742
* ao_sndio: remove duplicated conditionKacper Michajłow2023-11-281-1/+1
|
* meson: adjust win32 definesKacper Michajłow2023-11-251-0/+1
| | | | | | | | - Don't define _GNU_SOURCE on Windows, no need - Define WIN32_LEAN_AND_MEAN to strip some unneded headers from windows.h - Define NOMINMAX and _USE_MATH_DEFINES as they are common for Windows headers
* ao_coreaudio_chmap: suppress vla warningKacper Michajłow2023-11-241-2/+2
|
* various: replace some OOM handlingsfan52023-11-241-4/+2
| | | | | | We prefer to fail fast rather than degrade in unpredictable ways. The example in sub/ is particularly egregious because the code just skips the work it's meant to do when an allocation fails.
* ao/coreaudio_exclusive: fix segfault when changing formatsleetoburrito2023-11-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PR #12747 missed updating a variable declaration in `ca_change_physical_format_sync`, which ultimately leads to the thread crashing. The problem reproduces consistently on AS Macs (I don't have an Intel Mac to test on anymore), and produces stack traces like the following: ``` Thread 3 Crashed:: mpv 0 libsystem_kernel.dylib 0x18cebd11c __pthread_kill + 8 1 libsystem_pthread.dylib 0x18cef4cc0 pthread_kill + 288 2 libsystem_c.dylib 0x18ce04ad4 __abort + 136 3 libsystem_c.dylib 0x18cdf56c4 __stack_chk_fail + 96 4 mpv 0x1026b66d0 ca_change_physical_format_sync + 420 5 mpv 0x1026b3b70 init + 1052 6 mpv 0x1025c5afc ao_init + 332 7 mpv 0x1025c5bec ao_init + 572 8 mpv 0x1025c5830 ao_init_best + 1228 9 mpv 0x102622fac fill_audio_out_buffers + 1820 10 mpv 0x1026450d0 run_playloop + 132 11 mpv 0x10263f958 play_current_file + 5116 12 mpv 0x10263e4e8 mp_play_files + 452 13 mpv 0x102641308 mpv_main + 128 14 mpv 0x10269f520 playback_thread + 40 15 libsystem_pthread.dylib 0x18cef5034 _pthread_start + 136 16 libsystem_pthread.dylib 0x18ceefe3c thread_start + 8 ``` Note that non-exclusive output seems to be unaffected. To reproduce this problem (and/or test this fix), pass `--audio-exclusive=yes` to mpv.
* ao_wasapi: add missing comma in strings arrayKacper Michajłow2023-11-181-1/+1
|
* audio: fix UB when casting INFINITY to integerKacper Michajłow2023-11-151-3/+3
| | | | | | Fixes busy wait, because in practice inf would be casted to 0. Fixes: 174df99
* audio: avoid unnecessary silence padding in read_buffer()Thomas Weißschuh2023-11-081-11/+14