Support the low-latency variant of the aptx codec.
The magic mostly seems to be on the device side, since the stream is the
same as standard aptx, but latency is smaller even if stream/packet
sizes are the same.
Sound output latency is noticeably less than with the standard aptx.
Tested on Sennheiser HD 250 / Avantree Aria Pro.
The codec in principle also supports bidirectional duplex streams,
but that is not implemented here.
Enable SBC-XQ by default, and move it at the end of the codecs list, so
that bluez does not connect to it automatically except when it is the
codec used previously.
When the codec is disabled by quirks, it won't appear in the codecs
list, and so can't be selected by user (and so won't be connected
automatically).
However, since SelectConfiguration does not carry information which
device is in question, we cannot prevent BlueZ connecting to the codec
even if it's disabled for a specific device. If the "impossible" occurs
regardless, we won't reject the connection and the profile will be shown
as the generic "A2DP" one. If the sound is garbled, the user can select
some other profile that works.
If a log message is rate limited, we only need to know about it if we
are actually interested in that log level. We therefore add an argument
to the ratelimit_test function to set the log level of the message
printed if a message is skipped
Change-Id: I5ccd4a78bf7e972fe8b0e7133cd7e08c1e38835f
Set node.target metadata to "-1" instead of deleting it to direct nodes
to the default device.
Deleting the metadata, as done previously, does not work for nodes for
which the client has node.target set.
Handle all node.target behavior in rescan_node.
Make distinction between target nodes set in session manager via
metadata or via restore-stream; priorities are
metadata > client's node.target > restore-stream.
Allow metadata override to also remove the target node setting.
For nodes that have node.target set, when the target is not available,
media-session links them to any available node. If the target node
appears afterward, media-session would not re-link them, leading to
output being directed to wrong place (e.g. pavucontrol input monitor)
even though the intended target or a better fallback is available.
This occurs e.g. when devices are removed and re-added.
Fix this by (i) for reconnectable nodes, reconnect them if target
appears later, and (ii) for non-reconnectable nodes, raise error to the
client if node.target is set but not found (but proceed to fallback if
obj->target_node is set).
Also slightly reorganize policy-node.c:rescan_node for clarity.
Also set the driver on an inactive node when it wants a driver.
Fixes the case where xjadeo does not activate itself but still wants
to poll the transport state of the driver.
See #1491
When XDG_STATE_HOME is unset, we save in $HOME/.local/state/pipewire,
so try to first load the state file from there as well before we
try to fall back to the old XDG_CONFIG_HOME location.
Defaulting to $HOME/.local/state, this is the directory that state
information is to be kept.
As with the configuration loading, where a caller requests an absolute
path, that path will be honored, we only fall back to XDG_STATE_HOME for
relative paths.
This adds a new PIPEWIRE_STATE_DIR environment variable to override this
directory.
If a reconnecting node was linked at least once successfully, and a
re-link ends up not finding any node to link to, don't raise an error.
Instead, just unlink the node, and wait for a suitable sink to appear
later.
This fixes the issue that some Pulseaudio apps have to be restarted
if all devices go away, before they start working.
It also seems like the right thing to do, because if you remove links
manually, this does not cause errors to occur.
When `val` was used, it was always a true-ish since the
address of an array on the stack was assigned to it.
Remove this variable altogether, and use `name` directly.
Only use `name` when it is valid - when `key && value`.
`impl->default_sink` is dynamically allocated, but previously
it was not freed when the containing struct was being destroyed.
Fix that by freeing it in `session_destroy()`.
There's no particular problem to have default.configured to point to a
non-existent device, it will be ignored. This was left over when
default and configured default were made separate things.
default-nodes also doesn't need to track the id of the configured
default, so remove also other stuff that's no longer necessary. It can
simply load the values to metadata on startup, and save them to a file
when they are changed, without needing to understand what the values
mean.
Also fixes commit 7071562334 causing defaults to be forgotten when
nodes are removed.
We only want to call process() from Start when we are not a driver and
not realtime.
When we are a driver, the user will need to call _trigger_process()
to kick things of.
When we are asked to schedule process from the realtime thread, we
need to wait until the RT thread is scheduled.
In all other cases we can call _process() from the mainloop so that
the RT thread has something to collect when it gets scheduled.
When the node is driving, we need to call trigger_process()
otherwise we don't and we simply need to wait for the process() to
be called, triggered by the driver node.
See #1484
It has the DRIVER flag set and sets a PW_KEY_PRIORITY_DRIVER value
to something higher than the source so that it becomes the driver.
Every timeout it does pw_stream_drive() to start the graph, which
will eventually call the process function with a pulled buffer to
display.
The framerate is set to something lower (80ms between frames) to
show the pull effect.
fixes#1484
This method is meant for driver streams when they have data or need
data.
Previously only source (output) streams could drive the graph and
indirectly by doing pw_stream_queue_buffer(). This behaviour is now
deprecated (but will still work) in favour of calling
pw_stream_drive() explicitly.
pw_stream_drive() will call the process function immediately (if
driver) or later (when not a driver) so that the same code paths
can be used when running as a driver or not.
In a similar way, a consumer (input) driver stream can now be
written. It will call pw_stream_drive() when it wants data and the
process function will be called when the data is ready.
See #1484
We need to check the position vs the clock to see if we are currently
driving the graph. We can only call the node ready callback when
we are actually driving the graph.
