Intercept the Output Latency paran and parse it for later.
Use the computed latency as the ProcessLatency and expose this
as the ProcessLatency param and the updated Input latency.
Accept updates to ProcessLatency to modify the latency, which then also
updates the Input Latency param.
See #4270
Improve the Latency reporting, we always report Input and Output latency
pairs.
Keep ProcessLatency on the capture and playback streams. The capture
stream process latency is reported as input latency and the playback
process latency as output latency.
Setting ProcessLatency on the capture stream (Sink), for example, will
propagate the added latency upstream. This would then instruct players
to send the audio earlier to compensate for the delay.
See #4270
JACK emits the bufsize callback from the processing thread while
jack_activate() is called. Do the same with a blocking invoke.
The GStreamer plugin relies on this and when it reives the bufsize
callback later, it will error out.
Fixes#4260
First try to pass the format of the converter directly into the
follower. This allows us to avoid conversion when it can be avoided.
Iterate all follower formats (not just the first one) to find something
that intersects with the converter formats.
We don't need to use the raw audio format parsing functions, we can use
the more generic audio ones. This avoids some extra parsing for the
media type and subtype and will support compressed audio formats
as well when the converter handles this.
To activate:
PIPEWIRE_PROPS='{ video.adapt.converter = video.convert.ffmpeg }' build/src/examples/video-play
This makes it possible to start firefox with mjpg capture and then
video-play and it will decode the mjpeg transparently. Works for other
incompatible video formats as well, as long as they can be mmapped.
Ideally this should use something GPU accelerated and this is what the
vulkan converter will do.
Try to passthrough the converter format to the follower when we can
before negotiating a conversion.
Try to convert between all follower formats instead of just the first
one.
When enumerating the port params, first enum the follower formats and
then the conversion formats.
We have to unlink pcms when they are linked to a driver from
a different pcm.
When a playback and a capture pcm is linked and we start
the playback pcm and the capture pcm later this can leads
to a 'EPIPE' error on the capture device.
...
spa.alsa: hw:3,0c: snd_pcm_start: Broken pipe
...
When we drop the first buffer to avoid timestamp problems, queue it
again in the driver or else we will not be able to dequeue is again
later and we will be running with a buffer less.
Move the check for the follower==target to the negotiate functions.
Refer to the target when doing operations. The converter reference
is just some internal element that may or may not be active at the
moment. If we have multiple converter elements, the current active
one will be in target.
Keep the original sequence number of the port_set_param(Format) and
port_use_buffer() calls around. When they produce an error, we will
get an error with the same sequence number.
When the sync completes, check if we got an error for the pending
operation and return that as the result.
We then also mark the link in error. We don't mark the port in error
because that is not really the case.
This should make the link error when negotiation of format or buffers
fails instead of silently continuing.
Since the dummy plugin can't process buffers, we should configure the
adapter to use passthrough mode for now, instead of requiering the user
to do it manually.
Instead of binding the socket to 0.0.0.0 with port 0, make some config
options source.ip and source.port to configure this. This makes it
possible to bind to other interfaces or to use a fixed port for the
data messages.
Fixes#4144
First try to parse the float value as a JSON number and then fall
back to atof to get the locale dependent variant.
This transparently makes things work with values such as 0.5 and 0,5.
Fixes#4234
Use the pipewire header version for the minor/micro/proto in the
jack version. That way the jack version will increment and we can
easily see what pipewire version it was compied with.
Our current AES67 sender setup requires that that PTP driver drive the
entire graph. This adds support for allowing the AES67 RTP sink to be
driven by an arbitrary driver, while still using the PTP driver for
sending data on the network.
When aes67.driver-group is specified a pw_filter is created with no
ports, node.always-process = true and node.group set to the
aes67.driver-group. When set to PTP, this gives us process callbacks at
the PTP rate which we use to get the current PTP time in the RTP sender
by interpolating the clock snapshots from the pw-filter.
Implementation ideas from Wim Taymans. Co-authored with Sanchayan Maity.
For a detailed reference, refer the following papers by Fons Adriaensen.
- Using a DLL to filter time
(https://kokkinizita.linuxaudio.org/papers/usingdll.pdf)
- Controlling adaptive resampling
(http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf)
We allow a quantum of jitter in the write timestamp. The previous value
of 32 seems to be empirically determined, using the actual quantum
allows us to reason about this better.
