Move accounting for pending ISO packet to the reference time. Make sure
rate matching is reset on start, and reset matching on resync properly.
Allow resync on first cycle, ok since iso_io->now is valid immediately.
Silence padding larger than ISO packet may be needed for resync when
quantum is large. We can't insert silence by adding data to encoding
buffer, as the encoding buffer may be then too small and it may also be
partially filled.
Fix by inserting silence from flush_data() just before buffers would be
consumed.
Fixes ISO stream alignment at playback start.
If BlueZ doesn't reply, it may consider the operation still active.
Try to Release the transport to get to a known state.
This can happen if device doesn't respond to operations in reasonable
time and BlueZ doesn't have its own timeout which is the case for BAP
currently (which is a bug there).
Log something less confusing when connection to remote device drops
unexpectedly.
Silence logging transport Release() error in cases where the transport
was simultaneously deleted.
When using LC3-24kHz, remote device drops connection after a few seconds
if there is no sink playback. Avoid this by sending silence, one TX
packet for each RX packet, if sink hasn't been feeding data within a
timeout.
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).
Take resampler delay into account when computing the buffer fill level,
including the fractional part.
If decode-buffer is now fed nominal packet reference times in
write_packet(), it converges the total buffer + resampler latency to the
target at sub-sample accuracy.
This is needed for aligning RX of ISO streams in the same group, so that
e.g. stereo pair alignment is achieved even though the streams have
separate resamplers. Resampler phases get aligned via independent rate
matching.
The rate matching calculations are done in the system clock domain. If
the driver ticks at a different rate, the correction factor needs to be
adjusted by the rate_diff.
setup_matching() also needs to be before spa_bt_decode_buffer_process():
as follower we should use rate matching value calculated on the
*previous* cycle, because this is what driver is doing when it adjusts
it tick rate.
On production systems, having a constant high latency is favored over
dynamically adjusting it in order to optimize for low latency,
because every time a dynamic adjustment happens, there's a glitch.
This adds an option to let the user specify the exact amount of latency
they want.
The hardcoded latency of 512/<rate> is quite low on some ALSA devices.
Instead of forcing that latency onto the graph, just don't set it at all
unless it originates from the BAP presentation delay. That means that
the functionality remains the same for BAP but changes for A2DP to favor
the preferred quantum of the ALSA sink (or whatever is the driver).
Also, avoid setting an empty string ("") latency and rate in the cases
where it's not defined. This allows users to override those properties
through the wireplumber monitor rules if they need to.
Improve the spa_ump_to_midi function so that it can consume multiple UMP
messages and produce multiple midi messages.
Some UMP messages (like program changes) need to be translated into up
to 3 midi messages. Do this byt adding a state to the function and by
making it consume the input bytes, just like the spa_ump_from_midi
function.
Adapt code to this new world. This is a little API break..
Use kernel BT_PKT_SEQNUM (likely in Linux v6.17) to provide the ISO
packets sequence numbers. Fall back to counting packets if kernel is too
old to support the feature.
When we skip the CIEV event in order to update the call list with CLCC,
we may receive multiple +CLCC events or even none, if the calls are
disconnected. To avoid any mistakes, update the hfp_hf_in_progress flag
after the CLCC update is entirely done.
This removes the need to call poll() on the rfcomm socket in order
to wait for replies from the AG.
Use a queue to buffer all the commands that are to be sent to the AG
and match them to replies when they are received. Optionally associate
each command with a DBusMessage that is assumed to be a method call
from the telephony interface, which is then replied to when the rfcomm
command reply is received. Also associate each command with a state,
so that it is always deterministic what gets executed after the reply
is received.
On the telephony module, pass on the DBusMessage on the callbacks and
add a method to allow the receiver to send a reply. Only send FAILED
directly when the callback is not handled. Also, remove the return value
from the Dial() command (it was not advertised on the introspection
anyway) to make things easier.
Pass zero-length packets to the codec. BAP/ISO may use these to indicate
missing data.
Fix A2DP codecs to not parse input with spa_return_val_if_fail, that's
meant for assertions. Just return -EINVAL directly, it's normal that
input data may contain garbage.
If packet sequence number jumps ahead, or we would underflow, use
codec-provided packet loss concealment to produce some audio data.
When we produce it during underflow, skip the corresponding number of
sequence numbers of future packets.
If codec doesn't have PLC, keep the previous behavior (pad with zeros,
buffering pauses to wait for data).
LC3 and Opus have built-in support for packet loss concealment.
Add codec interface for that, and implement for LC3.
Extend media_codec interface so that packets not aligned with socket
reads can be handled, as in HFP. This is required for correct sequence
number counting, and for being able to run codec PLC *before* decoding
the next correctly received packet.
Update rate matching only once per process(). This ensures all nodes in
the group update their rate matching in the same way.
Also account for audio data in ISO output buffer in the reference time.
The calculations is in system clock domain, so when converting from
samples/duration to time rate difference should be accounted.
This does not have much effect in practice.
The rate matching calculations are done in the system clock domain. If
the driver ticks at a different rate, the correction factor needs to be
adjusted by the rate_diff.
This fixes ISO streams getting out of sync with each other when target
delay changes. This happens because typically one of them is the driver
and the other follower. Driver adjust clock rate, and follower does its
own adjustment *on top of that* so it rate matches more or less at
double speed. (The DLL of the follower to some degree corrects for
this, but can't do that when hitting RATE_CTL_DIFF_MAX and moreover it
acts with a delay.)
A2DP v1.4 uses the rfa bits for adding 5.1 and 7.1 configurations.
Clear those bits properly when sending configuration, in case remote
device sets them.
When dialing an incorrect phone number some phones (e.g. iOS 18.5)
replies with OK but never send +CIEV updates, so there's no way to
know that the dial is not in progress and the call object should be
removed.
This change waits for +CIEV event to create the call object.
Change media-source to use sco-io for HFP codecs.
Replace sco-source with media-source.
sco-source is mostly copypaste from media-source, only differed in the
IO handling.
Change media-sink to use sco-io for HFP codecs.
Move SCO fragmentation to sco-io side.
Replace sco-sink with media-sink.
sco-sink is mostly copypaste from media-sink, and only differed in the
fragmentation detail, which can as well be handled on sco-io side.
