Instead of requiring each VO or AO to manually add members to MPOpts and
the global option table, make it possible to register them automatically
via vo_driver/ao_driver.global_opts members. This avoids modifying
options.c/options.h every time, including having to duplicate the exact
ifdeffery used to enable a driver.
With the previous commit, ao_alsa.c now has 3 possible ways to pause
playback. Actually all 3 of them need get_delay() to fake its return
value, so don't duplicate that code.
Also much of the code looks a bit questionable when considering
inconsistent pause/resume calls from outside, so ignore redundant calls.
push.c does not handle this automatically, and AOs using push.c have to
handle it themselves. Also, ALSA is low-level enough that it needs
explicit support in user code. At least I haven't found any option that
does this.
We still can get away relatively cheaply by abusing underflow-handling
for this. ao_alsa.c already configures ALSA to handle underflows by
playing silence. So we purposely induce an underflow when opening the
device, as well as when pausing or resetting the device.
This introduces minor misbehavior: it doesn't account for the additional
delay the initial silence adds, unless the device has fully played the
fragment of silence when the player starts sending data to it. But
nobody cares.
This commit adds an --audio-channel=auto-safe mode, and makes it the
default. This mode behaves like "auto" with most AOs, except with
ao_alsa. The intention is to allow multichannel output by default on
sane APIs. ALSA is not sane as in it's so low level that it will e.g.
configure any layout over HDMI, even if the connected A/V receiver does
not support it. The HDMI fuckup is of course not ALSA's fault, but other
audio APIs normally isolate applications from dealing with this and
require the user to globally configure the correct output layout.
This will help with other AOs too. ao_lavc (encoding) is changed to the
new semantics as well, because it used to force stereo (perhaps because
encoding mode is supposed to produce safe files for crap devices?).
Exclusive mode output on Windows might need to be adjusted accordingly,
as it grants the same kind of low level access as ALSA (requires more
research).
In addition to the things mentioned above, the --audio-channels option
is extended to accept a set of channel layouts. This is supposed to be
the correct way to configure mpv ALSA multichannel output. You need to
put a list of channel layouts that your A/V receiver supports.
This reportedly makes it work on ODROID-C2. The idea for this hack is
taken from kodi; they unconditionally set some or all of those flags.
I don't trust ALSA enough to hope that setting these flags couldn't
break something else, so we try without them first.
It's not clear whether this is a driver bug or a bug in the ALSA libs.
There is no ALSA bug tracker (the ALSA website has had a dead link to
a deleted bug tracker fo years). There's not much we can do other than
piling up ridiculous hacks. At least I think that at this point invalid
API usage by mpv can be excluded as a cause.
ALSA might be the worst audio API ever.
Remove known useless device entries from the --audio-device list (and
corresponding property). Do this because the list is supposed to be a
high level list of devices the user can select. ALSA does not provide
such a list (in an useable manner), and ao_alsa.c is still in the best
position to improve the situation somewhat.
The ALSA doxygen says:
IOID - input / output identification ("Input" or "Output"), NULL
means both
This bug was blatantly introduced with commit cf94fce4.
Essentially we'd use something random, just because it's part of the srt
of traditionally used ALSA channel mappings. But each driver can do its
own things.
This doesn't let me sleep at night, so remove it.
We need to effectively swap the last channel pair. See commit 4e358a96
and 5a18c5ea for details.
Doing this seems rather strange, as 7.1 just extends 5.1 with 2 new
speakers, and 5.1 doesn't need this change. Going by the HDMI standard
and the Intel HDA sources (cited in the referenced commits), it also
looks like 7.1 should simply append two channels to 5.1 as well. But
swapping them is apparently correct. This is also what XBMC does. (I
didn't find any other applications doing 7.1 PCM using the ALSA channel
map API. VLC seems to ignore the 7.1 case.) Testing reveals that at
least the end result is correct.
"Normal" ALSA 7.1 is unaffected by this, as it reports a different
(and saner) channel layout.
Instead of constructing an ALSA channel map from mpv ones from scratch,
try to find the original ALSA channel map again. Th result is that we
need to convert channel maps only in one direction. If we need to map
a mp_chmap to ALSA, we fetch the device's channel map list, convert
each entry to mp_chmap, and find the first one which fits.
This seems helpful for the following commit. For now, this only gets rid
of mapping back the trivial MONO mapping, which alone would still be
acceptable, but with other channel layout mogrifications it gets messy
fast. While we need to do something awkward to keep our channel map
reordering for VAR chmaps (which basically gives nicer output and
possibly slightly better performance), this is still the better
solution.
These calls actually can leave the ALSA configuration space empty (how
very useful), which is why snd_pcm_hw_params() can fail. An earlier
change intended to make this non-fatal, but it didn't work for this
reason.
Backup the old parameters, so we can retry with the non-empty
configuration space. (It has to be non-empty, because the previous
setters didn't fail.)
Note that the buffer settings are not very important to us. They're
a leftover from MPlayer, which needed to write enough data to the
audio device to not underrun while decoding and displaying a video
frame. In mpv, most of these things happen asynchronously, _and_
there is a dedicated thread just for feeding the audio device, so
we should be pretty imune even against extreme buffer settings. But
I suppose it's still useful to prevent PulseAudio from making the
buffer too large, so still keep this code.
Again, this could have bad access, is unlikely, and has no bad
consequences. It's noteworthy that vlc and the ALSA PCM example both do
this first, even if they set the sample rate later.
I'm worried that not restricting the access type before restricting the
format will cause problems. While it's unlikely, it might prevent
failures in some corner cases. Also, since we by default always use
interleaved access (buggy ALSA plugins), this will have no effects at
all.
If the API doesn't list padded channel maps, but the final device
channel map is padded, and if unpadded output is not possible (unlike in
the somewhat similar dmix case), then we shouldn't apply the channel
count mismatch fallback in the beginning. Do it after channel map
negotiation instead.
Doesn't matter much; effectively this prevents just log spam in some
cases where the map is legitimately padded. Normally this is really
only needed for the dmix ALSA case. (See git blame for details.)
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.
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.
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".
So apparently, this essentially happens when the kernel driver doesn't
implement write accesses in the channel map control. Which doesn't
necessarily mean that the channel map is unsupported, or that there is a
bug - it's just lazyness and a consequence of the terrible ALSA kernel
API for the channel mapping stuff.
In these cases, the channel count implicitly selects the channel map,
and snd_pcm_set_chmap() always fails with ENXIO.
I'm actually not sure what happens if dmix is on top of e.g. HDMI, which
actually lets you change the channel mapping.
I'm also not sure why commit d20e24e5d1614354e9c8195ed0b11fe089c489e4
(alsa-lib git repository) does not take care of this.
They are useless. Not only are they actually rarely in use; but
libavcodec doesn't even output them, as libavcodec has no such sample
formats for decoded audio.
Even if it should happen that we actually still need them (e.g. if doing
direct hardware output), there are better solutions. Swapping the sign
is a fast and lossless operation and can be done inplace, so AO actually
needing it could do this directly.
If you wonder why we keep U8 instead of S8: because libavcodec does it.
Channel maps reported by the device as SND_CHMAP_TYPE_VAR can be freely
reordered. We don't use this much (out of laziness), but in this case
it's a simple way to reduce necessary reordering (which would be an
extra libavresample invocation), and to make debug output more readable.
If you try to play surround with dmix, it will advertise surround and
lets you set more than 2 channels, but will report a stereo channel map,
with the extra channels identified as NA. We could handle this now, but
we don't want to (because it's excessively stupid).
Do it only if the channel map is not what we requested, instead of just
acting if it contains NA entries at all. This avoids that we hurt
ourselves in the unlikely but possible case we actually have to use
channel maps with NA entries.
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.
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.)
wm4
Kevin Mitchell