| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[motivation]
Seeking on MacOS appears to be lagged when users connect
to wireless audio output (airpods for example).
This commit attempts to fix mpv-player/mpv#10270
[observation]
1. When using other media player (VLC to be exact) simultaneously,
the lagging on seek disappear. We could guess that the AudioDevice
is on some sort of "warm-up" state.
See mpv-player/mpv#9243 for detailed description.
2. `AudioOutputUnitStart` takes significant longer time after each seek
or pause/play when using wireless output devices compares to wired devices.
[rationale]
After investigate codes in ao_coreaudio.c, it appears that the the `stop`
function was used as `ao_driver.reset` function. Therefore every seek
and pause would call `AudioOutputUnitStop`.
It turns out that `ao_driver.reset` function is used in `ao_reset`.
And `ao_reset` function is used to clean up the state of current `ao`
so I think `AudioUnitReset` is more proper than `AudioOutputUnitStop`
under this semantics.
Since ao_coreaudio use pull base mechanism, audio playback behaviors
upon pause/seek could be handled by callback function
(streaming silence when paused) so there is no need to stop AudioUnit when resetting.
Therefore using `AudioUnitReset` as `ao_driver.reset` looks proper.
Additionally, after using proper reset, the AudioUnit that represents
hardware I/O devices doesn't need to be restart everytime seek/pause actions happen.
Restarting wireless devices simply takes longer in MacOS which is
the root cause of lagging observed by users when they seek or pause/play media.
[method]
Use `AudioUnitReset` for ao_driver.reset.
|
|
|
|
|
|
|
|
|
|
| |
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 reverts commit b5373079f20aeeba8ac80e773f3cc05692dbb51f.
|
|
|
|
|
|
|
| |
By explictly shutting down the stream pipewire can deactivate the used
hardware, saving CPU and power.
Fixes #9835
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Fixes sync issues when using high-latency devices at non-native sample rates
Closes #10984
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has been a long standing annoyance - ffmpeg is removing
sizeof(AVPacket) from the API which means you cannot stack-allocate
AVPacket anymore. However, that is something we take advantage of
because we use short-lived AVPackets to bridge from native mpv packets
in our main decoding paths.
We don't think that switching these to `av_packet_alloc` is desirable,
given the cost of heap allocation, so this change takes a different
approach - allocating a single packet in the relevant context and
reusing it over and over.
That's fairly straight-forward, with the main caveat being that
re-initialising the packet is unintuitive. There is no function that
does exactly what we need (what `av_init_packet` did). The closest is
`av_packet_unref`, which additionally frees buffers and side-data.
However, we don't copy those things - we just assign them in from our
own packet, so we have to explicitly clear the pointers before calling
`av_packet_unref`. But at least we can make a wrapper function for
that.
The weirdest part of the change is the handling of the vtt subtitle
conversion. This requires two packets, so I had to pre-allocate two in
the context struct. That sounds excessive, but if allocating the
primary packet is too expensive, then allocating the secondary one for
vtt subtitles must also be too expensive.
This change is not conditional as heap allocated AVPackets were
available for years and years before the deprecation.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This reverts commit 8b114e574abd08892612e21e784ea1872e1adf8c.
|
|
|
|
|
| |
This matches our internal expectations, as well as fixes handling
of non-ASCII device descriptions.
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
different translation units
`struct entry` already exists from <search.h>, so the one we declare in audio/format.c needs to be named differently
|
| |
|
|
|
|
|
|
| |
* Remove unneeded braces.
* Don't use non-standard %m in printf.
* Organize struct priv a bit.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When af_scaletempo2.c:process() detects a format change, it goes back
through mp_scaletempo2_init() to reinitialize everything. However,
mp_scaletempo2.input_buffer is not necessarily reallocated due to a
check in af_scaletempo2_internals.c:resize_input_buffer(). This is a
problem if the number of audio channels increases, since without
reallocating, the buffer for the new channel(s) will at best point to
NULL, and at worst uninitialized memory.
Since resize_input_buffer() is only called from two places, pull size
check out into mp_scaletempo2_fill_input_buffer(). This allows each
caller to decide whether they want to resize or not. We could be
smarter about when to reallocate, but that would add a lot of machinery
for a case I don't expect to be hit often in practice.
|
|
|
|
|
|
|
| |
Fixes 5.1/7.1 output mapping on tvOS 16,
and also makes the AC3-layout hack unnecessary.
Also adds some diagnostic log messages.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
This is used to notify an AO about the type of media that is being
played.
Either a movie or music.
|
| |
|
|
|
|
|
|
|
| |
`opus` codec likes returning denormalized floats in some cases, causing
wacky issues.
Fixes #10290
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
uau did some investigation and noticed that we do not send a wakeup
event when we encounter end-of-stream in ao_read_data(), in contrast to
the equivalent logic for push AOs in ao_play_data().
Inserting that wakeup fixes the original problem of lack of
reinitialization on a format change without the problems we saw with
the previous attempted fix.
Fixes #10566
|
|
|
|
|
|
|
|
|
|
| |
The error description in #10545 could indicate that we are overflowing
we are corrupting the buffer metadata ourselves through out-of-bound
writes.
This check is also present in pw-cat so it seems to be expected for
b->requested to exceed the actual available buffer space.
Potential fix for #10545
|
| |
|
| |
|
|
|
|
|
| |
This allows the audio server better to make sense of the data instead of
having to use heuristics.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Don't use cube root volumes, pipewire uses linear volumes.
|
|
|
|
|
|
|
|
| |
pw_core_disconnect frees the core, so accessing it afterward to
destroy the context is not allowed.
Instead, just destroy the context, the first thing it does is disconnect
all cores for us.
|
|
|
|
|
| |
The listeners need to be cleared because removing them might invoke the
removed handler, which could otherwise point to invalid memory.
|
|
|
|
|
|
|
|
| |
mpv only remembers volume for two channels.
Always apply the same volume to all channels in case of
non-stereo layout similarly to ao_pulse.
Don't try to do anything smart when averaging volumes,
normally they are equal anyway.
|
|
|
|
|
| |
Mostly useful for unit tests in order to access the channel
layouts from chmap which have mapped channels.
|
| |
|
| |
|
|
|
|
| |
This simplifies ifdeffery with AVChannelLayouts.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is the new FFmpeg channel layout structure, which now
combines channel count and layout into a single location.
Only unspecified (channel count only) and native (channel layout
mask based) layouts are currently supported for the initial move
towards non-deprecated APIs.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Stopping the thread is done using pw_thread_loop_stop(),
*which must be called without the lock held.*
Fixes #10033
|
|
|
|
|
|
|
| |
We have to destroy the core before destroying the loop.
Also we have to lock the mainloop for operations on its objects.
Fixes #10003
|
|
|
|
|
| |
No change in logic, but wrap the LT operator and the && in parentheses
to silence the compiler warning.
|
|
|
|
|
|
|
|
| |
Pass channel volumes to `pw_stream_set_control` as array.
This is correct calling conventions and prevents
right channel muting every time ao-volume property is changed.
Terminate `pw_stream_set_control` calls with 0.
|
|
|
|
|
| |
Our allocated buffers should be big enough, but add some errorhandling
just in case.
|
| |
|
|
|
|
|
|
|
|
| |
Changes:
* fixed hangups in the loop function and in some other cases
* refactoring according to @michaelforney's recommendations in #8314
* a few minor and/or cosmetic changes
* ability to build ao_sndio using meson
|
|
|
|
|
|
|
|
|
| |
Changes:
- rewrite to use new internal MPV API;
- code refactoring;
- fix buffers size calculations;
- buffer set to auto;
- reset() - clean/reinit device only after errors;
|
|
|
|
|
|
|
|
|
|
| |
Sometimes the most obvious things can be missed.
Reflects authorship described in the original commit.
* https://github.com/mpv-player/mpv/pull/7902
* https://github.com/Oschowa/mpv/commit/fddb143282fa74425a8a6f29c9566e51777759d0
* https://github.com/mpv-player/mpv/pull/9587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AO provides a way for mpv to directly submit audio to the PipeWire
audio server.
Doing this directly instead of going through the various compatibility
layers provided by PipeWire has the following advantages:
* It reduces complexity of going through the compatibility layers
* It allows a richer integration between mpv and PipeWire
(for example for metadata)
* Some users report issues with the compatibility layers that to not
occur with the native AO
For now the AO is ordered after all the other relevant AOs, so it will
most probably not be picked up by default.
This is for the following reasons:
* Currently it is not possible to detect if the PipeWire daemon that mpv
connects to is actually driving the system audio.
(https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835)
* It gives the AO time to stabilize before it is used by everyone.
Based-on-patch-by: Oschowa <oschowa@web.de>
Based-on-patch-by: Andreas Kempf <aakempf@gmail.com>
Helped-by: Ivan <etircopyhdot@gmail.com>
|
|
|
|
| |
mark an array as static, a typo and a missing free
|
| |
|
|