mirrors/pipewire
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/pipewire.git synced 2025-11-03 09:01:54 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
pipewire/spa/plugins/bluez5/iso-io.c

864 lines
22 KiB
C
Raw Normal View History

bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
/* Spa ISO I/O */
/* SPDX-FileCopyrightText: Copyright © 2023 Pauli Virtanen. */
/* SPDX-License-Identifier: MIT */
*: unify config.h handling config.h needs to be consistently included before any standard headers if we ever want to set feature test macros (like _GNU_SOURCE or whatever) inside. It can lead to hard-to-debug issues without that. It can also be problematic just for our own HAVE_* that it may define if it's not consistently made available before our own headers. Just always include it first, before everything. We already did this in many files, just not consistently.
2025-05-30 10:15:49 +01:00
#include "config.h"
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
#include <unistd.h>
#include <stddef.h>
#include <stdio.h>
#include <errno.h>
#include <limits.h>
#include <spa/support/loop.h>
#include <spa/support/log.h>
#include <spa/utils/list.h>
#include <spa/utils/string.h>
#include <spa/utils/result.h>
#include <spa/node/io.h>
#include "iso-io.h"
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
#include "media-codecs.h"
#include "defs.h"
bluez5: ensure capture target latency is uniform for an ISO group All BAP client sources in the ISO group should use same target latency, so that capture streams stay in sync.
2025-07-12 13:40:54 +03:00
#include "decode-buffer.h"
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
spa: export log topic enumerations
2023-12-23 21:07:45 +02:00
SPA_LOG_TOPIC_DEFINE_STATIC(log_topic, "spa.bluez5.iso");
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
#undef SPA_LOG_TOPIC_DEFAULT
#define SPA_LOG_TOPIC_DEFAULT &log_topic
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
#include "bt-latency.h"
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
#define IDLE_TIME (500 * SPA_NSEC_PER_MSEC)
#define EMPTY_BUF_SIZE 65536
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
#define LATENCY_PERIOD (1000 * SPA_NSEC_PER_MSEC)
#define MAX_LATENCY (50 * SPA_NSEC_PER_MSEC)
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
#define CLOCK_SYNC_AVG_PERIOD (500 * SPA_NSEC_PER_MSEC)
#define CLOCK_SYNC_RATE_DIFF_MAX 0.005
#define ISO_BUFFERING_AVG_PERIOD (50 * SPA_NSEC_PER_MSEC)
#define ISO_BUFFERING_RATE_DIFF_MAX 0.05
struct clock_sync {
/** Reference monotonic time for streams in the group */
int64_t base_time;
/** Average error for current cycle */
int64_t avg_err;
unsigned int avg_num;
/** Log rate limiting */
uint64_t log_pos;
/** Rate matching ISO clock to monotonic clock */
struct spa_bt_rate_control dll;
};
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
struct group {
struct spa_log *log;
struct spa_loop *data_loop;
struct spa_system *data_system;
struct spa_source source;
struct spa_list streams;
int timerfd;
bluez5: iso-io: get proper group id for broadcast
2023-11-12 18:24:45 +02:00
uint8_t id;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
int64_t next;
int64_t duration_tx;
int64_t duration_rx;
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
bool flush;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
bool started;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
struct clock_sync rx_sync;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
};
struct stream {
struct spa_bt_iso_io this;
struct spa_list link;
struct group *group;
int fd;
bool sink;
bool idle;
spa_bt_iso_io_pull_t pull;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
const struct media_codec *codec;
uint32_t block_size;
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
struct spa_bt_latency tx_latency;
bluez5: ensure capture target latency is uniform for an ISO group All BAP client sources in the ISO group should use same target latency, so that capture streams stay in sync.
2025-07-12 13:40:54 +03:00
struct spa_bt_decode_buffer *source_buf;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
/** Stream packet sequence number, relative to group::rx_sync */
int64_t rx_pos;
/** Current graph clock position */
uint64_t position;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
};
struct modify_info
{
struct stream *stream;
struct spa_list *streams;
};
static int do_modify(struct spa_loop *loop, bool async, uint32_t seq, const void *data, size_t size, void *user_data)
{
struct modify_info *info = user_data;
if (info->streams)
spa_list_append(info->streams, &info->stream->link);
else
spa_list_remove(&info->stream->link);
return 0;
}
static void stream_link(struct group *group, struct stream *stream)
{
struct modify_info info = { .stream = stream, .streams = &group->streams };
int res;
loop: spa_loop_invoke -> spa_loop_locked where possible When we simply need to change some state for the code executed in the loop, we can use locked() instead of invoke(). This is more efficient and avoids some context switches in the normal case.
2025-05-30 11:59:35 +02:00
res = spa_loop_locked(group->data_loop, do_modify, 0, NULL, 0, &info);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
spa_assert_se(res == 0);
}
static void stream_unlink(struct stream *stream)
{
struct modify_info info = { .stream = stream, .streams = NULL };
int res;
loop: spa_loop_invoke -> spa_loop_locked where possible When we simply need to change some state for the code executed in the loop, we can use locked() instead of invoke(). This is more efficient and avoids some context switches in the normal case.
2025-05-30 11:59:35 +02:00
res = spa_loop_locked(stream->group->data_loop, do_modify, 0, NULL, 0, &info);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
spa_assert_se(res == 0);
}
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
static int stream_silence(struct stream *stream)
{
static uint8_t empty[EMPTY_BUF_SIZE] = {0};
const size_t max_size = sizeof(stream->this.buf);
int res, used, need_flush;
size_t encoded;
stream->idle = true;
res = used = stream->codec->start_encode(stream->this.codec_data, stream->this.buf, max_size, 0, 0);
if (res < 0)
return res;
res = stream->codec->encode(stream->this.codec_data, empty, stream->block_size,
SPA_PTROFF(stream->this.buf, used, void), max_size - used, &encoded, &need_flush);
if (res < 0)
return res;
used += encoded;
if (!need_flush)
return -EINVAL;
stream->this.size = used;
return 0;
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
static int set_timeout(struct group *group, uint64_t time)
{
struct itimerspec ts;
ts.it_value.tv_sec = time / SPA_NSEC_PER_SEC;
ts.it_value.tv_nsec = time % SPA_NSEC_PER_SEC;
ts.it_interval.tv_sec = 0;
ts.it_interval.tv_nsec = 0;
return spa_system_timerfd_settime(group->data_system,
group->timerfd, SPA_FD_TIMER_ABSTIME, &ts, NULL);
}
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
static uint64_t get_time_ns(struct spa_system *system, clockid_t clockid)
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
{
struct timespec now;
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
spa_system_clock_gettime(system, clockid, &now);
return SPA_TIMESPEC_TO_NSEC(&now);
}
static int set_timers(struct group *group)
{
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
if (group->duration_tx == 0)
bluez5: bap: determine SDU interval from codec frame duration BlueZ API as BAP Server gives us the ISO interval, instead of the SDU interval, in the MediaTransport.QoS.Interval property. They are not necessarily the same. What we need is the SDU interval. The SDU interval is the interval between packets the encoder outputs, so it is determined by the codec configuration, and for LC3 is equal to the frame duration. Add codec method get_interval() that returns the correct interval, and use it in iso-io.
2024-04-01 17:26:35 +03:00
return -EINVAL;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
group->next = SPA_ROUND_UP(get_time_ns(group->data_system, CLOCK_MONOTONIC) + group->duration_tx,
group->duration_tx);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
return set_timeout(group, group->next);
}
bluez5: iso-io: drop RX data when source is not running When media-source is not running, we need to drop any RX data so that there is room in the socket buffer for the latency reporting.
2024-03-02 00:37:02 +02:00
static void drop_rx(int fd)
{
ssize_t res;
do {
res = recv(fd, NULL, 0, MSG_TRUNC | MSG_DONTWAIT);
} while (res >= 0);
}
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
static bool group_latency_check(struct group *group)
{
struct stream *stream;
int32_t min_latency = INT32_MAX, max_latency = INT32_MIN;
unsigned int kernel_queue = UINT_MAX;
spa_list_for_each(stream, &group->streams, link) {
if (!stream->sink)
continue;
if (!stream->tx_latency.enabled)
return false;
if (kernel_queue == UINT_MAX)
kernel_queue = stream->tx_latency.kernel_queue;
if (group->flush && stream->tx_latency.queue) {
spa_log_debug(group->log, "%p: ISO group:%d latency skip: flushing",
group, group->id);
return true;
}
if (stream->tx_latency.kernel_queue != kernel_queue) {
/* Streams out of sync, try to correct if it persists */
spa_log_debug(group->log, "%p: ISO group:%d latency skip: imbalance",
group, group->id);
group->flush = true;
return true;
}
}
group->flush = false;
spa_list_for_each(stream, &group->streams, link) {
if (!stream->sink)
continue;
if (!stream->tx_latency.valid)
return false;
min_latency = SPA_MIN(min_latency, stream->tx_latency.ptp.min);
max_latency = SPA_MAX(max_latency, stream->tx_latency.ptp.max);
}
if (max_latency > MAX_LATENCY) {
spa_log_debug(group->log, "%p: ISO group:%d latency skip: latency %d ms",
group, group->id, (int)(max_latency / SPA_NSEC_PER_MSEC));
group->flush = true;
return true;
}
return false;
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
static void group_on_timeout(struct spa_source *source)
{
struct group *group = source->data;
struct stream *stream;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
bool resync = false;
bool fail = false;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
uint64_t exp;
int res;
if ((res = spa_system_timerfd_read(group->data_system, group->timerfd, &exp)) < 0) {
if (res != -EAGAIN)
spa_log_warn(group->log, "%p: ISO group:%u error reading timerfd: %s",
bluez5: iso-io: get proper group id for broadcast
2023-11-12 18:24:45 +02:00
group, group->id, spa_strerror(res));
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
return;
}
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
if (!exp)
return;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
spa_list_for_each(stream, &group->streams, link) {
bluez5: iso-io: drop RX data when source is not running When media-source is not running, we need to drop any RX data so that there is room in the socket buffer for the latency reporting.
2024-03-02 00:37:02 +02:00
if (!stream->sink) {
if (!stream->pull) {
/* Source not running: drop any incoming data */
drop_rx(stream->fd);
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
continue;
bluez5: iso-io: drop RX data when source is not running When media-source is not running, we need to drop any RX data so that there is room in the socket buffer for the latency reporting.
2024-03-02 00:37:02 +02:00
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
spa_bt_latency_recv_errqueue(&stream->tx_latency, stream->fd, group->log);
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (stream->this.need_resync) {
resync = true;
stream->this.need_resync = false;
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (!group->started && !stream->idle && stream->this.size > 0)
group->started = true;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
}
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
if (group_latency_check(group)) {
spa_list_for_each(stream, &group->streams, link)
spa_bt_latency_reset(&stream->tx_latency);
goto done;
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
/* Produce output */
spa_list_for_each(stream, &group->streams, link) {
bluez: initialize variable to avoid warning
2024-04-12 18:14:54 +02:00
int res = 0;
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
uint64_t now;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
if (!stream->sink)
continue;
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
if (!group->started) {
bluez5: media-sink: resync ISO streams on playback start Resynchronize ISO streams on playback (re)start, so the stream positions are aligned immediately. This is better than relying on rate matching to correct any offsets.
2023-04-09 19:53:42 +03:00
stream->this.resync = true;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
stream->this.size = 0;
continue;
}
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (stream->this.size == 0) {
spa_log_debug(group->log, "%p: ISO group:%u miss fd:%d",
bluez5: iso-io: get proper group id for broadcast
2023-11-12 18:24:45 +02:00
group, group->id, stream->fd);
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (stream_silence(stream) < 0) {
fail = true;
continue;
}
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
now = get_time_ns(group->data_system, CLOCK_REALTIME);
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
res = spa_bt_send(stream->fd, stream->this.buf, stream->this.size,
&stream->tx_latency, now);
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (res < 0) {
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
res = -errno;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
fail = true;
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
group->flush = true;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
spa_log_trace(group->log, "%p: ISO group:%u sent fd:%d size:%u ts:%u idle:%d res:%d latency:%d..%d%sus queue:%u",
bluez5: iso-io: get proper group id for broadcast
2023-11-12 18:24:45 +02:00
group, group->id, stream->fd, (unsigned)stream->this.size,
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
(unsigned)stream->this.timestamp, stream->idle, res,
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
stream->tx_latency.ptp.min/1000, stream->tx_latency.ptp.max/1000,
stream->tx_latency.valid ? " " : "* ",
stream->tx_latency.queue);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
stream->this.size = 0;
}
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (fail)
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
spa_log_debug(group->log, "%p: ISO group:%d send failure", group, group->id);
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
bluez5: iso-io: improve latency logic If kernel socket queues for different streams get out of sync, it will mess up time alignment of different streams. If that happens, flush to resync. If total latency becomes too large, flush queue. Get accurate queue sizes from tx timestamping.
2024-05-31 20:31:59 +03:00
done:
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
/* Pull data for the next interval */
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
group->next += exp * group->duration_tx;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
spa_list_for_each(stream, &group->streams, link) {
if (!stream->sink)
continue;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (resync)
stream->this.resync = true;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
if (stream->pull) {
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
stream->idle = false;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
stream->this.now = group->next;
stream->pull(&stream->this);
} else {
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
stream_silence(stream);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
}
}
set_timeout(group, group->next);
}
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
static struct group *group_create(struct spa_bt_transport *t,
bluez5: iso-io: get BAP interval from dbus, not getsockopt For ISO server sockets, the QOS struct from getsockopt contains values with different meaning from ISO client socket. Get the values via DBus instead, which is right in both cases.
2023-04-06 23:02:44 +03:00
struct spa_log *log, struct spa_loop *data_loop, struct spa_system *data_system)
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
{
struct group *group;
bluez5: iso-io: get proper group id for broadcast
2023-11-12 18:24:45 +02:00
uint8_t id;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
bluez5: iso-io: get proper group id for broadcast
2023-11-12 18:24:45 +02:00
if (t->profile & (SPA_BT_PROFILE_BAP_SINK | SPA_BT_PROFILE_BAP_SOURCE)) {
id = t->bap_cig;
} else if (t->profile & (SPA_BT_PROFILE_BAP_BROADCAST_SINK | SPA_BT_PROFILE_BAP_BROADCAST_SOURCE)) {
id = t->bap_big;
} else {
errno = EINVAL;
return NULL;
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
group = calloc(1, sizeof(struct group));
if (group == NULL)
return NULL;
spa_log_topic_init(log, &log_topic);
bluez5: iso-io: get proper group id for broadcast
2023-11-12 18:24:45 +02:00
group->id = id;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
group->log = log;
group->data_loop = data_loop;
group->data_system = data_system;
spa_list_init(&group->streams);
group->timerfd = spa_system_timerfd_create(group->data_system,
CLOCK_MONOTONIC, SPA_FD_CLOEXEC | SPA_FD_NONBLOCK);
if (group->timerfd < 0) {
int err = errno;
free(group);
errno = err;
return NULL;
}
group->source.data = group;
group->source.fd = group->timerfd;
group->source.func = group_on_timeout;
group->source.mask = SPA_IO_IN;
group->source.rmask = 0;
spa_loop_add_source(group->data_loop, &group->source);
return group;
}
static int do_remove_source(struct spa_loop *loop, bool async, uint32_t seq,
const void *data, size_t size, void *user_data)
{
struct group *group = user_data;
if (group->source.loop)
spa_loop_remove_source(group->data_loop, &group->source);
set_timeout(group, 0);
return 0;
}
static void group_destroy(struct group *group)
{
int res;
spa_assert(spa_list_is_empty(&group->streams));
loop: spa_loop_invoke -> spa_loop_locked where possible When we simply need to change some state for the code executed in the loop, we can use locked() instead of invoke(). This is more efficient and avoids some context switches in the normal case.
2025-05-30 11:59:35 +02:00
res = spa_loop_locked(group->data_loop, do_remove_source, 0, NULL, 0, group);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
spa_assert_se(res == 0);
close(group->timerfd);
free(group);
}
treewide: mark some functions `static` These were found by enabling the "missing-declarations" warning.
2023-07-03 04:34:59 +02:00
static struct stream *stream_create(struct spa_bt_transport *t, struct group *group)
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
{
struct stream *stream;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
void *codec_data = NULL;
int block_size = 0;
struct spa_audio_info format = { 0 };
int res;
bluez5: Add LE Audio BAP broadcast source support Once Pipewire is started it will try to register a BAP broadcast source media endpoint on UUID 00001852-0000-1000-8000-00805f9b34fb if the media codec that supports BAP and the adapter indicates LE Audio is supported. When the endpoint is detected (over DBus) by Pipewire and it has a broadcast sink UUID, a new device will be created with the address 00:00:00:00:00:00. This device will be our simulated remote device. This is done because a broadcast source emitting device does not need any connection to start transmitting the audio. This device is set as connected. When the SetConfiguration DBus method is called and the spa_bt_transport structure with the profile BAP broadcast source is created we switch the device from the one read from DBus to the one created by us. This is done because in BlueZ, when the transport is created, at the Device property, BlueZ sets the adapter as the device that the transport is connected to. Here the device will have the newly created SPA_BT_PROFILE_BAP_BROADCAST_SINK profile connected. Added code that allows to create a node in the graph for a device connected to the SPA_BT_PROFILE_BAP_BROADCAST_SINK profile.
2023-07-23 22:16:17 +03:00
bool sink;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
int64_t interval, *duration;
bluez5: bap: determine SDU interval from codec frame duration BlueZ API as BAP Server gives us the ISO interval, instead of the SDU interval, in the MediaTransport.QoS.Interval property. They are not necessarily the same. What we need is the SDU interval. The SDU interval is the interval between packets the encoder outputs, so it is determined by the codec configuration, and for LC3 is equal to the frame duration. Add codec method get_interval() that returns the correct interval, and use it in iso-io.
2024-04-01 17:26:35 +03:00
if (t->profile == SPA_BT_PROFILE_BAP_SINK ||
t->profile == SPA_BT_PROFILE_BAP_BROADCAST_SINK) {
bluez5: Add LE Audio BAP broadcast source support Once Pipewire is started it will try to register a BAP broadcast source media endpoint on UUID 00001852-0000-1000-8000-00805f9b34fb if the media codec that supports BAP and the adapter indicates LE Audio is supported. When the endpoint is detected (over DBus) by Pipewire and it has a broadcast sink UUID, a new device will be created with the address 00:00:00:00:00:00. This device will be our simulated remote device. This is done because a broadcast source emitting device does not need any connection to start transmitting the audio. This device is set as connected. When the SetConfiguration DBus method is called and the spa_bt_transport structure with the profile BAP broadcast source is created we switch the device from the one read from DBus to the one created by us. This is done because in BlueZ, when the transport is created, at the Device property, BlueZ sets the adapter as the device that the transport is connected to. Here the device will have the newly created SPA_BT_PROFILE_BAP_BROADCAST_SINK profile connected. Added code that allows to create a node in the graph for a device connected to the SPA_BT_PROFILE_BAP_BROADCAST_SINK profile.
2023-07-23 22:16:17 +03:00
sink = true;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
duration = &group->duration_tx;
Fix problems found in the review of the broadcast sink support.
2023-08-22 14:53:51 +03:00
} else {
bluez5: Add LE Audio BAP broadcast source support Once Pipewire is started it will try to register a BAP broadcast source media endpoint on UUID 00001852-0000-1000-8000-00805f9b34fb if the media codec that supports BAP and the adapter indicates LE Audio is supported. When the endpoint is detected (over DBus) by Pipewire and it has a broadcast sink UUID, a new device will be created with the address 00:00:00:00:00:00. This device will be our simulated remote device. This is done because a broadcast source emitting device does not need any connection to start transmitting the audio. This device is set as connected. When the SetConfiguration DBus method is called and the spa_bt_transport structure with the profile BAP broadcast source is created we switch the device from the one read from DBus to the one created by us. This is done because in BlueZ, when the transport is created, at the Device property, BlueZ sets the adapter as the device that the transport is connected to. Here the device will have the newly created SPA_BT_PROFILE_BAP_BROADCAST_SINK profile connected. Added code that allows to create a node in the graph for a device connected to the SPA_BT_PROFILE_BAP_BROADCAST_SINK profile.
2023-07-23 22:16:17 +03:00
sink = false;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
duration = &group->duration_rx;
bluez5: Add LE Audio BAP broadcast source support Once Pipewire is started it will try to register a BAP broadcast source media endpoint on UUID 00001852-0000-1000-8000-00805f9b34fb if the media codec that supports BAP and the adapter indicates LE Audio is supported. When the endpoint is detected (over DBus) by Pipewire and it has a broadcast sink UUID, a new device will be created with the address 00:00:00:00:00:00. This device will be our simulated remote device. This is done because a broadcast source emitting device does not need any connection to start transmitting the audio. This device is set as connected. When the SetConfiguration DBus method is called and the spa_bt_transport structure with the profile BAP broadcast source is created we switch the device from the one read from DBus to the one created by us. This is done because in BlueZ, when the transport is created, at the Device property, BlueZ sets the adapter as the device that the transport is connected to. Here the device will have the newly created SPA_BT_PROFILE_BAP_BROADCAST_SINK profile connected. Added code that allows to create a node in the graph for a device connected to the SPA_BT_PROFILE_BAP_BROADCAST_SINK profile.
2023-07-23 22:16:17 +03:00
}
bluez5: replace codec->bap/asha flags with codec->kind enum Indicate codec type with enum instead of bool flags. This is in preparation of moving also HFP to media codecs.
2025-06-07 20:18:49 +03:00
if (t->media_codec->kind != MEDIA_CODEC_BAP || !t->media_codec->get_interval) {
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
res = -EINVAL;
goto fail;
}
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
res = t->media_codec->validate_config(t->media_codec, 0, t->configuration, t->configuration_len, &format);
if (res < 0)
goto fail;
bluez5: bap: determine SDU interval from codec frame duration BlueZ API as BAP Server gives us the ISO interval, instead of the SDU interval, in the MediaTransport.QoS.Interval property. They are not necessarily the same. What we need is the SDU interval. The SDU interval is the interval between packets the encoder outputs, so it is determined by the codec configuration, and for LC3 is equal to the frame duration. Add codec method get_interval() that returns the correct interval, and use it in iso-io.
2024-04-01 17:26:35 +03:00
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
codec_data = t->media_codec->init(t->media_codec, 0, t->configuration, t->configuration_len,
&format, NULL, t->write_mtu);
if (!codec_data) {
res = -EINVAL;
goto fail;
}
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
block_size = t->media_codec->get_block_size(codec_data);
if (block_size < 0 || block_size > EMPTY_BUF_SIZE) {
res = -EINVAL;
goto fail;
}
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
interval = t->media_codec->get_interval(codec_data);
if (interval <= 5000) {
res = -EINVAL;
goto fail;
}
bluez5: bap: determine SDU interval from codec frame duration BlueZ API as BAP Server gives us the ISO interval, instead of the SDU interval, in the MediaTransport.QoS.Interval property. They are not necessarily the same. What we need is the SDU interval. The SDU interval is the interval between packets the encoder outputs, so it is determined by the codec configuration, and for LC3 is equal to the frame duration. Add codec method get_interval() that returns the correct interval, and use it in iso-io.
2024-04-01 17:26:35 +03:00
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
if (*duration == 0) {
*duration = interval;
} else if (interval != *duration) {
/* SDU_Interval in ISO group must be same for each direction */
res = -EINVAL;
goto fail;
}
bluez5: bap: determine SDU interval from codec frame duration BlueZ API as BAP Server gives us the ISO interval, instead of the SDU interval, in the MediaTransport.QoS.Interval property. They are not necessarily the same. What we need is the SDU interval. The SDU interval is the interval between packets the encoder outputs, so it is determined by the codec configuration, and for LC3 is equal to the frame duration. Add codec method get_interval() that returns the correct interval, and use it in iso-io.
2024-04-01 17:26:35 +03:00
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
if (!sink) {
t->media_codec->deinit(codec_data);
codec_data = NULL;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
stream = calloc(1, sizeof(struct stream));
if (stream == NULL)
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
goto fail_errno;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
stream->fd = t->fd;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
stream->sink = sink;
stream->group = group;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
stream->this.duration = *duration;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
stream->codec = t->media_codec;
stream->this.codec_data = codec_data;
stream->this.format = format;
stream->block_size = block_size;
bluez5: update timestamping code to match kernel & bluez Update code to match the final version landed in mainline Linux 6.15
2024-05-26 12:46:31 +03:00
spa_bt_latency_init(&stream->tx_latency, t, LATENCY_PERIOD, group->log);
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (sink)
stream_silence(stream);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
stream_link(group, stream);
return stream;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
fail_errno:
res = -errno;
fail:
if (codec_data)
t->media_codec->deinit(codec_data);
errno = -res;
return NULL;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
}
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
struct spa_bt_iso_io *spa_bt_iso_io_create(struct spa_bt_transport *t,
bluez5: iso-io: get BAP interval from dbus, not getsockopt For ISO server sockets, the QOS struct from getsockopt contains values with different meaning from ISO client socket. Get the values via DBus instead, which is right in both cases.
2023-04-06 23:02:44 +03:00
struct spa_log *log, struct spa_loop *data_loop, struct spa_system *data_system)
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
{
struct stream *stream;
struct group *group;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
group = group_create(t, log, data_loop, data_system);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
if (group == NULL)
return NULL;
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
stream = stream_create(t, group);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
if (stream == NULL) {
int err = errno;
group_destroy(group);
errno = err;
return NULL;
}
return &stream->this;
}
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
struct spa_bt_iso_io *spa_bt_iso_io_attach(struct spa_bt_iso_io *this, struct spa_bt_transport *t)
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
{
struct stream *stream = SPA_CONTAINER_OF(this, struct stream, this);
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
stream = stream_create(t, stream->group);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
if (stream == NULL)
return NULL;
return &stream->this;
}
void spa_bt_iso_io_destroy(struct spa_bt_iso_io *this)
{
struct stream *stream = SPA_CONTAINER_OF(this, struct stream, this);
stream_unlink(stream);
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
spa_bt_latency_flush(&stream->tx_latency, stream->fd, stream->group->log);
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
if (spa_list_is_empty(&stream->group->streams))
group_destroy(stream->group);
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (stream->this.codec_data)
stream->codec->deinit(stream->this.codec_data);
stream->this.codec_data = NULL;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
free(stream);
}
static bool group_is_enabled(struct group *group)
{
struct stream *stream;
bluez5: iso-io: drop RX data when source is not running When media-source is not running, we need to drop any RX data so that there is room in the socket buffer for the latency reporting.
2024-03-02 00:37:02 +02:00
spa_list_for_each(stream, &group->streams, link) {
if (!stream->sink)
continue;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
if (stream->pull)
return true;
bluez5: iso-io: drop RX data when source is not running When media-source is not running, we need to drop any RX data so that there is room in the socket buffer for the latency reporting.
2024-03-02 00:37:02 +02:00
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
return false;
}
/** Must be called from data thread */
void spa_bt_iso_io_set_cb(struct spa_bt_iso_io *this, spa_bt_iso_io_pull_t pull, void *user_data)
{
struct stream *stream = SPA_CONTAINER_OF(this, struct stream, this);
bool was_enabled, enabled;
bluez5: bap: determine SDU interval from codec frame duration BlueZ API as BAP Server gives us the ISO interval, instead of the SDU interval, in the MediaTransport.QoS.Interval property. They are not necessarily the same. What we need is the SDU interval. The SDU interval is the interval between packets the encoder outputs, so it is determined by the codec configuration, and for LC3 is equal to the frame duration. Add codec method get_interval() that returns the correct interval, and use it in iso-io.
2024-04-01 17:26:35 +03:00
if (!stream->sink)
return;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
was_enabled = group_is_enabled(stream->group);
stream->pull = pull;
stream->this.user_data = user_data;
enabled = group_is_enabled(stream->group);
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
if (!enabled && was_enabled) {
stream->group->started = false;
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
set_timeout(stream->group, 0);
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
} else if (enabled && !was_enabled) {
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
set_timers(stream->group);
bluez5: output silence if no data for some ISO sinks When a sink contributing to an ISO CIG does not have data, output silence for it, as long as at least one sink in the CIG is running. Only if writes to sockets fail, pause all streams to reset synchronization. This way we write exactly the same number of packets for each CIS at the same time, which probably is the best tested configuration in BT adapters and devices. We also don't then have to pause output if some sinks are not running or miss their timing, as we generate silence on the fly. When using iso-io, have it initialize the codec instance, and have media-sink uses that instance, so that silence and actual audio are encoded with the same codec.
2023-04-09 21:28:40 +03:00
}
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
bluez5: iso-io: ensure streams are initially marked idle Mark streams idle when they are being stopped/started, so that the pause-to-sync logic always triggers when they are added.
2023-04-06 18:06:29 +03:00
stream->idle = true;
bluez5: media-sink: resync ISO streams on playback start Resynchronize ISO streams on playback (re)start, so the stream positions are aligned immediately. This is better than relying on rate matching to correct any offsets.
2023-04-09 19:53:42 +03:00
stream->this.resync = true;
bluez5: iso-io: ensure streams are initially marked idle Mark streams idle when they are being stopped/started, so that the pause-to-sync logic always triggers when they are added.
2023-04-06 18:06:29 +03:00
bluez5: add spa_bt_iso_io that does the low-level part for ISO Add factored out helper for ISO socket I/O. ISO sockets need synchronization of writes and audio position for different stream fds in the same isochronous group, and it's easier to separate out the part that coordinates it.
2023-03-25 16:58:27 +02:00
if (pull == NULL) {
stream->this.size = 0;
return;
}
}
bluez5: iso-io: track and apply corrections to tx latency 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/
2024-02-20 23:01:07 +02:00
/** Must be called from data thread */
int spa_bt_iso_io_recv_errqueue(struct spa_bt_iso_io *this)
{
struct stream *stream = SPA_CONTAINER_OF(this, struct stream, this);
struct group *group = stream->group;
return spa_bt_latency_recv_errqueue(&stream->tx_latency, stream->fd, group->log);
}
bluez5: ensure capture target latency is uniform for an ISO group All BAP client sources in the ISO group should use same target latency, so that capture streams stay in sync.
2025-07-12 13:40:54 +03:00
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
/**
* Set decode buffer used by a stream when it has packet RX. Set to NULL when stream is
* inactive.
*
* Must be called from data thread.
*/
bluez5: ensure capture target latency is uniform for an ISO group All BAP client sources in the ISO group should use same target latency, so that capture streams stay in sync.
2025-07-12 13:40:54 +03:00
void spa_bt_iso_io_set_source_buffer(struct spa_bt_iso_io *this, struct spa_bt_decode_buffer *buffer)
{
struct stream *stream = SPA_CONTAINER_OF(this, struct stream, this);
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
struct group *group = stream->group;
struct clock_sync *sync = &group->rx_sync;
spa_zero(sync->dll);
bluez5: ensure capture target latency is uniform for an ISO group All BAP client sources in the ISO group should use same target latency, so that capture streams stay in sync.
2025-07-12 13:40:54 +03:00
stream->source_buf = buffer;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
if (buffer) {
/* Take over buffer overrun handling */
buffer->no_overrun_drop = true;
buffer->buffering = false;
buffer->avg_period = ISO_BUFFERING_AVG_PERIOD;
buffer->rate_diff_max = ISO_BUFFERING_RATE_DIFF_MAX;
}
bluez5: ensure capture target latency is uniform for an ISO group All BAP client sources in the ISO group should use same target latency, so that capture streams stay in sync.
2025-07-12 13:40:54 +03:00
}
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
/**
* Get automatic group-wide stream RX target latency. This is useful only for BAP Client.
* BAP Server target latency is determined by the presentation delay.
*
* Must be called from data thread.
*/
int32_t spa_bt_iso_io_get_source_target_latency(struct spa_bt_iso_io *this)
bluez5: ensure capture target latency is uniform for an ISO group All BAP client sources in the ISO group should use same target latency, so that capture streams stay in sync.
2025-07-12 13:40:54 +03:00
{
struct stream *stream = SPA_CONTAINER_OF(this, struct stream, this);
struct group *group = stream->group;
struct stream *s;
int32_t latency = 0;
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
if (!stream->source_buf)
return 0;
bluez5: ensure capture target latency is uniform for an ISO group All BAP client sources in the ISO group should use same target latency, so that capture streams stay in sync.
2025-07-12 13:40:54 +03:00
spa_list_for_each(s, &group->streams, link)
if (s->source_buf)
latency = SPA_MAX(latency, spa_bt_decode_buffer_get_auto_latency(s->source_buf));
bluez5: iso-io: sync to ISO RX clock, align stream RX in group Align RX of streams in same ISO group: - Ensure all streams in ISO group have same target latency also for BAP Client - Determine rate matching to ISO group clock from RX times of all streams in the group - Based on this, compute nominal packet RX times, and feed them to decode-buffer instead of the real RX time. This is enough for sub-sample level sync. - Customise buffer overrun handling for ISO so that it drops data to arrive exactly at the target, for faster convergence at RX start The ISO clock matching is done based on kernel-provided packet RX times, so it has unknown offset from the actual ISO clock, probably a few ms. Current kernels (6.17) do not provide anything better to use for the clock matching, and doing it properly appears to be controller vendor-defined (if possible at all).
2025-09-07 17:04:08 +03:00
return latency;
}
/**
* Called on stream packet RX with packet monotonic timestamp.
*
* Returns the logical SDU reference time, with respect to which decode-buffer should
* target its fill level. This is needed so that all streams converge to same latency
* (with sub-sample accuracy needed for eg. stereo stream alignment).
*
* Determines the ISO group clock rate matching from individual stream packet RX times.
* Packet arrival time is decomposed to
*
* now = group::rx_sync::base_time + stream::rx_pos * group::duration_rx + err
*
* Clock rate matching is done by drifting base_time by the rate difference, so that `err`
* is zero on average across different streams. If stream's rx_pos appears to be out of
* sync, it is resynchronized to a new position.
*
* The logical SDU timestamps for different streams are aligned and occur at equal
* intervals, but the RX timestamp `now` we actually get here is a software timestamp
* indicating when packet was received by kernel. In practice, they are not equally spaced
* but are approximately aligned between different streams.
*
* The Core v6.1 specification does **not** provide any way to synchronize Controller and
* Host clocks, so we can attempt to sync to ISO clock only based on the RX timestamps.
*
* Because the actual packet RX times are not equally spaced, it's ambiguous what the
* logical SDU reference time is. It's then impossible to achieve clock synchronization with
* better accuracy than this jitter (on Intel AX210 it's several ms jitter in a regular
* pattern, plus some random noise).
*
* Aligned playback for different devices cannot be implemented with the tools provided in
* the specification. Some implementation-defined clock synchronization mechanism is
* needed, but kernel (6.17) doesn't have anything and it's not clear such vendor-defined
* mechanisms exist over USB.
*
* The HW timestamps on packets do not help with this, as they are in controller's clock
* domain. They are only useful for aligning packets from different streams. They are also
* optional in the specification and controllers don't necessarily implement them. They
* are not used here.
*
* Must be called from data thread.
*/
int64_t spa_bt_iso_io_recv(struct spa_bt_iso_io *this, int64_t now)
{
struct stream *stream = SPA_CONTAINER_OF(this, struct stream, this);
struct group *group = stream->group;
struct clock_sync *sync = &group->rx_sync;
struct stream *s;
bool resync = false;
int64_t err, t;
spa_assert(stream->source_buf);
if (sync->dll.corr == 0) {
sync->base_time = now;
spa_bt_rate_control_init(&sync->dll, 0);
}
stream->rx_pos++;
t = sync->base_time + group->duration_rx * stream->rx_pos;
err = now - t;
if (SPA_ABS(err) > group->duration_rx) {
resync = true;
spa_log_debug(group->log, "%p: ISO rx-resync large group:%u fd:%d",
group, group->id, stream->fd);
}
spa_list_for_each(s, &group->streams, link) {
if (s == stream || !s->source_buf)
continue;
if (SPA_ABS(now - s->source_buf->rx.nsec) < group->duration_rx / 2 &&
stream->rx_pos != s->rx_pos) {
spa_log_debug(group->log, "%p: ISO rx-resync balance group:%u fd:%d fd:%d",
group, group->id, stream->fd, s->fd);
resync = true;
break;
}
}
if (resync) {
stream->rx_pos = (now - sync->base_time + group->duration_rx/2) / group->duration_rx;
t = sync->base_time + group->duration_rx * stream->rx_pos;
err = now - t;
spa_log_debug(group->log, "%p: ISO rx-resync group:%u fd:%d err:%"PRIi64,
group, group->id, stream->fd, err);
}
sync->avg_err = (sync->avg_err * sync->avg_num + err) / (sync->avg_num + 1);
sync->avg_num++;
return t;
}
/**
* Call at end of stream process(), after consuming data.
*
* Apply ISO clock rate matching.
*
* Realign stream RX to target latency, if it is too far off, so that rate matching
* converges faster to alignment.
*
* Must be called from data thread
*/
void spa_bt_iso_io_check_rx_sync(struct spa_bt_iso_io *this, uint64_t position)
{
struct stream *stream = SPA_CONTAINER_OF(this, struct stream, this);
struct group *group = stream->group;
struct stream *s;
const int64_t max_err = group->duration_rx;
struct clock_sync *sync = &group->rx_sync;
int32_t target;
bool overrun = false;
double corr;
if (!stream->source_buf)
return;
/* Check sync after all input streams have completed process() on same cycle */
stream->position = position;
spa_list_for_each(s, &group->streams, link) {
if (!s->source_buf)
continue;
if (s->position != stream->position)
return;
}
target = stream->source_buf->target;
/* Rate match ISO clock */
corr = spa_bt_rate_control_update(&sync->dll, sync->avg_err, 0,
group->duration_rx, CLOCK_SYNC_AVG_PERIOD, CLOCK_SYNC_RATE_DIFF_MAX);
sync->base_time += (int64_t)(group->duration_rx * (corr - 1));
enum spa_log_level log_level = (sync->log_pos > SPA_NSEC_PER_SEC) ? SPA_LOG_LEVEL_DEBUG
: SPA_LOG_LEVEL_TRACE;
if (SPA_UNLIKELY(spa_log_level_topic_enabled(group->log, SPA_LOG_TOPIC_DEFAULT, log_level))) {
spa_log_lev(group->log, log_level,
"%p: ISO rx-sync group:%u base:%"PRIi64" avg:%g err:%"PRIi64" corr:%g",
group, group->id, sync->base_time, sync->dll.avg, sync->avg_err, corr-1);
sync->log_pos = 0;
}
sync->log_pos += stream->source_buf->duration_ns;
sync->avg_err = 0;
sync->avg_num = 0;
/* Handle overrun (e.g. resyncs streams after initial buffering) */
spa_list_for_each(s, &group->streams, link) {
if (s->source_buf) {
double level = s->source_buf->level;
int max_level = target + max_err * s->source_buf->rate / SPA_NSEC_PER_SEC;
if (level > max_level)
overrun = true;
}
}
if (!overrun)
return;
spa_list_for_each(s, &group->streams, link) {
if (!s->source_buf)
continue;
int32_t level = (int32_t)s->source_buf->level;
if (level > target) {
uint32_t drop = (level - target) * s->source_buf->frame_size;
uint32_t avail = spa_bt_decode_buffer_get_size(s->source_buf);
drop = SPA_MIN(drop, avail);
spa_log_debug(group->log, "%p: ISO overrun group:%u fd:%d level:%f target:%d drop:%u",
group, group->id, s->fd,
s->source_buf->level,
target,
drop/s->source_buf->frame_size);
spa_bt_decode_buffer_read(s->source_buf, drop);
}
spa_bt_decode_buffer_recover(s->source_buf);
}
bluez5: ensure capture target latency is uniform for an ISO group All BAP client sources in the ISO group should use same target latency, so that capture streams stay in sync.
2025-07-12 13:40:54 +03:00
}
Reference in a new issue Copy permalink