This updates transport select to link transports together before calling
the "Select" method for each of them.
The bluetoothctl log below shows a Broadcast Sink detecting
2 streams from a source and selecting both of them. After the
first transport is acquired, the link is created and the first
transport goes active.
client/bluetoothctl
[bluetooth]# endpoint.register 00001851-0000-1000-8000-00805f9b34fb 0x06
[/local/endpoint/ep0] Auto Accept (yes/no): y
[/local/endpoint/ep0] Max Transports (auto/value): a
[/local/endpoint/ep0] Locations: 1
[/local/endpoint/ep0] Supported Context (value): 1
Capabilities:
03 01 ff 00 02 02 03 05 04 1a 00 f0 00 02 03 01
Metadata:
[bluetooth]# Endpoint /local/endpoint/ep0 registered
[bluetooth]# scan on
[bluetooth]# [NEW] Device 17:7A:80:64:A7:93 17-7A-80-64-A7-93
[17-7A-80-64-A7-93]# [NEW] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
[17-7A-80-64-A7-93]# [NEW] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# transport.select
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0 State: broadcasting
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1 State: broadcasting
[17-7A-80-64-A7-93]# transport.acquire
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
Links: /org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0 acquiring complete
[17-7A-80-64-A7-93]# Acquire successful: fd 8 MTU 40:0
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0 State: active
The btmon log shows that sync has been established with both BISes:
< HCI Command: LE Broadcast Isochronous Group Create Sync (0x08|0x006b)
BIG Handle: 0x00
BIG Sync Handle: 0x0000
Encryption: Unencrypted (0x00)
Broadcast Code[16]: 00000000000000000000000000000000
Maximum Number Subevents: 0x00
Timeout: 20000 ms (0x07d0)
Number of BIS: 2
BIS ID: 0x01
BIS ID: 0x02
> HCI Event: Command Status (0x0f) plen 4
LE Broadcast Isochronous Group Create Sync (0x08|0x006b) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19
LE Broadcast Isochronous Group Sync Estabilished (0x1d)
Status: Success (0x00)
BIG Handle: 0x00
Transport Latency: 0 us (0x000000)
NSE: 3
BN: 1
PTO: 1
IRC: 3
Maximum PDU: 40
ISO Interval: 10.00 msec (0x0008)
Connection Handle #0: 6
Connection Handle #1: 7
< HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13
Handle: 6
Data Path Direction: Output (Controller to Host) (0x01)
Data Path: HCI (0x00)
Coding Format: Transparent (0x03)
Company Codec ID: Ericsson Technology Licensing (0)
Vendor Codec ID: 0
Controller Delay: 0 us (0x000000)
Codec Configuration Length: 0
Codec Configuration[0]:
> HCI Event: Command Complete (0x0e) plen 6
LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
Status: Success (0x00)
Handle: 6
< HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13
Handle: 7
Data Path Direction: Output (Controller to Host) (0x01)
Data Path: HCI (0x00)
Coding Format: Transparent (0x03)
Company Codec ID: Ericsson Technology Licensing (0)
Vendor Codec ID: 0
Controller Delay: 0 us (0x000000)
Codec Configuration Length: 0
Codec Configuration[0]:
> HCI Event: Command Complete (0x0e) plen 6
LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
Status: Success (0x00)
Handle: 7
The second transport can then be acquired and it will go straight
to active, since the fd has already been set:
[17-7A-80-64-A7-93]# transport.acquire
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
Links: /org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
[17-7A-80-64-A7-93]# Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1 acquiring complete
[17-7A-80-64-A7-93]# Acquire successful: fd 9 MTU 40:0
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1 State: active
The transports can them be released one by one:
[17-7A-80-64-A7-93]# transport.release
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
[17-7A-80-64-A7-93]# Transport fd disconnected
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0 State: idle
[17-7A-80-64-A7-93]# Release successful
[17-7A-80-64-A7-93]# transport.release
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# Transport fd disconnected
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1 State: idle
[17-7A-80-64-A7-93]# Release successful
A Broadcast Sink might scan encrypted streams, and the user might not
know the Broadcast Code to decrypt them.
This commit adds the option to set an empty Broadcast Code when prompted
for it after transport.select, if the Code is unknown. In this case, if
the Broadcast Sink is acting as a Scan Delegator, it can ask its peer
Broadcast Assistants to provide the Code through BASS.
This makes transport.show arguments optional and in case none is given
print all configured transports:
[bluetooth]# transport.show
Transport /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/sep4/fd0
UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb)
Codec: 0x02 (2)
Media Codec: MPEG24
Object Types: MPEG-2 AAC LC
Frequencies: 48kHz
Channels: 2
Bitrate: 320000
VBR: Yes
Device: /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
State: active
Delay: 0x06a4 (1700)
Volume: 0x0059 (89)
Endpoint: /org/bluez/hci0/dev_94_XX_XX_XX_XX_XX/sep4
This adds support for entering the broadcast code on sink side. When
the user selects a transport, if the transport is encrypted, the user
will be prompted to enter the broadcast code before the process of
transport selection can continue.
If just the endpoint objects is passed to endpoint.presets then just
print it instead of the listing the presets available for the UUID:
[bluetooth]# endpoint.presets /local/endpoint/ep2
Preset 32_1_1
Configuration.#0: len 0x02 type 0x01
Configuration.Sampling Frequency: 32 Khz (0x06)
Configuration.#1: len 0x02 type 0x02
Configuration.Frame Duration: 7.5 ms (0x00)
Configuration.#2: len 0x03 type 0x04
Configuration.Frame Length: 60 (0x003c)
This exposes the 'Unselect' method for Broadcast transports. This
allows the user to terminate the sync to a specific BIS, via a 2
step process. The first step is the call to this method, which
changes the transport's state to idle, with the second step being
done by the audio server which detects this change and releases
the transport.
This exposes the 'Select' method for Broadcast transports. This
allows the user to select the desired stream when running the setup
with PipeWire since it acquires any transport that is broadcasting.
This adds support for alternative preset to be entered so when auto
accepting configuration a different preset can be selected following the
order given to endpoint.presets.
This sets the number of channels based on the locations set rather than
always hardcoding it to 3 which in certain case is incorrect and can
lead for the same location to be configured multiple times.
This adds support for naming custom presets instead of always having
just one "custom" codec preset which needs to be overwriten everytime
a new set of settings needs to be entered.
In function 'cmd_send_transport':
error: passing argument 2 of 'getpeername' from incompatible pointer
type [-Wincompatible-pointer-types]
err = getpeername(transport->sk, &addr, &optlen);
| | ^~~~~
| | |
| | struct sockaddr_iso *
note: expected 'struct sockaddr * restrict' but argument is of
type 'struct sockaddr_iso *'
To resolve the compiler warnings, cast the pointer with
(struct sockaddr *).
This fixes the usage of getpeername, introduced by 04153538aa
("client/player: Fix using unicast QoS for broadcast"), without
initializing optlen which causes the following problem:
Unable to send: Operation not permitted (1)
We are sending data to controller at wrong average rate not equal to
1 packet / SDU interval, if Transport_Latency is not an integer multiple
of SDU_Interval. The calculation currently may also give zero, so no
data gets sent.
We are sending data in bursts of num ~= Transport_Latency/SDU_Interval
packets, in hopes that possibly larger timer interval makes things more
efficient.
Fix the data rate by sending num packets every num*SDU_Interval, so that
the average data rate is correct.
Also fix use of itimerspect.it_value with TFD_TIMER_ABSTIME. The value
set previously is going to always be in the past in CLOCK_MONOTONIC so
just set it to 1.
Error: COPY_PASTE_ERROR (CWE-398): [#def95] [important]
client/player.c:1846:6: original: "qos->sync_cte_type" looks like the original copy.
client/player.c:1852:6: copy_paste_error: "sync_cte_type" in "qos->sync_cte_type" looks like a copy-paste error.
client/player.c:1852:6: remediation: Should it say "mse" instead?
1850| }
1851|
1852|-> if (qos->sync_cte_type) {
1853| bt_shell_printf("MSE %u\n", qos->mse);
1854| g_dbus_dict_append_entry(iter, "MSE", DBUS_TYPE_BYTE,
Fix function iov_append_ltv crashes because is not reallocating memory
Use util_ltv_push from util.c
[bluetooth]# [NEW] Endpoint /org/bluez/hci0/pac_bcast0
[bluetooth]# Endpoint /local/endpoint/ep0 registered
endpoint.config /org/bluez/hci0/pac_bcast0 /local/endpoint/ep0 48_4_1
[/local/endpoint/ep0] BIG (auto/value): 0
[/local/endpoint/ep0] Enter channel location (value/no): 3
=================================================================
==80806==ERROR: AddressSanitizer: heap-buffer-overflow on
address 0x60200000a8ba at pc 0x561971611e0e bp 0x7ffd45ab1f00
sp 0x7ffd45ab1ef0 WRITE of size 1 at 0x60200000a8ba thread T0
0x561971611e0d in put_u8 src/shared/util.h:254
0x561971611e0d in util_iov_push_u8 src/shared/util.c:534
0x5619715c28f0 in iov_append_ltv client/player.c:3565
0x5619715c28f0 in config_endpoint_channel_location client/player.c:3593
0x5619716226ce in bt_shell_release_prompt src/shared/shell.c:744
0x561971623087 in rl_handler src/shared/shell.c:769
util_iov_append has been recently created. This implementation
allocates new memory for the appended data, while the old
version of iov_append from client/player.c did not. This could
lead to crashes in some scenarios, such as Unicast.
Currently the minimum LC3 SDU size is set to 30B. Thus, if a source
uses the 8_1_1 config which has a SDU size of 26 the sink's capabilities
won't match and the appropriate endpoint won't be created.
Although their name matches unicast and broadcast are not actually the
same when it comes to RTN and Max Latency, so this splits their settings
into 2 presets tables and fix the values for broadcast.
Support parsing Opus (Google) A2DP vendor codec capabilities.
Transport /org/bluez/hci0/dev_B8_7B_D4_32_44_15/sep3/fd2
UUID: 0000110a-0000-1000-8000-00805f9b34fb
Codec: 0xff (255)
Media Codec: Vendor Specific A2DP Codec
Vendor ID 0x000000e0
Vendor Specific Codec ID 0x0001
Vendor Specific Data: 0x92
Vendor Specific Value (Opus [Google])
Frequencies: 48kHz
Channel modes: Stereo
Frame durations: 20 ms
Device: /org/bluez/hci0/dev_B8_7B_D4_32_44_15
State: idle
Delay: 0x0898 (2200)
Volume: 0x001e (30)
Endpoint: /org/bluez/hci0/dev_B8_7B_D4_32_44_15/sep3
This updates the input prompts for broadcast endpoint register and
config.
To register a broadcast endpoint, the user will be asked to enter
the supported stream locations and context types.
At broadcast source endpoint config, the user will provide stream
config options: The BIG that the new stream will be part of, the
stream Channel Allocation, and the metadata of the subgroup to
include the stream. These options will be used to configure the
BASE and the BIG.
The flow to create a Broadcast Source is the following:
[bluetooth]# endpoint.register 00001852-0000-1000-8000-
00805f9b34fb 0x06
[/local/endpoint/ep0] Auto Accept (yes/no): y
[/local/endpoint/ep0] Max Transports (auto/value): a
[/local/endpoint/ep0] Locations: 3
[/local/endpoint/ep0] Supported Context (value): 15
[NEW] Endpoint /org/bluez/hci0/pac_bcast0
Endpoint /local/endpoint/ep0 registered
[bluetooth]# endpoint.config /org/bluez/hci0/pac_bcast0
/local/endpoint/ep0 16_2_1
[/local/endpoint/ep0] BIG (auto/value): 1
[/local/endpoint/ep0] Enter channel location (value/no): 3
[/local/endpoint/ep0] Enter Metadata (value/no): 0x03 0x02
0x04 0x00
To create a Broadcast Sink, enter the following:
[bluetooth]# endpoint.register 00001851-0000-1000-8000-
00805f9b34fb 0x06
[/local/endpoint/ep0] Auto Accept (yes/no): y
[/local/endpoint/ep0] Max Transports (auto/value): a
[/local/endpoint/ep0] Locations: 3
[/local/endpoint/ep0] Supported Context (value): 15
[bluetooth]# scan on
[NEW] Endpoint /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/
pac_bcast0
[bluetooth]# endpoint.config
/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/pac_bcast0
/local/endpoint/ep0 16_2_1
This adds .name field to struct capabilities which is then used to form
the endpoint object path so it is easier to identify the endpoint
capabilities:
[bluetooth]# endpoint.list local
/local/endpoint/pac_snk/lc3
/local/endpoint/pac_src/lc3
/local/endpoint/bcaa/lc3
endpoint.config where taking different arguments for broadcast which is
not recommended with shell as it doesn't support such a thing.
So instead of taking different arguments for broadcast both remote and
local endpoints shall be passed but in case of broadcast source both the
remote and the local endpoint actually refer to the same endpoint
registered by bluetoothctl:
endpoint.config /org/bluez/hci0/pac_bcast0 /local/endpoint/ep2 16_2_1
If there are multiple locations, aka. multiplexing, being selected then
that should be accounted properly on the SDU size since the presets only
account for just 1 channel.
Fixes: https://github.com/bluez/bluez/issues/662
This makes use of ChannelAllocation when present on SelectProperties
dictionary which is then passed on to bluetoothd and send over as part
of Codec Configuration:
< ACL Data TX: Handle 2048 flags 0x00 dlen 109
ATT: Write Command (0x52) len 104
Handle: 0x0098 Type: ASE Control Point (0x2bc6)
Data: 0104050202060000000010020103020201030428000503010000000
6020206000000001002010302020103042800050302000000010202060000
0000100201030202010304280005030100000002020206000000001002010
302020103042800050302000000
Opcode: Codec Configuration (0x01)
Number of ASE(s): 4
ASE: #0
ASE ID: 0x05
Target Latency: Balance Latency/Reliability (0x02)
PHY: 0x02
LE 2M PHY (0x02)
Codec: LC3 (0x06)
Codec Specific Configuration: #0: len 0x02 type 0x01
Sampling Frequency: 16 Khz (0x03)
Codec Specific Configuration: #1: len 0x02 type 0x02
Frame Duration: 10 ms (0x01)
Codec Specific Configuration: #2: len 0x03 type 0x04
Frame Length: 40 (0x0028)
Codec Specific Configuration: #3: len 0x05 type 0x03
Location: 0x00000001
Front Left (0x00000001)
ASE: #1
ASE ID: 0x06
Target Latency: Balance Latency/Reliability (0x02)
PHY: 0x02
LE 2M PHY (0x02)
Codec: LC3 (0x06)
Codec Specific Configuration: #0: len 0x02 type 0x01
Sampling Frequency: 16 Khz (0x03)
Codec Specific Configuration: #1: len 0x02 type 0x02
Frame Duration: 10 ms (0x01)
Codec Specific Configuration: #2: len 0x03 type 0x04
Frame Length: 40 (0x0028)
Codec Specific Configuration: #3: len 0x05 type 0x03
Location: 0x00000002
Front Right (0x00000002)
ASE: #2
ASE ID: 0x01
Target Latency: Balance Latency/Reliability (0x02)
PHY: 0x02
LE 2M PHY (0x02)
Codec: LC3 (0x06)
Codec Specific Configuration: #0: len 0x02 type 0x01
Sampling Frequency: 16 Khz (0x03)
Codec Specific Configuration: #1: len 0x02 type 0x02
Frame Duration: 10 ms (0x01)
Codec Specific Configuration: #2: len 0x03 type 0x04
Frame Length: 40 (0x0028)
Codec Specific Configuration: #3: len 0x05 type 0x03
Location: 0x00000001
Front Left (0x00000001)
ASE: #3
ASE ID: 0x02
Target Latency: Balance Latency/Reliability (0x02)
PHY: 0x02
LE 2M PHY (0x02)
Codec: LC3 (0x06)
Codec Specific Configuration: #0: len 0x02 type 0x01
Sampling Frequency: 16 Khz (0x03)
Codec Specific Configuration: #1: len 0x02 type 0x02
Frame Duration: 10 ms (0x01)
Codec Specific Configuration: #2: len 0x03 type 0x04
Frame Length: 40 (0x0028)
Codec Specific Configuration: #3: len 0x05 type 0x03
Location: 0x00000002
Front Right (0x00000002)
