There's an edge cause with gapless audio and pausing. Since, gapless
audio works by sending an EOF immediately, it's possible to pause on the
next file before audio actually finishes playing and thus the sound gets
cut off. The fix is to simply just always do an ao_drain if the ao is
about to set a pause on EOF and we still have audio playing.
Fixes#8898.
The difference this makes is that the OS API will notice
when we underrun (as opposed to being fed silence).
Other AOs mostly seem to not do this because they've committed
to filling a buffer of a certain size no matter what, but I have
not observed any ill effects for AudioTrack in my testing.
This looks like a pretty bad bug but only became a problem
with the last commit that allows rates like 22.5kHz to pass through
directly instead of being resampled.
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.
The avpkt was created once on decoder init but destroyed each time the
filter was destroyed, this obviously can't work. Move the packet alloc
to the filter init function instead.
fixes: 4574dd5dc6
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>
Instead of brute forcing the name until it is set, without any error
checking and expecting it would start to work, fallback to client name
if initial request fails.
Fixes player going into infinite loop with very long title names. The
API rejects unreasonably long names, which make sense.
As for alleged "weird race condition in the IAudioSessionControl itself"
I cannot comment. It works on my end and even if it fails, it is not a
critical error or even something that we should care about... and
obviously not hang the whole player for that.
Fixes: #11803
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.
c784820454 introduced a bool option type
as a replacement for the flag type, but didn't actually transition and
remove the flag type because it would have been too much mundane work.
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.
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.
