Take advantage of the fact that list_devs is called with a
hotplug_inited ao. Also eliminate unnecessary nested function
abstraction of hotplug_(un)init and list_devs. However, keep list_devs
in ao_wasapi_utils.c since it uses the private functions get_device_id,
get_device_name and exposing these would require including headers for
IMMDevice in ao_wasapi_utils.h.
Create a second copy of the change_notify structure for the hotplug
ao. change_notify->is_hotplug distinguishes the hotplug version from
the regular one monitoring the currently playing ao. Also make the
change notification less verbose now that there might be two of them around.
More clearly separate the exclusive and shared mode format discovery.
Make the exclusive mode search more systematic in particular about
channel maps (i.e., use chmap_sel). Assume that the same sample format
/ sample rates work for all channels to narrow the search space.
The code actually uses blocking mode, so opening sound device in non-blocking
mode results in choppy sound. Also, inflating the buffer isn't necessary in
blocking mode, so the function may simply return without doing anything.
Instead of maintaining a private ring buffer, use the generic support
for audio APIs with pull callbacks (internally called AO pull API). This
also fixes latency calculations: instead of just returning the
ringbuffer status, the audio playback state is calculated better and
includes interpolation.
The main reason this wasn't done earlier was mid-stream format
switching. The pull API can now handle it (in a way) by destroying and
recreating the AO. This is a bit brutal, but quite simple. It's untested
in this new AO, though. Some details might not be right, like how ot
restores the old format when reloading.
This could mute a digital passthrough stream by writing zeros. All other
volume values did nothing.
The comment about MPlayer dying hasn't been true in mpv for quite a
while. It's even possible that it's fixed in upstream MPlayer. mpv will
print a scary error message when trying to change volume with spdif, and
continue normally.
If we really want to mute by writing zeros, we should do it in a
separate filter. But I'm not overly fascinated by this approach; is it
even guaranteed receivers will not be confused by a stream of zeros?
The main reason to remove this is that it's in the way of further
cleanups.
This echanges the two events hForceFeed/hFeedDone for hResume. This
like the last commit makes things more deterministic.
Importantly, the forcefeed is only done if there is not already a full
buffer yet to be played by the device. This should fix some of the
problems with exclusive mode.
This commit also removes the necessity to have a proxy to the
AudioClient object in the main thread.
fixes#1529
This makes things a bit more deterministic. It ensures that the audio
thread isn't doing anything between IAudioClient_Stop(),
IAudioClient_Reset() and setting the sample_count to 0.
Buffer overfilling on resume is still a problem in exclusive mode (see
next commit).
This commit adds notifications for hot plugging of devices. It also extends
the old behaviour of the `audio-out-detected-device` property which is now
backed by the hotplugging code. This allows clients to be notified when the
actual audio output device changes.
Maybe hotplugging should be supported for ao_coreaudio_exclusive too, but it's
device selection code is a bit fragile.
This requires jumping through multiple hoops on fire. Since the
PulseAudio API is virtually undocumented, I'm not sure if this is
correct either. We only react to sink events, and only to the NEW/REMOVE
events. CHANGE events are ignored, because PulseAudio fires them far too
often - even if the system is completely idle! If pa_sink_info.name can
change, we're in trouble. pa_sink_info.description is not so important,
but it'd also be a bit un-nice if it can change, and we don't update it.
The weird way how the actual AO and the hotplug context share the same
struct (ao) comes in handy here, although context_success_cb() still had
to be duplicated from success_cb() - the unused argument has a different
type.
Not very important for the command line player; but GUI applications
will want to know about this.
This only adds the internal API; support for specific audio outputs
comes later.
This reuses the ao struct as context for the hotplug event listener,
similar to how the "old" device listing API did. This is probably a bit
unclean and confusing. One argument got reusing it is that otherwise
rewriting parts of ao_pulse would be required (because the PulseAudio
API requires so damn much boilerplate). Another is that --ao-defaults is
applied to the hotplug dummy ao struct, which automatically applies such
defaults even to the hotplug context.
Notification works through the property observation mechanism in the
client API. The notification chain is a bit complicated: the AO notifies
the player, which in turn notifies the clients, which in turn will
actually retrieve the device list. (It still has the advantage that it's
slightly cleaner, since the AO stuff doesn't need to know about client
API issues.)
The weird handling of atomic flags in ao.c is because we still don't
require real atomics from the compiler. Otherwise we'd just use atomic
bitwise operations.
This is a small oversight. The client name (as set on command line
options or, more importantly, the client API) was not set when listing
devices e.g. via the "audio-device-list" property.
Might or might not fix#1578.
Also adjust the log level for an unrelated message.
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.
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.
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.
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.
* 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
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
