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.
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
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
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.
The "old" method (before the ALSA channel map API) used device aliases
like "surround51" to set the channel layout. The "interesting" part was
that these devices usually redirect to a hardware device. This means
playing stereo would lead you to the "default" device (dmix), while e.g.
5.1 to "surround51", which automatically takes care of the fact that
dmix can't do 5.1.
This is pretty much nonsense, though. It shouldn't depend on the damn
input media file whether the player is going to use shared access (dmix)
or exclusive access (direct hw device).
As a consequence, by default ao_alsa will do only what dmix can do. If
the user actually wants multichannel, he has to select a suitable hw
device with --audio-device. From there on, the correct speaker mapping
will be ensured via the channel mapping API.
The change is preparation for making multichannel output the default (as
far as supported by the audio output API). Of the common APIs, only ALSA
messes up beyond repair, so I feel like this change is needed.
On ancient alsa-lib versions, only stereo and mono can be played with
this branch.
dmix reports channel layouts it doesn't support. The rest of the
technical part of the story is in the code comment.
This seems to be the only reasonable way to fallback from trying to
initialize certain devices (like dmix) with multichannel audio. We could
probably add support for such padding channels to our audio chain or to
ao_alsa itself, but this would probably be much more work than this
commit.
What dmix does is probably a bug. I've tried to report it to ALSA. Thay
have a link on their website to a bug tracker, but it's a dead link, and
has been for years. I've posted to alsa-devel, but received no reply.
I'm thus assuming this absolutely retarded behavior is by design, and
nothing will happen to improve upon it.
I'm considering sending Lennart Poettering a "thank you" email, because
with PulseAudio, multichannel audio just works (although some other
things just don't work).
Whether we print it as warning or error doesn't really matter; we
continue anyway. (I don't actually know what the implications of running
in non-blocking mode are; for what's it worth, when I tested with
explicitly changing to non-blocking, it seemed to work fine anyway, so
don't change that part.)
ALSA returns "FL" as channel layout when trying to play mono. mpv and
libavresample don't like this; in particular, using libavresample to
convert stereo to "FL" fails.
If no-block was given, the device would be opened with SND_PCM_NOBLOCK.
Also, after opening, blocking mode was unconditionally enabled anyway
with snd_pcm_nonblock(). Further, if opening with SND_PCM_NOBLOCK
failed, opening was retried without this flag.
This doesn't make any sense to me, and I've never heard of someone using
this suboption. I suspect it has to do with ancient ALSA bugs or API
caveats. Remove it and simplify the code.
ALSA is crap. It's impossible to make multichannel playback just do the
right thing. dmix (the default on most distros) can do stereo only, and
will refuse to play multichannel. On the other hand, if you try like mpv
(and mplayer) to open a multichannel device (like "surround51" etc.),
this will actually open a hardware device, which will either fail if
dmix is active, or block out dmix if opening succeeds.
This commit falls back to "default" (i.e. dmix) if opening a
multichannel device fails, which is a tiny step towards the right
behavior. (Although fixing it fully is impossible.)
This could trigger an assertion when using ao_alsa or ao_coreaudio. The
code was simply assuming the number of channel maps was bounded
statically (which was true at first in both AOs).
Fix by using dynamic memory allocation. It needs to be explicitly
enabled by the AOs by setting a temp context, because otherwise the
memory couldn't be freed. (Or at least this seems to be the most elegant
solution.)
Fixes#1306.
Before it used whatever was in ao->format and changed the bits even
though this might have nothing to do with the actual WAVEFORMAT
negotiated with WASAPI.
For example, if the initial ao->format was a float and we had set the
WAVEFORMAT to s24, this would create a non-existent float24 format.
Worse, it might put an u16 into ao->format when WAVEFORMAT described s16.
WASAPI doesn't support unsigned at all as far as I can tell.
this involved inverting the logic of find_formats, enumerate_devies
and wasapi_fill_VistaBlob. The latter two were trivial as their return
values were not actually checked (to be fixed in a later
commit).
Before these definitions were incorrectly guarded by and #ifdef
but since they aren't macros, this would never be true so that
if they were ever added to mingw headers we would have problems.
rename KSDATAFORMAT constants with the same mp prefix for consistency.
also use DEFINE_GUID rather than defining the bare structure
