| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
If "--af=rubberband" is used, librubberband will be used to speed up or
slow down audio with pitch correction.
This still has some problems: the audio delay is not calculated
correctly, so the audio position jitters around by a few milliseconds.
This will probably ruin video timing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Staring at the code a bit, it turns out that changing speed without
losing state is quite easy. The initialization code is big and
complicated, but most of it is specific only to the configured audio
format, not the speed.
Refactor the code so that changing speed at runtime could work. (It's
not actually used yet - the player code still does a complete reinit.
This will be fixed in the next commit.)
The "if (s->speed_tempo == s->speed_pitch)" looks a bit strange, but
does the same thing as the code did before: speed can be changed only if
exactly one flag is set. If both are set or none, speed can't be
changed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code skipped initialization if no speed/pitch change was to be
applied.
It also didn't force conversion of the audio to a supported format,
which is probably the most important case in context of compatibility.
With this change applied, af_scaletempo will always force format
conversion.
To make the change less disruptive, make the filter detach if
unconvertable formats are used. Some users use spdif and also have
"af=scaletempo" in their config, so better not completely break this.
In the case the filter was added with the "speed=both" suboption, the
filter also detached itself in this case; but it's an obscure case, so I
don't care about that.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously we let the user use the audio device ID, but this is not persistent
and can change when plugging in new devices. That of course made it quite
worthless for storing it as a user setting for GUIs, or for user scripts.
In theory getting the kAudioDevicePropertyDeviceUID can fail but it doesn't
on any of my devices, so I'm leaving the error reporting quite high and see if
someone complains.
|
|
|
|
|
| |
This can be useful to adjust some other audio related properties
at runtime depending on the audio device being used.
|
|
|
|
|
| |
I'm not sure how common this behavior possibly is; well whatever. This
option will allow reproducing such behavior, and help debugging it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MSDN documentation for IsFormatSupported says a return code of
AUDCLNT_E_UNSUPPORTED_FORMAT means the function "succeeded but the
specified format is not supported in exclusive mode." This seems to
imply that the format is supported in shared mode, and that's what the
old code assumed, however try_format would incorrectly return success
with some drivers.
The remarks section of the documentation contradicts that assumption. It
says that in shared mode, if the audio engine does not support the
caller-specified format or any similar format, ppClosestMatch is set to
NULL and the function returns AUDCLNT_E_UNSUPPORTED_FORMAT. This is the
same as in exclusive mode, so treat AUDCLNT_E_UNSUPPORTED_FORMAT the
same regardless of opt_exclusive. In shared mode, the format selection
code will fall back to the mix format, which should always be supported.
|
|
|
|
|
|
|
|
|
| |
Apparently, physically disconnecting the audio device (consider USB
audio) breaks the ALSA device handle forever. It will signal ENODEV.
Fortunately, it's easy for us to handle this, and we can just use
existing mechanisms that will make the playback core close and reopen
the AO. Whether the immediate reopening will actually succeeds really is
ALSA's problem, though.
|
|
|
|
|
|
|
|
|
|
| |
In general, you need to check errno when using strtol(), but as far as I
know, strtol() won't reset errno on success. This has to be done
manually. The code could have failed sporadically if strtol() succeeded,
and errno was already set to one of the checked values.
(This strtol() still isn't fully error checked, but I don't know if it's
intentional, e.g. for parsing a numeric prefix only.)
|
|
|
|
|
|
|
|
|
| |
Before this commit, ao_null was used as last fallback. This doesn't make
too much sense. Why would you decode audio just to discard it? Let audio
initialization fail instead. This also handles the weird but possible
corner-case that ao_null might fail initializing, in which case e.g.
ao_pcm could be autoselected. (This happened once, and had to be fixed
manually.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the slightly duplicated code for picking the required AO
driver if --audio-device forces one. Now --audio-device reuses the same
code as --ao for this.
As a consequence, ao_alloc_pb() and ao_create() can be merged into
ao_init(). Although the ao_init() argument list, which is already pretty
big, grows by one, it's better than having all these similar sounding
functions around.
Actually, I just wanted to do the change the following commit will do,
but I found this code was more of a mess than it had to be.
|
| |
|
|
|
|
|
| |
All of these filters are very similar in frame management, and copy data
to a new frame during filtering.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds about 7 lines of boilerplate per filter. This could be avoided by
providing a different entrypoint (something like af->filter_inplace),
which would basically mirror the old interface exactly for this kind of
filter. But I feel like it would just be a hack to support all those
old, useless filters better. (The ideal solution would be using a
language that can do closures to provide a compat. wrapper, but
whatever.)
af_bs2b has terribly repetitious code for setting up filter functions
for each format (most of them useless, in addition to bs2b being
useless), so I did something terrible with macros.
af_sinesuppress had commented code for float filtering (maybe it was
broken; it has been commented every since it was added in 2006). Remove
this code.
|
|
|
|
|
|
|
|
|
|
|
| |
Just to make sure all filters get the correct format. Together wih the
check in af_add_output_frame(), this asserts that
af->prev->fmt_out == af->fmt_in
This also requires setting the "in" pseudo-filter (s->first) formats
correctly. Before this commit, the fmt_in/fmt_out fields weren't used
for this filter.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Pretty useful for debugging, although a bit useless or possibly
misleading too (see comments in the manpage).
|
|
|
|
|
|
|
|
|
|
| |
Commit 5e25a3d2 broke handling of the initial frame (the one decoded
with initial_audio_decode()). It didn't update the pts_offset field,
leading to a shift in timestamps by one audio frame.
Fix by calling the actual decode function in a single place. This
requires slightly more changes than what would be necessary to fix the
bug, but it also somewhat simplifies the data flow.
|
|
|
|
|
|
|
| |
There are several cases in which a decoder may need several packets to
produce some output audio. Commit 5e25a3d2 broke this.
Fixes #1471.
|
|
|
|
|
| |
This requires allocating a fully new frame. 32->24 could be in-place,
but this is not possible for 24->32.
|
|
|
|
|
| |
These are also quite simple, but require requesting write access to the
frames. The error handling (for OOM) is a bit annoying.
|
|
|
|
| |
These are read-only, and very trivial to convert.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal is switching the whole audio chain to using refcounted frames.
This brings the architecture closer to FFmpeg, enables better
integration with libavfilter, will reduce useless copying somewhat, and
will probably allow better timestamp tracking.
For now, every filter goes through a semi-awful wrapper in
af_do_filter(), though. This will be fixed step by step, and the wrapper
should eventually be removed. Another thing that will have to be done is
improving the timestamp handling and avoiding extra copies for the AO.
Some of the new code is rather similar to the video filter code (the
core filter code basically just has types replaced). Such code
duplication is normally very unwanted, but in this case there's probably
no other choice. On the other hand, this code is pretty simple (even if
somewhat tricky). Maybe there will be unified filter code in the future,
but this is still far away.
|
|
|
|
| |
Used in the following commits.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of this function was to filter only as much audio input as
needed to produce a certain amount of audio output. This could (in
theory) avoid excessive buffering when e.g. changing playback speed with
resampling.
Use of this was already removed in commit 5fd8a1e0. No problems were
experienced, so let's assume this feature is practically worthless.
(Though it's possible that it was quite useful over a decade ago, or in
some cornercases with evil files.)
|
|
|
|
|
|
| |
This can for example reproduced by killing the pulseaudio server. If
this happens, just try to reload the AO, instead of breaking everything
forever.
|
|
|
|
|
|
|
| |
We must not try to remap channels with this. Whethever ALSA gives us,
and whatever we do with it, the result will probably be nonsense.
Untested, as I don't have the required hardware.
|
|
|
|
| |
Apparently this was a mistake.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This used to be required to workaround PulseAudio bugs. Even later, when
the bugs were (partially?) fixed in PulseAudio, I had the feeling the
hacks gave better behavior. On the other hand, I couldn't actually
reproduce any bad behavior without the hacks lately. On top of this, it
seems our hacks sometimes perform much worse than PulseAudio's native
implementation (see #1430).
So disable the hacks by default, but still leave the code and the option
in case it still helps somewhere. Also, being able to blame PulseAudio's
code by using its native API is much easier than trying to debug our own
(mplayer2-derived) hacks.
|
|
|
|
|
| |
Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into
the build system, instead of defining them over and over in the code.
|
|
|
|
| |
Also, don't use av_log() for mpv output.
|
| |
|
| |
|
|
|
|
| |
fixes #1376
|
|
|
|
|
|
|
|
| |
* bits instead of bytes
* add valid_bits argument
* just pass in the mp_chmap and get the number and wavext channel map from that
* indicate valid bits in waveformat_to_str
* make appropriate accomodations in try_format
|
|
|
|
| |
someone on irc reported seeing this error
|
|
|
|
|
| |
It's just completely useless. We have good native support for all 3
desktop platforms, and ao_sdl or ao_openal as fallbacks.
|
|
|
|
|
|
|
|
|
|
| |
This message is printed when the audio device advertised a channel map,
but couldn't set it - which is probably a dmix bug (we'll never know,
ALSA doesn't take bug reports).
Print the requested map, so that the user (maybe) can make a connection
when seeing the message and the actually used channel map, which might
be less confusing. Or at least less useless.
|
|
|
|
| |
This could be helpful with bug reports.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of just failing during channel map selection, try to select a close
layout that makes most sense and upmix/downmix to that instead of failing AO
initialization. The heuristic is rather simple, and uses the following steps:
1) If mono is required always prefer stereo to a multichannel upmix.
2) Search for an upmix that is an exact superset of the required channel map.
3) Search for a downmix that is the exact subset of the required channel map.
4) Search for either an upmix or downmix that is the closest (minimum difference
of channels) to the required channel map.
|
|
|
|
| |
This is common on Apple systems so it's handy to have a label for it.
|
|
|
|
| |
useless after 069016fd6c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There where 3 major errors in the previous code:
1) The kAudioDevicePropertyPreferredChannelLayout selector returns a single
layout not an array.
2) The check for AudioChannelLayout allocation size was wrong (didn't account
for variable sized struct).
3) Didn't query the kAudioDevicePropertyPreferredChannelsForStereo selector
since I didn't know about it's existence.
All of these are fixed.
Might help with #1367
|
| |
|
| |
|
|
|
| |
Should help remote debugging #1367 with --msg-level=ao=debug
|
|
|
|
|
|
|
|
| |
Makes all of overlay_add work on windows/mingw.
Since we now don't explicitly check for mmap() anymore (it's always
present), this also requires us to make af_export.c compile, but I
haven't tested it.
|
|
|
|
|
|
|
|
| |
AudioChannelLayout uses a trailing variable sized array so we need to
query CoreAudio for the size of the struct it is going to need (or the
conversion of that particular layout would fail).
Fixes #1366
|
|
|
|
| |
The resume code was accidentally fully removed from this code path.
|
|
|
|
|
|
|
|
|
|
|
| |
snd_pcm_prepare() was not always called, which could result in an
infinite loop.
Whether snd_pcm_prepare() was actually called depended on whether the
device was a hw device (or other characteristics; depending on
snd_pcm_hw_params_can_pause()), and required real suspend (annoying for
testing), so it was somewhat tricky to reproduce without knowing these
things.
|
|
|
|
|
|
|
| |
When setting the ALSA channel map, we never actually set the map we got
from ALSA directly, but convert it to mpv's, and then back to ALSA's.
mpv and ALSA use different conventions for mono, and there is already an
exception for ALSA->mpv, but not mpv->ALSA.
|
|
|
|
|
|
|
|
| |
This was only added recently (c1e97161) as an attempt to minimize the
bad impact of channel layout device aliases. But use of these was
removed in commit 49df0132. Now this code does pretty much nothing, and
shouldn't be needed anymore. It does something when using spdif, but
this fallback won't work anyway.
|
|
|
|
|
| |
This would have always forced mono first (if supported by the AO),
instead of stereo.
|
|
|
|
| |
This makes it fallback to stereo properly.
|
|
|
|
|
|
| |
Needed after af3bbb800d since now we use channel mapping all the time.
Fixes #1357
|
| |
|
|
|
|
| |
before we were reinventing this wheel
|