From: "Pali Rohár" <pali.rohar@gmail.com>
To: Luiz Augusto von Dentz <luiz.dentz@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:15:53 +0200 [thread overview]
Message-ID: <20190608111553.65s6yoyhmusmr3pc@pali> (raw)
In-Reply-To: <20190608105924.qmauvrwyz7nofx74@pali>
[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]
On Saturday 08 June 2019 12:59:24 Pali Rohár wrote:
> Ok. So is there any way how to check if bluez supports profile switching
> or not? And if not, could be introduced some flag/property on DBus so
> applications would not this information?
Because older versions of bluez does not support profile switching and
does not support properly remembering last used SEP, I need to know this
information in pulseaudio. To prevent any breakage e.g. that high
bandwidth codec would be chosen by old version of bluez in unsuitable
environment. Because of these problems I do not think that pulseaudio
should register these high quality codec with fixed high bandwidth. And
currently there is no way (or at last I do not know) how to check if
bluez support these features. And I need to know it at time when
pulseaudio is registering to DBus so it would correctly decide if SBC
UHQ codec should be registered via DBus to bluez or not.
Currently I know one way how to detect it -- look if there are available
SEP paths at dbus. But this works only after A2DP connection is active.
So I cannot use this "heuristic".
Therefore I'm asking for some DBus property or flag or whatever which
would tell me, prior to registering A2DP codecs via DBus to bluez, if
bluez supports profile switching or not.
Without this information, pulseaudio could enter into state when it is
unable to transmit any audio via bluetooth because old bluez chosen
unsuitable codec. And because old bluez version does not support profile
switching, nobody (pulseaudio or user) is able to fix this problem.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2019-06-08 11:15 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
2019-06-08 10:59 ` Pali Rohár
2019-06-08 11:15 ` Pali Rohár [this message]
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=20190608111553.65s6yoyhmusmr3pc@pali \
--to=pali.rohar@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@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).