| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Reportedly fixes operation with "USB connected Parasound ZDAC v.2". (OSX
and USB audio sure is not nice at all.)
This might be perceived as hang by some users, so it's quite possible
that this will have to be adjusted again somehow.
Fixes #2409.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Small adjustments to the playback speed use swr_set_compensation()
to stretch the audio as it is required. But since large adjustments
are now handled by actually reinitializing libswresample, the small
adjustments get rounded off completely with typical frame sizes.
Compensate for this by accounting for the rounding error and keeping
track of fractional samples that should have been output to achieve
the correct ratio.
This fixes display sync mode behavior, which requires these adjustments
to be relatively accurate.
|
|
|
|
|
|
| |
swr/avresample_set_compensation() was made for small speed adjustments.
Non-documentation says it should be used for changes not larger than 1%,
so reinitialize the sampler if the change is larger than that.
|
|
|
|
|
|
|
|
|
|
| |
swr_set_compensation() changes the apparent sample rate on the fly (who
would have guessed). It is thus very well-suited for adjusting audio
speed on the fly during playback (like needed by the display-sync mode).
It skips the relatively slow resampler reinitialization.
If this doesn't work (libswresample soxr backend), then fall back to the
old method.
|
|
|
|
|
|
|
|
| |
The previous commit handled not falling back to normal decoding if the
AO was reloaded (I think...), and this tries to re-engage spdif pass-
through if it was previously falling back to normal decoding (e.g.
because it temporarily switched to an audio device incapable of
passthrough).
|
| |
|
|
|
|
|
| |
Set format to invalid after each failed test. This way the final check
for valid format will actually fail if no formats work.
|
|
|
|
|
|
|
|
|
| |
The manpage entry explains this.
(Maybe this option could be always enabled and removed. I don't quite
remember what valid use-cases there are for just disabling audio
entirely, other than that this is also needed for audio decoder init
failure.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the code a bit more uniform. Always build a "dummy" audio output
list before probing, which means that opening preferred devices and
pure auto-probing is done with the same code. We can drop the second
ao_init() call.
This also makes the next commit easier, which wants to selectively
fallback to ao_null. This could have been implemented by passing a
different requested audio output list (instead of reading it from
MPOptions), but I think it's better if this rather special feature
is handled internally in the AO code. This also makes sure the AO
code can handle its own options (such as the audio output list) in
a self-contained way.
|
|
|
|
|
|
|
| |
This can happen with USB audio. There was already code for this, but
something in mpv and ALSA changed - and now the old code is not
necessarily triggered anymore. It probably depends on the exact
situation.
|
|
|
|
|
|
|
|
| |
This could sometimes cause crashes in hotplug events. (Apparently in
cases when CoreAudio changes its state asynchronously, or such.)
CA_GET_STR() does not set the string if there was an error, so errors
have to be strictly checked before using it.
|
|
|
|
|
|
|
|
|
|
| |
This flag was used by some filters and made sure none of these filters
were inserted twice. This triggers only if the user explicitly tries to
add multiple filters (and not e.g. due to auto-insertion), so at best
this warned the user from doing something potentially pointless. At
worst, it blocked some (mildly) legitimate use-cases. Get rid of it.
Also see #2322.
|
|
|
|
|
|
|
| |
Works like vf-metadata. Unfortunately requires some code duplication
(even though it's not much).
Fixes #2311.
|
|
|
|
|
|
|
| |
The reason MPlayer traditionally duplicated them all over the place is
that it wanted every component to be a self-contained library (e.g.
audio filters were in "libaf"). But this is not necessarily helpful, and
this change makes the following commit a bit simpler.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* (de)planarize -1
* pad 1 byte -8
* truncate 1 byte -1024
* float -> int 1048576 * (8 - dst_bytes)
* int -> float -512
Now the score is negative if and only if the conversion is lossy
(e.g. previously s24 -> float was given a negative (lossy) score),
However, int->float is still considered bad
(s16->float is worse than than s16->s32).
This penalizes any loss of precision more than performance / bandwidth hits.
For example, previously s24->s16p was considered equal to s24->u8.
Finally, we penalize padding more than (de)planarizing as this will
increase the output size for example with ao_lavc.
|
| |
|
|
|
|
|
|
|
| |
This is just a refactor, which makes it use the previously introduced
function, and allows us to make af_format_conversion_score() private.
(We drop 2 unlikely warning messages too... who cares.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This mixed up the returned score for some interleaved/non-interleaved
comparisons. Changing interleaving subtracted 1 point, while extending
sample size by 1 byte also subtracted 1 point.
(This scoring system is not ideal - it'd be much cleaner to do a 3-way
sample format comparison instead, and sort the formats according to the
comparison instead of the score.)
|
|
|
|
|
| |
...for int->float conversions. This code accidentally inverted the
condition.
|
|
|
|
|
|
|
| |
Not sure why struct af_resample_opts even exists. It seems useful to
group the fields set by user options. But storing the current format
conversion parameters doesn't seem very elegant, and having a separate
instance in the "ctx" field isn't helpful either.
|
| |
|
|
|
|
|
|
| |
Apparently, this broke compilation with Libav under some circumstances.
Looking at it again, it shouldn't have, but this change doesn't hurt
anyway.
|
|
|
|
|
|
|
| |
Some users still use this filter, so the filter was going to be kept.
But I overlooked that libavfilter provides this filter. Remove the
redundant wrapper from mpv. Something like --af=lavfi=bs2b should work
and give exactly the same results.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of these filters are considered not useful anymore by us. Some have
replacements in libavfilter (useable through af_lavfi).
af_center, af_extrastereo, af_karaoke, af_sinesuppress, af_sub,
af_surround, af_sweep: pretty simple and useless filters which probably
nobody ever wants.
af_ladspa: has a replacement in libavfilter.
af_hrtf: the algorithm doesn't work properly on most sources, and the
implementation was buggy and complicated. (The filter was inherited from
MPlayer; but even in mpv times we had to apply fixes that fixed major
issues with added noise.) There is a ladspa filter if you still want to
use it.
af_export: I'm not even sure what this is supposed to do. Possibly it
was meant for GUIs rendering audio visualizations, but it couldn't
really work well. For example, the size of the audio depended on the
samplerate (fixed number of samples only), and it couldn't retrieve the
complete audio, only fragments. If this is really needed for GUIs, mpv
should add native visualization, or a proper API for it.
|
|
|
|
|
|
|
| |
So snd_device_name_get_hint() return values do in fact have to be freed.
Also, change listing semantics slightly: if io==NULL, skip the entry,
instead of assuming it's an output device.
|
|
|
|
| |
It was never used, but is a leftover from old times.
|
|
|
|
| |
Was used internally once; has no function anymore.
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"
Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was essentially missing from commit 0b52ac8a.
Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.
For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually
use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context,
using WCHAR instead is more portable.
This affects only non-MinGW parts, so not all uses of wchar_t need to
be changed. For example, terminal-win.c won't be used on Midipix at
all. (Most of io.c won't either, so the search & replace here is more
than necessary, but also not harmful.)
(Midipix is not useable yet, so this is just preparation.)
|
|
|
|
|
| |
Was broken by 68bbab0e42e141896545f1f6e9699bcad2d685f8, which changed
the number of fields to scan, but not the expected return value.
|
|
|
|
|
|
|
|
| |
This was a minor optimization to potentially avoid resampler
reconfiguration when the filter is reinitialized. But filter
reinitialization is a rare event, and the case when no reconfiguration
is needed is even rarer. As such, this is an unnecessary micro-
optimization and only adds potential for bugs.
|
|
|
|
|
|
|
|
|
| |
This message bloats verbose log output if e.g. audio speed is frequently
readjusted, such as when syncing audio to video. So don't print the
message if only speed is changed. (This case requires reconfiguration,
but can't change the input/output channel maps.)
Also do not print the message if no remixing is done at all.
|
|
|
|
|
|
|
|
| |
Some filter chains require a huge number of auto-inserted conversion
filters. There is an overly stupid safeguard against infinite filter
insertions, which counts the number of conversion filters inserted. This
triggered accidentally in this case. Fix by resetting this counter after
a non-conversion filter was successfully configured.
|
|
|
|
|
|
|
|
|
| |
ao_coreaudio (using AudioUnit) accounted only for part of the latency -
move the code in ao_coreaudio_exclusive to utils, and use that for the
AudioUnit code.
(There's still the question why CoreAudio and AudioUnit require you to
jump through hoops this much, but apparently that's how it is.)
|
|
|
|
|
| |
Makes it work with (apparently) crappy drivers, which refuse to set the
physical format in some cases.
|
| |
|
|
|
|
| |
Only causes problems.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, this was for AC3 only. For PCM, we used AudioUnit in
ao_coreaudio, and the only reason ao_coreaudio_exclusive exists
is that there is no other way to passthrough AC3.
PCM support is actually rather simple. The most complicated
issue is that modern OS X versions actually do not support
copying through the data; instead everything must go through
float. So we have to deal with virtual and physical format
being different, which causes some complications.
This possibly also doesn't support some other things correctly.
For one, if the device allows non-interleaved output only, we
will probably fail. (I couldn't test it, so I don't even know
what is required. Supporting it would probably be rather
simple, and we already do it with AudioUnit.)
|
|
|
|
|
| |
Currently this is equivalent. On the other hand, all audio code should
reject formats that is not in a category known to it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Mapping of spdif formats was imperfect. Since the first format on the
list is somehow AAC, it was returned first, which is confusing, because
CoreAudio calls all spdif formats AC3. Since the spdif formats have some
rather arbitrary, reverse mapping the formats didn"t actually work
either. Fix by explicitly ignoring these when spdif is used.
Also, don't forget to set the samplerate in ca_asbd_to_mpformat(), or it
will work only in some cases.
|
|
|
|
|
| |
This field is basically deprecated or for convenience only, and
this code doesn't need it.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
With all the reordering etc. that can go on in this filter, it's useful
to see what upmix/downmix it's actually performing.
|
|
|
|
|
|
|
|
| |
May help with (supposedly) bad drivers, which can put the device into
some sort of broken state when trying to set a different physical
format. When the previous format is restored, it apparently recovers.
This might make the change-physical-format suboption more robust.
|
|
|
|
|
|
|
| |
We can be pretty sure that AudioUnit will remix for us.
Before this commit, we usually upmixed to stereo, because the
stereo and multichannel layouts were the only whitelisted ones.
|
| |
|
|
|
|
| |
This probably fixes the regression introduced with commit 6147bcce.
|
|
|
|
|
| |
And use it for the mono case. This is slightly more formal and will make
it easier to add more such cases.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Replace all the check macros with function calls. Give them all the
same case and naming schema.
Drop af_fmt2bits(). Only af_fmt2bps() survives as af_fmt_to_bytes().
Introduce af_fmt_is_pcm(), and use it in situations that used
!AF_FORMAT_IS_SPECIAL. Nobody really knew what a "special" format
was. It simply meant "not PCM".
|
|
|
|
| |
Having a big switch() is simpler.
|
|
|
|
|
|
|
|
|
|
| |
Audio formats used a semi-clever schema to encode the properties of the
PCM encoding as bitfields into the format integer value.
The af_fmt_change_bits() implementation becomes a bit weird, but it's
an improvement to the rest of the code.
(I've always disliked it, so why not get rid of it.)
|
|
|
|
|
| |
This is actually the last line of code outside of format.c/h which still
tries to fiddle with the format bitfields.
|
|
|
|
|
|
| |
So whoever (nobody?) would want to deal with this broken and obscure AO
for an obscure audio API could add support for some more channel
layouts.
|
|
|
|
|
| |
This saves us the trouble of interleaving the audio data for
no reason.
|
|
|
|
|
|
|
| |
This may o |