[PATCH BlueZ bluez] bap: reduce ISO sync timeout to 2s

[PATCH BlueZ bluez] bap: reduce ISO sync timeout to 2s

[Yang Li via B4 Relay]

From: Yang Li <yang.li@amlogic.com>

The ISO sync timeout was previously set to 20 seconds,
which is too long for PA sync. This could leave the userspace
flow pending for an extended period of time.

Signed-off-by: Yang Li <yang.li@amlogic.com>
---
 lib/bluetooth/bluetooth.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/bluetooth/bluetooth.h b/lib/bluetooth/bluetooth.h
index f9f22c3f7..572009e75 100644
--- a/lib/bluetooth/bluetooth.h
+++ b/lib/bluetooth/bluetooth.h
@@ -152,7 +152,7 @@ struct bt_voice {
 #define BT_ISO_QOS_BIG_UNSET	0xff
 #define BT_ISO_QOS_BIS_UNSET	0xff
 
-#define BT_ISO_SYNC_TIMEOUT	0x07d0 /* 20 secs */
+#define BT_ISO_SYNC_TIMEOUT	0x00c8 /* 2 secs */
 
 /* For an ISO Broadcaster, this value is used to compute
  * the desired Periodic Advertising Interval as a function

---
base-commit: a94f994201a69a36753abda65cc51937de9cd3e3
change-id: 20260112-iso_sync_timeout-8e3ecf43d82e

Best regards,
-- 
Yang Li <yang.li@amlogic.com>

RE: [BlueZ,bluez] bap: reduce ISO sync timeout to 2s

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1041012

---Test result---

Test Summary:
CheckPatch                    PENDING   0.25 seconds
GitLint                       PENDING   0.22 seconds
BuildEll                      PASS      20.03 seconds
BluezMake                     PASS      634.54 seconds
MakeCheck                     PASS      19.21 seconds
MakeDistcheck                 PASS      241.94 seconds
CheckValgrind                 PASS      289.19 seconds
CheckSmatch                   PASS      351.19 seconds
bluezmakeextell               PASS      181.90 seconds
IncrementalBuild              PENDING   0.33 seconds
ScanBuild                     PASS      1022.63 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH BlueZ bluez] bap: reduce ISO sync timeout to 2s

[Luiz Augusto von Dentz]

Hi Yang,

On Mon, Jan 12, 2026 at 1:42 AM Yang Li via B4 Relay
<devnull+yang.li.amlogic.com@kernel.org> wrote:
>
> From: Yang Li <yang.li@amlogic.com>
>
> The ISO sync timeout was previously set to 20 seconds,
> which is too long for PA sync. This could leave the userspace
> flow pending for an extended period of time.

I think we used 20 seconds based on the connection timeout, that said
I do wonder if 2 seconds is going to be enough given that the
advertisement window can be wider than that, specially when SID needs
to be resolved.

> Signed-off-by: Yang Li <yang.li@amlogic.com>
> ---
>  lib/bluetooth/bluetooth.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/bluetooth/bluetooth.h b/lib/bluetooth/bluetooth.h
> index f9f22c3f7..572009e75 100644
> --- a/lib/bluetooth/bluetooth.h
> +++ b/lib/bluetooth/bluetooth.h
> @@ -152,7 +152,7 @@ struct bt_voice {
>  #define BT_ISO_QOS_BIG_UNSET   0xff
>  #define BT_ISO_QOS_BIS_UNSET   0xff
>
> -#define BT_ISO_SYNC_TIMEOUT    0x07d0 /* 20 secs */
> +#define BT_ISO_SYNC_TIMEOUT    0x00c8 /* 2 secs */
>
>  /* For an ISO Broadcaster, this value is used to compute
>   * the desired Periodic Advertising Interval as a function
>
> ---
> base-commit: a94f994201a69a36753abda65cc51937de9cd3e3
> change-id: 20260112-iso_sync_timeout-8e3ecf43d82e
>
> Best regards,
> --
> Yang Li <yang.li@amlogic.com>
>
>
>


-- 
Luiz Augusto von Dentz

Re: [PATCH BlueZ bluez] bap: reduce ISO sync timeout to 2s

[Yang Li]

Hi Luiz,

> [ EXTERNAL EMAIL ]
>
> Hi Yang,
>
> On Mon, Jan 12, 2026 at 1:42 AM Yang Li via B4 Relay
> <devnull+yang.li.amlogic.com@kernel.org> wrote:
>> From: Yang Li <yang.li@amlogic.com>
>>
>> The ISO sync timeout was previously set to 20 seconds,
>> which is too long for PA sync. This could leave the userspace
>> flow pending for an extended period of time.
> I think we used 20 seconds based on the connection timeout, that said
> I do wonder if 2 seconds is going to be enough given that the
> advertisement window can be wider than that, specially when SID needs
> to be resolved.


Yes, the Core Specification defines a PA sync timeout when no PA reports 
are received for six consecutive PA intervals. In our testing across a 
wide range of devices, a PA sync timeout of around 3.6 seconds works well.

This assumes a PA interval of 500 ms, which is already a relatively 
large value. Taking into account six intervals plus the time needed to 
receive extended advertising during scanning, this timeout should cover 
most practical use cases.

I understand this is ultimately an empirical choice, and I am happy to 
adjust it based on feedback. From your experience, do you have a 
recommended timeout value?


>
>> Signed-off-by: Yang Li <yang.li@amlogic.com>
>> ---
>>   lib/bluetooth/bluetooth.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/bluetooth/bluetooth.h b/lib/bluetooth/bluetooth.h
>> index f9f22c3f7..572009e75 100644
>> --- a/lib/bluetooth/bluetooth.h
>> +++ b/lib/bluetooth/bluetooth.h
>> @@ -152,7 +152,7 @@ struct bt_voice {
>>   #define BT_ISO_QOS_BIG_UNSET   0xff
>>   #define BT_ISO_QOS_BIS_UNSET   0xff
>>
>> -#define BT_ISO_SYNC_TIMEOUT    0x07d0 /* 20 secs */
>> +#define BT_ISO_SYNC_TIMEOUT    0x00c8 /* 2 secs */
>>
>>   /* For an ISO Broadcaster, this value is used to compute
>>    * the desired Periodic Advertising Interval as a function
>>
>> ---
>> base-commit: a94f994201a69a36753abda65cc51937de9cd3e3
>> change-id: 20260112-iso_sync_timeout-8e3ecf43d82e
>>
>> Best regards,
>> --
>> Yang Li <yang.li@amlogic.com>
>>
>>
>>
>
> --
> Luiz Augusto von Dentz

Re: [PATCH BlueZ bluez] bap: reduce ISO sync timeout to 2s

[Luiz Augusto von Dentz]

[-- Attachment #1: Type: text/plain, Size: 3113 bytes --]

Hi Yang,

On Thu, Jan 15, 2026 at 4:42 AM Yang Li <yang.li@amlogic.com> wrote:
>
> Hi Luiz,
>
> > [ EXTERNAL EMAIL ]
> >
> > Hi Yang,
> >
> > On Mon, Jan 12, 2026 at 1:42 AM Yang Li via B4 Relay
> > <devnull+yang.li.amlogic.com@kernel.org> wrote:
> >> From: Yang Li <yang.li@amlogic.com>
> >>
> >> The ISO sync timeout was previously set to 20 seconds,
> >> which is too long for PA sync. This could leave the userspace
> >> flow pending for an extended period of time.
> > I think we used 20 seconds based on the connection timeout, that said
> > I do wonder if 2 seconds is going to be enough given that the
> > advertisement window can be wider than that, specially when SID needs
> > to be resolved.
>
>
> Yes, the Core Specification defines a PA sync timeout when no PA reports
> are received for six consecutive PA intervals. In our testing across a
> wide range of devices, a PA sync timeout of around 3.6 seconds works well.
>
> This assumes a PA interval of 500 ms, which is already a relatively
> large value. Taking into account six intervals plus the time needed to
> receive extended advertising during scanning, this timeout should cover
> most practical use cases.
>
> I understand this is ultimately an empirical choice, and I am happy to
> adjust it based on feedback. From your experience, do you have a
> recommended timeout value?

Actually the code define some recommended values for us to scan:

TGAP(Sync_Scan_­Interval)

320 ms

Interval between the start of adjacent synchronization scan windows

Recommended value

TGAP(Sync_Scan_­Window)

91.25 ms

Duration of Synchronization scan window

Recommended value

TGAP(Sync_Train_­Duration)

30.72 s

Duration of synchronizability mode

Required value

That said the duration seem to be only mention in the context of the
source, anyway perhaps we can use 6x320ms=1920ms(~2sec), this will
make us resolve the broadcasters a lot faster but then we need to
check in case we timeout we should try to rescan a few times.

>
> >
> >> Signed-off-by: Yang Li <yang.li@amlogic.com>
> >> ---
> >>   lib/bluetooth/bluetooth.h | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/lib/bluetooth/bluetooth.h b/lib/bluetooth/bluetooth.h
> >> index f9f22c3f7..572009e75 100644
> >> --- a/lib/bluetooth/bluetooth.h
> >> +++ b/lib/bluetooth/bluetooth.h
> >> @@ -152,7 +152,7 @@ struct bt_voice {
> >>   #define BT_ISO_QOS_BIG_UNSET   0xff
> >>   #define BT_ISO_QOS_BIS_UNSET   0xff
> >>
> >> -#define BT_ISO_SYNC_TIMEOUT    0x07d0 /* 20 secs */
> >> +#define BT_ISO_SYNC_TIMEOUT    0x00c8 /* 2 secs */
> >>
> >>   /* For an ISO Broadcaster, this value is used to compute
> >>    * the desired Periodic Advertising Interval as a function
> >>
> >> ---
> >> base-commit: a94f994201a69a36753abda65cc51937de9cd3e3
> >> change-id: 20260112-iso_sync_timeout-8e3ecf43d82e
> >>
> >> Best regards,
> >> --
> >> Yang Li <yang.li@amlogic.com>
> >>
> >>
> >>
> >
> > --
> > Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 39989 bytes --]

Re: [PATCH BlueZ bluez] bap: reduce ISO sync timeout to 2s

[Yang Li]

Hi Luiz,


> [ EXTERNAL EMAIL ]
>
> Hi Yang,
>
> On Thu, Jan 15, 2026 at 4:42 AM Yang Li <yang.li@amlogic.com> wrote:
>> Hi Luiz,
>>
>>> [ EXTERNAL EMAIL ]
>>>
>>> Hi Yang,
>>>
>>> On Mon, Jan 12, 2026 at 1:42 AM Yang Li via B4 Relay
>>> <devnull+yang.li.amlogic.com@kernel.org> wrote:
>>>> From: Yang Li <yang.li@amlogic.com>
>>>>
>>>> The ISO sync timeout was previously set to 20 seconds,
>>>> which is too long for PA sync. This could leave the userspace
>>>> flow pending for an extended period of time.
>>> I think we used 20 seconds based on the connection timeout, that said
>>> I do wonder if 2 seconds is going to be enough given that the
>>> advertisement window can be wider than that, specially when SID needs
>>> to be resolved.
>>
>> Yes, the Core Specification defines a PA sync timeout when no PA reports
>> are received for six consecutive PA intervals. In our testing across a
>> wide range of devices, a PA sync timeout of around 3.6 seconds works well.
>>
>> This assumes a PA interval of 500 ms, which is already a relatively
>> large value. Taking into account six intervals plus the time needed to
>> receive extended advertising during scanning, this timeout should cover
>> most practical use cases.
>>
>> I understand this is ultimately an empirical choice, and I am happy to
>> adjust it based on feedback. From your experience, do you have a
>> recommended timeout value?
> Actually the code define some recommended values for us to scan:
>
> TGAP(Sync_Scan_­Interval)
>
> 320 ms
>
> Interval between the start of adjacent synchronization scan windows
>
> Recommended value
>
> TGAP(Sync_Scan_­Window)
>
> 91.25 ms
>
> Duration of Synchronization scan window
>
> Recommended value
>
> TGAP(Sync_Train_­Duration)
>
> 30.72 s
>
> Duration of synchronizability mode
>
> Required value
>
> That said the duration seem to be only mention in the context of the
> source, anyway perhaps we can use 6x320ms=1920ms(~2sec), this will
> make us resolve the broadcasters a lot faster but then we need to
> check in case we timeout we should try to rescan a few times.


I understand.

In our system, the application layer has a timer to monitor whether the 
PA sync process times out. If it does, it will re-execute the scanning 
and PA sync actions.

>>>> Signed-off-by: Yang Li <yang.li@amlogic.com>
>>>> ---
>>>>    lib/bluetooth/bluetooth.h | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/lib/bluetooth/bluetooth.h b/lib/bluetooth/bluetooth.h
>>>> index f9f22c3f7..572009e75 100644
>>>> --- a/lib/bluetooth/bluetooth.h
>>>> +++ b/lib/bluetooth/bluetooth.h
>>>> @@ -152,7 +152,7 @@ struct bt_voice {
>>>>    #define BT_ISO_QOS_BIG_UNSET   0xff
>>>>    #define BT_ISO_QOS_BIS_UNSET   0xff
>>>>
>>>> -#define BT_ISO_SYNC_TIMEOUT    0x07d0 /* 20 secs */
>>>> +#define BT_ISO_SYNC_TIMEOUT    0x00c8 /* 2 secs */
>>>>
>>>>    /* For an ISO Broadcaster, this value is used to compute
>>>>     * the desired Periodic Advertising Interval as a function
>>>>
>>>> ---
>>>> base-commit: a94f994201a69a36753abda65cc51937de9cd3e3
>>>> change-id: 20260112-iso_sync_timeout-8e3ecf43d82e
>>>>
>>>> Best regards,
>>>> --
>>>> Yang Li <yang.li@amlogic.com>
>>>>
>>>>
>>>>
>>> --
>>> Luiz Augusto von Dentz
>
>
> --
> Luiz Augusto von Dentz

Re: [PATCH BlueZ bluez] bap: reduce ISO sync timeout to 2s

[Luiz Augusto von Dentz]

Hi Yang,

On Wed, Jan 21, 2026 at 2:27 AM Yang Li <yang.li@amlogic.com> wrote:
>
> Hi Luiz,
>
>
> > [ EXTERNAL EMAIL ]
> >
> > Hi Yang,
> >
> > On Thu, Jan 15, 2026 at 4:42 AM Yang Li <yang.li@amlogic.com> wrote:
> >> Hi Luiz,
> >>
> >>> [ EXTERNAL EMAIL ]
> >>>
> >>> Hi Yang,
> >>>
> >>> On Mon, Jan 12, 2026 at 1:42 AM Yang Li via B4 Relay
> >>> <devnull+yang.li.amlogic.com@kernel.org> wrote:
> >>>> From: Yang Li <yang.li@amlogic.com>
> >>>>
> >>>> The ISO sync timeout was previously set to 20 seconds,
> >>>> which is too long for PA sync. This could leave the userspace
> >>>> flow pending for an extended period of time.
> >>> I think we used 20 seconds based on the connection timeout, that said
> >>> I do wonder if 2 seconds is going to be enough given that the
> >>> advertisement window can be wider than that, specially when SID needs
> >>> to be resolved.
> >>
> >> Yes, the Core Specification defines a PA sync timeout when no PA reports
> >> are received for six consecutive PA intervals. In our testing across a
> >> wide range of devices, a PA sync timeout of around 3.6 seconds works well.
> >>
> >> This assumes a PA interval of 500 ms, which is already a relatively
> >> large value. Taking into account six intervals plus the time needed to
> >> receive extended advertising during scanning, this timeout should cover
> >> most practical use cases.
> >>
> >> I understand this is ultimately an empirical choice, and I am happy to
> >> adjust it based on feedback. From your experience, do you have a
> >> recommended timeout value?
> > Actually the code define some recommended values for us to scan:
> >
> > TGAP(Sync_Scan_­Interval)
> >
> > 320 ms
> >
> > Interval between the start of adjacent synchronization scan windows
> >
> > Recommended value
> >
> > TGAP(Sync_Scan_­Window)
> >
> > 91.25 ms
> >
> > Duration of Synchronization scan window
> >
> > Recommended value
> >
> > TGAP(Sync_Train_­Duration)
> >
> > 30.72 s
> >
> > Duration of synchronizability mode
> >
> > Required value
> >
> > That said the duration seem to be only mention in the context of the
> > source, anyway perhaps we can use 6x320ms=1920ms(~2sec), this will
> > make us resolve the broadcasters a lot faster but then we need to
> > check in case we timeout we should try to rescan a few times.
>
>
> I understand.
>
> In our system, the application layer has a timer to monitor whether the
> PA sync process times out. If it does, it will re-execute the scanning
> and PA sync actions.

You mean in bap plugin? Or something other than bap plugin short PA
sync that enumerates broadcasters? Anyway, if your system is using
something else that is besides the point, the thing is that PA short
sync shall be able to recover if the PA Sync times out.

> >>>> Signed-off-by: Yang Li <yang.li@amlogic.com>
> >>>> ---
> >>>>    lib/bluetooth/bluetooth.h | 2 +-
> >>>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/lib/bluetooth/bluetooth.h b/lib/bluetooth/bluetooth.h
> >>>> index f9f22c3f7..572009e75 100644
> >>>> --- a/lib/bluetooth/bluetooth.h
> >>>> +++ b/lib/bluetooth/bluetooth.h
> >>>> @@ -152,7 +152,7 @@ struct bt_voice {
> >>>>    #define BT_ISO_QOS_BIG_UNSET   0xff
> >>>>    #define BT_ISO_QOS_BIS_UNSET   0xff
> >>>>
> >>>> -#define BT_ISO_SYNC_TIMEOUT    0x07d0 /* 20 secs */
> >>>> +#define BT_ISO_SYNC_TIMEOUT    0x00c8 /* 2 secs */
> >>>>
> >>>>    /* For an ISO Broadcaster, this value is used to compute
> >>>>     * the desired Periodic Advertising Interval as a function
> >>>>
> >>>> ---
> >>>> base-commit: a94f994201a69a36753abda65cc51937de9cd3e3
> >>>> change-id: 20260112-iso_sync_timeout-8e3ecf43d82e
> >>>>
> >>>> Best regards,
> >>>> --
> >>>> Yang Li <yang.li@amlogic.com>
> >>>>
> >>>>
> >>>>
> >>> --
> >>> Luiz Augusto von Dentz
> >
> >
> > --
> > Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz

Re: [PATCH BlueZ bluez] bap: reduce ISO sync timeout to 2s

[Yang Li]

Hi Luiz,


> [ EXTERNAL EMAIL ]
>
> Hi Yang,
>
> On Wed, Jan 21, 2026 at 2:27 AM Yang Li <yang.li@amlogic.com> wrote:
>> Hi Luiz,
>>
>>
>>> [ EXTERNAL EMAIL ]
>>>
>>> Hi Yang,
>>>
>>> On Thu, Jan 15, 2026 at 4:42 AM Yang Li <yang.li@amlogic.com> wrote:
>>>> Hi Luiz,
>>>>
>>>>> [ EXTERNAL EMAIL ]
>>>>>
>>>>> Hi Yang,
>>>>>
>>>>> On Mon, Jan 12, 2026 at 1:42 AM Yang Li via B4 Relay
>>>>> <devnull+yang.li.amlogic.com@kernel.org> wrote:
>>>>>> From: Yang Li <yang.li@amlogic.com>
>>>>>>
>>>>>> The ISO sync timeout was previously set to 20 seconds,
>>>>>> which is too long for PA sync. This could leave the userspace
>>>>>> flow pending for an extended period of time.
>>>>> I think we used 20 seconds based on the connection timeout, that said
>>>>> I do wonder if 2 seconds is going to be enough given that the
>>>>> advertisement window can be wider than that, specially when SID needs
>>>>> to be resolved.
>>>> Yes, the Core Specification defines a PA sync timeout when no PA reports
>>>> are received for six consecutive PA intervals. In our testing across a
>>>> wide range of devices, a PA sync timeout of around 3.6 seconds works well.
>>>>
>>>> This assumes a PA interval of 500 ms, which is already a relatively
>>>> large value. Taking into account six intervals plus the time needed to
>>>> receive extended advertising during scanning, this timeout should cover
>>>> most practical use cases.
>>>>
>>>> I understand this is ultimately an empirical choice, and I am happy to
>>>> adjust it based on feedback. From your experience, do you have a
>>>> recommended timeout value?
>>> Actually the code define some recommended values for us to scan:
>>>
>>> TGAP(Sync_Scan_­Interval)
>>>
>>> 320 ms
>>>
>>> Interval between the start of adjacent synchronization scan windows
>>>
>>> Recommended value
>>>
>>> TGAP(Sync_Scan_­Window)
>>>
>>> 91.25 ms
>>>
>>> Duration of Synchronization scan window
>>>
>>> Recommended value
>>>
>>> TGAP(Sync_Train_­Duration)
>>>
>>> 30.72 s
>>>
>>> Duration of synchronizability mode
>>>
>>> Required value
>>>
>>> That said the duration seem to be only mention in the context of the
>>> source, anyway perhaps we can use 6x320ms=1920ms(~2sec), this will
>>> make us resolve the broadcasters a lot faster but then we need to
>>> check in case we timeout we should try to rescan a few times.
>>
>> I understand.
>>
>> In our system, the application layer has a timer to monitor whether the
>> PA sync process times out. If it does, it will re-execute the scanning
>> and PA sync actions.
> You mean in bap plugin? Or something other than bap plugin short PA
> sync that enumerates broadcasters? Anyway, if your system is using
> something else that is besides the point, the thing is that PA short
> sync shall be able to recover if the PA Sync times out.


Yes, the short PA sync is implemented in the bap plugin.

The application layer will initiate an LE Scan with a timeout of 3 
seconds. Once the PA sync is successful, it will create a transport and 
notify the application layer via the DBus signal. If the PA sync fails, 
it will rescan and trigger the PA sync again in the next LE Scan cycle.

>>>>>> Signed-off-by: Yang Li <yang.li@amlogic.com>
>>>>>> ---
>>>>>>     lib/bluetooth/bluetooth.h | 2 +-
>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/lib/bluetooth/bluetooth.h b/lib/bluetooth/bluetooth.h
>>>>>> index f9f22c3f7..572009e75 100644
>>>>>> --- a/lib/bluetooth/bluetooth.h
>>>>>> +++ b/lib/bluetooth/bluetooth.h
>>>>>> @@ -152,7 +152,7 @@ struct bt_voice {
>>>>>>     #define BT_ISO_QOS_BIG_UNSET   0xff
>>>>>>     #define BT_ISO_QOS_BIS_UNSET   0xff
>>>>>>
>>>>>> -#define BT_ISO_SYNC_TIMEOUT    0x07d0 /* 20 secs */
>>>>>> +#define BT_ISO_SYNC_TIMEOUT    0x00c8 /* 2 secs */
>>>>>>
>>>>>>     /* For an ISO Broadcaster, this value is used to compute
>>>>>>      * the desired Periodic Advertising Interval as a function
>>>>>>
>>>>>> ---
>>>>>> base-commit: a94f994201a69a36753abda65cc51937de9cd3e3
>>>>>> change-id: 20260112-iso_sync_timeout-8e3ecf43d82e
>>>>>>
>>>>>> Best regards,
>>>>>> --
>>>>>> Yang Li <yang.li@amlogic.com>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Luiz Augusto von Dentz
>>>
>>> --
>>> Luiz Augusto von Dentz
>
>
> --
> Luiz Augusto von Dentz

Re: [PATCH BlueZ bluez] bap: reduce ISO sync timeout to 2s

[Luiz Augusto von Dentz]

Hi Yang,

On Wed, Jan 21, 2026 at 10:28 PM Yang Li <yang.li@amlogic.com> wrote:
>
> Hi Luiz,
>
>
> > [ EXTERNAL EMAIL ]
> >
> > Hi Yang,
> >
> > On Wed, Jan 21, 2026 at 2:27 AM Yang Li <yang.li@amlogic.com> wrote:
> >> Hi Luiz,
> >>
> >>
> >>> [ EXTERNAL EMAIL ]
> >>>
> >>> Hi Yang,
> >>>
> >>> On Thu, Jan 15, 2026 at 4:42 AM Yang Li <yang.li@amlogic.com> wrote:
> >>>> Hi Luiz,
> >>>>
> >>>>> [ EXTERNAL EMAIL ]
> >>>>>
> >>>>> Hi Yang,
> >>>>>
> >>>>> On Mon, Jan 12, 2026 at 1:42 AM Yang Li via B4 Relay
> >>>>> <devnull+yang.li.amlogic.com@kernel.org> wrote:
> >>>>>> From: Yang Li <yang.li@amlogic.com>
> >>>>>>
> >>>>>> The ISO sync timeout was previously set to 20 seconds,
> >>>>>> which is too long for PA sync. This could leave the userspace
> >>>>>> flow pending for an extended period of time.
> >>>>> I think we used 20 seconds based on the connection timeout, that said
> >>>>> I do wonder if 2 seconds is going to be enough given that the
> >>>>> advertisement window can be wider than that, specially when SID needs
> >>>>> to be resolved.
> >>>> Yes, the Core Specification defines a PA sync timeout when no PA reports
> >>>> are received for six consecutive PA intervals. In our testing across a
> >>>> wide range of devices, a PA sync timeout of around 3.6 seconds works well.
> >>>>
> >>>> This assumes a PA interval of 500 ms, which is already a relatively
> >>>> large value. Taking into account six intervals plus the time needed to
> >>>> receive extended advertising during scanning, this timeout should cover
> >>>> most practical use cases.
> >>>>
> >>>> I understand this is ultimately an empirical choice, and I am happy to
> >>>> adjust it based on feedback. From your experience, do you have a
> >>>> recommended timeout value?
> >>> Actually the code define some recommended values for us to scan:
> >>>
> >>> TGAP(Sync_Scan_­Interval)
> >>>
> >>> 320 ms
> >>>
> >>> Interval between the start of adjacent synchronization scan windows
> >>>
> >>> Recommended value
> >>>
> >>> TGAP(Sync_Scan_­Window)
> >>>
> >>> 91.25 ms
> >>>
> >>> Duration of Synchronization scan window
> >>>
> >>> Recommended value
> >>>
> >>> TGAP(Sync_Train_­Duration)
> >>>
> >>> 30.72 s
> >>>
> >>> Duration of synchronizability mode
> >>>
> >>> Required value
> >>>
> >>> That said the duration seem to be only mention in the context of the
> >>> source, anyway perhaps we can use 6x320ms=1920ms(~2sec), this will
> >>> make us resolve the broadcasters a lot faster but then we need to
> >>> check in case we timeout we should try to rescan a few times.
> >>
> >> I understand.
> >>
> >> In our system, the application layer has a timer to monitor whether the
> >> PA sync process times out. If it does, it will re-execute the scanning
> >> and PA sync actions.
> > You mean in bap plugin? Or something other than bap plugin short PA
> > sync that enumerates broadcasters? Anyway, if your system is using
> > something else that is besides the point, the thing is that PA short
> > sync shall be able to recover if the PA Sync times out.
>
>
> Yes, the short PA sync is implemented in the bap plugin.
>
> The application layer will initiate an LE Scan with a timeout of 3
> seconds. Once the PA sync is successful, it will create a transport and
> notify the application layer via the DBus signal. If the PA sync fails,
> it will rescan and trigger the PA sync again in the next LE Scan cycle.

Looks like we never reached a conclusion here, or you are still with
the opinion that 2 seconds timeout is the way to go?

> >>>>>> Signed-off-by: Yang Li <yang.li@amlogic.com>
> >>>>>> ---
> >>>>>>     lib/bluetooth/bluetooth.h | 2 +-
> >>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/lib/bluetooth/bluetooth.h b/lib/bluetooth/bluetooth.h
> >>>>>> index f9f22c3f7..572009e75 100644
> >>>>>> --- a/lib/bluetooth/bluetooth.h
> >>>>>> +++ b/lib/bluetooth/bluetooth.h
> >>>>>> @@ -152,7 +152,7 @@ struct bt_voice {
> >>>>>>     #define BT_ISO_QOS_BIG_UNSET   0xff
> >>>>>>     #define BT_ISO_QOS_BIS_UNSET   0xff
> >>>>>>
> >>>>>> -#define BT_ISO_SYNC_TIMEOUT    0x07d0 /* 20 secs */
> >>>>>> +#define BT_ISO_SYNC_TIMEOUT    0x00c8 /* 2 secs */
> >>>>>>
> >>>>>>     /* For an ISO Broadcaster, this value is used to compute
> >>>>>>      * the desired Periodic Advertising Interval as a function
> >>>>>>
> >>>>>> ---
> >>>>>> base-commit: a94f994201a69a36753abda65cc51937de9cd3e3
> >>>>>> change-id: 20260112-iso_sync_timeout-8e3ecf43d82e
> >>>>>>
> >>>>>> Best regards,
> >>>>>> --
> >>>>>> Yang Li <yang.li@amlogic.com>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> --
> >>>>> Luiz Augusto von Dentz
> >>>
> >>> --
> >>> Luiz Augusto von Dentz
> >
> >
> > --
> > Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz