Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3402404ybi; Mon, 10 Jun 2019 09:38:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqwiWPMG7T8yhlLFz6SdN5C49IwdYR6rZovR6+87a4wkkuaZ3XHE3f+f6Y+WmxM4FFSxfxju X-Received: by 2002:a17:90a:af8a:: with SMTP id w10mr22573691pjq.132.1560184717644; Mon, 10 Jun 2019 09:38:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560184717; cv=none; d=google.com; s=arc-20160816; b=Dhckdv7Z1ToNBBxWxP7XAmwbSj3r2u+P1lATsmlqdpdRlA6LQPJmbCrkVC+N1/P4r0 lfC/COetwRFzjmO8IjW8UYpuHIpywiFeNNG7cc14zJ31hknrg9+MUnkWm1dPLf4IIgHt a++j9Z2fo+jvdsdwe7QsaghoeU2C8honqW9AEA3v/3ibNQDvjtMpVpoBl4ErJjvyOBxA HEgu0nTVS0Wp0ifKEzXD81UMReasU2bDf9kCuCk1gq5NqFT+6wr1S+OcyGLICK1yoUBc nidHdbFO//t3/ruCyqy+zP0WGDzpwt+SV0R3OYHMy2sjEPyRyPtdR5WQwqM+JA3kG7eX /mzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:subject:from:dkim-signature; bh=CaGA49BNdswYorM8WQAqFGos1AkNpcg/BifLW9C5DQU=; b=EGHdfcvm18vfGDN7/d1XSw4eZeG87DdMxls3APTlfLFshbGLN1g97utX6TGZOkVnMi g/IjvIswLxznr9qNXrSBLhx+y6jY8RSyHb2vqlAklINU4ltcYCXC2AaLVXWqfHGCDTRC Pk/oi/z/jgXPM3Qh+m101WRuxtTAWRrhiGGaFFAYWkXHtuxH9FDZINz6dN6CR8eQDcVa 0ftqHfCX9qehrhYag07X2u630r4kn8MzJIpLsGLfe/LqbebarWhG64bHuupGL+oEilFx ptYz90KEM54urmzCVVXtpHiv1zscItK3yhXVNcc6fZetjNipr8KKA6cZG2CFDyfXC1QQ ZOvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jyuQcYv+; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 15si10322080pfo.121.2019.06.10.09.38.11; Mon, 10 Jun 2019 09:38:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jyuQcYv+; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390908AbfFJQG6 (ORCPT + 99 others); Mon, 10 Jun 2019 12:06:58 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:34615 "EHLO mail-wm1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391372AbfFJQG6 (ORCPT ); Mon, 10 Jun 2019 12:06:58 -0400 Received: by mail-wm1-f49.google.com with SMTP id w9so251124wmd.1 for ; Mon, 10 Jun 2019 09:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=CaGA49BNdswYorM8WQAqFGos1AkNpcg/BifLW9C5DQU=; b=jyuQcYv+DCYRfmdPMZ1akl+AWVbWE0jQtVwOuBD9Flebp3TK6pOGhL7wfD37RTu/bv fxCS2Qu10JmZMfjryujJq0gcxxZUdgnhgnw5vpz+XRkEKIErAC49apqtL8VXDt0hJsd3 /FKps9Y5Dt/YDjVFsmQ8jzv8Q9C73Ka8iEqGxpVj0jwtdN0Szq44EaDt641b423iRgHz 1p4wcICd4occAQh5xGMEt8oot7pSBDXmSCdbItfBe0rEc+eYS0tW77n2xzY4ZQ7r8MyX N6Rvjv6A0dPJsJTWRafFn98Gwy2PDt4PpCOWQ8ow4NAIJOyJ08OPO6U8UnIuHBh0e3mn z6Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CaGA49BNdswYorM8WQAqFGos1AkNpcg/BifLW9C5DQU=; b=b2G1SvyTx8kv4YbCYfLrJYpd07xWMFVIt3aUTn9VynAl0XbsvgD2jVP36m87otu4L/ XR21hum+8VAbYLB1pdpC0SXAroyEGLYIme5Kh+Smfb1jghGIdrvPrjVqOwlVdYHZ2fiY 2L7CbuqR3xVgK1ejQQcmo6HwXNWgrlbjnxUR0D/nhVFhLfN1nlsdbOgpvRPpX+jLx30d 5p/kLv1qLqzGrm22M1HFhcbNN+9kX5z/lXGMQbBGOID+sGwVOtvQPIOzbGNPhhGMIytk x+s5NiHVOLSVC/iXt1tVTisS7eOdEoFq+0/HbF2Q8h9XOpF5TwDHuQdNgm3WAGf4CuCZ bnLQ== X-Gm-Message-State: APjAAAWlsmmxAzPJ7cqN9sH+K9Q/h5s9OXAs+BMHHaQCtoVqckBwD8vp y881uJsodheovFYxlyT0BZeI2Vnu X-Received: by 2002:a1c:c907:: with SMTP id f7mr14467644wmb.142.1560182815697; Mon, 10 Jun 2019 09:06:55 -0700 (PDT) Received: from [192.168.102.9] (97.205.83.79.rev.sfr.net. [79.83.205.97]) by smtp.gmail.com with ESMTPSA id l8sm4022942wrg.40.2019.06.10.09.06.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jun 2019 09:06:54 -0700 (PDT) From: =?UTF-8?Q?Fr=c3=a9d=c3=a9ric_Danis?= Subject: Re: bluez A2DP socket reliability To: =?UTF-8?Q?Pali_Roh=c3=a1r?= , Luiz Augusto von Dentz Cc: "linux-bluetooth@vger.kernel.org" References: <20190518190618.m7rdkthvpz4agxd2@pali> <20190519122223.gabew7qfftihlbic@pali> <20190607130021.ntd3dfd6nzmuy3m3@pali> <20190610105130.un3muj4knwoua5cb@pali> Message-ID: Date: Mon, 10 Jun 2019 18:06:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190610105130.un3muj4knwoua5cb@pali> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi, Le 10/06/2019 à 12:51, Pali Rohár a écrit : > On Friday 07 June 2019 18:23:41 Luiz Augusto von Dentz wrote: >> Hi Pali, >> >> On Fri, Jun 7, 2019 at 4:00 PM Pali Rohár wrote: >>> On Sunday 19 May 2019 14:22:23 Pali Rohár wrote: >>>> On Sunday 19 May 2019 11:13:09 Luiz Augusto von Dentz wrote: >>>>> Hi Pali, >>>>> >>>>> On Sat, May 18, 2019 at 11:12 PM Pali Rohár wrote: >>>>>> Hello! How is L2CAP layer of bluetooth socket used for A2DP audio >>>>>> transfer configured in bluez? It is reliable with big/infinite >>>>>> retransmit count? Or in best-effort manner and some packets may be >>>>>> dropped? And it is possible to change between these two modes for >>>>>> application which uses bluez DBUS API? I'm asking because some A2DP >>>>>> audio codecs are designed to deal with packet loss and for those codecs >>>>>> it would be probably better to configure L2CAP socket to unreliable >>>>>> mode. >>>>> We don't use ERTM with AVDTP, both signaling and transport sockets are >>>>> using basic mode which don't support retransmissions, there the >>>>> concept of flush timeout which iirc we don't currently it. >>>> On bluez.org site there is no information how to use bluez sockets and >>>> the only documentation/tutorial which I found on internet was this: >>>> >>>> https://people.csail.mit.edu/albert/bluez-intro/x559.html >>>> >>>> I do not know how up-to-date it is, but seems that by default bluez >>>> L2CAP sockets are reliable and to change them to unreliable mode it is >>>> needed to issue OGF_HOST_CTL / OCF_WRITE_AUTOMATIC_FLUSH_TIMEOUT (0x28) >>>> request. As default is zero = infinity = reliable connection. >>>> >>>> I do not understand low level bluetooth details, but is ERTM related to >>>> OCF_WRITE_AUTOMATIC_FLUSH_TIMEOUT? >>>> >>>> So what are default settings for L2CAP socket used by AVDTP/A2DP >>>> profiles which are transferred to user application via DBUS? >>> Hi! Do you have any idea about OCF_WRITE_AUTOMATIC_FLUSH_TIMEOUT? It is >>> related to ERTM or not? >> The OCF usually describes an HCI command which may affect the entire >> ACL connection, ERTM is a L2CAP channel mode that includes >> retransmissions. The A2DP stream transport doesn't ERTM so no >> retransmissions shall take place. > Fine, no retransmission is good for A2DP. I am not sure there is no retransmission with current implementation. AFAIU, ERTM and automatic flush timeout are not linked. ERTM operates at L2CAP level while automatic flush timeout [1] operates at ACL level. When I read the automatic flush timeout set for an A2DP SBC connection it returns 0, which means that the connection uses an infinite timeout. So, even if higher levels set packets as flushable, the ACL policy requests baseband to indefinitely try to send data [3]:   "The default Flush Timeout shall be infinite,     i.e. re-transmissions are carried out until     physical link loss occurs. This is also     referred to as a 'reliable channel.'" [1] Bluetooth core Vol 2, Part E, 6.19 [2] Bluetooth core Vol 2, Part E, 7.3.29 [3] Bluetooth core Vol 2, Part B, 7.6.3 -- Frédéric Danis Embedded Linux Consultant frederic.danis.oss@gmail.com