linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: bluez - check for new a2dp features
Date: Sat, 8 Jun 2019 13:56:29 +0300	[thread overview]
Message-ID: <CABBYNZ+gPRkAgFAeeoSqZ7tp5fYimGdju9JSuSpn_kL+f9hJhQ@mail.gmail.com> (raw)
In-Reply-To: <20190607153715.w5exsodd25qxc6xv@pali>

Hi Pali,

On Fri, Jun 7, 2019 at 6:37 PM Pali Rohár <pali.rohar@gmail.com> wrote:
>
> On Friday 07 June 2019 18:26:02 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Fri, Jun 7, 2019 at 3:58 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > On Monday 13 May 2019 19:05:50 Pali Rohár wrote:
> > > > Hello!
> > > >
> > > > In current git bluez master repository are new features related to A2DP.
> > > > E.g. support for codec switching or fallback to other local dbus
> > > > endpoints when current selected rejected connection...
> > > >
> > > > Moreover codec switching support is behind experimental runtime switch.
> > > >
> > > > For pulseaudio a2dp module I need to do runtime check if above features
> > > > are supported by currently running bluez instance (which registered to
> > > > dbus org.bluez. It is needed to ensure that pulseaudio does not
> > > > introduce regression for older bluez version without above new A2DP
> > > > features.
> > > >
> > > > But currently I have not found any way how to detect if bluez supports
> > > > codec switching or if it has support for trying another local SEP for
> > > > connection.
> > > >
> > > > So, could you please export e.g. bluez version as dbus property? And
> > > > also property if codec switching is supported and enabled by that
> > > > experimental flag?
> > >
> > > Hello, I would like to ask for some possibility to export these
> > > information. Without them it is not really possible to have stable
> > > implementation which would work with both old and new bluez version.
> >
> > I wonder what you are talking about since your changes do have checks
> > for when endpoints are detected,
>
> But this does not work as endpoints are available on DBus only when A2DP
> connection is active. I already asked to export them always (even when
> A2DP is not connected).
>
> Main problem is that when profile switching is not available, there
> should be registered only one A2DP codec (SBC in automatic quality) as
> changing is not possible. This is to prevent introducing any regression
> or having registered codec which would not work correctly.

I fill like repeating myself over and over, but here it goes again,
endpoints are not supposed to initiate connection which is the reason
why in PA the card is created only when a profile is connected, and no
we are not going to introduce feature like this to counter bugs where
HFP is left connect while A2DP isn't, etc. It is very important to
note that while we are caching the remote endpoints we never assume
they are valid before we connect and confirm they are still available.

> > isn't that enough to detect if one can switch codecs or not?
>
> Yes, this could be enough... but endpoints on DBus must be always
> available, not only when A2DP profile is connected.

Not gonna happen.

> > This logic used to work just fine last time I tested it.
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Luiz Augusto von Dentz

  reply	other threads:[~2019-06-08 10:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-13 17:05 bluez - check for new a2dp features Pali Rohár
2019-06-07 12:58 ` Pali Rohár
2019-06-07 15:26   ` Luiz Augusto von Dentz
2019-06-07 15:37     ` Pali Rohár
2019-06-08 10:56       ` Luiz Augusto von Dentz [this message]
2019-06-08 10:59         ` Pali Rohár
2019-06-08 11:15           ` Pali Rohár
2019-06-22 16:18             ` Pali Rohár
2019-06-22 17:01               ` Luiz Augusto von Dentz
2019-06-22 17:09                 ` Pali Rohár
2019-07-03 12:56                   ` Pali Rohár
2019-07-03 13:26                     ` Luiz Augusto von Dentz
2019-07-03 13:30                       ` Pali Rohár

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABBYNZ+gPRkAgFAeeoSqZ7tp5fYimGdju9JSuSpn_kL+f9hJhQ@mail.gmail.com \
    --to=luiz.dentz@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).