This allows to connect the SCO link with old HFP AG devices which
doesn't support the codec negotiation.
The audio connection could be done even without an ongoing call.
When the Bluetooth earphones claim to support AAC `MPEG-2 AAC LC` type only,
PipeWire encodes audio using MPEG-4 FDK-AAC profile which enables unsupported
Perceptual Noise Substitution (PNS) encoder feature.
Use AOT_MP2_AAC_LC pseudo-profile which is AOT_AAC_LC with PNS disabled.
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.
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.
Including C headers inside of `extern "C"` breaks use from C++. Hoist
the includes of standard C headers above the block so we don't try
to mangle the stdlib.
I initially tried to scope this with a targeted change but it's too
hard to do correctly that way. This way, we avoid whack-a-mole.
Firefox is working around this in their e21461b7b8b39cc31ba53c47d4f6f310c673ff2f
commit.
Bug: https://bugzilla.mozilla.org/1953080
There is no need to encode the potential format in the format.dsp of
control ports, this is just for legacy compatibility with JACK apps. The
actual format can be negotiated with the types field.
Fixes midi port visibility with apps compiled against 1.2, such as JACK
apps in flatpaks.
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.
Use TX timestamping to figure out the accurate amount of unsent data,
including controller buffers. SIOCOUTQ does not report accurate data
size as it includes overheads.
Now that we have ASHA & BAP, this->device_set now refers to the device
set of the active profile. It cannot be used to produce
EnumProfile/EnumRoute.
Fix this by computing the device set for given profile(s) as needed.
3-way incoming calls are created in waiting state. When those calls are
hang-up before being active, the +CIEV: (callsetup = 0) should also be
managed for waiting calls.
One of the ideas behind retrying the sending of a failed packet with the
poll callback was to make sure that we do not end up with missing seqnums
by missing received credit due to some jitter.
However, the rate matching behaviour for ASHA is not clear and we do not
seem to face problems in local testing by just dropping the packet.
The two sides of a ASHA pair rarely if ever start together and the
sequence number was always a bit off due to the stateful nature of
reset_buffer and ASHA needing the sequence number to be matched to
the other side.
Simplify this by setting the sequence number for ASHA just before
flushing.
Set different icons for A2DP & HFP output routes, so that they look
different (in Gnome).
Don't call the non-HFP output route as "headset" or "handsfree" in this
case, to be less ambiguous about microphone availability.
Also set device.icon-name for the device too.
While ASHA does not really use the D-Bus device set interface
but since ASHA has a device-wide HiSyncId and needs to handle
left and right side via a combine sink, use the device set
notion for ASHA as well.
Let's just directly use the next timer value from the other side
directly, and the reference time as well to calculate the expected next
sample position we want to send from on this side.
For ASHA stereo, the timer for flushing packets on both sides of a
pair should be as closed to each other as possible.
Also set seqnum before first flush so other side sends the correct
packets at the start.
In ASHA, we might need to sync sequence numbers between
left and right side media sink. If the sequence number
is added in start encode, it becomes difficult to set
the sequence number again when a call to reset_buffer
in media sink might have happened already.
This effectively reverts commit ab5f81b9a.
ASHA devices with the same HiSyncId are a pair and this
will be used later on to set them up together with a
combine sink like device set for BAP. Side information
is required for channel information when setting up the
combine sink.
The +BCS event may interrupt any of the initialization commands after
SLC is established and by changing the state here we may lose track
of the initialization sequence.
There is no reason to have the hfp_hf_bcs state anyway. If the
initialization sequence is over, we can remain in the hfp_hf_vgm state.
Print the error in td->err (the SO_ERROR) or else let the user know
this is a regular hangup. The previous printout was always reporting
EAGAIN (remainder in errno from the event loop code, I suppose)
as an error, without any real data.
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
