Build the filtered result into a new separate builder and copy it into
the result builder afterwards. This ensures the memory of the old
builder does not suddenly change when it gets reallocated.
The continue functions takes a builder as the argument and makes a new
builder that starts from the old builder memory. If the old builder was
dynamic, the new one will also be dynamic. Because it's a separate
builder, the memory of the old builder will not be reallocated when
extended.
This makes it possible to freely read the memory from the old builder
while we construct the result in a new builder without having to worry
about reallocating the memory of the old builder. When the new object is
completed, it can then be copied into the old builder.
Use kernel-provided packet reception timestamps to get less jitter in
packet timings. Mostly matters for ISO/SCO which have regular schedule.
A2DP (L2CAP) doesn't currently do RX timestamps in kernel, but we can as
well use the same mechanism for it.
Add configuration options for the BAP/PACS sink and source endpoint
location (= channel positions) and context settings.
Although BlueZ associates these with individual endpoints, in the PACS
spec they are actually device-global, so configure directly in monitor
settings.
Parse BAP settings in a single place, and simplify QoS customization a
bit.
Ensure the selected preset gets selected.
For all the BAP codec settings, use device settings instead of global
monitor ones.
The current BAP QoS configuration allows to register a sampling
frequency based on the configuration done using wireplumber configuration.
However, for a scenario were the user need to use a specific SDU framelength
it cannot be done as the select_bap_qos function selects the QOS based on
priority and hence it will use the best possible config rather than the user
configured.
This PR adds option to select the QoS set based on user configured value. If
the remote device doesn't have the user configured capabilities it will always
use the best priority config.
Further, this change also allows the user to set RTN, Latency, Delay QoS config
for certain use case to have controller use optimum bandwidth usage.
Below are the example configuration on setting LC3 capabilities in config file:
bluez5.bap.set_name = "48_2_1"
bluez5.bap.rtn = 5
bluez5.bap.latency = 20
bluez5.bap.delay = 40000
bluez5.framing = false
The current BAP unicast QoS configuration allows to register a sampling
frequency based on the configuration done using wireplumber configuration.
However, for a scenario were the user need to use a specific SDU framelength
it cannot be done as the select_bap_qos function selects the QoS based on
priority and hence it will use the best possible config rather than the user
configured.
This PR adds option to select the QoS set based on user configured value. If
the remote device doesn't have the user configured capabilities it will always
use the best priority config.
Further, this change also allows the user to set RTN, Latency, Delay QoS config
for certain use case to have controller use optimum bandwidth usage.
Below is the example for the options that can be configured & selected
in config file:
bluez5.bap.set_name = "48_2_1"
bluez5.bap.rtn = 5
bluez5.bap.latency = 20
bluez5.bap.delay = 40000
bluez5.framing = false
Parameter values read into a 512 byte long buffer, which is insufficient
for medium to long filter-graph parameters.
Increase the buffer to 4096 bytes to give some wiggle-room.
Parse and use DSP formats.
Redo the conversion setup when the formats changed. We usually do this
when starting the node but the formats can change while running as well.
When the builder is overflowed, we might get a NULL pod. This is a valid
situation that we need to handle because it can be used to get the
required builder buffer size.
Get the dataType field from the Buffer param. This is a mask of the
supported data types for the buffers. Pass this to the allocating node
if there is one, otherwise use MemPtr as the allocated format.
The set_format function can return 1 when the format was adjusted to the
nearest supported format so return this from the port_set_param
function.
This instructs the adapter to recheck the configured format so that it
can store the adjuted format on the converter.
Because we advertize on out ports that we support DYNAMIC data, we need
to read the data pointer directly from the buffer and only fall back to
our cache (mmaped) pointer when it is NULL.
With DYNAMIC data, the peer element (mixer-dsp) directly copies the
input data pointer into the buffer data in the processing loop in order
to avoid a memcpy when there is no mixing needed.
When there is no data and the buffer is mmapable, try to mmap it. Unmap
again when clearing the buffers.
Use the mmaped data pointer of the buffer when processing.
Prefer to let the follower allocate buffers. If we are allocating
buffers, first do use_buffers on the allocating node or else the
non-allocating node just ends up with NULL buffers.
Keep the passthrough flag up to date when we unset a port format or when
it changes.
We should only fill in the buffer data/fd when the ALLOC flag is set.
We should only take the passthrough input buffer as output when we are
in passthrough mode.
Copy the header metadata.
The audioconverter starts in Convert mode, so make sure it goes to the
None mode before we attempt to reconfigure ourselves.
Also remove the ports on audioconvert when going to None mode. This used
to somewhat work because we configured it in DSP mode without any
params, which is like None without ports.
When we construct an Enum, check if we only added 1 value and remove the
duplicate default value we added. If we added more values, promote the
choice to an enum.
