summaryrefslogtreecommitdiffstats
path: root/audio
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | Not all callers of read_buffer() require the buffer to be padded with silence.
* ao_audiotrack: switch to ao_read_data_nonblocking()Thomas Weißschuh2023-11-081-1/+1
|
* ao_coreaudio: switch to ao_read_data_nonblocking()Thomas Weißschuh2023-11-081-1/+1
|
* ao_pipewire: switch to ao_read_data_nonblocking()Thomas Weißschuh2023-11-081-1/+1
| | | | Avoid blocking the process callback as it runs with realtime privileges.
* audio: introduce ao_read_data_nonblocking()Thomas Weißschuh2023-11-082-10/+38
| | | | | This behaves similar to ao_read_data() but does not block and may return partial data.
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-057-92/+87
|
* various: remove trailing whitespaceGuido Cella2023-10-301-1/+1
|
* ao_coreaudio: signal buffer underrunsUmar Getagazov2023-10-291-1/+8
| | | | | Change the resulting buffer sizes to match the actual amount of samples read, and set a flag in case no samples were read at all.
* mp_threads: rename threads for consistent naming across all of themKacper Michajłow2023-10-272-2/+2
| | | | | | | | I'd like some names to be more descriptive, but to work with 15 chars limit we have to make some sacrifice. Also because of the limit, remove the `mpv/` prefix and prioritize actuall thread name.
* semaphore_osx: change mp_sem_timedwait to mp_timeKacper Michajłow2023-10-261-2/+2
|
* semaphore_osx: don't overwrite global symbolsKacper Michajłow2023-10-261-5/+5
|
* Revert "audio: don't block on lock in ao_read_data"sfan52023-10-241-2/+1
| | | | | | | | | | It was found that this causes issues with at least ao_coreaudio, essentially revealing a way bigger issue: Some AOs don't check for 0 and/or have no way to deal with short writes. Someone will have to figure out a fix later but get rid of the direct cause for now. This reverts commit ae908a70cecebb2cac8354a3b4d8967af847bd3e.
* audio: don't block on lock in ao_read_dataThomas Weißschuh2023-10-201-1/+2
| | | | | | | ao_read_data() is used by pull AOs potentially from threads managed by external libraries. These threads can be sensitive to blocking. For example the pipewire ao is using a realtime thread for the callbacks.
* various: sort some standard headersNRK2023-10-204-5/+7
| | | | | | | | | | | | since i was going to fix the include order of stdatomic, might as well sort the surrouding includes in accordance with the project's coding style. some headers can sometime require specific include order. standard library headers usually don't. but mpv might "hack into" the standard headers (e.g pthreads) so that complicates things a bit more. hopefully nothing breaks. if it does, the style guide is to blame.
* osdep: remove atomic.hNRK2023-10-206-5/+9
| | | | | | | replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with explicit _Atomic qualified types. also add missing config.h includes on some files.
* ao: convert all timing code to nanosecondsDudemanguy2023-10-1613-60/+61
| | | | | | | Pull AOs work off of a callback that relies on mpv's internal timer. So like with the related video changes, convert all of these to nanoseconds instead. In many cases, the underlying audio API does actually provide nanosecond resolution as well.
* timer: add convenience time unit conversion macrosDudemanguy2023-10-161-3/+3
| | | | | | | There's a lot of wild 1e6, 1000, etc. lying around in the code. A macro is much easier to read and understand at a glance. Add some helpers for this. We don't need to convert everything now but there's some simple things that can be done so they are included in this commit.
* af_scaletempo2: better defaultsChristoph Heinrich2023-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Why a bigger search-interval is required: scaletempo2 doesn't do a good job when the signal contains frequencies less then 1/search_interval. With a search interval of 30ms that means anything below 33.333Hz sounds bad. Depending on the genre it's very for music to contain frequencies down to 30Hz, and sometimes even a little bit below that. Therefore a higher default value is needed to handle such cases. Based on that an argument can be made for a value of 50, as that should work down to 20Hz, or something even higher because movies sometimes have some infrasonic content. However the downside of big search intervals is increased CPU usage and intelligibility at higher speeds, as it effectively leads to parts of the audio being skipped. A value of 40 can handle frequencies down to 25Hz, enough for all music except very rare edge cases, while still providing decent intelligibility. Why a smaller window-size is required: Large values reduce intelligibility at high speeds and therefore small values are preferred. However when values get too small it starts to sound weird (similar to librubberband). In my testing a value of 10 already works well, but adding a small safety margin seems like a good idea, especially since it made no noticeable difference to intelligibility, which is why 12 was chosen.
* timer: change mp_sleep_us to mp_sleep_nsDudemanguy2023-10-101-3/+3
| | | | | | | | | | | Linux and macOS already use nanosecond resolution for their sleep functions. It was just being converted from microseconds before. Since we have mp_time_ns now, go ahead and bump the precision here. The timer for windows uses some timeBeginPeriod thing which I'm not sure what it does really but whatever just convert the units to ms like they were doing before. There's really no reason to keep the mp_sleep_us helper around. A multiplication by 1000 is trivial and underlying OS clocks have nanosecond precision.
* af_scaletempo: overlap is a factor not a percentageChristoph Heinrich2023-10-071-4/+4
|
* timer: teach it about nanosecondsKacper Michajłow2023-09-291-1/+1
| | | | | Those changes will alow to change vsync base to more precise time base. In general there is no reason to truncate values returned by system.
* ao_audiotrack: convert to nanosecondsKacper Michajłow2023-09-291-14/+14
|
* audio/chmap: support up to 64 channelsKacper Michajłow2023-09-291-1/+1
| | | | This fixes AAC 22.2 playback
* wasapi: clamp number of output channels to 8Kacper Michajłow2023-09-291-1/+13
| | | | | | This is the most supported in standard layout, if we request more it tends to fallback to stereo instead. Also channels mask is 32-bit and it can get truncated.
* chmap: add more channel layouts up to 22.2Kacper Michajłow2023-09-294-1/+30
|
* audio/chmap: link string buffer size to MP_NUM_CHANNELSKacper Michajłow2023-09-292-3/+6
|
* af_scaletempo2: raise max playback rate to 8.0llyyr2023-09-271-1/+1
| | | | | | 4.0 was too low and copied from Chromium defaults when the filter was initially written, there's no good reason for it to be so low, so double it.
* options: remove a few options marked with .deprecation_messageDudemanguy2023-09-211-3/+0
| | | | | | | | | | | A bit different from the OPT_REPLACED/OPT_REMOVED ones in that the options still possibly do something but they have a deprecation message. Most of these are old and have no real usage. The only potentially controversial ones are the removal of --oaffset and --ovoffset which were deprecated years ago and seemingly have no real replacement. There's a cryptic message about --audio-delay but who knows. The less encoding mode code we have, the better so just chuck it.
* af_scaletempo2: fix missing variable init, remove redundant initferreum2023-09-201-1/+1
|
* af_scaletempo2: truncate final packet to expected lengthferreum2023-09-201-0/+14
| | | | | | | | | | Avoid generating too much audio after EOF. Note: This often has no effect, because less audio is produced than required. Usually this comes to effect with the userspeed filter at high speed (4x) and going back to 1x speed to remove the filter.
* af_scaletempo2: fix processing of final packetferreum2023-09-203-16/+64
| | | | | | | | | | | | After the final input packet, the filter padded with silence to allow one more iteration. That was not enough to process the final frames. Continue padding the end of `input_buffer` with silence until the final frames have been processed. Implementation: Instead of padding when adding final samples, pad before running WSOLA iteration. Count number of added silent frames and remaining input frames for time keeping.
* af_scaletempo2: calculate latency by center of search blockferreum2023-09-202-6/+6
| | | | | | | | | | | | | | | | | | | | | This changes the emitted pts values from the start of the search block to the center of the search block. Change initial `output_time` accordingly. Initial `search_block_index` is irrelevant, because it's overwritten before the first iteration. Using the `output_time` removes the rounding of `search_block_index`, which also fixes the <20 microsecond gaps in timestamps between output packets. Rationale: The variance in audio position was in the range `0..search-interval`. With this change, the range is (- search-interval / 2)..(search-interval / 2)` which ensures lower maximum offset.
* af_scaletempo2: restore exact audio sync on return to 1x speedferreum2023-09-201-1/+9
| | | | | | | | | Target block can be anywhere in the previous search-block, varying by `search-interval` while the filter is active. This resulted in constant audio offset when returning to 1x playback speed. - Move the search block to the target block to sync up exactly. - Drop old frames to minimize input_buffer usage.
* af_scaletempo2: fix speed change latency and pts spikesferreum2023-09-203-42/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The internal time update function involved multiple problems: - Time was updated after WSOLA iteration. The means speed was updated one iteration later than it could be. - The update functions caused spikes of too many or too few samples advanced, leading to audio glitches on speed changes. - The inconsistent updates made it very difficult to produce gapless audio packets. - The `output_time` update function involved complicated feedback: `search_block_index` influenced how many frames from `input_buffer` are retained, which influenced how much `output_time` is changed, which influenced `search_block_index`. With these changes: - Time is updated before WSOLA iterations. Speed changes are effective instantly. - There are no spikes in playback speed during speed changes. - No significant gaps are introduced in output packets. - The time update function becomes (function calls omitted for brevity) output_time += ola_hop_size * playback_rate Functions received a `playback_rate` parameter to check how many samples are needed before iteration. Internal state is only updated when the iteration is actually run, so the speed is allowed to change until enough data is received.
* af_scaletempo2: fix audio artifact on initial WSOLA iterationferreum2023-09-202-7/+20
| | | | | | | | | The first WSOLA iteration overlapped audio with whatever was in the `wsola_output` buffer. This was either silence (if not run before), or old frames (if switching to 1x and back to a different speed). Track the state of the output buffer and memcpy the whole window for the first iteration instead.
* af_scaletempo2: fix audio offset when playing back at 1x speedferreum2023-09-201-9/+13
| | | | | `read_input_buffer` needs to respect the `target_block_index`, otherwise the audio resumes at the wrong position.
* af_scaletempo2: fix inconsistent search block position after initferreum2023-09-201-2/+3
| | | | | | | | | `output_time` is used to set the center of the search block. Init of both `search_block_index` and `output_time` with 0 caused inconsistent search block movement for the first iterations. Initialize with `search_block_center_offset` for consistency with initial `search_block_index`.
* af_scaletempo2: move latency calculation to internal functionferreum2023-09-203-3/+9
|
* af_scaletempo2: fix missing dereference when processing final packetferreum2023-09-201-1/+1
| | | | | Missing dereference was not noticed because assigning 0 to pointer is allowed.
* af_scaletempo2: fix audio-video de-sync caused by speed changesferreum2023-09-201-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #12028 There was an additional issue that audio was always delayed by half the configured search-interval. This was caused by the `out` buffer length not being included in the delay calculation. Notes: - Every WSOLA iteration advances the input buffer by _some amount_, and produces data in the output buffer always of size `ola_hop_size`. - `mp_scaletempo2_fill_buffer` is always called with `ola_hop_size` - Thus, the rendered frames are always cleared immediately after processing, and `num_complete_frames` is 0 in the delay calculation. - The factors contributing to delay are: - the pending samples in the input buffer according to the search block position, and - the pending rendered samples in the output buffer (always empty in practice). The frame_delay code looked like that of the rubberband filter, which might not work for scaletempo2. Sometimes a different amount of input audio was consumed by scaletempo2 than expected. It may have been caused by speed changes being a more dynamic process in scaletempo2. This can be seen by where `playback_rate` is used in `run_one_wsola_iteration`: `playback_rate` is only referenced after the iteration, when updating the time and removing old data from buffers. In scaletempo2, the playback speed is applied by changing the amount the search block is moved. That apparently averages out correctly at constant playback speed, but when the speed changes, the error in this assumption probably spikes. This error accumulated across all speed changes because of the persistent `frame_delay` value. With the removal of the persistent `frame_delay`, there should be no way for the audio to drift off. By deriving the delay from filter buffer positions, and the buffers are filled only as much as needed, the delay always stays within buffer bounds.
* Revert "ao/pulse: implement period_size"sfan52023-08-201-1/+0
| | | | | | | This is why you don't merge three year old contributions without checking that they're even applicable anymore. This reverts commit 5a94c86029a2d0e5452c07a7c12d2a6981f607df.
* ao/pulse: implement period_sizeNicolas F2023-08-201-0/+1
| | | | | | | | The idea behind period_size is that it's the minimum amount of data that your audio subsystem wants to fetch. For PulseAudio, this is given by the minreq buffer attribute, which is in bytes for all channels. Hence the divisions.
* ao/jack: set device_buffer to JACK buffer sizeNicolas F2023-08-201-0/+2
| | | | | | | | | | | | | This change sets the device_buffer member of the ao struct for the JACK ao to whatever value we read during init. While JACK allows changing the audio buffer size on-the-fly (you can do this for example through DBus), having it somehow reconfigure the entire audio buffer logic of mpv that depends on device_buffer in some way when that happens only leads to audio dropout and weird code. device_buffer's role is mostly for prebuffer from what I understand, which means that simply setting it to its current value in the init function is fine.
* ao_oss: add "spdif" passthrough support for high bitrate codecs (e.g. Dolby ↵rim2023-08-201-5/+5
| | | | | | | | | | | | | | | | Atmos, DTS-HD, etc.) over HDMI In addition to the patch, appropriate additions to the mpv.conf file will of course be needed for this to work. For example on my system: audio-device=oss//dev/dsp4 audio-spdif=ac3,dts,dts-hd,eac3,truehd This has been tested using recent FreeBSD-13.1-stable, using external surround processors (both a Trinnov Altitude 16 and an LG OLED that supports Dolby Atmos, and connected with HDMI to an NVidia RTX 2070). Author and tester: David G Lawrence <dg1007@dglawrence.com>
* audio: drain ao before setting pauseDudemanguy2023-08-112-2/+7
| | | | | | | | | There's an edge cause with gapless audio and pausing. Since, gapless audio works by sending an EOF immediately, it's possible to pause on the next file before audio actually finishes playing and thus the sound gets cut off. The fix is to simply just always do an ao_drain if the ao is about to set a pause on EOF and we still have audio playing. Fixes #8898.
* ao_audiotrack: enable pcm-float by defaultsfan52023-08-081-0/+3
| | | | Since recent commits this should work 100% as well as s16.
* ao_audiotrack: support more channel layoutssfan52023-08-081-25/+39
|
* ao_audiotrack: support media rolesfan52023-08-081-1/+5
| | | | maybe this is good for something, who knows
* ao_audiotrack: don't ignore ao_read_data return valuesfan52023-08-081-2/+1
| | | | | | | | The difference this makes is that the OS API will notice when we underrun (as opposed to being fed silence). Other AOs mostly seem to not do this because they've committed to filling a buffer of a certain size no matter what, but I have not observed any ill effects for AudioTrack in my testing.
* ao_audiotrack: allow byte buffer data transfer for float samplessfan52023-08-081-12/+15
|
* ao_audiotrack: align buffer size to sample sizesfan52023-08-081-2/+8
| | | | | | This looks like a pretty bad bug but only became a problem with the last commit that allows rates like 22.5kHz to pass through directly instead of being resampled.
* ao_audiotrack: do not needlessly resamplesfan52023-08-081-1/+1
| | | | | Resampling when the driver says it isn't outputting more than a certain rate anyway makes sense, the inverse does not.
* ao_audiotrack: fix broken exception checkssfan52023-08-081-3/+3
| | |