As mentioned in [0] the suffix "_locked" would have been the appropriate
naming in line with similar uses inside mpv.
See `mp_abort_recheck_locked()`, `mp_abort_trigger_locked()`,
`retrigger_locked()`, `wakeup_locked()`...
[0] https://github.com/mpv-player/mpv/pull/12811#discussion_r1477518525
ao_read_data() is used by pull AOs potentially from threads managed by
external libraries. These threads can be sensitive to blocking.
For example the pipewire ao is using a realtime thread for the
callbacks.
wireplumber uses the media role when the node is first created.
To have the property available at this point reliably we need to set it
directly when creating the stream/node.
As the role property is interpreted by wireplumber it can only be
evaluated when creating the stream. The current, dynamic mechanism is
racy so revert it.
See: #11253Fixes: #12041
This reverts commit 535cd6f313.
Doing a pw_thread_loop_wait() without checking conditions is invalid.
The thread loop could be signalled for other reasons and in this case
the wait needs to continue.
PipeWire added such additional signaling in
commit 33be898130f0 ("thread-loop: signal when started").
This meant that for_each_sink would return before the callbacks have
fired and session_has_sink() would incorrectly return "false", failing
the initialization of ao_pipewire.
Fixes#11995
Now that Debian 12 is release bump the minium required version to what
is provided in Ubuntu Jammy (22.04).
The same as has been done for the wayland dependencies.
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
By making the data thread realtime it is able to serve requests faster
and more reliable reducing crackling in certain situations.
As the mpv callbacks that are running on the data thread are all
non-blocking and very short this should be safe.
The same mechanism is also used by pw-cat and the alsa plugin shipped by
pipewire.
Older versions of pipewire segfault when calling spa_hook_remove() on
hooks that are zeroed.
Add a backfill for the logic added by pipewire 0.3.57.
Being able to remove zeroed hooks makes errorhandling much easier.
See #11309
PipeWire supports a global volume control for streams that works on top
of the per-channel volumes.
As mpv only supports a single volume with ao-volume it can make sense to
use the single global volume from PipeWire for it.
This allows the user to also specify per-channel volumes and not have
mpv trample over them.
This mode is not the default as pulseaudio does not support this
global volume control and all tooling controlling PipeWire via
pipewire-pulse (like pavucontrol) will not be able to see this channel.
As ao_pipewire is probed first if a user does not have PipeWire running
they will see a scary warning message even if another AO afterwards is
probed fine.
Tone down the error message so as not to confuse users.
When building both cplayer and libmpv in the same build previously all
sources were built twice.
By reusing the objects from libmpv in cplayer we can thus save 50%
percent of the build steps.
ao-volume is represented in the code with a `struct ao_control_vol_t`
which contains volumes for two channels, left and right.
However the code implementing this property in command.c never treats
these values individually. They are always averaged together.
On the other hand the code in the AOs handling these values also has to
handle the case where *not* exactly two channels are handled.
So let's remove the `struct ao_control_vol_t` and replace it with a
simple float.
This makes the semantics clear to AO authors and allows us to drop some code from the AOs and command.c.
Core code should not use these features as it would mean that a libmpv
build could change an mpv executable and vice-versa.
Also changing one of them should not force a full recompile of the other
one through a change to config.h.
The libmpv feature should not have any impact on the built core code.
Otherwise a mpv executable compiled in a build together with libmpv has
different features than one from a build without.
The gl feature doesn't hurt, so always enable it.
This allows us to rebuild the manpages and html documentation only when
necessary. It is not necessary to manually keep the list of dependencies
up to date.
Unfortunately rst2pdf does not yet support this feature, see
https://github.com/rst2pdf/rst2pdf/issues/1108
When a pull AO reaches reaches EOF then ao_read_data() will set
p->playing = false.
Because the ao is marked as not playing ao_set_pause(true) will not
reset the AO.
This keeps the output stream unintentionally open.
Fixes#9835
This allows us to more easily see the datapath from mpv to pipewire.
We know how often the callbacks are triggered, how big the buffers are
and how much data mpv provides to pipewire.
This allows the core of mpv to know about issues in the AO.
Otherwise playback will just freeze as no more data callbacks are sent
by PipeWire.
Also it allows mpv to try to reconnect the AO or find another, working
AO.
We want to add more logic to the stream event handler.
This logic should not be triggered during normal stream shutdown, so we
remove the listener beforehand.
The AO is feature-complete now.
As PipeWire also provides compatibility with PulseAudio, ALSA and Jack
we should put it before those for the autodetection to work.
The pure presence of PipeWire does not mean that it is actually driving
the audio session. For example it could only be meant for video.
Currently there is no proper API to detect this (see [0]), so we check
for the presence of audio sinks.
As soon as a proper API exists, we should use that.
[0] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835
Specifying the id of the target node during stream connect is
deprecated. Instead the property target.object should be used to link
by target serial or name. Using the name allows us to drop a bunch of
custom code.
Previously we would only call list_devs() on available AOs if an AO
*did not* have a hotplug_init() callback or for the first one that *did*
have it.
This is problematic when multiple fully functional hotplug-capable AOs
are available.
The second one would not be able to contribute discovered devices.
This problem prevents ao_pipewire from introducing full hotplug support
with hotplug_init().
When a platform has multiple valid AOs that can provide hotplug events
we should try to use the one that also provides playback.
Concretely this will help when introducing hotplug support for
ao_pipewire.
Currently ao_pulse is probed by ao_hotplug_get_device_list() before
ao_pipewire and on the common setups where both AOs could work pulse
will be selected for hotplug handling.
This means that hotplug_init() of ao_pipewire will never be called and
list_devs() has to do its own initialization.
But if ao_pulse is non-functional or not compiled-in suddenly
ao_pipewire *must* implement hotplug_init() for hotplugging events to
work for all.
Also if the hotplug ao_pulse connects to a PulseAudio instance that is
not emulated by the same PipeWire instance as the playback ao_pipewire
the hotplug events are useless.
30 characters are not a lot.
Also when the name is calculated from the allocation site the line
number will be the at the end of the name, so truncating it is
especially inconvenient.