Have monitor streams not affect the latency calculation of the ports
they are connected to.
Connecting monitor streams to ports (e.g. volume level monitoring)
should not affect latency values of other streams connected to those
ports.
This fixes e.g. just running pavucontrol from modifying latencies of all
existing ports.
Add port.ignore-latency prop, which if true causes peer ports to ignore
the latency of the given port.
This is useful for ports that are not intended to affect latency
calculations of other ports, such as ports in monitor streams.
A DBusMessage needs to be unref-ed after sending it regardless
whether or not it was successfully sent. So do that in
`mm_dbus_connection_send_with_reply()` so that the callers
do not need to deal with that.
It is inherently racy, and we have a better way to ensure that
we won't autostart the service:
dbus_message_set_auto_start()
So use that.
This commit also adds a missing call to `dbus_pending_call_unref()`
and indirectly fixes a type mismatch (`dbus_bool_t` vs. `bool`)
that was present in `is_dbus_service_running()`.
The DBusError passed to `dbus_set_error_from_message()` must
be initialized, otherwise libdbus aborts:
dbus[129473]: arguments to dbus_set_error_from_message() were incorrect,
assertion "(error) == NULL || !dbus_error_is_set ((error))"
failed in file dbus-message.c line 4043.
This is normally a bug in some application using the D-Bus library.
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.
Some functions need to wait for the reply of the server before they can
complete but the JACK API does not allow us to emit notifications while
blocking a function.
Delay emiting notifications when we are in selected methods and send a
notify to an eventfd to call the queued notifications.
Fixes#3183
The trigger operation decrements the activation count on a node and
signals the eventfd when 0.
Implement pw_stream_trigger_process() with this new function.
Make the 3 types of trigger operations on a stream more explicit.
trigger: -> do node_trigger()
driver/driving -> start graph with ready callback
other: -> emit request trigger event.
Don't call into the node process directly but use the eventfd to wake up
the node.
This is slightly slower and causes some change in behaviour
because we now need to go back to the poll loop and then let the node be
scheduled.
It is however nicer to have a uniform way to wake up nodes and it
opens up some new possibilities such as scheduling nodes in their own
threads on the server.
When flushing a capture stream we move all dequeued buffers to the
queued queue for recycling. The dequeued queue is filled again when
captured buffers become available. Otherwise we might never recycle
some dequeued buffers.
Don't go through the signal_func when we need to complete the graph
or when we need to process the node, do directly to process_node.
The signal_func is really only for nodes activating peers.
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.
Only stop processing the ready callback if we are a driver and not currently
driving the graph.
Streams that use trigger will also emit the ready callback and are not
driving the graph (but also are not a driver) and should therefore be
allowed to continue to resume_node to schedule the peer nodes.
See #3184
The transport set volume call may take a long time or never complete, so
make them async to not block main loop.
Also reduce log level to info for the failed volume setting, as this is
something the user can do nothing about.
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.
Wim Taymans
Pauli Virtanen
Barnabás Pőcze
Christian Glombek