My log files get completely clobbered by this; thousands of lines of:
Jan 18 18:14:44 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:15:39 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:15:39 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:16:34 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:16:34 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:17:29 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:17:29 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:18:25 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:18:25 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:19:20 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:19:20 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:20:15 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
This seems like it should be a debug log, not a notice.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/810>
When we connect Lenovo XT99 bt headset in the Ubuntu 22.04, this
headset could only work in A2DP profile, couldn't work in HFP profile
with a high chance.
This headset supports mSBC, after pulseaudio replies "+BCS:2" to
headset, we expect to receive a "AT+BCS=2\r" from the headset, but
with a high chance, it will receive 2 AT commands in a buffer like
this "AT+CHLD=?\rAT+BCS=2\r", and we also observed other 2 AT commands
in a buffer like this "AT+NREC=0\rAT+CGMI?\r".
Here we don't suppose there is only one AT command in a buffer, we
will find each command by the delimiter "\r" and handle each command
by sequence.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/804>
Looks like sbc_decode() would seldom access more than specified input length
bytes from input buffer if input length is less than expected frame size.
Fix potential access past allocated memory by checking if input contains
complete frame before calling sbc_decode()
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/781>
When bluetooth transport has both both sink and source, pulseaudio would
synchronize writing out frames with reading frames from peer to make fair
schedule of reads and writes. Pulseaudio allows two blocks of data to be sent to
peer before synchronizing writes with reads just in case that peer implements
similar write schedule.
It could happen that first blocks are still missed by peer, which would cause
pulseaudio writes to stall waiting for first frames from peer.
Fix this by allowing more data frames out until data from peer is actually
received.
Closes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1424
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/777>
Incoming RFCOMM string has extra end-of-command terminating character which
breaks both AT+BIA= and AT+BAC= parsers which only expect a comma.
This leads to error parsing last element of response in both cases and could
prevent detecting mSBC availability if mSBC codec id comes last, e.g. AT+BIA=1,2
Fix this by additionally checking for delimiters in both parsers.
Fixes: 3c63f8e6d ("backend-native: Fix stack corruption reading RFCOMM AT+BIA= response")
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/768>
Faststream backchannel decoder does not know whether incoming stream is mono or
stereo before first packet is decoded, and some devices return stereo stream.
As it is not easy to change source sample spec after source is created, use
stereo sample spec always and perform conversion if mono stream is found.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/628>
When `indicator` is initialized to `1`:
- it always succeeds the `indicator == CIND_CALL_INDICATOR` check;
- hence always calls `continue`;
- hence never reaches the end of the `while` loop where `indicator++` is
called;
- hence `indicator` never contains any other value than `1` meaning
`cind_enabled_indicators` is ever updated.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/740>
This reverts commit b05e34e092.
Now that backend-native uses a different way to get to its own
`native_backend` instance - without going through
`pa_bluetooth_discovery` - this patch can be reverted again, as nothing
outside bluez5-util is supposed to know the internals of this struct.
That's what the many functions are for which all take pointers to this
(at that point) opaque struct instead.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/740>
This removes the inverse/recursive dependency of backend-native on the
`pa_bluetooth_discovery` struct, which is supposed to be opaque outside
of `bluez5-util` in favour of the many accessor functions defined in
`bluez5-util.h`.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/740>
AT+BIA is used to enable/disable CIND indicators by Bluetooth HFP spec.
By default, all indicators are enabled on connection.
AT+BIA will configure which indicators should be disabled then,
the disabled indicators may be enabled later on again with AT+BIA.
When the connection is lost and recovered, all indicators are enabled
again. The HF will reconfigure the indicators again with an AT+BIA
command.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/631>
GST_TYPE_BITMASK is 64-bit bit mask while corresponding channel_mask in
pulseaudio is int therefore usually 32-bit. Switch to uint64_t instead
to match internal representation in gstreamer.
Fixes pulseaudio crash on ARM 32-bit when pulseaudio is compiled with
gstreamer and either LDAC or aptX support is available.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/723>
Bluetooth transport layer already allows for packets larger than mSBC frame, and
there are up to 1 + MTU / (mSBC packet size) complete frames to be decoded from
each incoming SCO packet.
Now decoder fails when there is more than one complete frame available, which
could happen if MTU size is larger than 1.5 * (mSBC packet size) = 90
Fix this by adding a loop over avialable frames, and adjust decoded buffer size
to allow decoding up to 1 + MTU / (mSBC packet size) frames at once.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/706>
The AVRCP service is known to not be connected before the A2DP transport
is, resulting in PulseAudio asking BlueZ for an initial 'Volume' value
but not getting it because the property doesn't exist.
To prevent end-users from conjecturing this to be the source of whatever
issue they're observing, demote it to a warning.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/707>
Turned out that SelectConfiguration is only used for outgoing connections, and
incoming connection from bluetooth headset using SBC codec ends up with a
bitpool as large as declared by headset. When resulting bitpool is so large that
SBC frame size plus RTP header size exceeds write MTU size, number of frames per
packet becomes zero causing crash dividing by zero in update_sink_buffer_size()
Fix this by limiting available bitpool value exposed for SBC endpoints.
Fixes: 89082cbfa ("bluetooth: a2dp dual channel SBC XQ codec configurations")
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/695>
Commit c6d6ca541 ("bluetooth/gst: Replace buffer accumulation in adapter
with direct pull") removed the `timestamp` parameter from GStreamer
transcoders due to being unused, but these should instead be propagated
to the GStreamer encoding buffers.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/494>
Bluetooth codecs should always have fixed in/output and are hence able
to have their results directly read from the codec, instead of
accumulating in a buffer asynchronously that is subsequently only read
in the transcode callback. The Bluetooth backends calling encode/decode
also expect these fixed buffer sizes.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/494>
Handling multiple threads does not come without overhead, especially
when the end-goal is to ping-pong them making the whole system run
serially. This patch rips out all that thread handling and instead
"chains" buffers to be encoded/decoded directly into the pipeline,
making them execute their work on the current thread. The resulting
buffer can be pulled out from appsink immediately without require extra
locking and signalling. While the overhead on modern systems is found
to be negligible or unnoticable, code complexity of such locking and
signalling systems is prevalent making it the main drive behind this
refactor.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/494>
Drop rtpldacpay and payload the LDAC encoded output manually in the
RTP header.
The RTP payload seems to be required as it carries the frame count
information. Right now, rtpldacpay does not add this so construct
the RTP header and payload manually.
Strangely some devices like Shanling MP4 and Sony XM3 would still
work without this while some like the Sony XM4 does not.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/689>
Change d7f95170a1 added a dependency on device
adapter pointer being valid while checking if bluetooth profile is supported by
device.
When adapter object is released, each device holding pointer to adapter being
released is notified to reset that to NULL. Since adapter objects are released
first when discovery object is unreferenced, each device will have adapter
pointer reset before the time device objects are released.
Fix observed crash by examining device adapter pointer. If it is NULL report
that device does not support any bluetooth profile instead of looking at UUIDs
supported by adapter.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/646>
Commit 7fd89e491 ("bluetooth: Try to reconnect SCO") introduces a call
to pa_msleep but failed to include the header, resulting in a:
../pulseaudio/src/modules/bluetooth/backend-native.c: In function ‘sco_acquire_cb’:
../pulseaudio/src/modules/bluetooth/backend-native.c:336:17: warning: implicit declaration of function ‘pa_msleep’ [-Wimplicit-function-declaration]
336 | pa_msleep(300);
| ^~~~~~~~~
(Un)fortunately this implicit declaration gets resolved at link-time,
otherwise the issue would have been caught sooner.
Fixes: 7fd89e491 ("bluetooth: Try to reconnect SCO")
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/651>
Check whether a Bluetooth profile is supported both by the remote device
and the local host before creating a card profile for it.
This is useful when some of the media profiles have not been registered
with bluetoothd because ex., oFono is not running and the headset
backend is not available.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/638>
The remote device list of UUIDs reflects which profiles are supported by
the remote device alone. We currently rely solely on this list to decide
if a certain card profile is supported, and thus should be created and
get connected.
This used to be accurate when the Bluetooth modules were first written,
but now BlueZ is more dynamic and local profile support can be added or
removed during runtime. The adapter's list of UUIDs is an accurate
representation of the profiles supported by the local host at a certain
moment.
This commit combines the list of UUIDs supported by remote device and
the list of UUIDs supported by the local host to determined whether a
Bluetooth profile is actually supported or not, and whether it should be
expected to get connected during device connection.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/638>
When the SCO connection is in use, if you disconnect first and then connect,
the SCO connection will occasionally fail, and the Bluetooth error code is 42
(0x2A in hexadecimal). This is usually because an error occurred when the SCO
connection was initiated, we need to try to reconnect to optimize the handling
of this problem. The log returned by the kernel is as follows:
Bluetooth: sco_connect_cfm: hcon 0000000003328902 bdaddr 40:ef:4c:0c:11:f0 status 42
Bluetooth: sco_sock_connect status is -38
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/622>
Commit f89d64b98e fixed a crash
when disabling adapters. However, now if any device is removed
ofono card is removed, even if it belongs to different device.
Add a check for the device being unlinked to our callback to fix.
Signed-off-by: Juho Hämäläinen <juho.hamalainen@jolla.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/624>
With USB Alternate Setting 3 size of HCI payload is 72 bytes which is already
larger than mSBC frame size. Largest known size of HCI payload is with USB
Alternate Setting 5 (144 bytes), make it the default SCO socket MTU.
Reserve additional space in bluetooth encoder buffer to cover this case.
Since mSBC encoder and decoder will now work with larger packet sizes, drop
assertions about MTU larger than mSBC frame size.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/617>
Try to register profile support again after RegisterProfile fails, when
BlueZ indicates no one else is implementing the profiles we are
interested in.
Ideally this would rely on a list of UUIDs supported by the profile
manager instead of the adapter, but BlueZ has no such API.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/593>
Create pa_bluetooth_profile_status_t to represent all stages an external
Bluetooth profile can go through:
0. Inactive: Initial state, no D-Bus object has been registered for
this profile yet.
1. Active: an object implementing the org.bluez.Profile1 interface has
been registered on the system bus.
2. Registering: RegisterProfile has been called.
3. Registered: RegisterProfile succeeded.
This will be useful to handle RegisterProfile failures, as well as
dynamically register and un-register a profile based on the current
active seat.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/593>
