eSCO latency configuration

eSCO latency configuration

[Arnaud Mouiche]

Hi,

I was surprised to not see a possibility to configure the latency used 
for (e)SCO connection during creation or accept phase.

the kernel code shows simply this (in any git repo I check)

net/bluetooth/hci_conn.c: hci_setup_sync()

164 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l164> 
void hci_setup_sync(struct hci_conn *conn, __u16 handle)
165 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l165> 
{
166 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l166> 
         struct hci_dev *hdev = conn->hdev;
167 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l167> 
         struct hci_cp_setup_sync_conn cp;
168 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l168> 

169 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l169> 
         BT_DBG("%p", conn);
170 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l170> 

171 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l171> 
         conn->state = BT_CONNECT;
172 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l172> 
         conn->out = 1;
173 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l173> 

174 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l174> 
         conn->attempt++;
175 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l175> 

176 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l176> 
         cp.handle   = cpu_to_le16(handle);
177 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l177> 
         cp.pkt_type = cpu_to_le16(conn->pkt_type);
178 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l178> 

179 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l179> 
         cp.tx_bandwidth   = cpu_to_le32(0x00001f40);
180 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l180> 
         cp.rx_bandwidth   = cpu_to_le32(0x00001f40);
181 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l181> 
         cp.max_latency    = cpu_to_le16(0xffff); <<<<<< static 
configuration
182 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l182> 
         cp.voice_setting  = cpu_to_le16(hdev->voice_setting);
183 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l183> 
         cp.retrans_effort = 0xff;
184 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l184> 

185 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l185> 
         hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
186 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l186> 
}
187 
<http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=blob;f=net/bluetooth/hci_conn.c;h=ea7f031f3b04607efc65e79ab061dd0c5cb9337c;hb=refs/heads/master#l187> 




What could be a way to add the feature without breaking any API
1) use the MTU of the socket or hdev ?
2) add hdev entry for sco latency (which can be configured with 
hciconfig like voice settings)
3) something else ...
or
4) no one cares about latency...

PS: the same way, the retransmit effort is not configurable today.

regards,
arnaud

Re: eSCO latency configuration

[Johan Hedberg]

Hi Arnaud,

On Mon, Sep 05, 2011, Arnaud Mouiche wrote:
> What could be a way to add the feature without breaking any API
> 1) use the MTU of the socket or hdev ?
> 2) add hdev entry for sco latency (which can be configured with
> hciconfig like voice settings)
> 3) something else ...
> or
> 4) no one cares about latency...
> 
> PS: the same way, the retransmit effort is not configurable today.

I'm assuming this is for HFP or HSP? At least I'm not aware of other
significant profiles using (e)SCO. Since the HFP specification defines a
set of recommended parameter combinations I don't think we necessarily
need any user-space facing interface for this (with the exception of the
mSBC/CVSD codec selection which is needed for HFP 1.6).

Instead, the kernel could simply start with the S3 settings and fall
back to S2 and finally S1 if failures are encountered during the
connection setup. For mSBC the starting point would be T2 with a
fallback to T1 in case of failure. Do you agree that this would be an
acceptable solution?

Johan

Re: eSCO latency configuration

[Arnaud Mouiche]

Hi Johan,

On 11/27/2012 12:12 PM, Johan Hedberg wrote:
> Hi Arnaud,
>
> On Mon, Sep 05, 2011, Arnaud Mouiche wrote:
>> What could be a way to add the feature without breaking any API
>> 1) use the MTU of the socket or hdev ?
>> 2) add hdev entry for sco latency (which can be configured with
>> hciconfig like voice settings)
>> 3) something else ...
>> or
>> 4) no one cares about latency...
>>
>> PS: the same way, the retransmit effort is not configurable today.
> I'm assuming this is for HFP or HSP? At least I'm not aware of other
> significant profiles using (e)SCO. Since the HFP specification defines a
> set of recommended parameter combinations I don't think we necessarily
> need any user-space facing interface for this (with the exception of the
> mSBC/CVSD codec selection which is needed for HFP 1.6).
>
> Instead, the kernel could simply start with the S3 settings and fall
> back to S2 and finally S1 if failures are encountered during the
> connection setup. For mSBC the starting point would be T2 with a
> fallback to T1 in case of failure. Do you agree that this would be an
> acceptable solution?
> Johan

yes, I'm concerned by the HFP with mSBC/CVSD case, with multiple 
concurrent HFP sessions. So there is a need to avoid race conditions of 
the configuration (ie no configuration at the adapter level).

I found the BT_DEFER_SETUP feature from Frédéric to be a nice solution, 
since it gives more flexibility to the userland for this kind of 
configuration.
(up to now for my tests, I'm doing ugly things like forcing the kernel 
to not respond the eSCO setup, and do the response from userland.... )

I'm pretty busy at this time, but my goal may be to propose a way to 
configure the eSCO response on top of the BT_DEFER_SETUP.
With BT_DEFER_SETUP, accepting is done on the first 'recvmsg'. May be we 
can configure the socket (setsockopt, ioctl...) just before this first 
'recvmsg' to tell the kernel the real purpose of the socket.
For example, userland can provide the expected set of configuration 
(latency, bandwith, retransmissions, packets, voice settings). But I 
don't have a clear of how handling fallback indeed.

I'll be also interested to be able to reject the connection_request for 
"Limited Resources" reasons. The scenario using this feature is when 
multiple active calls are already managed by the device, and
routing a new voice stream is simply not possible (for the hardware 
and/or for the user).
(note: one limitation of the HFP specs is that the routing is not really 
agreed before opening the link. only the codec selection is negociated, 
but specifications are clear that we can't reject the CVSD codec, so a 
real rejection of the route is not possible)


just a [raw] idea I just have:

Module   --------------- Kernel --------------------------------- Userland

setsockopt( DEFER )
listen()

                            <-- socket in listen mode with DEFER option ---

   -- Connection_request -->
                             --- socket accept available ----------------->

A) [ accept case ] 
.............................................................
accept()

send() or
ioctl() or
setsockopt() or
better
                             <-------- provide the set of configuration 
items

recv()
  <-- Accept_synchronous_connection
-- Synchronous Connection Complete (OK or rjected) -->
-------------------------------> in case of failure
need to know the reason
for selecting a fallback
on next connection_request
attempt.




B) [ userland reject case ] 
.............................................................

accept()
close()

  <-- Reject_synchronous_connection (Limited Resources)





Note: Michael Knudsen seems to want to push also things concerning CSA2 
for codec configuration. I'm not really aware of what it imply and why 
it should be managed by the kernel. So I don't know how to put those 
things in the picture.


Arnaud