Like the previous commit this handles `Volume` property changes but
applies them to an A2DP sink instead of source stream. As mentioned in
the AVRCP spec v1.6.2 §5.8 the rendering device (A2DP sink) is
responsible for performing volume attenuation meaning PulseAudio should
pass through audio as-is without performing any attenuation in SW.
Setting a valid pointer to `set_sink_volume` and returning `true` from
`should_attenuate_volume` attaches a hardware callback to `pa_sink` such
that no volume attenuation is performed anymore.
In addition to receiving volume change notifications it is also possible
to control remote volume by writing a new value to the DBus property.
This is especially useful when playing back to in-ear audio devices
which usually lack physical buttons to adjust the final volume on the
sink.
While software volume (used before this patch) is generally fine it is
annoying to crank it up all the way to 100% when a previous connection
to a different device left saved volume on the peer at a low volume.
Providing this bidirectional synchronization is most natural to users
who wish to use physical controls on their headphones, are used to this
from their smartphone, or aforementioned volume mismatches where both PA
as source and the peer as sink/rendering device are performing
attenutation.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/239>
HFP Audio Connection SCO configuration is negotiated symmetrically in both
directions, and USB HCI SCO packet framing is also symmetric in both directions.
This means that packet size will be the same for reads and writes over HFP SCO
socket.
HFP profile specification states that valid speech data shall exist on the
Synchronous Connection in both directions after the Audio Connection is
established.
This guarantees that an incoming packet will arrive shortly after SCO connection
is established. Use it's size to fix write MTU in case kernel value is wrong.
Discussion here https://lore.kernel.org/patchwork/patch/1303411/
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/507>
Setting these callbacks adds the HW_{VOLUME,MUTE}_CTRL flag even when
PulseAudio is solely responsible for performing attenuation whilst only
keeping the peer posted on changes. For this case the hardware callback
is not registered at all but instead a hook is attached to catch
PA_CORE_HOOK_{SINK,SOURCE}_VOLUME_CHANGED. Only when the peer performs
attenuation (the peer is in HeadSet/HandsFree role) are the callbacks
used, without touching PA software volume at all. A future change could
potentially use software volume to compensate for the extremely coarse
16 steps of volume control in HSP and HFP, and to allow volume over
100%.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/519>
Originally written for A2DP this rework of that patch enables late-bound
hardware volume control on HFP and HSP. As per the specification the
headphones (where gain control for both speaker and microphone could
happen in hardware on the peer) are supposed to send initial values for
these before the SCO connection is created; these `AT+VG[MS]` commands
are also used to determine support for it. PA uses this information in
`add_{sink,source}` to attach hardware volume callbacks, _if_ it is
supported. Otherwise PA performs the attenuation in software.
Unfortunately headphones like the WH-1000XM3's connect to A2DP
initially and only send `AT+VGS` (microphone hardware gain is not
supported) _during_ SCO connection when the user switches to the HFP
profile afterwards; the callbacks set up dynamically in
`rfcomm_io_callback` are written after the sink and source have been
created (`add_{sink,source}`), leaving them without hardware volume
callbacks and with software volume when adjusted on the PA side. (The
headphones can still send volume updates resulting in abrupt changes if
software and peer volume differ. Furthermore the same attenuation is
applied twice - once in PA software, once on the peer).
To solve this problem we simply check whether the callbacks have been
attached whenever the peer sends a volume change, and if not attach the
callbacks to the sink/source and reset software volume.
Fixes: d510ddc7f ("bluetooth: Perform software attenuation until HF/HS reports gain control")
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/528>
HF/HS hardware attenuation is optional on HFP: the peer indicates
support with the AT+BRSF command, when bit 4 is set. That does not
explicitly mandate speaker or microphone gain control; either is
dynamically detected as soon as `AT+VG[MS]=` is received. Otherwise
software attenuation is performed.
It is also optional on HSP but nothing is mentioned about feature
detection, assume it is the same as HFP: perform software attenuation
until the HF/HS peer sends an `AT+VG[MS]=` command.
When PA is a HS/HF (and the peer the AG) we attenuate both channels in
software and unconditionally keep the peer up to date with
`AT+VGM/AT+VGS` commands.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/521>
Generalize the distinction between local and peer-attenuated volumes
into a function, paving the way for future changes where this needs to
be checked in more places and when A2DP Absolute Volume support is
added.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/521>
Sink and source naming is more generic when dealing with audio that is
directional in the sense that it either goes to or comes from the other
device, but not necessarily a microphone or speaker. A concrete example
is the swapped meaning when the current device is in the HeadSet
profile. The incoming audio can come from any source, not necessarily a
microphone. Likewise, audio captured by the microphone of the headset is
not necessarily played back by a speaker on the AG, it is merely acting
as a sink for the data: further handling is irrelevant to the naming.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/521>
For the upcoming A2DP AVRCP Absolute Volume feature the code in BlueZ5
has to be generic to be reusable. Move this conversion so that it
becomes possible to implement A2DP volume - which uses different values
- on top without duplicating existing callback functionality.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/521>
When HFP HF support is enabled in native backend, peer HFP HF profile connection
is preferred over same peer HSP HS profile connection if peer supports both
profiles.
Enforce the preference by rejecting HSP HS profile connections from such peer.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/491>
Native backend implements HFP AG but not HFP HF yet, therefore headset=auto
functionality is still needed if HFP HF is required.
To make headset=auto work again, drop both HFP AG and HSP AG roles while
performing handover from native backend when oFono is detected running.
While at it, restore profile description to Headset Head Unit (HSP/HFP)
to note that HFP may be still provided via oFono backend.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/491>
When all headsets supported both HSP and HFP, life was good and we
only needed to implement HSP in the native backend. Unfortunately
some headsets have started supporting HFP only. Unfortuantely, we
can't simply switch to HFP only because that might break older HSP
only headsets meaning we need to support both HSP and HFP separately.
This patch separates them from a joint profile to being two separate
ones. The older one retains the headset_head_unit name, meaning any
saved parameters will still select this (keeping us backward
compatible). It also introduces a new headset_handsfree.
For headsets that support both HSP and HFP, the two profiles will
become separately visible and selectable. This will only matter once
we start adding features to HFP that HSP can't support (like wideband
audio).
Signed-off-by: <James.Bottomley@HansenPartnership.com>
---
v6:
- merge profile switching fixes patch from Rodrigo Araujo
v5:
- rename option to enable_native_hfp_hf
- don't call profile_done for HFP_HF unless it was initialised
v3:
- Update for PA 11.0
v2:
- fold in review feedback
- add global disable option for not registering HFP
v3:
- change parameter to enable_profile_hfp
- update device_supports_profile to be aware of hfp/hsp exclusivity
- change parameter to enable_profile_hfp_hf
bluetooth: separate HSP and HFP (to me merged with this patch)
Hi.
First, just to say that your patches are going great. Finally I can use
the microphone of my HFP only headset (a version of a Bluedio T2+).
So far, I've only encontered one problem: the auto_switch option of
module_bluetooth_policy stops working. Dug through the code and I think
you missed a few spots were you have to hangle the new headset_handsfree
profile in module_bluetooth_policy.c
Applying the following after applying your v5 patches fixed the issue
for me, now when I start making a VOIP call the profile switches to
headset_handsfree and the mic works automatically, and when the call
finishes it reverts back to a2dp.
Thanks and best regards.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/491>
The PA_BLUETOOTH_PROFILE names should mirror the PA_BLUETOOTH_UUID
names using profile_function instead of randomly made up names. Fix
this with the transformation:
PA_BLUETOOTH_PROFILE_HEADSET_HEAD_UNIT -> PA_BLUETOOTH_PROFILE_HSP_HS
PA_BLUETOOTH_PROFILE_HEADSET_AUDIO_GATEWAY -> PA_BLUETOOTH_PROFILE_HFP_AG
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---
v4: update for PA 11.0
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/491>
Bluetooth thread may ask encoder to reduce bitrate if writing is not keeping up
with inputs or writing to bluetooth socket takes too much time.
Assuming conditions leading to reduced bitrate are intermittent, allow periodic
attempts to increase encoder bitrate, by default at most twice per second.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/481>
When it comes to codecs provided via GStreamer, we register all codecs
if GStreamer option is enabled for bluez5 via meson. However, the
GStreamer plugin required for the codec might not be present on the
system. This results in the codec being available for registration with
the bluez stack or selection by the user, but, trying to use the said
codec then fails.
To prevent the above, we now use the can_be_supported codec API to check
if the codec is usable and if not, we do not register the said codec and
also prevent users from switching to it.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/440>
For example, using the following on the command line will return the
current codec for a bluetooth device
pacmd send-message /card/bluez_card.4C_BC_98_80_01_9B/bluez get-codec
where 4C_BC_98_80_01_9B is the bluetooth device.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/440>
This exposes the currently active codec on the source or sink via the
proplist and can be seen in output of pacmd list-sinks/list-sources.
Also set it on the card. In case of a bi-directional codec, the codec
for the sink and source could be different. For example, for aptX-LL,
the codec name on card, sink and source would be aptx-ll, aptx and sbc
respectively.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/440>
For example, using the following on the command line will return the
list of possible codecs for a bluetooth device
pacmd send-message /card/bluez_card.4C_BC_98_80_01_9B/bluez list-codecs
where 4C_BC_98_80_01_9B is the bluetooth device.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/440>
This uses the messaging API to initiate a codec switch.
While a particular codec might be applicable only for a particular
profile, for eg. aptX can only be applicable for A2DP sink or source
and not for let's say HSP, the codec switching logic has not been
tied to the logic for switching profiles.
Codec can be switched by running the following on the command line.
pacmd send-message /card/bluez_card.XX_XX_XX_XX_XX_XX/bluez switch-codec{"ldac_hq"}
pacmd send-message /card/bluez_card.XX_XX_XX_XX_XX_XX/bluez switch-codec {"ldac_mq"}
pacmd send-message /card/bluez_card.XX_XX_XX_XX_XX_XX/bluez switch-codec {"ldac_sq"}
pacmd send-message /card/bluez_card.XX_XX_XX_XX_XX_XX/bluez switch-codec {"aptx_hd"}
pacmd send-message /card/bluez_card.XX_XX_XX_XX_XX_XX/bluez switch-codec {"aptx"}
pacmd send-message /card/bluez_card.XX_XX_XX_XX_XX_XX/bluez switch-codec {"sbc"}
Codec name passed above is matched against pa_a2dp_codec->name. Note that
the match is case sensitive. XX_XX_XX_XX_XX_XX needs to be substituted with
the actual bluetooth device id.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/440>
Since commit ad447d1468 (in 2009) pa_read and pa_write take care of
handling EINTR error.
So, pa_read, pa_write, pa_iochannel_read and pa_iochannel_write can not
exit with errno set to EINTR, and testing it is useless.
Add explanation why minimal bitpool value is used in SBC codec as initial
bitpool value for A2DP source.
Set buffer size for reading/writing from/to A2DP socket to exact link MTU
value. This would ensure that A2DP codec does not produce larger packet as
maximal possible size which can be sent.
Because A2DP socket is of SOCK_SEQPACKET type, it is guaranteed that
we do not read two packets via one read/recvmsg call.
Properly check for all return values of encode/encode methods of A2DP codec
functions. They may fail at different levels. Also encode or decode API
method may return zero length buffer (e.g. because of algorithmic delay of
codec), so do not fail in this case.
setup_stream() crashes when calling set_nonblock() with an invalid
stream_fd.
On a new call, the ofono backend gets notified of a new connection.
The ofono backend sets the transport state to playing, and that triggers
a profile change, which sets up the stream for the first time.
Then module-bluetooth-policy sets up the loopbacks. The loopbacks get
fully initialized before the crash.
After module-bluetooth-policy has done its things, the execution
continues in the transport state change hook. The next hook user is
module-bluez5-device, whose handle_transport_state_change() function
gets called. It will then set up the stream again even though it's
already set up. I'm not sure if that's a some kind of a bug.
setup_stream() can handle the case where it's unnecessarily called,
though, so this second setup is not a big problem.
The crash happens, because the connection died due to POLLHUP in the IO
thread before the second setup_stream() call.
This patch introduce new modular API for bluetooth A2DP codecs. Its
benefits are:
* bluez5-util and module-bluez5-device does not contain any codec specific
code, they are codec independent.
* For adding new A2DP codec it is needed just to adjust one table in
a2dp-codec-util.c file. All codec specific functions are in separate
codec file.
* Support for backchannel (microphone voice). Some A2DP codecs (like
FastStream or aptX Low Latency) are bi-directional and can be used for
both music playback and audio call.
* Support for more configurations per codec. This allows to implement low
quality mode of some codec together with high quality.
Current SBC codec implementation was moved from bluez5-util and
module-bluez5-device to its own file and converted to this new A2DP API.
If one device tries to use PulseAudio to send audio over A2DP to another
device with bluez-alsa, that doesn't work because PulseAudio uses an
incorrect RTP payload type and bluez-alsa checks that the RTP payload
type is correct. According to the A2DP spec, the payload type should be
set to a number between 96 and 127.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/591
This should make it easier for clients to elevate their audio threads to
real time priority without having to dig through much through specific
system internals.
