| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Useful for debugging cases when no standard orders are used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of somehow having 4 different cases with each their own weight,
do it with a single function that decides which channel layout is the
better fallback.
This is simpler, and also introduces new (fixed) semantics. The new test
added to test/chmap_sel.c actually works now. This is a mixed case with
no perfect upmix or downmix, but the better choice is the one which
loses the least channels from the original layout.
One test also changes. If the input is 7.1(wide-side), and the available
layouts are 7.1 and 5.1(side), the latter is now chosen instead of the
former. This makes sense: both layouts contain 6 out of 8 channels from
the original layout, but the 5.1(side) one is smaller. This follows the
general logic. The 7.1 layout has FLC/RLC speakers instead of BL/BR,
and judging by the names, "front left center" is completely different
from "back left". If these should be exchangeable, a separate exception
would have to be added.
|
| |
|
| |
|
|
|
|
| |
This made no sense and always evaluated to true.
|
|
|
|
|
|
| |
Reuse MP_SPEAKER_ID_NA for this. If all mp_chmap entries are set to NA,
the channel layout has special "unknown channel layout" semantics, which
are used to deal with some corner cases.
|
|
|
|
|
| |
Remove the requirement from mp_chmap that speaker entries must be
unique. Use this to get rid of all the redundant NA speaker IDs.
|
|
|
|
|
| |
While mpv has no internal equivalent representation, they can still be
used as physical CoreAudio formats. Thus this label is confusing.
|
|
|
|
| |
(I won't do this, but someone else seeing this might.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes, ALSA will return channel layouts with padded channels (NA
speakers). Use them instead of failing.
This still includes the old "braindeath" code to retry with a layout
without NA channels. This might be helpful for performance, and also the
padded channel layout string looks confusing.
To be fair, I have not encountered a case yet which would really need
this, and for which the old "braindeath" code did not fix it.
|
|
|
|
|
| |
One side effect is that the warning about too many channels goes away,
and is replaced with printing the ALSA channel map as "unknown".
|
|
|
|
|
| |
It seems if the format was already set, setting the same format will
not cause a property change.
|
|
|
|
|
|
|
|
|
|
|
| |
volatile barely means anything.
The polling is kind of bad too, but relatively harmless as device
opening/closing is a rare event, and the format change is not expected
to take long.
Remove the pointless talloc call too (must have been a leftover
from previous refactoring).
|
|
|
|
| |
PCM is digital too.
|
| |
|
|
|
|
|
|
| |
No reason to keep them separate. It's an artifact from the old
ao_coreaudio.c, which kept usage of two different APIs in the same file.
Removes a forward reference too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of trying to use af_format_conversion_score() (which tries to be
all kinds of clever), just compare the raw bits as a quality measure. Do
this because otherwise, weird formats like padded 24 bit formats will be
excluded, even though they might be the highest precision formats for
some hardware.
This means that for now, the user would have to check whether the format
is usable at all before calling ca_asbd_is_better(). But since this is
currently only used for ao_coreaudio.c and for the physical format, it
doesn't matter.
If coreaudio-exclusive should get PCM support, the best would be to
revert this change, and to add support for 24 bit formats directly.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some time ago, a mechanism was added for automatically removing PCM-only
filters if the input format is spdif.
This could cause an infinite loop if the AO did not support spdif, but
was falling back to some PCM format. Then this code tried to remove the
last filter, which is a dummy filter for receiving and queuing filter
output. af_remove() simply fails gracefully in this case, so this
happens over and over again.
Fix by explicitly checking whether the filter to remove is a dummy
filter. (af_remove() also fails only if the dummy filters are attempted
to be removed - checking this directly is simpler.)
|
|
|
|
|
| |
These ( ) were probably not removed when the format constants were
changed from defines to an enum.
|
|
|
|
|
|
|
|
|
|
| |
Move all of the channel map retrieval/negotiation code to a separate
file. This will (probably) be helpful when extending
ao_coreaudio_exclusive.c.
Nothing else changes, other than some minor cosmetics and renaming,
and changing some details for decoupling it from the ao_coreaudio.c
internals.
|
|
|
|
|
| |
Instead, apply a trick to make the caller allocate enough space on the
stack.
|
|
|
|
|
|
| |
It appears this is the reason coreaudio-exclusive does not work without
explicitly specifying a device, even if the default device maps to
something passthrough-capable.
|
|
|
|
| |
Didn't use the properties it was supposed to use.
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of always picking a somehow better format over the previous one,
select a format that is equal to or better the requested format, but is
also reasonably close.
Drop the mFormatID comparison - checking the sample format handles this
already.
Make sure to exclude channel counts that can't be used.
|
|
|
|
|
|
| |
If for example the physical format is set to stereo, the reported
multichannel layout will actually be stereo. It fixes itself only after
the physical format is changed.
|
|
|
|
|
|
|
|
|
|
|
|
| |
ao_coreaudio uses AudioUnit - the OSX software mixer. In theory, it
supports multichannel audio just fine. But in practice, this might be
disabled by default, and the user is supposed to select a multichannel
base format in the "Audio MIDI Setup" utility.
This option attempts to change this setting automatically. Some possible
disadvantages and caveats are listed in the manpage additions. It is off
by default, since changing this might be rather bad behavior for a
normal application.
|
| |
|
| |
|
|
|
|
|
|
|
| |
If for example the audio settings are set to 5.1 output, but the
hardware does 8 channels natively (HDMI), the reported channel
layout will have 2 dummy channels. To avoid falling back to stereo,
we have to write audio in this format to the device.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some audio APIs explicitly require you to add dummy channels. These are
not rendered, and only exist for the sake of the audio API or hardware
strangeness. At least ALSA, Sndio, and CoreAudio seem to have them.
This commit is preparation for using them with ao_coreaudio.
The result is a bit messy. libavresample/libswresample don't have good
API for this; avresample_set_channel_mapping() is pretty useless.
Although in theory you can use it to add and remove channels, you
can't set the channel counts. So we do the ordering ourselves by making
sure the audio data is planar, and by swapping the plane pointers. This
requires lots of messiness to get the conversions in place. Also, the
input reordering is still done with the "old" method, and doesn't
support padded channels - hopefully this will never be needed. (I tried
to come up with cleaner solutions, but compared to my other attempts,
the final commit is not that bad.)
|
|
|
|
| |
Convenience for the following commit.
|
|
|
|
| |
Basically as before, but avoid undefined behavior.
|
| |
|
|
|
|
|
|
| |
ca_label_to_mp_speaker_id() checked whether the last entry was >= 0, but
actually this condition was never true, and MP_SPEAKER_ID_UNKNOWN0 is
not negative.
|
|
|
|
|
|
|
|
|
| |
This should for now be equivalent; it's merely more explicit and will
be required if we add PCM support.
Note that the property listeners actually tell you what property
exactly changed, but resolving the current listener mess would be too
hard. So check for changes manually.
|
|
|
|
| |
As a consequence, it also logs whether mpv can a this format at all.
|
|
|
|
|
|
|
|
|
|
| |
Useful with some of the following commits.
ca_fill_asbd() should behave exactly as before.
Instead of actually implementing the inverse function of ca_fill_asbd(),
just loop over the (small) list of mpv functions and check if any mpv
equivalent to a given ASBD exists.
|
|
|
|
|
|
|
|
|
| |
kAudioFormatFlagIsSignedInteger implicates that it's only used with
integer formats. The mpv internal flag on the other hand signals the
presence of a sign, and this is set on float formats.
Until now, this probably worked fine, because at least AudioUnit is
ignoring the uncorrect flag.
|
|
|
|
|
| |
Should be almost equivalent, unless there are streams on which this call
does not work for unknown reasons.
|
|
|
|
| |
Make it easier to distinguish the fields.
|
|
|
|
|
|
|
| |
Whether this is correct is unknown. This change tripples the latency
from ~15ms to ~45ms.
XBMC does this, VLC does not from what I could see.
|
|
|
|
|
|
|
|
| |
We always want to prefer upmix to downmix, as long as it makes sense.
Even if the upmix is not "perfect" (not just adding channels), we want
to prefer the upmix.
Cleanup for commit d3c7fd9d.
|
|
|
|
|
|
|
|
| |
As indicated by the added test. In this case, fallback and downmix have
the same score, but fallback happens to give better results. So prefer
fallback over downmix.
(This is probably not a correct solution.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the old implementation for these properties. It was never very
good, often returned very innaccurate values or just 0, and was static
even if the source was variable bitrate. Replace it with the
implementation of "packet-video-bitrate". Mark the "packet-..."
properties as deprecated. (The effective difference is different
formatting, and returning the raw value in bits instead of kilobits.)
Also extend the documentation a little.
It appears at least some decoders (sipr?) need the
AVCodecContext.bit_rate field set, so this one is still passed through.
|
|
|
|
|
| |
configure_lavrr() clears s->pending, so we have to assign it after that
call.
|
|
|
|
|
|
| |
mp_chmap_from_channels_alsa() doesn't always succeed - there are a bunch
of channel counts for which no defined ALSA layout exists. Fallback to
stereo in this case. (Normally, this code path shouldn't happen at all.)
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
| |
The in/out pointers usually have not much meaning outside of
AF_CONTROL_REINIT. Also remove the redundant casts.
|
|
|
|
| |
It must be allowed to set format==0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It could happen that a lavrresample filter would keep its old output
format when the decoder changed its output format. This simply happened
because the output format was never reset.
Normally, this was not an issue, because lavrresample filters only
inserted for format conversion were removed on format changes. But if
--no-audio-pitch-correction is set and playback speed is changed, then
there is a "permanent" lavrresample filter in the filter chain, which
shows this behavior.
Fix by explicitly resetting output formats for all filters which support
it.
Note: this can crash with libswresample in some cases. I'm not sure if
this is mpv's fault or libswresample's, but since it works with
libavresample, I'm going to assume it's not our's.
|
|
|
|
| |
And also use the correct type for the printf call below.
|
|
|
|
| |
Fixes #1743 and partially #1780.
|
|
|
|
|
|
|
|
|
|
| |
The af_add() function has a problem: if the inserted filter returns
AF_DETACH during init, the function will have a dangling pointer. Until
now this was avoided by making sure none of the used filters actually
return AF_DETACH, but it's getting infeasible.
Solve this by requiring passing an unique label to af_add(), which is
then used instead of the pointer.
|
|
|
|
|
|
|
|
| |
Silence the usually user-visible warning about unsupported channel maps.
This might be an ALSA bug, but ALSA will never fix this behavior anyway.
(Or maybe it's a feature.)
Log some other information that might be useful.
|
|
|
|
|
|
| |
The message log level shouldn't get to decide whether something fails
or not. So replace the fatal error check on the verbose output code
path with a warning.
|
|
|
|
|
|
|
|
|
| |
Unfortunately, because we have proxy objects (pAudioVolumeProxy,
pEndpointVolumeProxy, pSessionControlProxy) it looks like we still
have to use MsgWaitForMultipleObjects and watch for and dispatch
pending messages:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680112%28v=vs.85%29.aspx
|
| |
|
| |
|
|
|
|
|
| |
af_fmt_is_float and af_fmt_is_planar were previously inconsistent with
AF_FORAMT_IS_SPECIAL/AF_FORMAT_IS_IEC61937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* unify passthrough and pcm exclusive mode format setting/testing
* set passthrough format parameters correctly
* support all of mpv's existing passthrough formats
* automatically test passthrough with exclusive mode and enable
exclusive if it succeeds, even if it was not explictly requested.
this obviates the need for --ao=wasapi,wasapi=exclusive
* if passthrough fails (such as the device doesn't support the
format), fallback to either exclusive pcm or shared mode depending
on what the user specified. Right now this isn't very useful as
it still fails due to the decoder path remainin stuck on spdif.
fixes #1742
|
|
|
|
|
|
|
|
|
|
| |
libswresample doesn't normalize when remixing to a float format. This
will cause clipping due to float samples being out of the allowed range.
Fortunately this extremely bad default can be changed.
This does not happen with libavresample: it normalizes by default.
Fixes #1752.
|
| |
|
| |
|
|
|
|
|
|
| |
Per-app volume would change the volume across all instances of the same
application, while a private volume control (HAS_PER_APP_VOLUME)
obviously should influence only one instance/audio stream only.
|
|
|
|
|
| |
CoreAudio doesn't seem to have this concept. The volume is reset the
next time audio is opened.
|
|
|
|
| |
Just so that this special-case is out of the common volume path.
|