Use TX timestamps to get accurate reading of queue length and latency on
kernel + controller side.
This is new kernel BT feature, so requires kernel with the necessary
patches, available currently only in bluetooth-next/master branch.
Enabling Poll Errqueue kernel experimental Bluetooth feature is also
required for this.
Use the latency information to mitigate controller issues where ISO
streams are desynchronized due to tx problems or spontaneously when some
packets that should have been sent are left sitting in the queue, and
transmission is off by a multiple of the ISO interval. This state is
visible in the latency information, so if we see streams in a group have
persistently different latencies, drop packets to resynchronize them.
Also make corrections if the kernel/controller queues get too long, so
that we don't have too big latency there.
Since BlueZ watches the same socket for errors, and TX timestamps arrive
via the socket error queue, we need to set BT_POLL_ERRQUEUE in addition
to SO_TIMESTAMPING so that BlueZ doesn't think TX timestamps are errors.
Link: https://github.com/bluez/bluez/issues/515
Link: https://lore.kernel.org/linux-bluetooth/cover.1710440392.git.pav@iki.fi/
Link: https://lore.kernel.org/linux-bluetooth/f57e065bb571d633f811610d273711c7047af335.1712499936.git.pav@iki.fi/
Add a -P (--properties) option to create the context with custom
properties. This can be used to control the modules that are loaded, for
example when they have conditions.
Change the flag from MAPPABLE to UNMAPPABLE to ease compatibility.
Older servers with newer client will not set the flag and so memory is
mappable for the client.
Newer server will set the flag but the client will ignore it and act
like before.
gst_pad_get_current_caps may return NULL and passing that into
gst_caps_is_equal may result in fatal critical log due to the
"g_return_val_if_fail (GST_IS_CAPS (caps1)" check. Fix by checking for
NULL to avoid this.
The target.id might be needed to find existing targets.
Update the properties after setting the initial state for the node, it
is a driver for itself and the properties can make it a driving node
when the driver property is set.
This patch fixes use case, when disable_tsched is set and
api.alsa.period-size is set to value different from default quantum size.
In a such configuration, threshold needs to be set to a final value
before snd_pcm_sw_params_set_avail_min is called to get IRQs with
right timing.
Avail minimum is calculated from a threshold set in the check_position_config.
The method returned different value for threshold right before playback
started and after the playback started. Therefore threshold used in
the snd_pcm_sw_params_set_avail_min was incorrect.
Force the check_position_config to use configured values when called
from spa_alsa_prepare as this method is called when starting new playback
and the state->period_frames and the state->rate are already known.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
Without this change, playback_ready or capture_ready was called
immediately after spa_alsa_start even tho start-delay was set.
Ready function was called with not precise "nsec" value, as "nsec"
plus latency should return time when the next buffer should be played
which wasn't true as start-delay was not included.
Now the playback is started immediately when the start_delay is set.
The alsa_do_wakeup_work is still called immediately but two things can
happened. Either start-delay is smaller then max_error and *_ready
function is called immediately, or start-delay is bigger then max_error
and state->next_time will be updated to correct value.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
Alsa needs to call handler soon enough to have headroom plus threshold
frames in the buffer and not only threshold left.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
Headroom are extra samples available in alsa buffer on top of a threshold.
Its use to prefill alsa buffer with silence before the playback starts
and later its use to calculate target number of a frames in the alsa buffer
when get_status is called. Target is calculated as headroom plus
threshold, which should be smaller then buffer size to make sense.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
A spa_node has callback both on the main and data thread, which can
modify the internal state of vulkan_blit_state. Especially critical are
functions, which might drop buffers currently in use. To mitigate this
a read-write lock is used. The data thread shall try to aquire a read
lock before accessing the buffers, while the main thread has to aquire
exclusive access via a write lock before modifying the buffers.
There is no reason to use the fd to schedule process_node, we can call
it directly when we detect an underrun need to complete the cycle with
whatever data made it to the driver.
This avoids starting the graph while the process_node is running and
avoids some stuttering.
See #3937
Implement pw_impl_node_set_io() and do all the things that need to be
done in it, such as taking the clock.id, checking for driver etc.
We can then remove some code that tries to reimplement this, most
notably in the remote-node (where it was missing updates to the
target_rate and target_quantum and maybe related to #3845.
Only activate the nodes when it was not-triggered, do this check with an
atomic compare-and-swap so that we only activate a node once.
We might be able to use this later to make sure that we resume the
untriggered peer nodes when we remove a node from the graph.
The min should always be 1. We have other ways of bumping the number of
buffers to 2, like the ASYNC allocation flag which we can set if we are
also doing some async scheduling. We could make this an option later.
Otherwise, we would also allocate 2 buffers by default between the mixer
and the node, which is unnecessary.
Add link.min-buffers option to set the minimum amount of buffers to
create for links. Set this by default to 2 because we really need two
now in case the sink xruns and does async mixing.
Make this an option because in low-memory cases and when xruns are not
expected, we can set this to 1.
