Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp628319ybi; Fri, 14 Jun 2019 00:16:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqytXGOTQGldXpJepekhr2B5+7RQGf8xJyjVHN416xks7JtbfFc1hAjpO9ranNdkQnYG1TBa X-Received: by 2002:a65:48c3:: with SMTP id o3mr34773153pgs.351.1560496605435; Fri, 14 Jun 2019 00:16:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560496605; cv=none; d=google.com; s=arc-20160816; b=pIK4nh2GievQhLSnXmrbVQWs4keeJrsTPENnsxjyHtWcn0VfFA3tblQkumFtKqSDlb WjtmNd8XceFFXpzv8HuUeyzpL7GdFh/4Pvjh77+uAXwrfLpIbqClDNg1qj6jpfdp6VzP Iwf3sZ1KELKLuyUU2KogDVdFQvVnm4q/9NsTpz2e8Fut33BsH/wYIdoeDgMrXnVWPagP X6gXlGvA6VijOqvkbJKoPGX+55nDC3L/4zdDLqMpcFgrvPY0ZjOLPxmCKu7m2KCbgJzf C75J3yscOZQ97lJ9hDl4hsGY22LM6Wq0RaIXS2YBhacR8+PVJbYQEMF4BzVamTFTZ6OA bDPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=bVAjztn4WgDKNgLQRExic9ECI/X5eMVwfyuZMAwh6wE=; b=NJJ58OPaTXc70UR1BD37Zxr5QHKxbkMp7vUYj78/WE5nepkQor4RM3Bk8P+JIw28jP xkkQxKUXVxJT586OA9VvA/K14QwBSCtBcAdHgOiHO+yogvCysXyptkaF5b3m5AOy0+UT 0zef5F9IQipBkDn25bYK/Qspsjo+haNg+VPaXLa5R5PjnsMW3efhV9ZrCtxS299iCMeA lsg+1kKm1rmezURXe9KARlBMjav+703OnNVlitasbkEg+L5tuqNAj3DMqJsqqWPkXzts sCb1vWl27f5e8gNjVYry50MojpJpbABaiFYrhhA7DtLjlJ7GNZw5UZ8ji+ed2O+NqTrd z9ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=a9+ayhA5; 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 a26si1664346pfh.147.2019.06.14.00.16.29; Fri, 14 Jun 2019 00:16:45 -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=a9+ayhA5; 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 S1725869AbfFNHQ2 (ORCPT + 99 others); Fri, 14 Jun 2019 03:16:28 -0400 Received: from mail-wm1-f42.google.com ([209.85.128.42]:40048 "EHLO mail-wm1-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725837AbfFNHQ2 (ORCPT ); Fri, 14 Jun 2019 03:16:28 -0400 Received: by mail-wm1-f42.google.com with SMTP id v19so1144705wmj.5 for ; Fri, 14 Jun 2019 00:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=bVAjztn4WgDKNgLQRExic9ECI/X5eMVwfyuZMAwh6wE=; b=a9+ayhA5zK+Jg8SPV2IwJbEPmZS8/pRds4JpencJnMolDwZM0WfAPDroASuNFXajHJ PbufjUL/dkjciNaKTmOOKFjX1uOg146LYC8C8rH7/VJzAxiK5kDxy+0ygwN0ymej80yB FUGfE5yTG/Yge4z+PJ7XlB1luhzoVO7xTCETMuMF3Dbmpf+UTnjfz2Gg33nl54se37lW 0uNrwBUiuB6VOL7k5CWmkg88SVJ5d/zqjx8i+5tfNuxB1RtBD0vilWEuMr60RtyUK1vW jTq2e42UyY8D15KxWiHMI5ItV+z7PGp4IMQyQCNdO7MEoNisvoB1FNjRwHOD4Nhsvuk4 wLZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=bVAjztn4WgDKNgLQRExic9ECI/X5eMVwfyuZMAwh6wE=; b=sLMGQ4XBYzZmVWzYj8j7lwLq04Xa8StIzchvfHcQGmdaaxs2M1WHkZgJOOdCCalOeM KA1hwbnlEhl+GNmBbacuw/bXqDep36iGg9VgcTFqy/pEaNfVr6HXSyvI+c/LS9y/E0l3 8Bsv2rAXX5WOvKbLk/KK4k3s/I58+Oc0NQN+7TVflYSY27LW1NJFg3h6/ontx2NIoBJP VDoS5U/frnjMxa4pjjGM0I3KdJ2yzYaOnTFIYHV880iwBXLMfnBVBFAjjUeZK8PPOI0A 6JArihWXGqmpzsLjUyMy1VAdugaP2x0glMUUueW2mb6GqWw9y3udhsvwfIAEphWp3EAU PAHA== X-Gm-Message-State: APjAAAWzxX5TiniEo7VrofcLxvkjuQZIF6XyXNfQnOczzV2tYBsOaKZU rMDvEKM8orO7BI8e3pWM9xavdWWMCac= X-Received: by 2002:a1c:e90f:: with SMTP id q15mr6964425wmc.89.1560496583734; Fri, 14 Jun 2019 00:16:23 -0700 (PDT) Received: from pali ([2a02:2b88:2:1::5cc6:2f]) by smtp.gmail.com with ESMTPSA id u5sm2636928wmc.32.2019.06.14.00.16.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 14 Jun 2019 00:16:23 -0700 (PDT) Date: Fri, 14 Jun 2019 09:16:22 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: =?utf-8?B?RnLDqWTDqXJpYw==?= Danis Cc: Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" Subject: Re: bluez A2DP socket reliability Message-ID: <20190614071622.wyra2hhkpzpt7i4z@pali> References: <20190518190618.m7rdkthvpz4agxd2@pali> <20190519122223.gabew7qfftihlbic@pali> <20190607130021.ntd3dfd6nzmuy3m3@pali> <20190610105130.un3muj4knwoua5cb@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org On Monday 10 June 2019 18:06:53 Frédéric Danis wrote: > 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 Mhm... I feeling quite lost. Is A2DP socket reliable with enabled retransmission or not? -- Pali Rohár pali.rohar@gmail.com