It is possible that we destroyed the source/sink when we get a latency
update from jack, don't try to update the source/sink in that case or
we will crash.
Let the server calculate signal time when it starts the graph. Otherwise
we overwrite old values and we can't do stats.
We might be able to piggyback the signal time in the prev_signal_time
field later.
Don't make an extra eventfd for activating the remote-node, we can
use the server side eventfd and send them to the remote side using
the transport.
The remote node already adds the eventfd to the data-loop so avoids
doing the same on the server.
This makes driver nodes trigger all remote nodes directly instead of
going through an intermediate eventfd. For resuming nodes, we already
used the node eventfd directly so this only a small optimization
for the initial cycle start.
Add latencyOffsetNsec prop to the combine node.
This is mainly useful for BAP device sets; the property appears in
Pulseaudio UI only when the node is associated with a device.
For client-nodes that use trigger, set the signal and wakeup time when
they start the server node. Also set finish time before we resume the
peers on the server.
Client-nodes should really resume the peers directly without going
through the server but this is something to improve later.
Currently, RAOP sinks referencing the same remote ip and port may be created multiple times:
One each for IPv4 and IPv6, times the number of network interfaces used for mDNS discovery.
A recent change added `(IPv4)`and `(IPv6)`identifiers to the sinks' pretty names, however that
is misleading, as often times the service advertised through an mDNSv6 record is actually an
IPv4 service (i.e. the IP reference contained in the IPv6 record may be an IPv4 address).
With this change, sink creation is skipped if a sink with the same advertised name already exists.
Determine application executable file so that the result can be trusted,
and the file exists in the current namespace.
Don't use /proc/pid/cmdline, since that contains whatever was specified
by the exec() call.
Stop our own data-loop and enter/iterate/leave it from the jack thread.
This runs all our nodes in the JACK thread and removes 2 context
switches (jack to and from pw thread).
We can possibly do this nicer by only pushing our own streams onto a
new custom data-loop but that's for later.
Add a new JACK sink/source pair that translates to a single JACK
client.
The JACK playback port appears as PipeWire source and is processed
directly, synchronously, through the complete pipewire graph into
the PipeWire sink that is then made available on the JACK capture
ports.
Because all this happens in the same JACK cycle with no delay, the
latency is 0. A jack_iodelay on the JACK server has exactly the same
latency as the jack_iodelay on the PipeWire side.
The PipeWire sink and source are forced into the same rate and
buffer_size as the JACK server and can't dynamically change.
This only supports Audio for now.
When we consumed all the buffer data, don't clear all the fds but only
those that were already consumed in the message. It is possible that we
already have fds for the next message and we don't want to discard
those.
Fixes some intermittend memory map errors.
Calculate the stats at the start of the new cycle. The results will be
about the previous cycle but this gives more accurate results because
we can also include awake and finish times of remote nodes.
Make sure not to change the status of the activation in the ready event
so that we don't overwrite the status of the last cycle yet.
This means we can always set the AWAKE and awake_time, the remote node
might update it when triggered but that's ok.
After processing we can update the FINISHED state for non-remote nodes,
the remote nodes will update it after they complete the process
function.
Pass the ready status to the client-node using the state array.
Don't just SPA_STATUS_HAVE_DATA on the server side but use the value
from the client.
This avoids some potential extra work when a driver sink pulls in data
with the NEED_DATA ready callback but then the server performs the
actions (tee) as if it were SPA_STATUS_HAVE_DATA.
Intercept the stream volume/mute and set it as the remove volume/mute.
Listen for remote volume/mute changes and set this as the local stream
volume. Make sure the adapter is using 1.0 software volume but reports
the real channelVolume of the remote stream.
Make the XOpenDiplay call failure print an info message instead of a
warning. We usually ignore this error in the config file. Add a
suggestion for how to fix this issue in the info log.
Fixes#2918
Actually convert the aec_args argument to something that the
echo-canceler will understand. Add the beamforming and mic-geometry
and target_direction properties.
Make the channels configurable for capture, source, playback and
sink streams. The playback and sink stream need to have the same number
of channels but the layout can be different.
Use init2 of the echo-cancel plugin when available to pass this info
around. The echo-canceler will then further adjust the settings to make
things work.
The raw biquad takes its values from the config and then updates the
control ports with them in activate. At runtime, the changes to the
ports are applied to the biquad.
Other biquads take values from the config ports in activate.
