[pulseaudio-discuss] [PATCH v3 4/7] bluetooth: Update a2dp-codecs.h from upstream bluez project
--- src/modules/bluetooth/a2dp-codecs.h | 354 +++- src/modules/bluetooth/bluez5-util.c | 6 +- 2 files changed, 349 insertions(+), 11 deletions(-) diff --git a/src/modules/bluetooth/a2dp-codecs.h b/src/modules/bluetooth/a2dp-codecs.h index 8afcfcb24..0bdd29110 100644 --- a/src/modules/bluetooth/a2dp-codecs.h +++ b/src/modules/bluetooth/a2dp-codecs.h @@ -4,6 +4,7 @@ * * Copyright (C) 2006-2010 Nokia Corporation * Copyright (C) 2004-2010 Marcel Holtmann + * Copyright (C) 2018 Pali Rohár * * * This library is free software; you can redistribute it and/or @@ -17,14 +18,19 @@ * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public - * License along with this library; if not, see <http://www.gnu.org/licenses/>. + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA * */ +#include +#include + #define A2DP_CODEC_SBC 0x00 #define A2DP_CODEC_MPEG12 0x01 #define A2DP_CODEC_MPEG24 0x02 -#define A2DP_CODEC_ATRAC 0x03 +#define A2DP_CODEC_ATRAC 0x04 +#define A2DP_CODEC_VENDOR 0xFF #define SBC_SAMPLING_FREQ_16000(1 << 3) #define SBC_SAMPLING_FREQ_32000(1 << 2) @@ -47,6 +53,9 @@ #define SBC_ALLOCATION_SNR (1 << 1) #define SBC_ALLOCATION_LOUDNESS1 +#define SBC_MAX_BITPOOL64 +#define SBC_MIN_BITPOOL2 + #define MPEG_CHANNEL_MODE_MONO (1 << 3) #define MPEG_CHANNEL_MODE_DUAL_CHANNEL (1 << 2) #define MPEG_CHANNEL_MODE_STEREO (1 << 1) @@ -63,10 +72,244 @@ #define MPEG_SAMPLING_FREQ_44100 (1 << 1) #define MPEG_SAMPLING_FREQ_48000 1 -#define MAX_BITPOOL 64 -#define MIN_BITPOOL 2 +#define MPEG_BIT_RATE_INDEX_0 (1 << 0) +#define MPEG_BIT_RATE_INDEX_1 (1 << 1) +#define MPEG_BIT_RATE_INDEX_2 (1 << 2) +#define MPEG_BIT_RATE_INDEX_3 (1 << 3) +#define MPEG_BIT_RATE_INDEX_4 (1 << 4) +#define MPEG_BIT_RATE_INDEX_5 (1 << 5) +#define MPEG_BIT_RATE_INDEX_6 (1 << 6) +#define MPEG_BIT_RATE_INDEX_7 (1 << 7) +#define MPEG_BIT_RATE_INDEX_8 (1 << 8) +#define MPEG_BIT_RATE_INDEX_9 (1 << 9) +#define MPEG_BIT_RATE_INDEX_10 (1 << 10) +#define MPEG_BIT_RATE_INDEX_11 (1 << 11) +#define MPEG_BIT_RATE_INDEX_12 (1 << 12) +#define MPEG_BIT_RATE_INDEX_13 (1 << 13) +#define MPEG_BIT_RATE_INDEX_14 (1 << 14) + +#define MPEG_MP1_BIT_RATE_32000MPEG_BIT_RATE_INDEX_1 +#define MPEG_MP1_BIT_RATE_64000MPEG_BIT_RATE_INDEX_2 +#define MPEG_MP1_BIT_RATE_96000MPEG_BIT_RATE_INDEX_3 +#define MPEG_MP1_BIT_RATE_128000 MPEG_BIT_RATE_INDEX_4 +#define MPEG_MP1_BIT_RATE_16 MPEG_BIT_RATE_INDEX_5 +#define MPEG_MP1_BIT_RATE_192000 MPEG_BIT_RATE_INDEX_6 +#define MPEG_MP1_BIT_RATE_224000 MPEG_BIT_RATE_INDEX_7 +#define MPEG_MP1_BIT_RATE_256000 MPEG_BIT_RATE_INDEX_8 +#define MPEG_MP1_BIT_RATE_288000 MPEG_BIT_RATE_INDEX_9 +#define MPEG_MP1_BIT_RATE_32 MPEG_BIT_RATE_INDEX_10 +#define MPEG_MP1_BIT_RATE_352000 MPEG_BIT_RATE_INDEX_11 +#define MPEG_MP1_BIT_RATE_384000 MPEG_BIT_RATE_INDEX_12 +#define MPEG_MP1_BIT_RATE_416000 MPEG_BIT_RATE_INDEX_13 +#define MPEG_MP1_BIT_RATE_448000 MPEG_BIT_RATE_INDEX_14 + +#define MPEG_MP2_BIT_RATE_32000MPEG_BIT_RATE_INDEX_1 +#define MPEG_MP2_BIT_RATE_48000MPEG_BIT_RATE_INDEX_2 +#define MPEG_MP2_BIT_RATE_56000MPEG_BIT_RATE_INDEX_3 +#define MPEG_MP2_BIT_RATE_64000MPEG_BIT_RATE_INDEX_4 +#define MPEG_MP2_BIT_RATE_8MPEG_BIT_RATE_INDEX_5 +#define MPEG_MP2_BIT_RATE_96000MPEG_BIT_RATE_INDEX_6 +#define MPEG_MP2_BIT_RATE_112000 MPEG_BIT_RATE_INDEX_7 +#define MPEG_MP2_BIT_RATE_128000 MPEG_BIT_RATE_INDEX_8 +#define MPEG_MP2_BIT_RATE_16 MPEG_BIT_RATE_INDEX_9 +#define MPEG_MP2_BIT_RATE_192000 MPEG_BIT_RATE_INDEX_10 +#define MPEG_MP2_BIT_RATE_224000 MPEG_BIT_RATE_INDEX_11 +#define MPEG_MP2_BIT_RATE_256000 MPEG_BIT_RATE_INDEX_12 +#define MPEG_MP2_BIT_RATE_32 MPEG_BIT_RATE_INDEX_13 +#define MPEG_MP2_BIT_RATE_384000 MPEG_BIT_RATE_INDEX_14 + +#define MPEG_MP3_BIT_RATE_32000MPEG_BIT_RATE_INDEX_1 +#define MPEG_MP3_BIT_RATE_4MPEG_BIT_RATE_INDEX_2 +#define MPEG_MP3_BIT_RATE_48000MPEG_BIT_RATE_INDEX_3 +#define MPEG_MP3_BIT_RATE_56000MPEG_BIT_RATE_INDEX_4 +#define MPEG_MP3_BIT_RATE_64000
[pulseaudio-discuss] [PATCH v3 7/7] bluetooth: Add A2DP FastStream codec support
Now only main channel, voice backchannel is not implemented yet.
---
src/Makefile.am | 2 +
src/modules/bluetooth/a2dp-codec-faststream.c | 401 ++
src/modules/bluetooth/a2dp-codec-util.c | 2 +
3 files changed, 405 insertions(+)
create mode 100644 src/modules/bluetooth/a2dp-codec-faststream.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 7c7f1b564..26c0e0794 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -2146,6 +2146,8 @@ libbluez5_util_la_SOURCES +=
modules/bluetooth/a2dp-codec-sbc.c
libbluez5_util_la_LIBADD += $(SBC_LIBS)
libbluez5_util_la_CFLAGS += $(SBC_CFLAGS)
+libbluez5_util_la_SOURCES += modules/bluetooth/a2dp-codec-faststream.c
+
if HAVE_OPENAPTX
libbluez5_util_la_SOURCES += modules/bluetooth/a2dp-codec-aptx.c
libbluez5_util_la_CPPFLAGS += $(OPENAPTX_CPPFLAGS)
diff --git a/src/modules/bluetooth/a2dp-codec-faststream.c
b/src/modules/bluetooth/a2dp-codec-faststream.c
new file mode 100644
index 0..8c910ea8b
--- /dev/null
+++ b/src/modules/bluetooth/a2dp-codec-faststream.c
@@ -0,0 +1,401 @@
+/***
+ This file is part of PulseAudio.
+
+ Copyright 2018-2019 Pali Rohár
+
+ PulseAudio is free software; you can redistribute it and/or modify
+ it under the terms of the GNU Lesser General Public License as
+ published by the Free Software Foundation; either version 2.1 of the
+ License, or (at your option) any later version.
+
+ PulseAudio is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.
+***/
+
+#ifdef HAVE_CONFIG_H
+#include
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "a2dp-codecs.h"
+#include "a2dp-codec-api.h"
+
+#define SBC_BITPOOL_DEC_LIMIT 32
+#define SBC_BITPOOL_DEC_STEP 5
+
+struct faststream_info {
+sbc_t sbc; /* Codec data */
+size_t codesize, frame_length; /* SBC Codesize, frame_length. We
simply cache those values here */
+};
+
+static bool accept_capabilities(const uint8_t *capabilities_buffer, uint8_t
capabilities_size, bool for_encoding) {
+const a2dp_faststream_t *capabilities = (const a2dp_faststream_t *)
capabilities_buffer;
+
+if (A2DP_GET_VENDOR_ID(capabilities->info) != FASTSTREAM_VENDOR_ID ||
A2DP_GET_CODEC_ID(capabilities->info) != FASTSTREAM_CODEC_ID)
+return false;
+
+if (!(capabilities->direction & (FASTSTREAM_DIRECTION_SINK |
FASTSTREAM_DIRECTION_SOURCE)))
+return false;
+
+if (capabilities->direction & FASTSTREAM_DIRECTION_SINK) {
+if (!(capabilities->sink_frequency &
(FASTSTREAM_SINK_SAMPLING_FREQ_44100 | FASTSTREAM_SINK_SAMPLING_FREQ_48000)))
+return false;
+} else {
+if (capabilities->sink_frequency != 0)
+return false;
+}
+
+if (capabilities->direction & FASTSTREAM_DIRECTION_SOURCE) {
+if (!(capabilities->source_frequency &
FASTSTREAM_SOURCE_SAMPLING_FREQ_16000))
+return false;
+} else {
+if (capabilities->source_frequency != 0)
+return false;
+}
+
+return true;
+}
+
+static const char *choose_capabilities(const pa_hashmap *capabilities_hashmap,
bool for_encoding) {
+const pa_a2dp_codec_capabilities *a2dp_capabilities;
+const char *key;
+void *state;
+
+/* There is no preference, just choose random valid entry */
+PA_HASHMAP_FOREACH_KV(key, a2dp_capabilities, capabilities_hashmap, state)
{
+if (accept_capabilities(a2dp_capabilities->buffer,
a2dp_capabilities->size, for_encoding))
+return key;
+}
+
+return NULL;
+}
+
+static uint8_t fill_capabilities(uint8_t capabilities_buffer[254]) {
+a2dp_faststream_t *capabilities = (a2dp_faststream_t *)
capabilities_buffer;
+
+pa_zero(*capabilities);
+
+capabilities->info = A2DP_SET_VENDOR_ID_CODEC_ID(FASTSTREAM_VENDOR_ID,
FASTSTREAM_CODEC_ID);
+capabilities->direction = FASTSTREAM_DIRECTION_SINK |
FASTSTREAM_DIRECTION_SOURCE;
+capabilities->sink_frequency = FASTSTREAM_SINK_SAMPLING_FREQ_44100 |
FASTSTREAM_SINK_SAMPLING_FREQ_48000;
+capabilities->source_frequency = FASTSTREAM_SOURCE_SAMPLING_FREQ_16000;
+
+return sizeof(*capabilities);
+}
+
+static bool validate_configuration(const uint8_t *config_buffer, uint8_t
config_size) {
+const a2dp_faststream_t *config = (const a2dp_faststream_t *)
config_buffer;
+
+if (config_size != sizeof(*config)) {
+pa_log_error("Invalid size of config buffer");
+return false;
+}
+
+if (A2DP_GET_VENDOR_ID(config->info) !=
Re: [pulseaudio-discuss] [PATCH v2 2/2] Bluetooth A2DP aptX codec support
On Wednesday 05 September 2018 13:57:08 Tanu Kaskinen wrote:
> On Sat, 2018-07-28 at 17:34 +0200, Pali Rohár wrote:
> > This patch provides support for aptX codec in bluetooth A2DP profile. In
> > pulseaudio it is implemented as a new profile a2dp_aptx_sink. For aptX
> > encoding it uses open source LGPLv2.1+ licensed libopenaptx library which
> > can be found at https://github.com/pali/libopenaptx.
> >
> > Limitations:
> >
> > Codec selection (either SBC or aptX) is done by bluez itself and it does
> > not provide API for switching codec. Therefore pulseaudio is not able to
> > change codec and it is up to bluez if it decide to use aptX or not.
> >
> > Only standard aptX codec is supported for now. Support for other variants
> > like aptX HD, aptX Low Latency, FastStream may come up later.
> > ---
> > configure.ac | 19 ++
> > src/Makefile.am | 5 +
> > src/modules/bluetooth/a2dp-codecs.h | 118 ++-
> > src/modules/bluetooth/bluez5-util.c | 48 -
> > src/modules/bluetooth/bluez5-util.h | 2 +
> > src/modules/bluetooth/module-bluez5-device.c | 65 +-
> > src/modules/bluetooth/pa-a2dp-codec-aptx.c | 297
> > +++
> > src/modules/bluetooth/pa-a2dp-codec.h| 1 +
> > 8 files changed, 548 insertions(+), 7 deletions(-)
> > create mode 100644 src/modules/bluetooth/pa-a2dp-codec-aptx.c
> >
> > diff --git a/configure.ac b/configure.ac
> > index d2bfab23b..c2d13fa53 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -1094,6 +1094,23 @@ AC_SUBST(HAVE_BLUEZ_5_NATIVE_HEADSET)
> > AM_CONDITIONAL([HAVE_BLUEZ_5_NATIVE_HEADSET], [test
> > "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = x1])
> > AS_IF([test "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = "x1"],
> > AC_DEFINE([HAVE_BLUEZ_5_NATIVE_HEADSET], 1, [Bluez 5 native headset backend
> > enabled]))
> >
> > + Bluetooth A2DP aptX codec (optional) ###
> > +
> > +AC_ARG_ENABLE([aptx],
> > +AS_HELP_STRING([--disable-aptx],[Disable optional bluetooth A2DP aptX
> > codec support (via libopenaptx)]))
> > +
> > +AS_IF([test "x$HAVE_BLUEZ_5" = "x1" && test "x$enable_aptx" != "xno"],
> > +[AC_CHECK_HEADER([openaptx.h],
> > +[AC_CHECK_LIB([openaptx], [aptx_init], [HAVE_OPENAPTX=1],
> > [HAVE_OPENAPTX=0])],
> > +[HAVE_OPENAPTX=0])])
>
> Have you considered providing a .pc file?
I will think about it (again).
> Now we have to hardcode the
> openaptx specific CFLAGS and LIBADD for libbluez5-util.
As a first step, I will remove hardcoded CFLAGS and LIBADD from
libbluez5-util. In autoconf, everything is possible to discover, so
really no need to hardcode and let autoconf find them.
> If you ever need to add new flags,
This is something which is not going to happen.
> all openaptx users need to update their build
> systems. Also, if the library is installed to a non-standard location,
> the .pc file can set the -L and -I flags to point to the right place.
> > diff --git a/src/modules/bluetooth/bluez5-util.c
> > b/src/modules/bluetooth/bluez5-util.c
> > index 9c4e3367b..c139f7fc3 100644
> > --- a/src/modules/bluetooth/bluez5-util.c
> > +++ b/src/modules/bluetooth/bluez5-util.c
> > @@ -50,7 +50,9 @@
> > #define BLUEZ_ERROR_NOT_SUPPORTED "org.bluez.Error.NotSupported"
> >
> > #define A2DP_SOURCE_SBC_ENDPOINT "/MediaEndpoint/A2DPSourceSBC"
> > +#define A2DP_SOURCE_APTX_ENDPOINT "/MediaEndpoint/A2DPSourceAPTX"
> > #define A2DP_SINK_SBC_ENDPOINT "/MediaEndpoint/A2DPSinkSBC"
> > +#define A2DP_SINK_APTX_ENDPOINT "/MediaEndpoint/A2DPSinkAPTX"
> >
> > #define ENDPOINT_INTROSPECT_XML \
> > DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE \
> > @@ -173,8 +175,22 @@ static bool
> > device_supports_profile(pa_bluetooth_device *device, pa_bluetooth_pr
> > switch (profile) {
> > case PA_BLUETOOTH_PROFILE_A2DP_SBC_SINK:
> > return !!pa_hashmap_get(device->uuids,
> > PA_BLUETOOTH_UUID_A2DP_SINK);
> > +case PA_BLUETOOTH_PROFILE_A2DP_APTX_SINK:
> > +#ifdef HAVE_OPENAPTX
> > +/* TODO: Implement once bluez provides API to check if codec
> > is supported */
> > +return !!pa_hashmap_get(device->uuids,
> > PA_BLUETOOTH_UUID_A2DP_SINK);
>
> Is someone working on that API?
Yes, Lui
Re: [pulseaudio-discuss] [PATCH v2 1/2] Modular API for Bluetooth A2DP codec
Hi Tanu! I'm working on a new version of this patch series.
Below are comments, I'm fixing problems which you pointed. Thank you for
review.
Also, on bluez mailing list are patches which add support for profile
switching, so I'm implementing it for this patch series.
Once I have implemented it, I will send a new version to pulseaudio
mailing list.
Most important change is removal of all codec specific enums, ifdefs,
etc... from bluez5-util.c and module-bluez5-device.c files. So for
adding new codec it would not be needed to touch these files!
On Tuesday 04 September 2018 11:44:10 Tanu Kaskinen wrote:
> On Sat, 2018-07-28 at 17:34 +0200, Pali Rohár wrote:
> > Move current SBC codec implementation into separate source file and use
> > this new API for providing all needed functionality for Bluetooth A2DP.
> >
> > Both bluez5-util and module-bluez5-device are changed to use this new
> > modular codec API.
> > ---
> > src/Makefile.am | 9 +-
> > src/modules/bluetooth/a2dp-codecs.h | 5 +-
> > src/modules/bluetooth/bluez5-util.c | 331 +--
> > src/modules/bluetooth/bluez5-util.h | 10 +-
> > src/modules/bluetooth/module-bluez5-device.c | 487 ++
> > src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579
> > +++
> > src/modules/bluetooth/pa-a2dp-codec.h| 40 ++
>
> The "pa-" prefix doesn't look very good to me. Maybe you didn't want to
> add a2dp-codec.h, because it looks so similar to the existing a2dp-
> codecs.h header? I think we can get rid of a2dp-codecs.h: the SBC stuff
> can be moved to a2dp-codec-sbc.c, and the MPEG stuff can be dropped
> since it's not used anywhere.
I'm going to change/fix it.
a2dp-codec-api.h --> structure definitions for implementing codecs
a2dp-codec-.c --> particular codec implementation
a2dp-codecs.h--> upstream bluez header file for A2DP definitions
a2dp-codec-util.h--> header file for utility functions for working
with codecs (e.g. listing all codecs, etc.)
a2dp-codec-util.c--> implementation of a2dp-codec-util.h
> > @@ -888,10 +889,21 @@ finish:
> > static void register_endpoint(pa_bluetooth_discovery *y, const char *path,
> > const char *endpoint, const char *uuid) {
> > DBusMessage *m;
> > DBusMessageIter i, d;
> > -uint8_t codec = 0;
> > +uint8_t capabilities[1024];
> > +size_t capabilities_size;
> > +uint8_t codec_id;
> > +const pa_a2dp_codec_t *codec;
> > +
> > +codec = pa_a2dp_endpoint_to_a2dp_codec(endpoint);
>
> I think it would be better to change the function parameters so that
> instead of an endpoint path the function would take a codec id.
That is not possible. endpoint is bound to pair (codec + direction).
I'm changing function parameters, so pulseaudio codec structure is
passed too (together with endpoint).
This simplify lot of other things and removal of
pa_a2dp_endpoint_to_a2dp_codec function call from there.
> > +if (!codec)
> > +return;
>
> As far as I can tell, this should never happen, so an assertion would
> be better (and it could be in the lookup function so that every caller
> doesn't need to add a check).
After above change, yes, so removing it.
> > @@ -1316,6 +1271,38 @@ const char
> > *pa_bluetooth_profile_to_string(pa_bluetooth_profile_t profile) {
> > return NULL;
> > }
> >
> > +const char *pa_bluetooth_profile_to_a2dp_endpoint(pa_bluetooth_profile_t
> > profile) {
>
> This function isn't used outside bluez5-util.c, so it can be made
> static and removed from bluez5-util.h. Then the pa_bluetooth_ prefix
> should be dropped.
Yes, doing it.
> > +switch (profile) {
> > +case PA_BLUETOOTH_PROFILE_A2DP_SBC_SINK:
> > +return A2DP_SOURCE_SBC_ENDPOINT;
> > +case PA_BLUETOOTH_PROFILE_A2DP_SBC_SOURCE:
> > +return A2DP_SINK_SBC_ENDPOINT;
> > +default:
> > +return NULL;
>
> I think it would be good to use pa_assert_not_reached() here. I assume
> this won't be used in a context where a non-a2dp profile would be
> passed to the function.
The whole bluez5-util.c file does not have any codec specific enums, so
this above profile switch was removed.
> > +}
> > +
> > +return NULL;
>
> This is redundant.
>
> > +}
> > +
> > +const pa_a2dp_codec_t
> > *pa_bluetooth_profile_to_a2dp_codec(pa_bluetooth_profile_t profile) {
> > +switch (profile) {
> > +case PA_BLUETOOTH_PROFILE_A2DP_SBC_SINK:
> > +case PA_BLUETOOTH_PROFILE_A2DP
Re: [pulseaudio-discuss] [PATCH v3 2/4] Add A2DP AAC codec support
On Friday 11 January 2019 15:32:44 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Fri, Jan 11, 2019 at 2:49 PM Pali Rohár wrote: > > > > On Friday 11 January 2019 14:23:21 Luiz Augusto von Dentz wrote: > > > Im little worried about the maintainance of a2dp_util.c if we keedp > > > the practice of #ifsef every codec, imo it would be much cleaner if we > > > just have a mechanism to register the codecs, maybe we load them as > > > separate plugins which then call a2dp_util.c to register their > > > 'drivers', the plugin can check if the bluetooth plugin is loaded in > > > order to register itself, doing that way we can also pass the > > > parameter via default.pa. > > > > Hi! I'm already working on a new version of my previous patch series. > > And your above point above tons of #ifdefs is being addresses. > > > > I though about it for a long time (heh :-) last version of my A2DP codec > > patch series is from summer) and I think I have a good API where adding > > new codec involves only adding new file (with all needed functions) plus > > putting codec structure into one list. > > > > So... I will rework my previous patch series, will add support for codec > > switching and then I send it to mailing list. > > Are you changes compatibles with this changes or we have to competing > solutions? These Huang-Huang Bao patches are competing to my solution which I already sent in summer. But I can take additional codec supports in this series and convert them into my. So no functionality would be lost. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v3 2/4] Add A2DP AAC codec support
On Friday 11 January 2019 14:23:21 Luiz Augusto von Dentz wrote: > Im little worried about the maintainance of a2dp_util.c if we keedp > the practice of #ifsef every codec, imo it would be much cleaner if we > just have a mechanism to register the codecs, maybe we load them as > separate plugins which then call a2dp_util.c to register their > 'drivers', the plugin can check if the bluetooth plugin is loaded in > order to register itself, doing that way we can also pass the > parameter via default.pa. Hi! I'm already working on a new version of my previous patch series. And your above point above tons of #ifdefs is being addresses. I though about it for a long time (heh :-) last version of my A2DP codec patch series is from summer) and I think I have a good API where adding new codec involves only adding new file (with all needed functions) plus putting codec structure into one list. So... I will rework my previous patch series, will add support for codec switching and then I send it to mailing list. Stay tuned... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Thursday 09 August 2018 16:39:09 ValdikSS wrote: > 0xFF 0x000A 0x0103 — Unknown codec found on Bose QuietComfort QC35 II "The CSR True Wireless Stereo v3 Codec ID for SBC." > Value hex dump: 07 06 00 00 ff ff 02 35 From information which I have, info payload is just embedded AVDTP media capability buffer. 07 - AVDTP_SERVICE_MEDIA_CODEC 06 - length 00 - AVDTP_MEDIA_TYPE_AUDIO 00 - A2DP_CODEC_SBC ff - SBC_CHANNEL_MODE_JOINT_STEREO | SBC_CHANNEL_MODE_STEREO | SBC_CHANNEL_MODE_DUAL_CHANNEL | SBC_CHANNEL_MODE_MONO | SBC_SAMPLING_FREQ_48000 | SBC_SAMPLING_FREQ_44100 | SBC_SAMPLING_FREQ_32000 | SBC_SAMPLING_FREQ_16000 ff - SBC_BLOCK_LENGTH_4 | SBC_BLOCK_LENGTH_8 | SBC_BLOCK_LENGTH_12 | SBC_BLOCK_LENGTH_16 | SBC_SUBBANDS_4 | SBC_SUBBANDS_8 SBC_ALLOCATION_SNR | SBC_ALLOCATION_LOUDNESS 02 - min bitpool 35 - max bitpool So it matches SBC definition buffer as expected. > 0xFF 0x000A 0x0104 — Unknown codec found on Bose QuietComfort QC35 II "The CSR True Wireless Stereo v3 Codec ID for AAC." > Value hex dump: 07 08 00 02 c0 ff 8c 84 e2 00 Again, it should be embedded AVDTP media capability buffer. 07 - AVDTP_SERVICE_MEDIA_CODEC 08 - length 00 - AVDTP_MEDIA_TYPE_AUDIO 02 - A2DP_CODEC_MPEG24 c0 - AAC_OBJECT_TYPE_MPEG2_AAC_LC | AAC_OBJECT_TYPE_MPEG4_AAC_LTP | AAC_OBJECT_TYPE_MPEG4_AAC_SCA ff 8c - frequences: all; channels: all 84 e2 00 - VBR; bitrate: 32 So also MPEG2/4 AAC buffer is correct. Moreover there also exist these codecs: 0xFF 0x000A 0x0105 - The CSR True Wireless Stereo v3 Codec ID for MP3. 0xFF 0x000A 0x0106 - The CSR True Wireless Stereo v3 Codec ID for AptX. And again capability buffer should contain embedded AVDTP media capability buffer for MPEG1 (with Layyer 3) and for aptX. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 2/4] Add A2DP AAC codec support
On Thursday 13 December 2018 19:43:37 EHfive wrote: > Optional (build with --disable-bluez5-aac-codec) > > AAC User Configurations: >KEY VALUEDESC > DEFAULT >aac_bitrate_mode[1, 5] Variable Bitrate (VBR) (encoder) 5 >0Constant Bitrate (CBR) (encoder) > >aac_fmt s16 16-bit signed LE (encoder)auto >s32 32-bit signed LE (encoder) >auto > >aac_afterburner FDK-AAC afterburner feature (encoder) on In my opinion, support for AAC make sense only in passthrough mode. E.g. when your music files are already stored in AAC and you have headset with AAC support; and you do not want to re-encode it twice. But I do not see support for passthrough mode in this patch. It is planned? Maybe similar thing could be useful for MPEG1 A2DP audio codec (as lot of people listen MP3 files), but I have not seen headset with MPEG1 support... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support
On Friday 14 December 2018 00:07:27 Huang-Huang Bao wrote: > "a2dp-codecs.h" copied from bluez I sent fixes for a2dp-codecs.h from bluez to linux-blueto...@vger.kernel.org list. So wait until it is fixed and we would not need to fix these problems in two different projects... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module
On Sunday 22 July 2018 13:37:06 Pali Rohár wrote: > On Sunday 22 July 2018 11:52:11 Georgi Boiko wrote: > > For codecs focusing on latency over sound quality, if I absolutely had to > > support them, I would put AptX LL between AptX and AAC. FastStream seems to > > be even more niche and focused purely on voice over HiFi audio on just a > > Information which I have about FastStream: It is just SBC codec with > following parameters: frequency rate 44.1 kHz or 48.0 kHz, Blocks 16, > Sub-bands 8, Joint Stereo, Loudness and Bitpool = 29. So data rate = 212 > kbps, packet size = 72*3+4 = 220 = DM5 and that DSP decoders round 71 > bytes frames to 72 bytes. So I'm not sure how "low latency" it is. > Normal SBC codec allows you to specify all those parameters. But > FastStream has one additional feature: it supports backchannel for > voice, so you do not have to switch between HFP/HSP and A2DP once you > have incoming voice call. You can always use just A2DP with FastStream. And information about aptX Low Latency codec: It is just normal aptX with different A2DP parameters and support for some kind of backchannel. Therefore existing aptX (non HD) encoder and decoder (like proprietary Android's, ffmpeg or https://github.com/pali/libopenaptx) are enough for implementing aptX Low Latency A2DP support. A2DP structures for aptX Low Latency codec are already described in my patch, search for a2dp_aptx_ll_t. https://patchwork.freedesktop.org/patch/241444/ -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support
On Saturday 15 December 2018 23:15:14 Pasi Kärkkäinen wrote: > On Fri, Dec 14, 2018 at 12:01:57PM +0100, Pali Rohár wrote: > > > > > > > > Therefore that priority list is not always enforced. > > > > > > How do you know? > > > > Because I wrote my own implementation of aptX and FastStream codec > > support for pulseaudio. Also I played with bluez a lot. In summer I sent > > those my patches to pulseaudio mailing list, including proposal for > > pulseaudio codec API. > > > > And there was discussion about it. Also bluez developer confirmed that > > priority list is not applied when headset initialize connection. > > > > So what's needed to get the pulseaudio codec api supported in pulseaudio / > patches merged? > Are there still not-yet-implemented items related to the pulseaudio codec api > proposal? > More reviews needed? > > I understand this is not a simple change, just trying to understand the > current status. One of the missing part is bluez API for selecting / switching A2DP codec. Without it, it is not possible to implement stable selection of A2DP codec in pulseaudio. I sent remainder email about this problem to linux-bluetooth ML: https://www.spinics.net/lists/linux-bluetooth/msg78127.html This is reason why I paused my work from summer for bringing Modular codec API into pulseaudio. As all future work will depends on how that new bluez dbus API would look like. Otherwise I would have finished my Modular codec API... https://patchwork.freedesktop.org/series/46058/ Luiz proposed, that bluez could device's MediaEndpoint1 with SelectConfiguration for every supported codec by remote device and pulseaudio then could choose which one want. See: https://www.spinics.net/lists/linux-bluetooth/msg76413.html > > Thanks, > > -- Pasi > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support
; > + > +void (*free_capabilities)(void **capabilities); > + > +size_t (*select_configuration)(const pa_sample_spec default_sample_spec, > const uint8_t *supported_capabilities, > + const size_t capabilities_size, void > **configuration); > + > +void (*free_configuration)(void **configuration); You can simplify memory management if caller (instead of callee) would be responsible for passing pointer to allocated memory (e.g. also from stack) with buffer size. Then API would not need any "free" functions. > +/* Return true if configuration valid */ > +bool (*set_configuration)(const uint8_t *selected_configuration, const > size_t configuration_size); If this function validates configuration, then "validate_configuration" is better name. > + > +}; -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 3/4] Add A2DP aptX, aptX HD codecs support
On Friday 14 December 2018 00:16:24 Huang-Huang Bao wrote: > 90 samples are only 90/44100 s = 2ms , which is ignorable. Yes, this not a problem. Problem is that first 90 samples is just "garbage" or rather initialization data for predictor. And to prevent hearing such "garbage" when decoding stream, you need to drop them. Put aptX stream into aptX decoder, but drop first 90 samples of decoded output. Hearing noise or any other disrupting sound also for just 2ms is not something which you want to hear. This also applies when resetting decoder, e.g. after aptX parity check does not match. In most cases, first 90 decoded samples should be just silence (at least this is doing ffmpeg and android's proprietary encoders). But when you start decoding not from beginning but from existing stream, then it is a problem. Decoding from the middle of stream happens when some A2DP packets are lost and decoder needs to be reset and start decoding again. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support
On Friday 14 December 2018 18:48:05 Huang-Huang Bao wrote:
> I don't want to debate too much about naming. In this state, we should pay
> attention to codes function.
>
> Broken codes and useless codes could be cleaned up after this patches set
> applied.
>
> If someone want to add another codec, he/she can just modify
> "a2dp-codeces.h" or others.
>
>
> On 12/14/18 5:41 PM, Pali Rohár wrote:
> > On Friday 14 December 2018 00:07:27 Huang-Huang Bao wrote:
> >> "a2dp-codecs.h" copied from bluez, then added a2dp_aptxhd_t, a2dp_ldac_t.
> > This does not excuse having broken code in pulseaudio. Atrac or big
> > endian definition seems to be really wrong.
> >
> > Is not it stupid to copy+paste broken code from one project to another?
> >
> >> I don't want to debate too much about naming.
> > Look, if other people comes up with something in the naming, then it
> > should be also reflected.
> >
> > Bad naming just increase confusion for other people who start reading
> > code later. This is the fact.
> >
> >> On 12/13/18 11:35 PM, Pali Rohár wrote:
> >>> On Thursday 13 December 2018 19:43:36 EHfive wrote:
> >>>> +#define A2DP_CODEC_SBC 0x00
> >>>> +#define A2DP_CODEC_MPEG12 0x01
> >>>> +#define A2DP_CODEC_MPEG24 0x02
> >>>> +#define A2DP_CODEC_ATRAC0x03
> >>> This is incorrect, Atrac codec has A2DP ID 0x04, see:
> >>> https://www.bluetooth.com/specifications/assigned-numbers/audio-video
> >>>
> >>>> +#define MAX_BITPOOL 64
> >>>> +#define MIN_BITPOOL 2
> >>> These two constants are SBC specific, so make them with SBC_ prefix.
> >>>
> >>>> +#define APTX_VENDOR_ID 0x004f
> >>> This ID is allocated for APT Ltd. company. Not just for aptX codec. So
> >>> maybe better name is A2DP_VENDOR_APT_LIC_LTD?
> >>>
> >>>> +#define APTX_CODEC_ID 0x0001
> >>>> +
> >>>> +#define APTX_CHANNEL_MODE_MONO 0x01
> >>>> +#define APTX_CHANNEL_MODE_STEREO0x02
> >>>> +
> >>>> +#define APTX_SAMPLING_FREQ_160000x08
> >>>> +#define APTX_SAMPLING_FREQ_320000x04
> >>>> +#define APTX_SAMPLING_FREQ_441000x02
> >>>> +#define APTX_SAMPLING_FREQ_480000x01
> >>>> +
> >>>> +#define LDAC_VENDOR_ID 0x012d
> >>> This ID is allocated for Sony Corporation company. Not just for LDAC
> >>> codec.
> >>>
> >>> See:
> >>> https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers
> >>>
> >>>> +#elif __BYTE_ORDER == __BIG_ENDIAN
> >>>> +
> >>>> +typedef struct {
> >>>> +uint8_t frequency:4;
> >>>> +uint8_t channel_mode:4;
> >>>> +uint8_t block_length:4;
> >>>> +uint8_t subbands:2;
> >>>> +uint8_t allocation_method:2;
> >>>> +uint8_t min_bitpool;
> >>>> +uint8_t max_bitpool;
> >>>> +} __attribute__ ((packed)) a2dp_sbc_t;
> >>>> +
> >>>> +typedef struct {
> >>>> +uint8_t layer:3;
> >>>> +uint8_t crc:1;
> >>>> +uint8_t channel_mode:4;
> >>>> +uint8_t rfa:1;
> >>>> +uint8_t mpf:1;
> >>>> +uint8_t frequency:6;
> >>>> +uint16_t bitrate;
> >>> This value for big endian systems seems to be broken. As you need to
> >>> store value in little endian. So maybe define as?
> >>>
> >>> uint8_t bitrate_low;
> >>> uint8_t bitrate_high;
> >>>
> >>> Or as
> >>>
> >>> uint8_t bitrate[2];
> >>>
> >>> Or better drop big endian support? Broken big endian support is not
> >>> useful at all.
> >>>
> >>>> +static size_t
> >>>> +pa_sbc_decode(const void *read_buf, size_t read_buf_size, void
> >>>> *write_buf, size_t write_buf_size, size_t *_decoded,
> >>>> + uint32_t *timestamp, void **codec_data) {
> >>>> +const struct rtp_header *header;
> >>>> +const struct rtp_payload *payload;
> >>>> +const vo
Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support
On Friday 14 December 2018 00:07:27 Huang-Huang Bao wrote:
> "a2dp-codecs.h" copied from bluez, then added a2dp_aptxhd_t, a2dp_ldac_t.
This does not excuse having broken code in pulseaudio. Atrac or big
endian definition seems to be really wrong.
Is not it stupid to copy+paste broken code from one project to another?
> I don't want to debate too much about naming.
Look, if other people comes up with something in the naming, then it
should be also reflected.
Bad naming just increase confusion for other people who start reading
code later. This is the fact.
> On 12/13/18 11:35 PM, Pali Rohár wrote:
> > On Thursday 13 December 2018 19:43:36 EHfive wrote:
> >> +#define A2DP_CODEC_SBC0x00
> >> +#define A2DP_CODEC_MPEG12 0x01
> >> +#define A2DP_CODEC_MPEG24 0x02
> >> +#define A2DP_CODEC_ATRAC 0x03
> > This is incorrect, Atrac codec has A2DP ID 0x04, see:
> > https://www.bluetooth.com/specifications/assigned-numbers/audio-video
> >
> >> +#define MAX_BITPOOL 64
> >> +#define MIN_BITPOOL 2
> > These two constants are SBC specific, so make them with SBC_ prefix.
> >
> >> +#define APTX_VENDOR_ID0x004f
> > This ID is allocated for APT Ltd. company. Not just for aptX codec. So
> > maybe better name is A2DP_VENDOR_APT_LIC_LTD?
> >
> >> +#define APTX_CODEC_ID 0x0001
> >> +
> >> +#define APTX_CHANNEL_MODE_MONO0x01
> >> +#define APTX_CHANNEL_MODE_STEREO 0x02
> >> +
> >> +#define APTX_SAMPLING_FREQ_16000 0x08
> >> +#define APTX_SAMPLING_FREQ_32000 0x04
> >> +#define APTX_SAMPLING_FREQ_44100 0x02
> >> +#define APTX_SAMPLING_FREQ_48000 0x01
> >> +
> >> +#define LDAC_VENDOR_ID0x012d
> > This ID is allocated for Sony Corporation company. Not just for LDAC
> > codec.
> >
> > See:
> > https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers
> >
> >> +#elif __BYTE_ORDER == __BIG_ENDIAN
> >> +
> >> +typedef struct {
> >> + uint8_t frequency:4;
> >> + uint8_t channel_mode:4;
> >> + uint8_t block_length:4;
> >> + uint8_t subbands:2;
> >> + uint8_t allocation_method:2;
> >> + uint8_t min_bitpool;
> >> + uint8_t max_bitpool;
> >> +} __attribute__ ((packed)) a2dp_sbc_t;
> >> +
> >> +typedef struct {
> >> + uint8_t layer:3;
> >> + uint8_t crc:1;
> >> + uint8_t channel_mode:4;
> >> + uint8_t rfa:1;
> >> + uint8_t mpf:1;
> >> + uint8_t frequency:6;
> >> + uint16_t bitrate;
> > This value for big endian systems seems to be broken. As you need to
> > store value in little endian. So maybe define as?
> >
> > uint8_t bitrate_low;
> > uint8_t bitrate_high;
> >
> > Or as
> >
> > uint8_t bitrate[2];
> >
> > Or better drop big endian support? Broken big endian support is not
> > useful at all.
> >
> >> +static size_t
> >> +pa_sbc_decode(const void *read_buf, size_t read_buf_size, void
> >> *write_buf, size_t write_buf_size, size_t *_decoded,
> >> + uint32_t *timestamp, void **codec_data) {
> >> +const struct rtp_header *header;
> >> +const struct rtp_payload *payload;
> >> +const void *p;
> >> +void *d;
> >> +size_t to_write, to_decode;
> >> +size_t total_written = 0;
> >> +sbc_info_t *sbc_info = *codec_data;
> >> +pa_assert(sbc_info);
> >> +
> >> +header = read_buf;
> >> +payload = (struct rtp_payload *) ((uint8_t *) read_buf +
> >> sizeof(*header));
> >> +
> >> +*timestamp = ntohl(header->timestamp);
> >> +
> >> +p = (uint8_t *) read_buf + sizeof(*header) + sizeof(*payload);
> >> +to_decode = read_buf_size - sizeof(*header) - sizeof(*payload);
> >> +
> >> +d = write_buf;
> >> +to_write = write_buf_size;
> >> +
> >> +*_decoded = 0;
> >> +while (PA_LIKELY(to_decode > 0)) {
> >> +size_t written;
> >> +ssize_t decoded;
> >> +
> >> +decoded = sbc_decode(_info->sbc,
> >> + p, to_decode,
> >> + d, to_write,
> >> + );
> >> +
> >> +if (PA_UNLIKELY(decoded <= 0)) {
> >> +pa_log_error("SBC decoding error (%
Re: [pulseaudio-discuss] [PATCH 3/4] Add A2DP aptX, aptX HD codecs support
On Thursday 13 December 2018 18:42:11 Pasi Kärkkäinen wrote: > On Thu, Dec 13, 2018 at 04:36:59PM +0100, Pali Rohár wrote: > > What is the purpose of adding aptX codec (non HD variant)? It is not > > better then default and mandatory SBC codec. > > > > When using AptX codec one can be certain it's always 352 kbps bitrate. > with SBC you never know what you end up using.. This is just because of current implementation of SBC in pulseaudio. Why not rather invest time to properly support SBC at high quality or allow user to set quality / show user current quality? SBC is mandatory and supported by all devices, aptX only by some (plus codec is proprietary). Adding aptX codec just because SBC implementation in pulseaudio is not so "nice" is not a good argument. > So it's good to have normal (non-HD) AptX supported aswell. > > > -- > > Pali Rohár > > pali.ro...@gmail.com > > > -- Pasi > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 3/4] Add A2DP aptX, aptX HD codecs support
On Thursday 13 December 2018 19:43:38 EHfive wrote: > diff --git a/src/modules/bluetooth/a2dp/a2dp-codecs.h > b/src/modules/bluetooth/a2dp/a2dp-codecs.h > index aefafb635..a6f054aec 100644 > --- a/src/modules/bluetooth/a2dp/a2dp-codecs.h > +++ b/src/modules/bluetooth/a2dp/a2dp-codecs.h > @@ -141,6 +141,9 @@ > #define APTX_SAMPLING_FREQ_44100 0x02 > #define APTX_SAMPLING_FREQ_48000 0x01 > > +#define APTX_HD_VENDOR_ID0x00D7 This ID is assigned to Qualcomm Technologies, Inc. Not for aptX HD codec, or aptX HD vendor. > +#define APTX_HD_CODEC_ID 0x0024 > + > #define LDAC_VENDOR_ID 0x012d > #define LDAC_CODEC_ID0x00aa > I wrote alternative implementation of aptX codec support for pulseaudio. It does not use big ffmpeg, but rather small libopenaptx library from https://github.com/pali/libopenaptx Patches are already in mailing list... Anyway, aptX decoder (both hd and non-hd variants) in ffmpeg has delay of about 90 samples. I have already some idea how to fix... and will try to implement it in libopenaptx. (Recompiling ffmpeg just for testing and debugging one codec is big pain; small library is better for this). -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 3/4] Add A2DP aptX, aptX HD codecs support
What is the purpose of adding aptX codec (non HD variant)? It is not better then default and mandatory SBC codec. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support
On Thursday 13 December 2018 19:43:36 EHfive wrote:
> +#define A2DP_CODEC_SBC 0x00
> +#define A2DP_CODEC_MPEG120x01
> +#define A2DP_CODEC_MPEG240x02
> +#define A2DP_CODEC_ATRAC 0x03
This is incorrect, Atrac codec has A2DP ID 0x04, see:
https://www.bluetooth.com/specifications/assigned-numbers/audio-video
> +#define MAX_BITPOOL 64
> +#define MIN_BITPOOL 2
These two constants are SBC specific, so make them with SBC_ prefix.
> +#define APTX_VENDOR_ID 0x004f
This ID is allocated for APT Ltd. company. Not just for aptX codec. So
maybe better name is A2DP_VENDOR_APT_LIC_LTD?
> +#define APTX_CODEC_ID0x0001
> +
> +#define APTX_CHANNEL_MODE_MONO 0x01
> +#define APTX_CHANNEL_MODE_STEREO 0x02
> +
> +#define APTX_SAMPLING_FREQ_16000 0x08
> +#define APTX_SAMPLING_FREQ_32000 0x04
> +#define APTX_SAMPLING_FREQ_44100 0x02
> +#define APTX_SAMPLING_FREQ_48000 0x01
> +
> +#define LDAC_VENDOR_ID 0x012d
This ID is allocated for Sony Corporation company. Not just for LDAC
codec.
See:
https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers
> +#elif __BYTE_ORDER == __BIG_ENDIAN
> +
> +typedef struct {
> + uint8_t frequency:4;
> + uint8_t channel_mode:4;
> + uint8_t block_length:4;
> + uint8_t subbands:2;
> + uint8_t allocation_method:2;
> + uint8_t min_bitpool;
> + uint8_t max_bitpool;
> +} __attribute__ ((packed)) a2dp_sbc_t;
> +
> +typedef struct {
> + uint8_t layer:3;
> + uint8_t crc:1;
> + uint8_t channel_mode:4;
> + uint8_t rfa:1;
> + uint8_t mpf:1;
> + uint8_t frequency:6;
> + uint16_t bitrate;
This value for big endian systems seems to be broken. As you need to
store value in little endian. So maybe define as?
uint8_t bitrate_low;
uint8_t bitrate_high;
Or as
uint8_t bitrate[2];
Or better drop big endian support? Broken big endian support is not
useful at all.
> +static size_t
> +pa_sbc_decode(const void *read_buf, size_t read_buf_size, void *write_buf,
> size_t write_buf_size, size_t *_decoded,
> + uint32_t *timestamp, void **codec_data) {
> +const struct rtp_header *header;
> +const struct rtp_payload *payload;
> +const void *p;
> +void *d;
> +size_t to_write, to_decode;
> +size_t total_written = 0;
> +sbc_info_t *sbc_info = *codec_data;
> +pa_assert(sbc_info);
> +
> +header = read_buf;
> +payload = (struct rtp_payload *) ((uint8_t *) read_buf +
> sizeof(*header));
> +
> +*timestamp = ntohl(header->timestamp);
> +
> +p = (uint8_t *) read_buf + sizeof(*header) + sizeof(*payload);
> +to_decode = read_buf_size - sizeof(*header) - sizeof(*payload);
> +
> +d = write_buf;
> +to_write = write_buf_size;
> +
> +*_decoded = 0;
> +while (PA_LIKELY(to_decode > 0)) {
> +size_t written;
> +ssize_t decoded;
> +
> +decoded = sbc_decode(_info->sbc,
> + p, to_decode,
> + d, to_write,
> + );
> +
> +if (PA_UNLIKELY(decoded <= 0)) {
> +pa_log_error("SBC decoding error (%li)", (long) decoded);
> +*_decoded = 0;
> +return 0;
> +}
> +
> +total_written += written;
> +
> +/* Reset frame length, it can be changed due to bitpool change */
> +sbc_info->frame_length = sbc_get_frame_length(_info->sbc);
> +
> +pa_assert_fp((size_t) decoded <= to_decode);
> +pa_assert_fp((size_t) decoded == sbc_info->frame_length);
> +
> +pa_assert_fp((size_t) written == sbc_info->codesize);
> +
> +*_decoded += decoded;
> +p = (const uint8_t *) p + decoded;
> +to_decode -= decoded;
> +
> +d = (uint8_t *) d + written;
> +to_write -= written;
> +}
> +
> +return total_written;
> +}
Seems that this decode procedure with while loop is similar/same for all
codecs. Months ago I sent to this mailing list different proposal for
codec API which tries to "fix" also this problem. Look into mailing list
archive for "[PATCH v2 1/2] Modular API for Bluetooth A2DP codec".
> +#define A2DP_SOURCE_ENDPOINT "/MediaEndpoint/A2DPSource"
> +#define A2DP_SINK_ENDPOINT "/MediaEndpoint/A2DPSink"
> +
> +#define A2DP_SBC_SRC_ENDPOINT A2DP_SOURCE_ENDPOINT "/SBC"
> +#define A2DP_SBC_SNK_ENDPOINT A2DP_SINK_ENDPOINT "/SBC"
> +
> +#define A2DP_VENDOR_SRC_ENDPOINT A2DP_SOURCE_ENDPOINT "/
Re: [pulseaudio-discuss] [PATCH v2 2/2] Bluetooth A2DP aptX codec support
On Tuesday 18 September 2018 13:55:08 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Mon, Sep 17, 2018 at 3:27 PM, Tanu Kaskinen wrote: > > On Thu, 2018-09-13 at 11:12 +0200, Pali Rohár wrote: > >> On Wednesday 05 September 2018 13:57:08 Tanu Kaskinen wrote: > >> > > + Bluetooth A2DP aptX codec (optional) ### > >> > > + > >> > > +AC_ARG_ENABLE([aptx], > >> > > +AS_HELP_STRING([--disable-aptx],[Disable optional bluetooth A2DP > >> > > aptX codec support (via libopenaptx)])) > >> > > + > >> > > +AS_IF([test "x$HAVE_BLUEZ_5" = "x1" && test "x$enable_aptx" != "xno"], > >> > > +[AC_CHECK_HEADER([openaptx.h], > >> > > +[AC_CHECK_LIB([openaptx], [aptx_init], [HAVE_OPENAPTX=1], > >> > > [HAVE_OPENAPTX=0])], > >> > > +[HAVE_OPENAPTX=0])]) > >> > > >> > Have you considered providing a .pc file? Now we have to hardcode the > >> > openaptx specific CFLAGS and LIBADD for libbluez5-util. If you ever > >> > need to add new flags, all openaptx users need to update their build > >> > systems. Also, if the library is installed to a non-standard location, > >> > the .pc file can set the -L and -I flags to point to the right place. > >> > >> Intension is that library is small and does not need any special cflags > >> or ldflags. So .pc file is not needed at all. And if library or include > >> file is in non-standard location then user really need to specify where > >> it is. But same argument can be used when .pc file is in non-standard > >> location. User again need to do some magic. > > Long term I think it is best to use autotools to properly generate the > .pc file, etc, otherwise it might be difficult for distros to pick > this up. I might be able to help you with that if you are willing to > accept patches. Because I know autotools, how to use it and how it works, I'm saying No. For small library I explicitly chose something which is easy and not big hell moloch. I really do not need anything special nor any custom or specific functionality. Also library has no dependences. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 1/2] Modular API for Bluetooth A2DP codec
On Monday 17 September 2018 15:02:18 Tanu Kaskinen wrote: > (I sent my review both to you and to the list, but you replied only > privately - probably not on purpose. I'll send this mail only to the > list.) Sorry for that. I was not my intension. > On Thu, 2018-09-13 at 10:54 +0200, Pali Rohár wrote: > > On Tuesday 04 September 2018 11:44:10 Tanu Kaskinen wrote: > > > Using libopenaptx directly > > > doesn't prevent us from switching to GStreamer later if someone writes > > > the code. > > > > Yes, that is truth. > > > > > Another point that was raised that the codec choice shouldn't be bound > > > to the card profile. I tend to agree with that. There are situations > > > where module-bluetooth-policy or the user only wants to switch from HSP > > > to A2DP and not care about the codec. You asked how the codec should be > > > negotiated or switched by the user if it's not bound to the profile. > > > Regarding negotiation, we can add a hook that module-bluetooth-policy > > > can use to make the codec decision (if module-bluetooth-policy isn't > > > loaded, SBC seems like a sensible default). > > > > > > Is there a need for the user to be able to choose the codec? Shouldn't > > > we always automatically pick the highest-quality one? > > > > What is "highest-quality" codec? How you would compare e.g. our SBC > > implementation which can dynamically change bitpool and therefore > > quality? > > > > Also how you can compare... has SBC higher quality as MPEG1? Or has aptX > > HD higher quality as MPEG/AAC? > > Fair point. > > > Until now everybody said that aptX "is better" then SBC. But today it > > does not look like it is truth. > > > > Also if you have MP3 files on disk, then the best quality which you can > > achieve is to passthru it without any reencoding. In other cases AAC can > > be better. > > Passthrough is a separate thing. If someone implements passthrough > support for bluetooth and a client requests it, we should always switch > to the requested codec regardless of other user preferences. > > > So answer to this question depends on lot of things and either user > > itself or user's application would better it. > > > > > I'm not against > > > adding the functionality, it would be useful for testing if nothing > > > else. It just doesn't seem very important. > > > > > > We could have a "preferred-a2dp-codec" option in bluetooth.conf (that > > > file doesn't exist, but can be added). A per-card option would be > > > possible too, as would be having both a global option that could be > > > overridden with a per-card option. > > > > Preferred codec is not helpful. The only mandatory codec is SBC, all > > other are optional. And basically every manufactor supports different > > set of codecs. So at least some kind of list or partially ordered set of > > codec is needed. > > Sure, a priority list can better capture the user preferences, but > surely a "preferred codec" option is better than nothing. A priority > list of codecs isn't an obvious ultimate solution either, since some > codecs have adjustable parameters that can affect the codec preference > ranking. For example, someone's preference might be: > > SBC (high bitrate) > aptX > SBC (medium bitrate) > > It's not clear to me how fine-grained control is optimal. A solution > that allows specifying a priority list with an arbitrary number of > codec parameters would obviously be sufficient, but it's unlikely we > want that complex system. The best thing is allowing user to choose codec itself (in some GUI under section additional settings, or similar) and ideally remember it for every device separately. > Real use cases are needed. I can't provide any, since I don't use > bluetooth (and if I did, I probably wouldn't bother with the codec > settings at all - SBC and aptX seem both good enough for me). Now that > you found out that aptX isn't that great after all, do you have > personal use for aptX either? This is interesting question. For more then month I'm using aptX codec and I have not hear difference or something which would disturb me. So I probably really do not need aptX at all. > > > For runtime configuration, we can add a command to set the codec > > > preference. This should be done with the message API that Georg Chini > > > has been working on (not yet finished). There's then need for saving > > > the choice too. We can either introduce a new database for bluetooth > > > stuff, or we can add
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On Thursday 13 September 2018 11:23:58 Tanu Kaskinen wrote: > On Wed, 2018-09-12 at 19:03 +0300, Luiz Augusto von Dentz wrote: > > On Wed, Sep 12, 2018 at 1:42 PM, Pali Rohár wrote: > > > 1) What to do with aptX? It is really useful for users to have it in > > > Linux & pulseaudio? Because it looks like that the only thing which it > > > has better is lower latency. But can pulseaudio on Linux system really > > > achieve it? > > > > I don't think, not the level of latency necessary for speech and to > > avoid lip sync issues, so that would leave aptX at the same category > > as SBC. > > How likely is it that a device that supports aptX only supports lower > SBC bitrates? In such situation aptX would apparently be an > improvement, but maybe that doesn't happen in real life. Such combination does not make sense for me. I do not see reason why headset would support only low SBC mode which is either due to slow bluetooth stack or slow DSP and also aptX at higher bitrate... I have not heard about such hardware. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On Wednesday 12 September 2018 19:03:41 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Wed, Sep 12, 2018 at 1:42 PM, Pali Rohár wrote: > > Hello! > > > > I would like to let you know that Serge from soundexpert.org did in last > > month some research on aptX and its quality. Detailed article is on the > > following website, specially see parts added around "August 2018": > > > > http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx > > > > > > Conclusions: > > > > aptX codec used in BT applications is no better than SBC@328. Despite > > slightly lower algorithmic delay of aptX both SBC and aptX codecs > > provide the same 100-150ms latency in real-life BT applications. > > > > If you hear the difference between SBC and aptX in some BT product, > > there can be only two explanations - placebo effect or using SBC in > > Middle or Low Quality modes. > > > > AptX is just a copper-less overpriced audio cable. > > > > aptX HD is high-bitrate version of aptX. It has clearly noticeable > > increase in sound quality (not dramatic though taking into account the > > increase in bitrate) > > > > > > And it just confirms my own testing. Whatever I did I was not able to > > either hear or see difference between aptX and SBC encoded-->decoded > > audio. > > > > I had discussion with Serge and there are some ideas which Linux > > Bluetooth A2DP software could supports: > > > > 1) Allow user to specify SBC codec quality. In most cases, including > > pulseaudio, SBC quality is chosen either to middle or low, not to > > maximum bitpool. In some cases SBC at high quality can provide better > > quality as aptX and more important -- SBC is supported by all headsets. > > > > 2) Show user current SBC codec quality. So user would know what was > > chosen and what should expect. I was told that Windows's Toshiba > > bluetooth stack has support for this indication. > > > > 3) In some cases SBC SNR bit allocation method can provide better > > quality as SBC loudness method. > > > > So then I could ask question: > > > > 1) What to do with aptX? It is really useful for users to have it in > > Linux & pulseaudio? Because it looks like that the only thing which it > > has better is lower latency. But can pulseaudio on Linux system really > > achieve it? > > I don't think, not the level of latency necessary for speech and to > avoid lip sync issues, so that would leave aptX at the same category > as SBC. That is what I thought. So seems that aptX (non-HD) has no benefit over SBC in pulseaudio. > > 2) Should we rather look at increasing quality of SBC codec in > > pulseaudio? And if yes, how should be quality of SBC configured? Via > > profiles? Or to invent some new protocol options? Can we increase > > default SBC bitpool allocation? > > I recall setting it to 64 before, but perhaps we are using 53 given > that most headset set that as maximum influenced by the spec suggested > values, I wouldn't go above 512kbit/s since then leave very little > room for any other traffic. So... seems that maximum value is 53: https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/bluetooth/bluez5-util.c#n1599 https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/bluetooth/bluez5-util.c#n1260 Even when headset advertise higher value. Should not we increase when headset support higher value? Also question about allocation method SNR vs loudness. Default is loudness. > > 3) If aptX is decided as useless, what about aptX HD codec? aptX HD > > codec is supported by less products (currently I do not own any), but > > this one may provide better quality as SBC according to that research. > > That is probably useful as something that provides a quality > improvement compared to SBC. Ok, I would let this part to other people as currently I do not have aptX HD native hardware. > > PS: That aptX research is the first and the only one about which I know. > > All other information about quality or other details which I found on > > internet are just marking informations. > > I had some suspicion before given that no manufacturer provided any > evidence aptX would beat SBC at the same bitrate, it is probably > better just because we are stuck at 53 bitpool with SBC while aptX can > probably have much higher bitrate. Anyway thanks to the researcher for > putting the time to evaluate the codecs we now have a good reference > for the quality each codec provides. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Bluetooth A2DP aptX codec quality
Hello! I would like to let you know that Serge from soundexpert.org did in last month some research on aptX and its quality. Detailed article is on the following website, specially see parts added around "August 2018": http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx Conclusions: aptX codec used in BT applications is no better than SBC@328. Despite slightly lower algorithmic delay of aptX both SBC and aptX codecs provide the same 100-150ms latency in real-life BT applications. If you hear the difference between SBC and aptX in some BT product, there can be only two explanations - placebo effect or using SBC in Middle or Low Quality modes. AptX is just a copper-less overpriced audio cable. aptX HD is high-bitrate version of aptX. It has clearly noticeable increase in sound quality (not dramatic though taking into account the increase in bitrate) And it just confirms my own testing. Whatever I did I was not able to either hear or see difference between aptX and SBC encoded-->decoded audio. I had discussion with Serge and there are some ideas which Linux Bluetooth A2DP software could supports: 1) Allow user to specify SBC codec quality. In most cases, including pulseaudio, SBC quality is chosen either to middle or low, not to maximum bitpool. In some cases SBC at high quality can provide better quality as aptX and more important -- SBC is supported by all headsets. 2) Show user current SBC codec quality. So user would know what was chosen and what should expect. I was told that Windows's Toshiba bluetooth stack has support for this indication. 3) In some cases SBC SNR bit allocation method can provide better quality as SBC loudness method. So then I could ask question: 1) What to do with aptX? It is really useful for users to have it in Linux & pulseaudio? Because it looks like that the only thing which it has better is lower latency. But can pulseaudio on Linux system really achieve it? 2) Should we rather look at increasing quality of SBC codec in pulseaudio? And if yes, how should be quality of SBC configured? Via profiles? Or to invent some new protocol options? Can we increase default SBC bitpool allocation? 3) If aptX is decided as useless, what about aptX HD codec? aptX HD codec is supported by less products (currently I do not own any), but this one may provide better quality as SBC according to that research. PS: That aptX research is the first and the only one about which I know. All other information about quality or other details which I found on internet are just marking informations. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] bluetooth: Wideband speech implementaion
On Wednesday 15 August 2018 09:24:04 Sathish Narasimman wrote: > Hi Pali, > > On Wed, Aug 15, 2018 at 1:31 AM, Pali Rohár wrote: > > > On Tuesday 14 August 2018 22:49:27 Luiz Augusto von Dentz wrote: > > > Hi Pali, > > > > > > On Tue, Aug 14, 2018 at 10:28 PM Pali Rohár > > wrote: > > > > > > > > On Tuesday 14 August 2018 19:44:49 Sathish Narasimman wrote: > > > > > mSBC-encoded streams for HFP. The wideband speec encoding and > > decoding > > > > > is implemeted with this patch. This patch was refered from original > > > > > patch of Joao Paula Rechi Vita and was verified with the supported > > > > > bluetooth controller. > > > > > > > > > > Signed-off-by: Sathish Narasimman > > > > > --- > > > > > src/modules/bluetooth/backend-ofono.c| 20 +- > > > > > src/modules/bluetooth/module-bluez5-device.c | 371 > > ++- > > > > > 2 files changed, 377 insertions(+), 14 deletions(-) > > > > > > > > Hi! This looks great. What about support also for other backends, not > > > > only ofono? > > > > > > Afaik only oFono supports WBS negotiation. > > > > IIRC codec negotiation is done via AT commands. Therefore native backend > > and its AT parser could be extended to support it. > > > > AFAIK i was not able to find Handsfree profile in native backend. I see > only the headset profile in which codec negotiation is not available. > please point me the right place where AT commands are implented in PA for > HFP profile in native backend. i can try the best. rfcomm_io_callback function in backend-native.c. There is implemented AT parser. For codec selection is needed to issue some AT command, therefore that code is needed to extend... -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] bluetooth: Wideband speech implementaion
On Tuesday 14 August 2018 22:49:27 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Tue, Aug 14, 2018 at 10:28 PM Pali Rohár wrote: > > > > On Tuesday 14 August 2018 19:44:49 Sathish Narasimman wrote: > > > mSBC-encoded streams for HFP. The wideband speec encoding and decoding > > > is implemeted with this patch. This patch was refered from original > > > patch of Joao Paula Rechi Vita and was verified with the supported > > > bluetooth controller. > > > > > > Signed-off-by: Sathish Narasimman > > > --- > > > src/modules/bluetooth/backend-ofono.c| 20 +- > > > src/modules/bluetooth/module-bluez5-device.c | 371 > > > ++- > > > 2 files changed, 377 insertions(+), 14 deletions(-) > > > > Hi! This looks great. What about support also for other backends, not > > only ofono? > > Afaik only oFono supports WBS negotiation. IIRC codec negotiation is done via AT commands. Therefore native backend and its AT parser could be extended to support it. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] bluetooth: Wideband speech implementaion
On Tuesday 14 August 2018 19:44:49 Sathish Narasimman wrote: > mSBC-encoded streams for HFP. The wideband speec encoding and decoding > is implemeted with this patch. This patch was refered from original > patch of Joao Paula Rechi Vita and was verified with the supported > bluetooth controller. > > Signed-off-by: Sathish Narasimman > --- > src/modules/bluetooth/backend-ofono.c| 20 +- > src/modules/bluetooth/module-bluez5-device.c | 371 > ++- > 2 files changed, 377 insertions(+), 14 deletions(-) Hi! This looks great. What about support also for other backends, not only ofono? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Thursday 09 August 2018 16:39:09 ValdikSS wrote: > On 06.07.2018 13:25, Pali Rohár wrote: > > I did some investigation and basically this is the list of all known > > codecs used in A2DP: > > > > Mandatory: > > 0x00 - SBC > > > > Optional: > > 0x01 - MPEG-1,2 (aka MP3) > > 0x02 - MPEG-2,4 (aka AAC) > > 0x04 - ATRAC > > > > Vendor specific: > > 0xFF 0x004F 0x01 - aptX > > 0xFF 0x000A 0x01 - FastStream > > 0xFF 0x000A 0x02 - aptX Low Latency > > 0xFF 0x00D7 0x24 - aptX HD > > 0xFF 0x012D 0xAA - LDAC > > > > And also I found some references that some sort of raw 16bit PCM samples > > via codec id 0x05 are used... But I have never seen such product. > > > > Could it be Samsung UHQ-BT? > https://www.samsung.com/uk/mobile-accessories/level-on-pro-wireless-headset-pn920/EO-PN920CFEGWW/ > > There are also: > 0xFF 0x0075 0x0102 — Samsung HD (found on Samsung LEVEL Link) > Value hex dump: 7a > > 0xFF 0x000A 0x0103 — Unknown codec found on Bose QuietComfort QC35 II > Value hex dump: 07 06 00 00 ff ff 02 35 > > 0xFF 0x000A 0x0104 — Unknown codec found on Bose QuietComfort QC35 II > Value hex dump: 07 08 00 02 c0 ff 8c 84 e2 00 > > > Samsung LEVEL on/on pro also have support for what Samsung call "Scalable > Codec". Interesting... I have not found any information about these A2DP codecs. I guess that "0xFF 0x0075 0x0102" would be that Samsung Scalable Codec. But others two allocated in QTIL vendor ID seems like some Qualcomm specific codec, or some variant of low latency codec or variant of aptX codec. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support
On Sunday 05 August 2018 11:08:25 Arun Raghavan wrote: > On Fri, 3 Aug 2018, at 7:13 PM, ValdikSS wrote: > > On 03.08.2018 16:32, Pali Rohár wrote: > > > On Friday 03 August 2018 16:22:05 ValdikSS wrote: > > >> Doesn't work for me with Intel 7260 Bluetooth 4.0 and RealForce > > >> OverDrive D1. > > >> > > >> When I connect headphones and change Pulseaudio profile from "Off" to > > >> "High Fidelity SBC playback (a2dp sink)", everything works as expected > > >> with SBC. > > >> Profile does not switch if I choose "High Fidelity aptX playback (a2dp > > >> sink)" when SBC profile is already active, log message: > > >> > > >> W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to > > >> a2dp_aptx_sink: Not connected > > > Profile switching does not work -- bluez does not provide API for it. > > > > > > Codec is chosen by bluez and headset when doing handshake. Try to > > > initialize A2DP connection from computer, not from headset. Then bluez > > > should choose aptX codec in case your headset supports it. > > > > Works now: > > AVDTP: Set Configuration (0x03) Command (0x00) type 0x00 label 10 > > nosp 0 > > ACP SEID: 5 > > INT SEID: 1 > > Service Category: Media Transport (0x01) > > Service Category: Media Codec (0x07) > > Media Type: Audio (0x00) > > Media Codec: Non-A2DP (0xff) > > Vendor ID: APT Licensing Ltd. (0x004f) > > Vendor Specific Codec ID: aptX (0x0001) > > Frequency: 44100 (0x20) > > Channel Mode: Stereo (0x02) > > > > > > > >> When I try to switch to aptX profile from "off" profile, pulseaudio > > >> crashes: > > >> > > >> E: [pulseaudio] module-bluez5-device.c: Assertion '!u->thread' failed at > > >> modules/bluetooth/module-bluez5-device.c:1491, function start_thread(). > > >> Aborting. > > > Try: > > > > > > $ pactl unload-module module-bluetooth-policy > > > > > > Seems that policy module needs to be fixed for new aptx profiles. > > > > That works, thanks. > > > > > > > >> Thread 1 "pulseaudio" received signal SIGABRT, Aborted. > > >> 0x744edfeb in raise () from /lib64/libc.so.6 > > >> (gdb) bt > > >> #0 0x744edfeb in raise () from /lib64/libc.so.6 > > >> #1 0x744d85c1 in abort () from /lib64/libc.so.6 > > >> #2 0x7fff7f3dab45 in start_thread (u=u@entry=0x5593d640) at > > >> modules/bluetooth/module-bluez5-device.c:1491 > > >> #3 0x7fff7f3dd263 in set_profile_cb (c=, > > >> new_profile=0x559251a0) at > > >> modules/bluetooth/module-bluez5-device.c:1859 > > >> #4 0x77b5148e in pa_card_set_profile (c=c@entry=0x558e4c20, > > >> profile=profile@entry=0x559251a0, save=save@entry=true) at > > >> pulsecore/card.c:318 > > >> #5 0x7fffe0a0362d in command_set_card_profile (pd=, > > >> command=, tag=127, t=, userdata= > >> out>) at pulsecore/protocol-native.c:4728 > > >> #6 0x76d83813 in pa_pdispatch_run (pd=0x55a2e4b0, > > >> packet=packet@entry=0x558a3020, > > >> ancil_data=ancil_data@entry=0x55975bf8, > > >> userdata=userdata@entry=0x558bebf0) at pulsecore/pdispatch.c:346 > > >> #7 0x7fffe0a0bee9 in pstream_packet_callback (p=0x55975960, > > >> packet=0x558a3020, ancil_data=0x55975bf8, > > >> userdata=0x558bebf0) at pulsecore/protocol-native.c:4951 > > >> #8 0x76d8629d in do_read (p=p@entry=0x55975960, > > >> re=re@entry=0x55975b28) at pulsecore/pstream.c:1012 > > >> #9 0x76d890eb in do_pstream_read_write (p=0x55975960) at > > >> pulsecore/pstream.c:248 > > >> #10 0x76d8949d in srb_callback (srb=0x558b0660, > > >> userdata=0x55975960) at pulsecore/pstream.c:287 > > >> #11 0x76d89d2a in srbchannel_rwloop (sr=0x558b0660) at > > >> pulsecore/srbchannel.c:190 > > >> #12 0x778fc8a8 in dispatch_pollfds (m=0x5576f120) at > > >> pulse/mainloop.c:140 > > >> #13 pa_mainloop_dispatch (m=m@entry=0x5576f120) at > > >> pulse/mainloop.c:898 > > >> #14 0x778fc
Re: [pulseaudio-discuss] Bi-directional Bluetooth A2DP
On Wednesday 08 August 2018 10:00:28 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Sat, Jul 28, 2018 at 10:34 PM, Pali Rohár wrote: > > Hi! > > > > Some Bluetooth A2DP codecs like aptX Low Latency or FastStream provides > > "backchannel" support for voice data. And it really in A2DP profile. > > > > It can be very useful as there is no need to switch between A2DP and HSP > > modes. > > > > Now I was able to get FastStream codec (rebranded SBC) working in > > PulseAudio. And in "btmon" I see that my headset started sending > > backchannel voice data in SBC codec. I decoded that dump and it is > > really SBC codec, voice is in very good quality, better then in > > HSP profile. I hope that bluez can send them to pulseaudio via file > > descriptor. > > The fd sent to PA is a socket which is already bi-directional. Ok. > > Question is, how to handle this configuration in pulseaudio? Should it > > be a new profile for bluetooth devices which would provides both sink > > and source? Because now A2DP is one-direction profile, not > > bi-directional. > > While A2DP only configures a single direction we can assume > bi-directional depending on the endpoint, so in theory all you have to > do is register an endpoint for FastStream and create both sink and > source when it is connected. That said note that A2DP uses L2CAP on > top of ACL link which is asynchronous so it may not be as low latency > as SCO, but I guess being able to chat while listening to stereo audio > is quite convenient in some situations (e.g. when gaming). I mean how to export this configuration from pulseaudio. If it should be a new profile on pulseaudio card, or something different. After correct bluez endpoint registration I was able to send data to headset which correctly played it -- this is working. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module
On Wednesday 08 August 2018 10:06:19 Luiz Augusto von Dentz wrote:
> Hi Pali,
>
> On Mon, Aug 6, 2018 at 11:03 AM, Pali Rohár wrote:
> > On Sunday 05 August 2018 15:59:05 ValdikSS wrote:
> >> On 30.07.2018 10:30, Pali Rohár wrote:
> >> > On Monday 30 July 2018 10:24:10 ValdikSS wrote:
> >> >>> ACL Data RX: Handle 256 flags 0x02 dlen 20 #109 [hci0]
> >> >>> 5.421906
> >> >> Channel: 66 len 16 [PSM 25 mode 0] {chan 2}
> >> >> AVDTP: Get Capabilities (0x02) Response Accept (0x02) type 0x00
> >> >> label 0 nosp 0
> >> >> Service Category: Media Transport (0x01)
> >> >> Service Category: Media Codec (0x07)
> >> >> Media Type: Audio (0x00)
> >> >> Media Codec: Non-A2DP (0xff)
> >> >> Vendor ID: Cambridge Silicon Radio (0x000a)
> >> >> Vendor Specific Codec ID: Unknown (0x0001)
> >> >> 03 23.#
> >> >>
> >> >>
> >> >> Am I misunderstanding the latest item? Is it not a FastStream?
> >> >
> >> > Yes, 0x000a/0x0001 is FastStream. "03" means that it supports both
> >> > sink and source, "2" means that it supports microphone source sampling
> >> > frequency 16kHz and "3" means that that is supports music sink sampling
> >> > frequency 48kHz and 41.1kHz.
> >> >
> >>
> >> How did you understand that? Do you have a documentation?
> >> I'm writing Wireshark protocol dissector and want to include FastStream
> >> too.
> >
> > Hi! Look at https://patchwork.freedesktop.org/patch/241444/ patch, into
> > file a2dp-codecs.h. I put there a2dp_faststream_t and FASTSTREAM_*
> > defines, so it should be enough for writing dissector.
>
> It doesn't look like we have FastStream decoding support in btmon either:
>
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/monitor/a2dp.c#n50
I think that all needed information for decoding those packets is in
that pulseaudio patch in a2dp-codecs.h file. So if somebody is going to
write dissector and would not be able to decode something, just ask me.
--
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support
On Friday 03 August 2018 12:45:51 Tanu Kaskinen wrote: > On Fri, 2018-08-03 at 10:33 +0200, Pali Rohár wrote: > > On Saturday 28 July 2018 17:34:51 Pali Rohár wrote: > > > This patch series moves A2DP codec code into new modules and add > > > support for Bluetooth A2DP aptX codec. > > > > > > Pali Rohár (2): > > > Modular API for Bluetooth A2DP codec > > > Bluetooth A2DP aptX codec support > > > > > > configure.ac | 19 + > > > src/Makefile.am | 14 +- > > > src/modules/bluetooth/a2dp-codecs.h | 123 +- > > > src/modules/bluetooth/bluez5-util.c | 377 +++-- > > > src/modules/bluetooth/bluez5-util.h | 12 +- > > > src/modules/bluetooth/module-bluez5-device.c | 542 > > > - > > > src/modules/bluetooth/pa-a2dp-codec-aptx.c | 297 ++ > > > src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 > > > +++ > > > src/modules/bluetooth/pa-a2dp-codec.h| 41 ++ > > > 9 files changed, 1393 insertions(+), 611 deletions(-) > > > create mode 100644 src/modules/bluetooth/pa-a2dp-codec-aptx.c > > > create mode 100644 src/modules/bluetooth/pa-a2dp-codec-sbc.c > > > create mode 100644 src/modules/bluetooth/pa-a2dp-codec.h > > > > Hello, can somebody review this patch series for aptX support? > > Yes, eventually. > > We're short on reviewer bandwidth - would you be interested in becoming > a regular reviewer yourself to improve the situation? Hi! I do not have time for reviewing all patches, nor I do not understand pulseaudio such deeply. I played more with bluetooth integration code, so I could help with reviewing bluetooth changes. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 1/2] Modular API for Bluetooth A2DP codec
On Sunday 05 August 2018 11:07:23 Arun Raghavan wrote: > On Sat, 28 Jul 2018, at 9:04 PM, Pali Rohár wrote: > > Move current SBC codec implementation into separate source file and use > > this new API for providing all needed functionality for Bluetooth A2DP. > > > > Both bluez5-util and module-bluez5-device are changed to use this new > > modular codec API. > > --- > > src/Makefile.am | 9 +- > > src/modules/bluetooth/a2dp-codecs.h | 5 +- > > src/modules/bluetooth/bluez5-util.c | 331 +-- > > src/modules/bluetooth/bluez5-util.h | 10 +- > > src/modules/bluetooth/module-bluez5-device.c | 487 ++ > > src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 > > +++ > > src/modules/bluetooth/pa-a2dp-codec.h| 40 ++ > > 7 files changed, 851 insertions(+), 610 deletions(-) > > create mode 100644 src/modules/bluetooth/pa-a2dp-codec-sbc.c > > create mode 100644 src/modules/bluetooth/pa-a2dp-codec.h > > > > diff --git a/src/Makefile.am b/src/Makefile.am > > index f62e7d5c4..411b9e5e5 100644 > > --- a/src/Makefile.am > > +++ b/src/Makefile.am > > @@ -2117,6 +2117,7 @@ module_bluetooth_discover_la_CFLAGS = $(AM_CFLAGS) > > -DPA_MODULE_NAME=module_bluet > > libbluez5_util_la_SOURCES = \ > > modules/bluetooth/bluez5-util.c \ > > modules/bluetooth/bluez5-util.h \ > > + modules/bluetooth/pa-a2dp-codec.h \ > > modules/bluetooth/a2dp-codecs.h > > if HAVE_BLUEZ_5_OFONO_HEADSET > > libbluez5_util_la_SOURCES += \ > > @@ -2131,6 +2132,10 @@ libbluez5_util_la_LDFLAGS = -avoid-version > > libbluez5_util_la_LIBADD = $(MODULE_LIBADD) $(DBUS_LIBS) > > libbluez5_util_la_CFLAGS = $(AM_CFLAGS) $(DBUS_CFLAGS) > > > > +libbluez5_util_la_SOURCES += modules/bluetooth/pa-a2dp-codec-sbc.c > > +libbluez5_util_la_LIBADD += $(SBC_LIBS) > > +libbluez5_util_la_CFLAGS += $(SBC_CFLAGS) > > + > > module_bluez5_discover_la_SOURCES = modules/bluetooth/module-bluez5- > > discover.c > > module_bluez5_discover_la_LDFLAGS = $(MODULE_LDFLAGS) > > module_bluez5_discover_la_LIBADD = $(MODULE_LIBADD) $(DBUS_LIBS) > > libbluez5-util.la > > @@ -2138,8 +2143,8 @@ module_bluez5_discover_la_CFLAGS = $(AM_CFLAGS) $ > > (DBUS_CFLAGS) -DPA_MODULE_NAME= > > > > module_bluez5_device_la_SOURCES = modules/bluetooth/module-bluez5- > > device.c > > module_bluez5_device_la_LDFLAGS = $(MODULE_LDFLAGS) > > -module_bluez5_device_la_LIBADD = $(MODULE_LIBADD) $(SBC_LIBS) > > libbluez5-util.la > > -module_bluez5_device_la_CFLAGS = $(AM_CFLAGS) $(SBC_CFLAGS) - > > DPA_MODULE_NAME=module_bluez5_device > > +module_bluez5_device_la_LIBADD = $(MODULE_LIBADD) libbluez5-util.la > > +module_bluez5_device_la_CFLAGS = $(AM_CFLAGS) - > > DPA_MODULE_NAME=module_bluez5_device > > > > # Apple Airtunes/RAOP > > module_raop_sink_la_SOURCES = modules/raop/module-raop-sink.c > > diff --git a/src/modules/bluetooth/a2dp-codecs.h b/src/modules/ > > bluetooth/a2dp-codecs.h > > index 8afcfcb24..004975586 100644 > > --- a/src/modules/bluetooth/a2dp-codecs.h > > +++ b/src/modules/bluetooth/a2dp-codecs.h > > @@ -47,6 +47,9 @@ > > #define SBC_ALLOCATION_SNR (1 << 1) > > #define SBC_ALLOCATION_LOUDNESS1 > > > > +#define SBC_MIN_BITPOOL 2 > > +#define SBC_MAX_BITPOOL 64 > > + > > #define MPEG_CHANNEL_MODE_MONO (1 << 3) > > #define MPEG_CHANNEL_MODE_DUAL_CHANNEL (1 << 2) > > #define MPEG_CHANNEL_MODE_STEREO (1 << 1) > > @@ -63,8 +66,6 @@ > > #define MPEG_SAMPLING_FREQ_44100 (1 << 1) > > #define MPEG_SAMPLING_FREQ_48000 1 > > > > -#define MAX_BITPOOL 64 > > -#define MIN_BITPOOL 2 > > > > #if __BYTE_ORDER == __LITTLE_ENDIAN > > > > diff --git a/src/modules/bluetooth/bluez5-util.c b/src/modules/ > > bluetooth/bluez5-util.c > > index 2d8337317..9c4e3367b 100644 > > --- a/src/modules/bluetooth/bluez5-util.c > > +++ b/src/modules/bluetooth/bluez5-util.c > > @@ -2,6 +2,7 @@ > >This file is part of PulseAudio. > > > >Copyright 2008-2013 João Paulo Rechi Vita > > + Copyrigth 2018 Pali Rohár > > > >PulseAudio is free software; you can redistribute it and/or modify > >it under the terms of the GNU Lesser General Public License as > > @@ -33,7 +34,7 @@ > > #include > > #include > > > > -#include "a
Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module
On Sunday 05 August 2018 15:59:05 ValdikSS wrote:
> On 30.07.2018 10:30, Pali Rohár wrote:
> > On Monday 30 July 2018 10:24:10 ValdikSS wrote:
> >>> ACL Data RX: Handle 256 flags 0x02 dlen 20 #109 [hci0]
> >>> 5.421906
> >> Channel: 66 len 16 [PSM 25 mode 0] {chan 2}
> >> AVDTP: Get Capabilities (0x02) Response Accept (0x02) type 0x00
> >> label 0 nosp 0
> >> Service Category: Media Transport (0x01)
> >> Service Category: Media Codec (0x07)
> >> Media Type: Audio (0x00)
> >> Media Codec: Non-A2DP (0xff)
> >> Vendor ID: Cambridge Silicon Radio (0x000a)
> >> Vendor Specific Codec ID: Unknown (0x0001)
> >> 03 23 .#
> >>
> >>
> >> Am I misunderstanding the latest item? Is it not a FastStream?
> >
> > Yes, 0x000a/0x0001 is FastStream. "03" means that it supports both
> > sink and source, "2" means that it supports microphone source sampling
> > frequency 16kHz and "3" means that that is supports music sink sampling
> > frequency 48kHz and 41.1kHz.
> >
>
> How did you understand that? Do you have a documentation?
> I'm writing Wireshark protocol dissector and want to include FastStream too.
Hi! Look at https://patchwork.freedesktop.org/patch/241444/ patch, into
file a2dp-codecs.h. I put there a2dp_faststream_t and FASTSTREAM_*
defines, so it should be enough for writing dissector.
--
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support
Patch v1 I tested with pulseaudio 10 which is in Debian. Patch v2 I tested with master version. So I guess after some fixes it should work also with older versions... On Friday 03 August 2018 16:29:13 ValdikSS wrote: > I applied the patch to stable Pulseaudio 12.2. The patch successfully applies > with some fuzzing. Should it be compatible with 12.2 or should I check it > with master? > > > On 03.08.2018 16:22, ValdikSS wrote: > > Doesn't work for me with Intel 7260 Bluetooth 4.0 and RealForce OverDrive > > D1. > > > > When I connect headphones and change Pulseaudio profile from "Off" to "High > > Fidelity SBC playback (a2dp sink)", everything works as expected with SBC. > > Profile does not switch if I choose "High Fidelity aptX playback (a2dp > > sink)" when SBC profile is already active, log message: > > > > W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to > > a2dp_aptx_sink: Not connected > > > > When I try to switch to aptX profile from "off" profile, pulseaudio crashes: > > > > E: [pulseaudio] module-bluez5-device.c: Assertion '!u->thread' failed at > > modules/bluetooth/module-bluez5-device.c:1491, function start_thread(). > > Aborting. > > > > Thread 1 "pulseaudio" received signal SIGABRT, Aborted. > > 0x744edfeb in raise () from /lib64/libc.so.6 > > (gdb) bt > > #0 0x744edfeb in raise () from /lib64/libc.so.6 > > #1 0x744d85c1 in abort () from /lib64/libc.so.6 > > #2 0x7fff7f3dab45 in start_thread (u=u@entry=0x5593d640) at > > modules/bluetooth/module-bluez5-device.c:1491 > > #3 0x7fff7f3dd263 in set_profile_cb (c=, > > new_profile=0x559251a0) at modules/bluetooth/module-bluez5-device.c:1859 > > #4 0x77b5148e in pa_card_set_profile (c=c@entry=0x558e4c20, > > profile=profile@entry=0x559251a0, save=save@entry=true) at > > pulsecore/card.c:318 > > #5 0x7fffe0a0362d in command_set_card_profile (pd=, > > command=, tag=127, t=, userdata= > out>) at pulsecore/protocol-native.c:4728 > > #6 0x76d83813 in pa_pdispatch_run (pd=0x55a2e4b0, > > packet=packet@entry=0x558a3020, > > ancil_data=ancil_data@entry=0x55975bf8, > > userdata=userdata@entry=0x558bebf0) at pulsecore/pdispatch.c:346 > > #7 0x7fffe0a0bee9 in pstream_packet_callback (p=0x55975960, > > packet=0x558a3020, ancil_data=0x55975bf8, userdata=0x558bebf0) > > at pulsecore/protocol-native.c:4951 > > #8 0x76d8629d in do_read (p=p@entry=0x55975960, > > re=re@entry=0x55975b28) at pulsecore/pstream.c:1012 > > #9 0x76d890eb in do_pstream_read_write (p=0x55975960) at > > pulsecore/pstream.c:248 > > #10 0x76d8949d in srb_callback (srb=0x558b0660, > > userdata=0x55975960) at pulsecore/pstream.c:287 > > #11 0x76d89d2a in srbchannel_rwloop (sr=0x558b0660) at > > pulsecore/srbchannel.c:190 > > #12 0x778fc8a8 in dispatch_pollfds (m=0x5576f120) at > > pulse/mainloop.c:140 > > #13 pa_mainloop_dispatch (m=m@entry=0x5576f120) at pulse/mainloop.c:898 > > #14 0x778fcb80 in pa_mainloop_iterate (m=0x5576f120, > > block=, retval=0x7fffdc18) at pulse/mainloop.c:929 > > #15 0x778fcc20 in pa_mainloop_run (m=0x5576f120, > > retval=0x7fffdc18) at pulse/mainloop.c:945 > > #16 0x5555b0c9 in main (argc=, argv=) > > at daemon/main.c:1144 > > > > > > I haven't installed any patches for bluez itself. Should I? If yes, which > > exactly? > > I moved libopenaptx to autotools and made Fedora .spec file for openaptx, > > are you interested in autotools support for libopenaptx, should I create a > > pull request to your repository? > > > > > > On 28.07.2018 18:34, Pali Rohár wrote: > >> This patch series moves A2DP codec code into new modules and add > >> support for Bluetooth A2DP aptX codec. > >> > >> Pali Rohár (2): > >> Modular API for Bluetooth A2DP codec > >> Bluetooth A2DP aptX codec support > >> > >> configure.ac | 19 + > >> src/Makefile.am | 14 +- > >> src/modules/bluetooth/a2dp-codecs.h | 123 +- > >> src/modules/bluetooth/bluez5-util.c | 377 +++-- > >> src/modules/bluetooth/bluez5-util.h | 12 +- > >> src/modules/bluetooth/module-bluez5-device.c | 542 > >> +
Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support
On Friday 03 August 2018 16:22:05 ValdikSS wrote: > Doesn't work for me with Intel 7260 Bluetooth 4.0 and RealForce OverDrive D1. > > When I connect headphones and change Pulseaudio profile from "Off" to "High > Fidelity SBC playback (a2dp sink)", everything works as expected with SBC. > Profile does not switch if I choose "High Fidelity aptX playback (a2dp sink)" > when SBC profile is already active, log message: > > W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to > a2dp_aptx_sink: Not connected Profile switching does not work -- bluez does not provide API for it. Codec is chosen by bluez and headset when doing handshake. Try to initialize A2DP connection from computer, not from headset. Then bluez should choose aptX codec in case your headset supports it. > When I try to switch to aptX profile from "off" profile, pulseaudio crashes: > > E: [pulseaudio] module-bluez5-device.c: Assertion '!u->thread' failed at > modules/bluetooth/module-bluez5-device.c:1491, function start_thread(). > Aborting. Try: $ pactl unload-module module-bluetooth-policy Seems that policy module needs to be fixed for new aptx profiles. > Thread 1 "pulseaudio" received signal SIGABRT, Aborted. > 0x744edfeb in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x744edfeb in raise () from /lib64/libc.so.6 > #1 0x744d85c1 in abort () from /lib64/libc.so.6 > #2 0x7fff7f3dab45 in start_thread (u=u@entry=0x5593d640) at > modules/bluetooth/module-bluez5-device.c:1491 > #3 0x7fff7f3dd263 in set_profile_cb (c=, > new_profile=0x559251a0) at modules/bluetooth/module-bluez5-device.c:1859 > #4 0x77b5148e in pa_card_set_profile (c=c@entry=0x558e4c20, > profile=profile@entry=0x559251a0, save=save@entry=true) at > pulsecore/card.c:318 > #5 0x7fffe0a0362d in command_set_card_profile (pd=, > command=, tag=127, t=, userdata= out>) at pulsecore/protocol-native.c:4728 > #6 0x76d83813 in pa_pdispatch_run (pd=0x55a2e4b0, > packet=packet@entry=0x558a3020, > ancil_data=ancil_data@entry=0x55975bf8, > userdata=userdata@entry=0x558bebf0) at pulsecore/pdispatch.c:346 > #7 0x7fffe0a0bee9 in pstream_packet_callback (p=0x55975960, > packet=0x558a3020, ancil_data=0x55975bf8, userdata=0x558bebf0) at > pulsecore/protocol-native.c:4951 > #8 0x76d8629d in do_read (p=p@entry=0x55975960, > re=re@entry=0x55975b28) at pulsecore/pstream.c:1012 > #9 0x76d890eb in do_pstream_read_write (p=0x55975960) at > pulsecore/pstream.c:248 > #10 0x76d8949d in srb_callback (srb=0x558b0660, > userdata=0x55975960) at pulsecore/pstream.c:287 > #11 0x76d89d2a in srbchannel_rwloop (sr=0x558b0660) at > pulsecore/srbchannel.c:190 > #12 0x778fc8a8 in dispatch_pollfds (m=0x5576f120) at > pulse/mainloop.c:140 > #13 pa_mainloop_dispatch (m=m@entry=0x5576f120) at pulse/mainloop.c:898 > #14 0x778fcb80 in pa_mainloop_iterate (m=0x5576f120, > block=, retval=0x7fffdc18) at pulse/mainloop.c:929 > #15 0x778fcc20 in pa_mainloop_run (m=0x5576f120, > retval=0x7fffdc18) at pulse/mainloop.c:945 > #16 0xb0c9 in main (argc=, argv=) > at daemon/main.c:1144 > > > I haven't installed any patches for bluez itself. Should I? If yes, which > exactly? There are no bluez patches. > I moved libopenaptx to autotools and made Fedora .spec file for openaptx, are > you interested in autotools support for libopenaptx, should I create a pull > request to your repository? Nope, I'm not interested to use autohell, simple Makefile for simple library is enough :-) Basically I see no reason for conversion to tool which then just generate Makefile back. > > On 28.07.2018 18:34, Pali Rohár wrote: > > This patch series moves A2DP codec code into new modules and add > > support for Bluetooth A2DP aptX codec. > > > > Pali Rohár (2): > > Modular API for Bluetooth A2DP codec > > Bluetooth A2DP aptX codec support > > > > configure.ac | 19 + > > src/Makefile.am | 14 +- > > src/modules/bluetooth/a2dp-codecs.h | 123 +- > > src/modules/bluetooth/bluez5-util.c | 377 +++-- > > src/modules/bluetooth/bluez5-util.h | 12 +- > > src/modules/bluetooth/module-bluez5-device.c | 542 > > - > > src/modules/bluetooth/pa-a2dp-codec-aptx.c | 297 ++ > > src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 > > +++ > > src/modules/bluetooth/pa-a2dp-codec.h
Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support
On Saturday 28 July 2018 17:34:51 Pali Rohár wrote: > This patch series moves A2DP codec code into new modules and add > support for Bluetooth A2DP aptX codec. > > Pali Rohár (2): > Modular API for Bluetooth A2DP codec > Bluetooth A2DP aptX codec support > > configure.ac | 19 + > src/Makefile.am | 14 +- > src/modules/bluetooth/a2dp-codecs.h | 123 +- > src/modules/bluetooth/bluez5-util.c | 377 +++-- > src/modules/bluetooth/bluez5-util.h | 12 +- > src/modules/bluetooth/module-bluez5-device.c | 542 - > src/modules/bluetooth/pa-a2dp-codec-aptx.c | 297 ++ > src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 > +++ > src/modules/bluetooth/pa-a2dp-codec.h| 41 ++ > 9 files changed, 1393 insertions(+), 611 deletions(-) > create mode 100644 src/modules/bluetooth/pa-a2dp-codec-aptx.c > create mode 100644 src/modules/bluetooth/pa-a2dp-codec-sbc.c > create mode 100644 src/modules/bluetooth/pa-a2dp-codec.h Hello, can somebody review this patch series for aptX support? -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Monday 30 July 2018 17:04:55 Arun Raghavan wrote: > On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote: > [...] > > I looked and there is absolutely nothing about A2DP codec parameter > > selections. So really does not help. > > Okay, I feel like this conversation has been us talking past each other, so > let me try to summarise what I'm saying more clearly: > > 1. The BlueZ modules will, possibly based on modargs, expose a set of > supported codecs. Yes, that includes codec parameters, the knowledge of which > the endpoint needs to have. If you have ideas for making this modular, I'm > open to suggestions. > > 2. For the specific process of RTP payload/depayload and selection of a codec > implementation for encode/decode, I believe we should construct and use a > GStreamer bin, so as to not have to offload that choice to the system > integrator rather than having to make that choice in PulseAudio. I feel > strongly enough about not linking to specific codec implementations that any > approach that does that is a NACK from me. I realise we already have this for > SBC, but I do not want to add any more. Look at my last (v2) patch series for aptX. Here I created some modularisation of codecs and addition of another codecs would be easier. I have not used Gstreamer as it does not help me -- it does not provide module for A2DP codec negotiation (it is not static list of parameters as you imagine, but negotiation function) nor it does not support aptX codec. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module
On Monday 30 July 2018 10:24:10 ValdikSS wrote:
> > ACL Data RX: Handle 256 flags 0x02 dlen 20 #109 [hci0]
> > 5.421906
> Channel: 66 len 16 [PSM 25 mode 0] {chan 2}
> AVDTP: Get Capabilities (0x02) Response Accept (0x02) type 0x00 label 0
> nosp 0
> Service Category: Media Transport (0x01)
> Service Category: Media Codec (0x07)
> Media Type: Audio (0x00)
> Media Codec: Non-A2DP (0xff)
> Vendor ID: Cambridge Silicon Radio (0x000a)
> Vendor Specific Codec ID: Unknown (0x0001)
> 03 23 .#
>
>
> Am I misunderstanding the latest item? Is it not a FastStream?
Yes, 0x000a/0x0001 is FastStream. "03" means that it supports both
sink and source, "2" means that it supports microphone source sampling
frequency 16kHz and "3" means that that is supports music sink sampling
frequency 48kHz and 41.1kHz.
--
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module
On Monday 30 July 2018 06:30:14 valdikss wrote: > On 22.07.2018 14:37, Pali Rohár wrote: > > > > > Information which I have about FastStream: It is just SBC codec with > > following parameters: frequency rate 44.1 kHz or 48.0 kHz, Blocks 16, > > Sub-bands 8, Joint Stereo, Loudness and Bitpool = 29. So data rate = 212 > > kbps, packet size = 72*3+4 = 220 = DM5 and that DSP decoders round 71 > > bytes frames to 72 bytes. So I'm not sure how "low latency" it is. > > Normal SBC codec allows you to specify all those parameters. But > > FastStream has one additional feature: it supports backchannel for > > voice, so you do not have to switch between HFP/HSP and A2DP once you > > have incoming voice call. You can always use just A2DP with FastStream. > > > > Pulseaudio for SBC codec choose those parameters: Joint Stereo, Block > > 16, Sub-bands 8, Loudness. Frequency and bitpool depends on pulseaudio > > source. If bluetooth device does not support those parameters, > > pulseaudio lower values. So for me it looks like that FastStream matches > > default SBC pulseaudio configuration. > > > > Backchannel in FastStream for microphone voice again uses SBC codec with > > parameters: 16 KHz frequency rate, Blocks 16, Sub-bands 8, Loudness, > > Bitpool 32. So data rate = 72 kbps, packet size = 3*72 + 4 = 220 <= DM5. > > Which should be much better then CVSD codec at 8 kHz used in HFP/HSP. > > But is there really difference for voice data which comes from > > (probably poor) microphone integrated in headsets? > > > >> handful of Creative headsets that don't seem to support any other codecs. I > >> would put it between SBC and AAC. If someone prefers SBC over it, they know > >> enough about Bluetooth operation to qualify as a power user capable of > >> using > >> the config file to disable FastStream. > > > > Based on above details I would say it must be similar (or same?) as SBC > > for streaming. But who knows how is receiver implemented? I would not be > > surprised if some bluetooth headset have degraded SBC A2DP codec just > > for marketing purposed to show that other vendor codec is "better". > > > > As I said, I need to play with FastStream and see what my headset would > > do with it. For me interesting part is that backchannel support to avoid > > all problems with switching between A2DP and HSP/HFP profiles (to > > activate HSP/HFP only in case I have incoming call and after hangup > > switch back to AD2P...). > > It would be great if FastStream support could be implemented. I have a > headset with CSR (now Qualcomm) chip which supports SBC, AptX, AAC and > FastStream. The headset is rather unknown and not expensive (but surprisingly > good), so I assume FastStream support is not that rare. > If high-quality duplex audio is possible with Bluetooth, that would be very > handy for conferences. Now I have working sink support (sending audio from host to headset) for FastStream codec in pulseaudio. Voice backchannel support would be rather challenge as I do not know if bluez provides API for such thing. Anyway good news is that at least my Creative headset automatically starts sending voice data after FastStream codec is negotiated and via "btmon" I was able to capture voice data and via "sbcdec" decode them to check that it is correct and usable. May I ask which headset it is? I was told that FastStream is supported only by Creative headsets. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Monday 30 July 2018 08:15:22 Arun Raghavan wrote: > On Sat, 28 Jul 2018, at 9:01 PM, Pali Rohár wrote: > > On Monday 23 July 2018 18:42:52 Arun Raghavan wrote: > > > On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote: > > > > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: > > > > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár : > > > > > > > > > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > > > > > Pre-installed doesn't mean much tbh. It is easy enough for > > > > > > > packages to depend on it. > > > > > > > > > > > > Can pulseaudio build process enforce it? > > > > > > Does not need to, that can be taken care of at packaging time, and > > > potentially at module load. > > > > Ok, I would ask differently: Can pulseaudio at packaging time enforce it? > > That depends on the packaging system, but broadly the answer is yes. Ack. > > > > > 2. GStreamer can, in theory, wrap the needed libraries, and does > > > > > support third-party plugins, but does not properly encapsulate the > > > > > "give me packets ready to send via bluez" part. > > > > > > > > And until this is supported by external library (ffmpeg, gstreamer, > > > > whatever), pulseaudio needs to implement it itself. > > > > > > > > And encapsulating encoded data for bluez is not enough. It is needed > > > > also to negotiate codec selection with bluez and codec parameters (which > > > > are codec specific). > > > > > > GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be > > > used (and again, less codec-specific stuff that needs to be in PA). > > > > But it does not solve above problem when it is needed to do A2DP codec > > selection and negotiation. > > I don't get what you mean here. That above RTP payloading does not solve obvious problem for A2DP codec selection and negotiation of A2DP codec parameters. > > > > In previous email I wrote about idea to move that codec stuff into bluez > > > > itself as bluez code already handles it for android. > > > > > > > > > > > > > > > > > > To have working bluetooth support in pulseadio, pulseaudio > > > > > > > > needs to use > > > > > > > > external library for encoding which *always* provides support > > > > > > > > for SBC. > > > > > > > > And not only if user manually installs some special plugin for > > > > > > > > 3rd party > > > > > > > > library. (And not only SBC, but also those other aptX, MPEG1/2, > > > > > > > > AAC and > > > > > > > > LDAC codecs) > > > > > > > > > > > > > > So I continue to disagree. Using a generic framework and letting > > > > > > > other parts of the system select the codec implementation is what > > > > > > > makes sense for the widest set of use-cases (this also allows > > > > > > > products to ship their own implementations of a codec without > > > > > > > changing the PulseAudio code). > > > > > > > > > > > > Still this is not enough for bluetooth codec. For specific codec you > > > > > > need to create bluez dbus endpoint with codec specific parameters. > > > > > > Plus > > > > > > implement select and set methods to decide on codec parameters > > > > > > between > > > > > > pulseaudio and bluetooth headset. And finally to send encoded data > > > > > > you > > > > > > need to know how to send them. To which endpoint, how header looks > > > > > > like > > > > > > etc... Some codecs needs to wrap data into RTP (e.g. SBC), some > > > > > > must not > > > > > > have RTP (e.g. aptX). And after that comes data from codec encoder > > > > > > function. > > > > > > > > > > > > So is there any library which all above support? I have not find > > > > > > anything. Nor ffmpeg nor gstreamer. > > > > > > > > > > > > Which means that pulseaudio cannot delegate codec selection, codec > > > > > > initialization and codec encoding to some external library (yet). > > > > > > At least for SBC and presumably AAC, this is all possible with GStreamer > > > > No, it is not possible -- or at least I have not found any way how. I > > spend more time with it and Gstreamer does not support it. If you still > > think that it is possible, post a gstreamer code or link how to do that. > > Look at the rtpsbcpay/rtpsbcdepay elements, for example. I looked and there is absolutely nothing about A2DP codec parameter selections. So really does not help. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Bi-directional Bluetooth A2DP
Hi! Some Bluetooth A2DP codecs like aptX Low Latency or FastStream provides "backchannel" support for voice data. And it really in A2DP profile. It can be very useful as there is no need to switch between A2DP and HSP modes. Now I was able to get FastStream codec (rebranded SBC) working in PulseAudio. And in "btmon" I see that my headset started sending backchannel voice data in SBC codec. I decoded that dump and it is really SBC codec, voice is in very good quality, better then in HSP profile. I hope that bluez can send them to pulseaudio via file descriptor. Question is, how to handle this configuration in pulseaudio? Should it be a new profile for bluetooth devices which would provides both sink and source? Because now A2DP is one-direction profile, not bi-directional. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Sunday 22 July 2018 10:45:57 Pali Rohár wrote: > On Friday 20 July 2018 14:30:56 Luiz Augusto von Dentz wrote: > > Hi Pali, > > > > On Wed, Jul 11, 2018 at 11:07 AM, Pali Rohár wrote: > > > On Monday 09 July 2018 17:56:16 Pali Rohár wrote: > > >> On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote: > > >> > > 2) How should codec switching from pulseaudio API and > > >> > > pactl/pavucontrol > > >> > > looks like? > > >> > > > >> > Usually we don't force reconfiguration but perhaps we should, note > > >> > though that we may end up with audio glitches since we have to > > >> > disconnect A2DP stream to be able to reconfigure it with another > > >> > codec. > > >> > > >> Glitches are already there if you switch from A2DP profile to HSP in > > >> pavucontrol. So I do not see any problem if glitches happen also when > > >> switching between A2DP (SBC) and A2DP (aptX). > > >> > > >> > We would probably have to expose each endpoint so you could > > >> > peek and choose what the codec to use. > > >> > > >> Yes. I think this is required when pulseaudio is going to support more > > >> then one codec. > > > > > > So when this will happen? As for now this is blocker for proper support > > > of multiple codecs in pulseaudio. > > > > > > We need some dbus method call which will tell bluez which endpoint > > > (registered by pulseaudio) should be used now for particular bluetooth > > > A2DP device. > > > > I can give you some pointers on how to expose the endpoints with > > MediaEndpoint interface. > > Ok. Until that, I sent a new version of aptX patch which let codec selection to bluez. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH v2 1/2] Modular API for Bluetooth A2DP codec
Move current SBC codec implementation into separate source file and use
this new API for providing all needed functionality for Bluetooth A2DP.
Both bluez5-util and module-bluez5-device are changed to use this new
modular codec API.
---
src/Makefile.am | 9 +-
src/modules/bluetooth/a2dp-codecs.h | 5 +-
src/modules/bluetooth/bluez5-util.c | 331 +--
src/modules/bluetooth/bluez5-util.h | 10 +-
src/modules/bluetooth/module-bluez5-device.c | 487 ++
src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 +++
src/modules/bluetooth/pa-a2dp-codec.h| 40 ++
7 files changed, 851 insertions(+), 610 deletions(-)
create mode 100644 src/modules/bluetooth/pa-a2dp-codec-sbc.c
create mode 100644 src/modules/bluetooth/pa-a2dp-codec.h
diff --git a/src/Makefile.am b/src/Makefile.am
index f62e7d5c4..411b9e5e5 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -2117,6 +2117,7 @@ module_bluetooth_discover_la_CFLAGS = $(AM_CFLAGS)
-DPA_MODULE_NAME=module_bluet
libbluez5_util_la_SOURCES = \
modules/bluetooth/bluez5-util.c \
modules/bluetooth/bluez5-util.h \
+ modules/bluetooth/pa-a2dp-codec.h \
modules/bluetooth/a2dp-codecs.h
if HAVE_BLUEZ_5_OFONO_HEADSET
libbluez5_util_la_SOURCES += \
@@ -2131,6 +2132,10 @@ libbluez5_util_la_LDFLAGS = -avoid-version
libbluez5_util_la_LIBADD = $(MODULE_LIBADD) $(DBUS_LIBS)
libbluez5_util_la_CFLAGS = $(AM_CFLAGS) $(DBUS_CFLAGS)
+libbluez5_util_la_SOURCES += modules/bluetooth/pa-a2dp-codec-sbc.c
+libbluez5_util_la_LIBADD += $(SBC_LIBS)
+libbluez5_util_la_CFLAGS += $(SBC_CFLAGS)
+
module_bluez5_discover_la_SOURCES = modules/bluetooth/module-bluez5-discover.c
module_bluez5_discover_la_LDFLAGS = $(MODULE_LDFLAGS)
module_bluez5_discover_la_LIBADD = $(MODULE_LIBADD) $(DBUS_LIBS)
libbluez5-util.la
@@ -2138,8 +2143,8 @@ module_bluez5_discover_la_CFLAGS = $(AM_CFLAGS)
$(DBUS_CFLAGS) -DPA_MODULE_NAME=
module_bluez5_device_la_SOURCES = modules/bluetooth/module-bluez5-device.c
module_bluez5_device_la_LDFLAGS = $(MODULE_LDFLAGS)
-module_bluez5_device_la_LIBADD = $(MODULE_LIBADD) $(SBC_LIBS) libbluez5-util.la
-module_bluez5_device_la_CFLAGS = $(AM_CFLAGS) $(SBC_CFLAGS)
-DPA_MODULE_NAME=module_bluez5_device
+module_bluez5_device_la_LIBADD = $(MODULE_LIBADD) libbluez5-util.la
+module_bluez5_device_la_CFLAGS = $(AM_CFLAGS)
-DPA_MODULE_NAME=module_bluez5_device
# Apple Airtunes/RAOP
module_raop_sink_la_SOURCES = modules/raop/module-raop-sink.c
diff --git a/src/modules/bluetooth/a2dp-codecs.h
b/src/modules/bluetooth/a2dp-codecs.h
index 8afcfcb24..004975586 100644
--- a/src/modules/bluetooth/a2dp-codecs.h
+++ b/src/modules/bluetooth/a2dp-codecs.h
@@ -47,6 +47,9 @@
#define SBC_ALLOCATION_SNR (1 << 1)
#define SBC_ALLOCATION_LOUDNESS1
+#define SBC_MIN_BITPOOL 2
+#define SBC_MAX_BITPOOL 64
+
#define MPEG_CHANNEL_MODE_MONO (1 << 3)
#define MPEG_CHANNEL_MODE_DUAL_CHANNEL (1 << 2)
#define MPEG_CHANNEL_MODE_STEREO (1 << 1)
@@ -63,8 +66,6 @@
#define MPEG_SAMPLING_FREQ_44100 (1 << 1)
#define MPEG_SAMPLING_FREQ_48000 1
-#define MAX_BITPOOL 64
-#define MIN_BITPOOL 2
#if __BYTE_ORDER == __LITTLE_ENDIAN
diff --git a/src/modules/bluetooth/bluez5-util.c
b/src/modules/bluetooth/bluez5-util.c
index 2d8337317..9c4e3367b 100644
--- a/src/modules/bluetooth/bluez5-util.c
+++ b/src/modules/bluetooth/bluez5-util.c
@@ -2,6 +2,7 @@
This file is part of PulseAudio.
Copyright 2008-2013 João Paulo Rechi Vita
+ Copyrigth 2018 Pali Rohár
PulseAudio is free software; you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as
@@ -33,7 +34,7 @@
#include
#include
-#include "a2dp-codecs.h"
+#include "pa-a2dp-codec.h"
#include "bluez5-util.h"
@@ -48,8 +49,8 @@
#define BLUEZ_ERROR_NOT_SUPPORTED "org.bluez.Error.NotSupported"
-#define A2DP_SOURCE_ENDPOINT "/MediaEndpoint/A2DPSource"
-#define A2DP_SINK_ENDPOINT "/MediaEndpoint/A2DPSink"
+#define A2DP_SOURCE_SBC_ENDPOINT "/MediaEndpoint/A2DPSourceSBC"
+#define A2DP_SINK_SBC_ENDPOINT "/MediaEndpoint/A2DPSinkSBC"
#define ENDPOINT_INTROSPECT_XML \
DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE \
@@ -170,9 +171,9 @@ static const char
*transport_state_to_string(pa_bluetooth_transport_state_t stat
static bool device_supports_profile(pa_bluetooth_device *device,
pa_bluetooth_profile_t profile) {
switch (profile) {
-case PA_BLUETOOTH_PROFILE_A2DP_SINK:
+case PA_BLUETOOTH_PROFILE_A2DP_SBC_SINK:
return !!pa_hashmap_get(device->uuids,
PA_BLUETOOTH_UUID_A2DP_SINK);
-case PA_BLUETOOTH_PROFILE_A2DP_SOURCE:
+case PA_BLUE
[pulseaudio-discuss] [PATCH v2 2/2] Bluetooth A2DP aptX codec support
This patch provides support for aptX codec in bluetooth A2DP profile. In
pulseaudio it is implemented as a new profile a2dp_aptx_sink. For aptX
encoding it uses open source LGPLv2.1+ licensed libopenaptx library which
can be found at https://github.com/pali/libopenaptx.
Limitations:
Codec selection (either SBC or aptX) is done by bluez itself and it does
not provide API for switching codec. Therefore pulseaudio is not able to
change codec and it is up to bluez if it decide to use aptX or not.
Only standard aptX codec is supported for now. Support for other variants
like aptX HD, aptX Low Latency, FastStream may come up later.
---
configure.ac | 19 ++
src/Makefile.am | 5 +
src/modules/bluetooth/a2dp-codecs.h | 118 ++-
src/modules/bluetooth/bluez5-util.c | 48 -
src/modules/bluetooth/bluez5-util.h | 2 +
src/modules/bluetooth/module-bluez5-device.c | 65 +-
src/modules/bluetooth/pa-a2dp-codec-aptx.c | 297 +++
src/modules/bluetooth/pa-a2dp-codec.h| 1 +
8 files changed, 548 insertions(+), 7 deletions(-)
create mode 100644 src/modules/bluetooth/pa-a2dp-codec-aptx.c
diff --git a/configure.ac b/configure.ac
index d2bfab23b..c2d13fa53 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1094,6 +1094,23 @@ AC_SUBST(HAVE_BLUEZ_5_NATIVE_HEADSET)
AM_CONDITIONAL([HAVE_BLUEZ_5_NATIVE_HEADSET], [test
"x$HAVE_BLUEZ_5_NATIVE_HEADSET" = x1])
AS_IF([test "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = "x1"],
AC_DEFINE([HAVE_BLUEZ_5_NATIVE_HEADSET], 1, [Bluez 5 native headset backend
enabled]))
+ Bluetooth A2DP aptX codec (optional) ###
+
+AC_ARG_ENABLE([aptx],
+AS_HELP_STRING([--disable-aptx],[Disable optional bluetooth A2DP aptX
codec support (via libopenaptx)]))
+
+AS_IF([test "x$HAVE_BLUEZ_5" = "x1" && test "x$enable_aptx" != "xno"],
+[AC_CHECK_HEADER([openaptx.h],
+[AC_CHECK_LIB([openaptx], [aptx_init], [HAVE_OPENAPTX=1],
[HAVE_OPENAPTX=0])],
+[HAVE_OPENAPTX=0])])
+
+AS_IF([test "x$HAVE_BLUEZ_5" = "x1" && test "x$enable_aptx" = "xyes" && test
"x$HAVE_OPENAPTX" = "x0"],
+[AC_MSG_ERROR([*** libopenaptx from https://github.com/pali/libopenaptx
not found])])
+
+AC_SUBST(HAVE_OPENAPTX)
+AM_CONDITIONAL([HAVE_OPENAPTX], [test "x$HAVE_OPENAPTX" = "x1"])
+AS_IF([test "x$HAVE_OPENAPTX" = "x1"], AC_DEFINE([HAVE_OPENAPTX], 1, [Have
openaptx codec library]))
+
UDEV support (optional)
AC_ARG_ENABLE([udev],
@@ -1579,6 +1596,7 @@ AS_IF([test "x$HAVE_SYSTEMD_JOURNAL" = "x1"],
ENABLE_SYSTEMD_JOURNAL=yes, ENABLE
AS_IF([test "x$HAVE_BLUEZ_5" = "x1"], ENABLE_BLUEZ_5=yes, ENABLE_BLUEZ_5=no)
AS_IF([test "x$HAVE_BLUEZ_5_OFONO_HEADSET" = "x1"],
ENABLE_BLUEZ_5_OFONO_HEADSET=yes, ENABLE_BLUEZ_5_OFONO_HEADSET=no)
AS_IF([test "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = "x1"],
ENABLE_BLUEZ_5_NATIVE_HEADSET=yes, ENABLE_BLUEZ_5_NATIVE_HEADSET=no)
+AS_IF([test "x$HAVE_OPENAPTX" = "x1"], ENABLE_APTX=yes, ENABLE_APTX=no)
AS_IF([test "x$HAVE_HAL_COMPAT" = "x1"], ENABLE_HAL_COMPAT=yes,
ENABLE_HAL_COMPAT=no)
AS_IF([test "x$HAVE_TCPWRAP" = "x1"], ENABLE_TCPWRAP=yes, ENABLE_TCPWRAP=no)
AS_IF([test "x$HAVE_LIBSAMPLERATE" = "x1"], ENABLE_LIBSAMPLERATE="yes
(DEPRECATED)", ENABLE_LIBSAMPLERATE=no)
@@ -1637,6 +1655,7 @@ echo "
Enable BlueZ 5: ${ENABLE_BLUEZ_5}
Enable ofono headsets: ${ENABLE_BLUEZ_5_OFONO_HEADSET}
Enable native headsets:${ENABLE_BLUEZ_5_NATIVE_HEADSET}
+Enable aptX codec: ${ENABLE_APTX}
Enable udev: ${ENABLE_UDEV}
Enable HAL->udev compat: ${ENABLE_HAL_COMPAT}
Enable systemd
diff --git a/src/Makefile.am b/src/Makefile.am
index 411b9e5e5..bbd797589 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -2136,6 +2136,11 @@ libbluez5_util_la_SOURCES +=
modules/bluetooth/pa-a2dp-codec-sbc.c
libbluez5_util_la_LIBADD += $(SBC_LIBS)
libbluez5_util_la_CFLAGS += $(SBC_CFLAGS)
+if HAVE_OPENAPTX
+libbluez5_util_la_SOURCES += modules/bluetooth/pa-a2dp-codec-aptx.c
+libbluez5_util_la_LIBADD += -lopenaptx
+endif
+
module_bluez5_discover_la_SOURCES = modules/bluetooth/module-bluez5-discover.c
module_bluez5_discover_la_LDFLAGS = $(MODULE_LDFLAGS)
module_bluez5_discover_la_LIBADD = $(MODULE_LIBADD) $(DBUS_LIBS)
libbluez5-util.la
diff --git a/src/modules/bluetooth/a2dp-codecs.h
b/src/modules/bluetooth/a2dp-codecs.h
index 004975586..0c3583434 100644
--- a/src/modules/bluetooth/a2dp-codecs.h
+++ b/src/modules/bluetooth/a2dp-codecs.h
@@ -4,6 +4,7 @@
*
* Copyright (C) 2006-2010 Nokia Corporation
[pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support
This patch series moves A2DP codec code into new modules and add support for Bluetooth A2DP aptX codec. Pali Rohár (2): Modular API for Bluetooth A2DP codec Bluetooth A2DP aptX codec support configure.ac | 19 + src/Makefile.am | 14 +- src/modules/bluetooth/a2dp-codecs.h | 123 +- src/modules/bluetooth/bluez5-util.c | 377 +++-- src/modules/bluetooth/bluez5-util.h | 12 +- src/modules/bluetooth/module-bluez5-device.c | 542 - src/modules/bluetooth/pa-a2dp-codec-aptx.c | 297 ++ src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 +++ src/modules/bluetooth/pa-a2dp-codec.h| 41 ++ 9 files changed, 1393 insertions(+), 611 deletions(-) create mode 100644 src/modules/bluetooth/pa-a2dp-codec-aptx.c create mode 100644 src/modules/bluetooth/pa-a2dp-codec-sbc.c create mode 100644 src/modules/bluetooth/pa-a2dp-codec.h -- 2.11.0 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Monday 23 July 2018 18:42:52 Arun Raghavan wrote: > On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote: > > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: > > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár : > > > > > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages > > > > > to depend on it. > > > > > > > > Can pulseaudio build process enforce it? > > Does not need to, that can be taken care of at packaging time, and > potentially at module load. Ok, I would ask differently: Can pulseaudio at packaging time enforce it? > > > 2. GStreamer can, in theory, wrap the needed libraries, and does > > > support third-party plugins, but does not properly encapsulate the > > > "give me packets ready to send via bluez" part. > > > > And until this is supported by external library (ffmpeg, gstreamer, > > whatever), pulseaudio needs to implement it itself. > > > > And encapsulating encoded data for bluez is not enough. It is needed > > also to negotiate codec selection with bluez and codec parameters (which > > are codec specific). > > GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be used > (and again, less codec-specific stuff that needs to be in PA). But it does not solve above problem when it is needed to do A2DP codec selection and negotiation. > > In previous email I wrote about idea to move that codec stuff into bluez > > itself as bluez code already handles it for android. > > > > > > > > > > > > To have working bluetooth support in pulseadio, pulseaudio needs to > > > > > > use > > > > > > external library for encoding which *always* provides support for > > > > > > SBC. > > > > > > And not only if user manually installs some special plugin for 3rd > > > > > > party > > > > > > library. (And not only SBC, but also those other aptX, MPEG1/2, AAC > > > > > > and > > > > > > LDAC codecs) > > > > > > > > > > So I continue to disagree. Using a generic framework and letting > > > > > other parts of the system select the codec implementation is what > > > > > makes sense for the widest set of use-cases (this also allows > > > > > products to ship their own implementations of a codec without > > > > > changing the PulseAudio code). > > > > > > > > Still this is not enough for bluetooth codec. For specific codec you > > > > need to create bluez dbus endpoint with codec specific parameters. Plus > > > > implement select and set methods to decide on codec parameters between > > > > pulseaudio and bluetooth headset. And finally to send encoded data you > > > > need to know how to send them. To which endpoint, how header looks like > > > > etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must not > > > > have RTP (e.g. aptX). And after that comes data from codec encoder > > > > function. > > > > > > > > So is there any library which all above support? I have not find > > > > anything. Nor ffmpeg nor gstreamer. > > > > > > > > Which means that pulseaudio cannot delegate codec selection, codec > > > > initialization and codec encoding to some external library (yet). > > At least for SBC and presumably AAC, this is all possible with GStreamer No, it is not possible -- or at least I have not found any way how. I spend more time with it and Gstreamer does not support it. If you still think that it is possible, post a gstreamer code or link how to do that. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module
Hi! On Monday 23 July 2018 10:55:39 Luiz Augusto von Dentz wrote: > HI Pali, > > On Sun, Jul 22, 2018 at 2:37 PM, Pali Rohár wrote: > > On Sunday 22 July 2018 11:52:11 Georgi Boiko wrote: > >> I understand the desire to do it properly and to support everything with > >> account for the fine detail, but that overcomplicates the immediate problem > >> at hand: falling behind other platforms and being stuck with SBC. > > > > In any way, I do not think it overcomplicate implementation. And until > > bluez does not provide needed API we are really stuck. > > I don't think this is true for all headset though, Yes, I did not say something like this. > also perhaps you > are trying to connect to a device that has already been paired? That > could be an influence in this randomness, otherwise perhaps the > headset is just bugged when it comes to codec selection? By pairing I mean, bluetooth pairing process. You need to send pin code or verify that pin code matches. Then both devices (laptop and headset) put other device into "trusted" list and allows connect to themselves. > Also codec > selection should only come into picture with user input, we shouldn't > be changing codecs by policy since that will only increase the > problems, so should work out the preferences when initiating the > connection so if the headset plays nice and remember it then nothing > has to be changed. Currently my patch which I sent to mailing list uses pulseaudio profiles for codec selection. So if we want to stay with this, then codec will be still chosen by bluez or remote device, but via pactl set-card-profile (or GUI equivalent) it would be possible to change codec. Also in future we could implement something like "remember last used codec for this device" and restore it after new reconnect to have stable and predicable codec selection/negotiation. I think that both ideas make sense and is something which user expect. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module
On Sunday 22 July 2018 11:52:11 Georgi Boiko wrote: > On 22/07/18 10:31, Pali Rohár wrote: > > On Sunday 22 July 2018 10:14:21 Georgi Boiko wrote: > > > Hi Pali, > > > > > > Does it have to be codec switching? > > > > Without codec switching it is not possible to "force" specific codec. > > And when bluetooth headset initiate connection, then headset choose > > codec. My testing shown me that my bluetooth headset chooses codec > > "randomly" when pulseaudio declares that support both SBC and aptX. > > > > And no, it is not a good idea to have "random" codec selection without > > possibility to switch it. > > > > So the only possible solution for now for enforcing aptX codec is to > > disable SBC codec registration to bluez. And codec registration is > > global for all headset and is done when initializing pulseaudio > > bluetooth module. > > Have you tried debugging that with hcidump? Yes. > It sounds like a codec > negotiation issue with a particular set of equipment. Look at mailing list discussion. This is limitation of bluez daemon. It does not provide needed DBUS API. In my case, it looks like audio headset remember the last used codec. And when I switch from phone (without aptX) to laptop (pulseaudio with my aptX patch), then it choose SBC. When I disabled support for SBC at compile time in pulseaudio, headset always choose aptX. This is really codec negotiation between bluez and A2DP device and we need a way to tell bluez to switch from one codec to another. > A simpler to implement alternative to codec switching via GUI could be to > add a config option to enable/disable codecs when the Bluetooth module > starts and negotiate using only enabled codecs. That would provide > reasonable defaults with an option for power users such as yourself to force > a specific codec according to their needs. This would also cut off a large > chunk off the scoped changes, as no GUI-related code would have to be > changed. How user choose codec (config file, GUI menu, ...) is not irrelevant. This is just second step once pulseaudio would have an option to choose codec. Currently bluez daemon does not provide API for it. > > > If there was to be an implementation > > > that settles on the best quality codec available that is supported by both > > > sides of communication > > > > This is possible to implement, but only in the case that > > pulseaudio/bluez initiate connection to bletooth headset. > > > > For my tested headset, this is possible only when putting headset into > > bluetooth "pairing" mode. Very unpractical. In normal case, that headset > > is what initialize connection. > > The 3 market leading Bluetooth headsets (Apple, Sony, Bose) all make the > first connection through pairing mode. Yes, first you need to pair your bluetooth device and once it is paired, then you can connect "directly". > If you meant recurring connections, > is there a way for PA to memorize which codec was used during the initial > session and only supply that option later? As a user, that is what I would > expect for recurring connections. I do not know if we have an "storage" for such thing. And if not, it can be added later and implemented. Current problem is that pulseaudio cannot choose codec. > > > it would already be over and beyond what currently > > > exists. The order is obvious as of today: > > > > For me it is not such obvious as you specified. > > > > > LDAC > > > > > > AptX HD > > > > > > AptX > > > > > > AAC > > > > In case I have music already in MPEG/AAC then this codec should have the > > higher priority as music could be passed as-is without decoding and > > reencoding. In this case it is the best possible quality. Same would be > > for MPEG/MP3 codec. > > > > Technically there are also other codecs supported by bluetooth headset, > > see my research: > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030199.html > > > > I have no clue right now where to put aptX Low Latency and FastStream > > codecs. Plus both codecs are somehow special that misuse A2DP protocol > > and optionally supports backchannel for microphone voice. So you can use > > them instead of HFP for voice calls. I have there a headset with > > FastStream codec and IIRC it is just some variant of SBC, so I would try > > to play with it. > > > > And I'm still in doubt if MPEG/AAC does not provide better quality as > > aptX. > > As long as the end result is consistent with other major platf
Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module
On Sunday 22 July 2018 10:14:21 Georgi Boiko wrote: > Hi Pali, > > Does it have to be codec switching? Without codec switching it is not possible to "force" specific codec. And when bluetooth headset initiate connection, then headset choose codec. My testing shown me that my bluetooth headset chooses codec "randomly" when pulseaudio declares that support both SBC and aptX. And no, it is not a good idea to have "random" codec selection without possibility to switch it. So the only possible solution for now for enforcing aptX codec is to disable SBC codec registration to bluez. And codec registration is global for all headset and is done when initializing pulseaudio bluetooth module. > If there was to be an implementation > that settles on the best quality codec available that is supported by both > sides of communication This is possible to implement, but only in the case that pulseaudio/bluez initiate connection to bletooth headset. For my tested headset, this is possible only when putting headset into bluetooth "pairing" mode. Very unpractical. In normal case, that headset is what initialize connection. > it would already be over and beyond what currently > exists. The order is obvious as of today: For me it is not such obvious as you specified. > LDAC > > AptX HD > > AptX > > AAC In case I have music already in MPEG/AAC then this codec should have the higher priority as music could be passed as-is without decoding and reencoding. In this case it is the best possible quality. Same would be for MPEG/MP3 codec. Technically there are also other codecs supported by bluetooth headset, see my research: https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030199.html I have no clue right now where to put aptX Low Latency and FastStream codecs. Plus both codecs are somehow special that misuse A2DP protocol and optionally supports backchannel for microphone voice. So you can use them instead of HFP for voice calls. I have there a headset with FastStream codec and IIRC it is just some variant of SBC, so I would try to play with it. And I'm still in doubt if MPEG/AAC does not provide better quality as aptX. > SBC > > BlueZ already follows this logic, it is just that PA does not register any > capabilities other than SBC. > > Allowing forced codec selection through the GUI is nice to have, but given > the complexity of implementing it, may not be worth the hassle for the > initial milestone. > > > On 22/07/18 09:51, Pali Rohár wrote: > > Hi! > > > > On Sunday 22 July 2018 00:10:47 Georgi Boiko wrote: > > > Hi, > > > > > > Does anybody know what happened after this discussion? Is this long > > > overdue > > > upgrade on the roadmap? > > > > > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-July/028398.html > > See this thread: > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030198.html > > > > Basically there is a patch for aptX support, but that one just replace > > SBC by aptX. So need to decide which codec to support at compile time. > > > > This is current limitation of bluez - linux bluetooth daemon - which > > does not support codec switching. > > > > See also this thread: > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030253.html > > > > So until bluez is extended to support switching and configuring A2DP > > codec, there would not be support for any other codec then SBC. > > > -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module
Hi! On Sunday 22 July 2018 00:10:47 Georgi Boiko wrote: > Hi, > > Does anybody know what happened after this discussion? Is this long overdue > upgrade on the roadmap? > > https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-July/028398.html See this thread: https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030198.html Basically there is a patch for aptX support, but that one just replace SBC by aptX. So need to decide which codec to support at compile time. This is current limitation of bluez - linux bluetooth daemon - which does not support codec switching. See also this thread: https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030253.html So until bluez is extended to support switching and configuring A2DP codec, there would not be support for any other codec then SBC. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Friday 20 July 2018 14:30:56 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Wed, Jul 11, 2018 at 11:07 AM, Pali Rohár wrote: > > On Monday 09 July 2018 17:56:16 Pali Rohár wrote: > >> On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote: > >> > > 2) How should codec switching from pulseaudio API and pactl/pavucontrol > >> > > looks like? > >> > > >> > Usually we don't force reconfiguration but perhaps we should, note > >> > though that we may end up with audio glitches since we have to > >> > disconnect A2DP stream to be able to reconfigure it with another > >> > codec. > >> > >> Glitches are already there if you switch from A2DP profile to HSP in > >> pavucontrol. So I do not see any problem if glitches happen also when > >> switching between A2DP (SBC) and A2DP (aptX). > >> > >> > We would probably have to expose each endpoint so you could > >> > peek and choose what the codec to use. > >> > >> Yes. I think this is required when pulseaudio is going to support more > >> then one codec. > > > > So when this will happen? As for now this is blocker for proper support > > of multiple codecs in pulseaudio. > > > > We need some dbus method call which will tell bluez which endpoint > > (registered by pulseaudio) should be used now for particular bluetooth > > A2DP device. > > I can give you some pointers on how to expose the endpoints with > MediaEndpoint interface. Ok. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Monday 09 July 2018 17:56:16 Pali Rohár wrote: > On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote: > > > 2) How should codec switching from pulseaudio API and pactl/pavucontrol > > > looks like? > > > > Usually we don't force reconfiguration but perhaps we should, note > > though that we may end up with audio glitches since we have to > > disconnect A2DP stream to be able to reconfigure it with another > > codec. > > Glitches are already there if you switch from A2DP profile to HSP in > pavucontrol. So I do not see any problem if glitches happen also when > switching between A2DP (SBC) and A2DP (aptX). > > > We would probably have to expose each endpoint so you could > > peek and choose what the codec to use. > > Yes. I think this is required when pulseaudio is going to support more > then one codec. So when this will happen? As for now this is blocker for proper support of multiple codecs in pulseaudio. We need some dbus method call which will tell bluez which endpoint (registered by pulseaudio) should be used now for particular bluetooth A2DP device. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [patches] constification round #4 (pa_mainloop_api)
On Tuesday 10 July 2018 13:54:42 Tanu Kaskinen wrote: > If we're ever going to make "libpulse 2", we need to have a plan about > everything that we want to change. I don't want to create a new library > just to constify the mainloop API... Feel free to start a wiki page > that lists compatibility breaking changes that we might want to make. If you are going to do such think like a new libpulse client library, I would suggest a larger discussion and ideally also tell about it to projects like https://github.com/i-rinat/apulse. And developers of existing libpulse applications should be part of discussion too. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Sun, Jul 8, 2018 at 11:47 PM, Pali Rohár wrote: > > On Sunday 08 July 2018 22:51:38 Luiz Augusto von Dentz wrote: > >> > In previous email I wrote about idea to move that codec stuff into bluez > >> > itself as bluez code already handles it for android. > >> > >> We are not going to do a pulseaudio module in BlueZ, if it is even > >> possible to have off the tree modules, in android we did that because > >> it is the only option we had and Im quite sure it probably needs > >> updating since code must have change since then... Any architecture > >> that would involve copying data over would be bad for latency, though > >> android does that, and Im pretty sure doing encoding/decoding on > >> daemon would be rejected as well. > > > > Ok. > > > > But why is there already code for encoding/decoding directly in bluez > > (even it is for android) and not in some separate library/project? > > > > Then both android and pulseaudio can benefit from it. As basically now > > pulseaudio needs to implement exactly same code and logic which is > > already in bluez project, which is doing that audio encoding. > > > >> The D-Bus interface already accounts to the parameter negotiation, > >> obviously frameworks such as ffmeg or gstreamer would not do it for > >> use but the module could take up the action to register the endpoint > >> and respond to the method calls when necessary. Anyway, lets start > >> with modularization of the endpoints/codecs, that way we can add > >> native codec support or gstreamer/ffmpeg and each platform decides > >> with what they want to go. > > > > Ok. Prior I start splitting codec related code, I need to know: > > > > 1) Cannot we reuse above bluez code for codec encoding which is already > > used for android? If it needs some refactoring (like stop doing data > > copying etc...). > > android does not use PulseAudio, what we have there is a plugin for > the android audio server. > > > 2) How should codec switching from pulseaudio API and pactl/pavucontrol > > looks like? > > Usually we don't force reconfiguration but perhaps we should, note > though that we may end up with audio glitches since we have to > disconnect A2DP stream to be able to reconfigure it with another > codec. Glitches are already there if you switch from A2DP profile to HSP in pavucontrol. So I do not see any problem if glitches happen also when switching between A2DP (SBC) and A2DP (aptX). > We would probably have to expose each endpoint so you could > peek and choose what the codec to use. Yes. I think this is required when pulseaudio is going to support more then one codec. > > 3) How to handle possible pass-through? E.g. I have already encoded > > music in aptX format (or MP3 or AAC) and want to send it directly > > without double decoding-encoding process. And how to handle MP3 input > > when device supports both aptX and MP3, but currently is activated aptX? > > Afaik that usually requires the application to know that underline > codec so PA needs to expose these details so it can avoid decoding and > send it. Switching depending on the content will not work well so > perhaps the only bet is if the device support multiplexing, which is > something we don't support in BlueZ, otherwise it is better to use > either aptX or SBC since those are simpler than going with AAC and MP3 > and possible encode any other audio. > > >> Btw, I guess you were on irc looking for how we prioritize the > >> matching of endpoints, this is done in the order of endpoint > >> registration, > > > > Yes, but I have not got any answer so I sent incomplete/wIP patch to > > this mailing list. > > > > -- > > Pali Rohár > > pali.ro...@gmail.com > > > > ___ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > > -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Sunday 08 July 2018 22:51:38 Luiz Augusto von Dentz wrote: > > In previous email I wrote about idea to move that codec stuff into bluez > > itself as bluez code already handles it for android. > > We are not going to do a pulseaudio module in BlueZ, if it is even > possible to have off the tree modules, in android we did that because > it is the only option we had and Im quite sure it probably needs > updating since code must have change since then... Any architecture > that would involve copying data over would be bad for latency, though > android does that, and Im pretty sure doing encoding/decoding on > daemon would be rejected as well. Ok. But why is there already code for encoding/decoding directly in bluez (even it is for android) and not in some separate library/project? Then both android and pulseaudio can benefit from it. As basically now pulseaudio needs to implement exactly same code and logic which is already in bluez project, which is doing that audio encoding. > The D-Bus interface already accounts to the parameter negotiation, > obviously frameworks such as ffmeg or gstreamer would not do it for > use but the module could take up the action to register the endpoint > and respond to the method calls when necessary. Anyway, lets start > with modularization of the endpoints/codecs, that way we can add > native codec support or gstreamer/ffmpeg and each platform decides > with what they want to go. Ok. Prior I start splitting codec related code, I need to know: 1) Cannot we reuse above bluez code for codec encoding which is already used for android? If it needs some refactoring (like stop doing data copying etc...). 2) How should codec switching from pulseaudio API and pactl/pavucontrol looks like? 3) How to handle possible pass-through? E.g. I have already encoded music in aptX format (or MP3 or AAC) and want to send it directly without double decoding-encoding process. And how to handle MP3 input when device supports both aptX and MP3, but currently is activated aptX? > Btw, I guess you were on irc looking for how we prioritize the > matching of endpoints, this is done in the order of endpoint > registration, Yes, but I have not got any answer so I sent incomplete/wIP patch to this mailing list. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] WIP: Bluetooth A2DP aptX codec support
On Sunday 08 July 2018 23:11:56 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Sun, Jul 8, 2018 at 11:02 PM, Pali Rohár wrote: > > On Sunday 08 July 2018 22:55:28 Luiz Augusto von Dentz wrote: > >> Hi Pali, > >> > >> On Sat, Jul 7, 2018 at 2:08 PM, Pali Rohár wrote: > >> > On Friday 06 July 2018 11:16:09 Pali Rohár wrote: > >> >> Known problems: > >> >> > >> >> For every A2DP codec it is needed to register endpoint to the bluez > >> >> daemon. > >> >> This is working fine, but I do not know how and why bluez daemon choose > >> >> endpoint (and so codec) for new connection. And I have not figured out > >> >> how > >> >> to tell bluez daemon to switch A2DP codec from SBC to aptX and > >> >> vice-versa. > >> >> It looks like that bluez daemon chooses endpoint (and so codec) at > >> >> connection time randomly :-( > >> > > >> > Any idea how to tell bluez which endpoint should use? Or how to change > >> > one active bluez endpoint to another for switching bluez codec? > >> > >> > >> It is the order PA register the endpoints, if you want apt-x take > >> priority register it first. > > > > Do you mean to call functions in this order? > > > > register_endpoint(y, path, A2DP_SOURCE_APTX_ENDPOINT, ...); > > register_endpoint(y, path, A2DP_SOURCE_SBC_ENDPOINT, ...); > > > > No, it does not work. Still codec is somehow selected randomly. > > Sometimes aptX, sometimes SBC. I tested it with one same device. > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/audio/a2dp.c#n1866 > > It is definitely not random in our end, note that this only works if > you initiate the connection, if the remote initiates it then it is up > to them to select which may explain why it is not always the same > priority. So if remote side initiate the connection, then we have no control which codec is chosen in case pulseaudio register more endpoints? And how to switch from one codec to another when there is an active connection? E.g. device supports both aptX and SBC, but it initiated connection and chose SBC -- and now I want to use aptX. Endpoint registration is global, not device specific, right? It means that we cannot set different priority for different A2DP devices? What I would like is to change A2DP codec in pavucontrol (or pactl or any other PA application) and currently my patch uses one pulseaudio profile for SBC and one for aptX. So it is possible to implement such switching based on changing profile? Or do you have a better idea how to select/change A2DP profile via pavucontrol/pactl/KDE sound app/...? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] WIP: Bluetooth A2DP aptX codec support
On Sunday 08 July 2018 22:55:28 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Sat, Jul 7, 2018 at 2:08 PM, Pali Rohár wrote: > > On Friday 06 July 2018 11:16:09 Pali Rohár wrote: > >> Known problems: > >> > >> For every A2DP codec it is needed to register endpoint to the bluez daemon. > >> This is working fine, but I do not know how and why bluez daemon choose > >> endpoint (and so codec) for new connection. And I have not figured out how > >> to tell bluez daemon to switch A2DP codec from SBC to aptX and vice-versa. > >> It looks like that bluez daemon chooses endpoint (and so codec) at > >> connection time randomly :-( > > > > Any idea how to tell bluez which endpoint should use? Or how to change > > one active bluez endpoint to another for switching bluez codec? > > > It is the order PA register the endpoints, if you want apt-x take > priority register it first. Do you mean to call functions in this order? register_endpoint(y, path, A2DP_SOURCE_APTX_ENDPOINT, ...); register_endpoint(y, path, A2DP_SOURCE_SBC_ENDPOINT, ...); No, it does not work. Still codec is somehow selected randomly. Sometimes aptX, sometimes SBC. I tested it with one same device. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: > сб, 7 июл. 2018 г. в 19:08, Pali Rohár : > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > > This is a good idea to let external service to do codec-specific > > > > functions... I agree that it simplify pulseaudio code and other things > > > > (like proving new codec by external library -- if properly implemented), > > > > but in bluetooth context we should look at questions: > > > > > > > > 1) Has gstreamer support for SBC codec? > > > > > > > > 2) Has gstreamer support for aptX codec? > > > > > > > > These are two major codecs supported by bluetooth headsets. > > > > > > > > Answer is: NO > > > > (SBC is now provided in the "bad" set which is not pre-installed by > > > > gstreamer) > > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages to > > > depend on it. > > > > Can pulseaudio build process enforce it? > > > > > > So gstreamer in current state is not very useful for pulseaudio. > > > > > > Writing a plugin around an existing decoder is pretty trivial. As is > > > exposing libav/ffmpeg codecs. > > > > > > > Important are also MPEG1/2 (which are defined as optional by A2DP) > > > > and also AAC and LDAC which Jan wrote. But gstreamer has again only > > > > plugins in "bad" and "ugly" sets for them; nothing preinstalled by > > > > default. > > > > > > Again, -bad doesn't mean much in the current day (historically it was a > > > staging ground). -ugly is for codecs that are known to be > > > patent-encumbered (and how that's made available is up to packagers). > > > > Still more distributions does not compile ffmpeg with all codecs due to > > patents problems. > > > > So there is a high chance that we end up in situation that pulseaudio > > would not be able to encode audio into codec X (even pulseaudio declare > > that it support) and user would not be able to do nothing as his > > distribution does not enabled codec X at compile time. It could be > > really a legal problem or problem because packager forgot to enable it > > or because he think that it could be a problem and rather disabled it. > > > > The only option to prevent such situation is compile time check. Like > > now pulseaudio does not compile bluetooth support when sbc codec is not > > available. And this check should be there even after moving to > > ffmpeg/gstreamer/whatever. So is this check possible to write in > > autoconf for that ffmpeg/gstreamer/whatever? > > I disagree here. Speaking here as an author of a patented codec (DTS) > implementation that is well supported by PulseAudio ;) But this is something different. DTS is not mandatory and devices in more cases can work without it (via PCM). But in bluetooth is SBC codec mandatory and must be always supported. And there are no license problems with SBC for A2DP bluetooth. > I was able to circumvent this kind of legal and technical issues by > providing a DTS encoder library (https://gitlab.com/patrakov/dcaenc) > and an ALSA plugin. The library implements stuff that is patented in > USA and thus cannot be included in USA-patent-free distributions. > However, the library is small and self-contained (not part of ffmpeg), > and users who don't care about patents can compile it anytime, and > they don't even have to replace any distribution-provided file by > installing this library. PulseAudio includes some profiles that > reference ALSA PCMs that are covered by the ALSA plugin that comes > with the library. No compile-time check needed - all the probing of > the form "can I open this PCM" is done at runtime in a generic way > that is not patched out by USA-patent-free distributions. Even the use > case when a product manufacturer has a DTS patent license which > instructs them to use a specific DTS implementation other than mine is > covered: that manufacturer can wrap that implementation in an ALSA > plugin that provides the same PCM names as mine, and PulseAudio will > still pick that up. > > All of that is possible because there is a not-so-horrible extension > point in ALSA library that allows to write software that takes PCM > data in and delivers it to strange devices (like a DTS receiver on an > optical SPDIF link). What we need here is to find a proper equivalent > of this extension point in the Bluetooth land (e.g. take PCM in, > produce ready-to-send packets with all the needed metadata
Re: [pulseaudio-discuss] [PATCH] WIP: Bluetooth A2DP aptX codec support
On Friday 06 July 2018 11:16:09 Pali Rohár wrote: > Known problems: > > For every A2DP codec it is needed to register endpoint to the bluez daemon. > This is working fine, but I do not know how and why bluez daemon choose > endpoint (and so codec) for new connection. And I have not figured out how > to tell bluez daemon to switch A2DP codec from SBC to aptX and vice-versa. > It looks like that bluez daemon chooses endpoint (and so codec) at > connection time randomly :-( Any idea how to tell bluez which endpoint should use? Or how to change one active bluez endpoint to another for switching bluez codec? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > This is a good idea to let external service to do codec-specific > > functions... I agree that it simplify pulseaudio code and other things > > (like proving new codec by external library -- if properly implemented), > > but in bluetooth context we should look at questions: > > > > 1) Has gstreamer support for SBC codec? > > > > 2) Has gstreamer support for aptX codec? > > > > These are two major codecs supported by bluetooth headsets. > > > > Answer is: NO > > (SBC is now provided in the "bad" set which is not pre-installed by > > gstreamer) > > Pre-installed doesn't mean much tbh. It is easy enough for packages to depend > on it. Can pulseaudio build process enforce it? > > So gstreamer in current state is not very useful for pulseaudio. > > Writing a plugin around an existing decoder is pretty trivial. As is exposing > libav/ffmpeg codecs. > > > Important are also MPEG1/2 (which are defined as optional by A2DP) > > and also AAC and LDAC which Jan wrote. But gstreamer has again only > > plugins in "bad" and "ugly" sets for them; nothing preinstalled by > > default. > > Again, -bad doesn't mean much in the current day (historically it was a > staging ground). -ugly is for codecs that are known to be patent-encumbered > (and how that's made available is up to packagers). Still more distributions does not compile ffmpeg with all codecs due to patents problems. So there is a high chance that we end up in situation that pulseaudio would not be able to encode audio into codec X (even pulseaudio declare that it support) and user would not be able to do nothing as his distribution does not enabled codec X at compile time. It could be really a legal problem or problem because packager forgot to enable it or because he think that it could be a problem and rather disabled it. The only option to prevent such situation is compile time check. Like now pulseaudio does not compile bluetooth support when sbc codec is not available. And this check should be there even after moving to ffmpeg/gstreamer/whatever. So is this check possible to write in autoconf for that ffmpeg/gstreamer/whatever? > > To have working bluetooth support in pulseadio, pulseaudio needs to use > > external library for encoding which *always* provides support for SBC. > > And not only if user manually installs some special plugin for 3rd party > > library. (And not only SBC, but also those other aptX, MPEG1/2, AAC and > > LDAC codecs) > > So I continue to disagree. Using a generic framework and letting other parts > of the system select the codec implementation is what makes sense for the > widest set of use-cases (this also allows products to ship their own > implementations of a codec without changing the PulseAudio code). Still this is not enough for bluetooth codec. For specific codec you need to create bluez dbus endpoint with codec specific parameters. Plus implement select and set methods to decide on codec parameters between pulseaudio and bluetooth headset. And finally to send encoded data you need to know how to send them. To which endpoint, how header looks like etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must not have RTP (e.g. aptX). And after that comes data from codec encoder function. So is there any library which all above support? I have not find anything. Nor ffmpeg nor gstreamer. Which means that pulseaudio cannot delegate codec selection, codec initialization and codec encoding to some external library (yet). Anyway, now in bluez source code is some kind of codec encoding support for android systems. Therefore should not be a wise idea to move all these codec A2DP mess into bluez source code? Because now part of A2DP is in bluez and another part in pulseaudio. And on android is everything in bluez now. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Wednesday 20 June 2018 17:35:42 Jan Alexander Steffens wrote: > On Mon, Jun 18, 2018, 09:42 Pali Rohár wrote: > > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > > > Hi! As you may know lot of bluetooth headsets support not only SBC, but > > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > > > ffmpeg has clean-room implementation based on expired patent. What > > about > > > > adding support for aptX via ffmpeg into pulseaudio? > > > > > > > > -- > > > > > > I'd actually like to delete the SBC code and replace it with a generic > > GStreamer bin. That would allow us to be codec agnostic, and support any of > > the codecs that are supported by GStreamer (which includes those that > > ffmpeg provides). > > > > This does not sound like a good idea. The only two relevant bluetooth > > codecs for most people are SBC and aptX. > > > > Don't forget AAC. I've seen this one a lot in devices meant for use with > iPhones, which apparently don't have aptX. GStreamer has a lot of encoders > for it so this shouldn't be a problem unless it's some strange AAC variant. > > There's also LDAC but I haven't seen it on a device yet. I did some investigation and basically this is the list of all known codecs used in A2DP: Mandatory: 0x00 - SBC Optional: 0x01 - MPEG-1,2 (aka MP3) 0x02 - MPEG-2,4 (aka AAC) 0x04 - ATRAC Vendor specific: 0xFF 0x004F 0x01 - aptX 0xFF 0x000A 0x01 - FastStream 0xFF 0x000A 0x02 - aptX Low Latency 0xFF 0x00D7 0x24 - aptX HD 0xFF 0x012D 0xAA - LDAC And also I found some references that some sort of raw 16bit PCM samples via codec id 0x05 are used... But I have never seen such product. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] WIP: Bluetooth A2DP aptX codec support
dule_bluez5_device_la_LDFLAGS = $(MODULE_LDFLAGS)
module_bluez5_device_la_LIBADD = $(MODULE_LIBADD) $(SBC_LIBS) libbluez5-util.la
module_bluez5_device_la_CFLAGS = $(AM_CFLAGS) $(SBC_CFLAGS)
-DPA_MODULE_NAME=module_bluez5_device
+if HAVE_OPENAPTX
+module_bluez5_device_la_LIBADD += -lopenaptx
+endif
+
# Apple Airtunes/RAOP
module_raop_sink_la_SOURCES = modules/raop/module-raop-sink.c
module_raop_sink_la_LDFLAGS = $(MODULE_LDFLAGS)
diff --git a/src/modules/bluetooth/a2dp-codecs.h
b/src/modules/bluetooth/a2dp-codecs.h
index 8afcfcb24..217f8056f 100644
--- a/src/modules/bluetooth/a2dp-codecs.h
+++ b/src/modules/bluetooth/a2dp-codecs.h
@@ -4,6 +4,7 @@
*
* Copyright (C) 2006-2010 Nokia Corporation
* Copyright (C) 2004-2010 Marcel Holtmann
+ * Copyright (C) 2018 Pali Rohár
*
*
* This library is free software; you can redistribute it and/or
@@ -25,6 +26,17 @@
#define A2DP_CODEC_MPEG12 0x01
#define A2DP_CODEC_MPEG24 0x02
#define A2DP_CODEC_ATRAC 0x03
+#define A2DP_CODEC_VENDOR 0xFF
+
+#define A2DP_VENDOR_APT_LIC_LTD0x004f
+#define APT_LIC_LTD_CODEC_APTX 0x0001
+
+#define A2DP_VENDOR_QTIL 0x000a
+#define QTIL_CODEC_FASTSTREAM 0x0001
+#define QTIL_CODEC_APTX_LL 0x0002
+
+#define A2DP_VENDOR_QUALCOMM_TECH_INC 0x00d7
+#define QUALCOMM_TECH_INC_CODEC_APTX_HD0x0024
#define SBC_SAMPLING_FREQ_16000(1 << 3)
#define SBC_SAMPLING_FREQ_32000(1 << 2)
@@ -47,6 +59,9 @@
#define SBC_ALLOCATION_SNR (1 << 1)
#define SBC_ALLOCATION_LOUDNESS1
+#define SBC_MIN_BITPOOL 2
+#define SBC_MAX_BITPOOL 64
+
#define MPEG_CHANNEL_MODE_MONO (1 << 3)
#define MPEG_CHANNEL_MODE_DUAL_CHANNEL (1 << 2)
#define MPEG_CHANNEL_MODE_STEREO (1 << 1)
@@ -63,8 +78,26 @@
#define MPEG_SAMPLING_FREQ_44100 (1 << 1)
#define MPEG_SAMPLING_FREQ_48000 1
-#define MAX_BITPOOL 64
-#define MIN_BITPOOL 2
+#define APTX_CHANNEL_MODE_MONO 0x1
+#define APTX_CHANNEL_MODE_STEREO 0x2
+
+#define APTX_SAMPLING_FREQ_16000 0x8
+#define APTX_SAMPLING_FREQ_32000 0x4
+#define APTX_SAMPLING_FREQ_44100 0x2
+#define APTX_SAMPLING_FREQ_48000 0x1
+
+#define FASTSTREAM_DIRECTION_SINK 0x1
+#define FASTSTREAM_DIRECTION_SOURCE0x2
+
+#define FASTSTREAM_SINK_SAMPLING_FREQ_441000x2
+#define FASTSTREAM_SINK_SAMPLING_FREQ_480000x1
+
+#define FASTSTREAM_SOURCE_SAMPLING_FREQ_16000 0x2
+
+typedef struct {
+ uint32_t vendor_id;
+ uint16_t codec_id;
+} __attribute__ ((packed)) a2dp_vendor_codec_t;
#if __BYTE_ORDER == __LITTLE_ENDIAN
@@ -88,6 +121,48 @@ typedef struct {
uint16_t bitrate;
} __attribute__ ((packed)) a2dp_mpeg_t;
+typedef struct {
+ a2dp_vendor_codec_t info;
+ uint8_t channel_mode:4;
+ uint8_t frequency:4;
+} __attribute__ ((packed)) a2dp_aptx_t;
+
+typedef struct {
+ a2dp_vendor_codec_t info;
+ uint8_t direction;
+ uint8_t sink_frequency:4;
+ uint8_t source_frequency:4;
+} __attribute__ ((packed)) a2dp_faststream_t;
+
+typedef struct {
+ uint8_t reserved;
+ uint16_t target_codec_level;
+ uint16_t initial_codec_level;
+ uint8_t sra_max_rate;
+ uint8_t sra_avg_time;
+ uint16_t good_working_level;
+} __attribute__ ((packed)) a2dp_aptx_ll_new_caps_t;
+
+typedef struct {
+ a2dp_vendor_codec_t info;
+ uint8_t channel_mode:4;
+ uint8_t frequency:4;
+ uint8_t bidirect_link:1;
+ uint8_t has_new_caps:1;
+ uint8_t reserved:6;
+ a2dp_aptx_ll_new_caps_t new_caps[0];
+} __attribute__ ((packed)) a2dp_aptx_ll_t;
+
+typedef struct {
+ a2dp_vendor_codec_t info;
+ uint8_t channel_mode:4;
+ uint8_t frequency:4;
+ uint8_t reserved0;
+ uint8_t reserved1;
+ uint8_t reserved2;
+ uint8_t reserved3;
+} __attribute__ ((packed)) a2dp_aptx_hd_t;
+
#elif __BYTE_ORDER == __BIG_ENDIAN
typedef struct {
@@ -110,6 +185,48 @@ typedef struct {
uint16_t bitrate;
} __attribute__ ((packed)) a2dp_mpeg_t;
+typedef struct {
+ a2dp_vendor_codec_t info;
+ uint8_t frequency:4;
+ uint8_t channel_mode:4;
+} __attribute__ ((packed)) a2dp_aptx_t;
+
+typedef struct {
+ a2dp_vendor_codec_t info;
+ uint8_t direction;
+ uint8_t source_frequency:4;
+ uint8_t sink_frequency:4;
+} __attribute__ ((packed)) a2dp_faststream_t;
+
+typedef struct {
+ uint8_t reserved;
+ uint16_t target_codec_level;
+ uint16_t initial_codec_level;
+ uint8_t sra_max_rate;
+ uint8_t sra_avg_time;
+ uint16_t good_working_level;
+} __attribute__ ((packed)) a2dp_aptx_ll_new_caps_t;
+
+typedef struct {
+ a2dp_vendor_codec_t info;
+ uint8_t frequency:4;
+ uint8_t channel_mode:4;
+ uint8_t reserved:6;
+
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Thursday 21 June 2018 05:45:39 Arun Raghavan wrote: > On Wed, 20 Jun 2018, at 9:05 PM, Jan Alexander Steffens wrote: > > On Mon, Jun 18, 2018, 09:42 Pali Rohár wrote: > > > > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > > > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > > > > Hi! As you may know lot of bluetooth headsets support not only SBC, > > > > > but > > > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > > > > ffmpeg has clean-room implementation based on expired patent. What > > > about > > > > > adding support for aptX via ffmpeg into pulseaudio? > > > > > > > > > > -- > > > > > > > > I'd actually like to delete the SBC code and replace it with a generic > > > GStreamer bin. That would allow us to be codec agnostic, and support any > > > of > > > the codecs that are supported by GStreamer (which includes those that > > > ffmpeg provides). > > > > > > This does not sound like a good idea. The only two relevant bluetooth > > > codecs for most people are SBC and aptX. > > > > > > > Don't forget AAC. I've seen this one a lot in devices meant for use with > > iPhones, which apparently don't have aptX. GStreamer has a lot of encoders > > for it so this shouldn't be a problem unless it's some strange AAC variant. > > > > There's also LDAC but I haven't seen it on a device yet. > > Right, there are multiple codecs that we can support, and we should not tie > ourselves to a specific implementation. For this reason, and more generally, > I'd like to have PulseAudio not have to deal with any codec implementations > at all (nor even RTP, if we can help it), hence my preference to use > something generic in the form of GStreamer. This is a good idea to let external service to do codec-specific functions... I agree that it simplify pulseaudio code and other things (like proving new codec by external library -- if properly implemented), but in bluetooth context we should look at questions: 1) Has gstreamer support for SBC codec? 2) Has gstreamer support for aptX codec? These are two major codecs supported by bluetooth headsets. Answer is: NO (SBC is now provided in the "bad" set which is not pre-installed by gstreamer) So gstreamer in current state is not very useful for pulseaudio. Important are also MPEG1/2 (which are defined as optional by A2DP) and also AAC and LDAC which Jan wrote. But gstreamer has again only plugins in "bad" and "ugly" sets for them; nothing preinstalled by default. To have working bluetooth support in pulseadio, pulseaudio needs to use external library for encoding which *always* provides support for SBC. And not only if user manually installs some special plugin for 3rd party library. (And not only SBC, but also those other aptX, MPEG1/2, AAC and LDAC codecs) -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Wednesday 20 June 2018 17:40:09 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Mon, Jun 18, 2018 at 10:35 AM, Pali Rohár wrote: > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > >> On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > >> > Hi! As you may know lot of bluetooth headsets support not only SBC, but > >> > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > >> > aptX HD encoder and decoder. AptX codec itself is proprietary, but > >> > ffmpeg has clean-room implementation based on expired patent. What about > >> > adding support for aptX via ffmpeg into pulseaudio? > >> > > >> > -- > >> > >> I'd actually like to delete the SBC code and replace it with a generic > >> GStreamer bin. That would allow us to be codec agnostic, and support any > >> of the codecs that are supported by GStreamer (which includes those that > >> ffmpeg provides). > > > > This does not sound like a good idea. The only two relevant bluetooth > > codecs for most people are SBC and aptX. > > > > IIRC you cannot just choose arbitrary codec and use it in bluetooth, you > > need to know how to put it into A2DP. Therefore for each bluetooth codec > > you need to write some A2DP code or at least declarative definition. So > > it would not work just adding dependency on gstreamer and let gstreamer > > provide some encoded stream. > > I guess we could limit to only codecs we know how to expose the > capabilities, but note that it is possible to define vendor specific > codecs in A2DP so in theory one can use other codecs like OPUS > although it most likely won't have much use without the remote to also > support them, but I guess it is a start. Yes, it is possible to define vendor specific codes in A2DP, but then only that "vendor" implementation would support that codec. So if you define "pulseaudio" vendor codec, then only other instance of pulseaudio on other A2DP would be able to use it. Which is not so much useful. > > And also we cannot ensure or force at compile time that users would have > > installed both gstreamer and ffmpeg at runtime to have working bluetooth > > support. > > We anyway register endpoints at runtime and if we cannot detect SBC > for example we can still fallback to non-gstreamer/native mode. That means we still need to have native (libsbc?) implementation in pulseadio. Then somebody can ask question: why we need to have support for gstreamer's sbc, if pulseaudio has own native support? (no offense) > > For me it looks like a overkill to add dependency on gstreamer to > > pulseaudio, which would have some runtime dependency on ffmpeg to have > > working bluetooth support. And it would work only with the last ffmpeg > > version which is not widely available yet (and replacing system version > > is not always trivial). > > > > Anyway, I would try to write simple aptX library based on published > > details and ffmpeg source code. And try to play with pulseaudio if I > > would be able to start streaming aptX to bluetooth headset. This is at > > least good starting point to prove that aptX codec is usable or not in > > pulseaudio. > > Having native support won't be bad either but I think we need to have > some module support added in order to make easier to add new codecs > which should be useful if we ever come to integrate with gstreamer. Module support in pulseaudio could be useful. But for every codec you need to define how to use it in A2DP. And because gstreamer does not provide this information, the only thing which can be done is definition of every supported codec in pulseaudio with code which would call gstreamer function for encoding (or decoding). I think this is too much work without big benefit for users. > > -- > > Pali Rohár > > pali.ro...@gmail.com > > ___ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > Hi! As you may know lot of bluetooth headsets support not only SBC, but > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > ffmpeg has clean-room implementation based on expired patent. What about > > adding support for aptX via ffmpeg into pulseaudio? > > > > -- > > I'd actually like to delete the SBC code and replace it with a generic > GStreamer bin. That would allow us to be codec agnostic, and support any of > the codecs that are supported by GStreamer (which includes those that ffmpeg > provides). This does not sound like a good idea. The only two relevant bluetooth codecs for most people are SBC and aptX. IIRC you cannot just choose arbitrary codec and use it in bluetooth, you need to know how to put it into A2DP. Therefore for each bluetooth codec you need to write some A2DP code or at least declarative definition. So it would not work just adding dependency on gstreamer and let gstreamer provide some encoded stream. And also we cannot ensure or force at compile time that users would have installed both gstreamer and ffmpeg at runtime to have working bluetooth support. For me it looks like a overkill to add dependency on gstreamer to pulseaudio, which would have some runtime dependency on ffmpeg to have working bluetooth support. And it would work only with the last ffmpeg version which is not widely available yet (and replacing system version is not always trivial). Anyway, I would try to write simple aptX library based on published details and ffmpeg source code. And try to play with pulseaudio if I would be able to start streaming aptX to bluetooth headset. This is at least good starting point to prove that aptX codec is usable or not in pulseaudio. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Bluetooth aptX codec
Hi! As you may know lot of bluetooth headsets support not only SBC, but also aptX codec. And new version of ffmpeg (4.0) has native aptX and aptX HD encoder and decoder. AptX codec itself is proprietary, but ffmpeg has clean-room implementation based on expired patent. What about adding support for aptX via ffmpeg into pulseaudio? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Headset support
On Friday 06 April 2018 10:20:42 David Woodhouse wrote: > > > On Wed, 2018-04-04 at 18:53 +0200, Pali Rohár wrote: > > On Wednesday 04 April 2018 16:47:57 David Woodhouse wrote: > > > I've now counted three types of headset control that we should support, > > > ideally through a consistent interface. > > > > > > > > > • The first is Bluetooth HFP/HSP for which support is already present > > > and just needs to be connected up. > > > > > > • Second is the USB HID devices, including most "Skype for Business" > > > certified headsets. I have a Pidgin plugin which drives these > > > directly, but it would be better for PulseAudio to open the HID > > > device for itself and for the controls to be associated with the > > > specific hardware. > > > > > > • Third is the Android/etc. 3.5mm jack where button presses are > > > implemented as short-circuit or specific resistances from the mic > > > pin to ground: > > > > > > https://source.android.com/devices/accessories/headset/plug-headset-spec > > > The Linux kernel has support for these (at least for a few codec > > > chips), and they appear as events on an input device along with the > > > jack insertion/removal events. Which I note we also don't support in > > > PA yet? Although there were patches in 2011 at > > > > > > https://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg09830.html > > > > > > > > > Are there any more? > > Thanks. > > > Nokia ECI headsets - 3.5mm jack with bi-directional ECI bus on MIC bias. > > In most cases those headsets contain buttons, but ECI bus supports also > > some memory read/write operations. But IIRC it is not possible to use > > them with ordinary sound cards (activating MIC bias is too slow for ECI) > > and Nokia implemented ECI protocol in their phones at ASIC level, some > > translation of ECI to I2C. ECI protocol itself is undocumented, but I > > saw some images from oscilloscope from which protocol could be decoded. > > That one I think is a kernel problem. If implemented in Linux, it would > presumably end up appearing to userspace just the same way as #3 above, > with a separate input device emitting events for the button presses. > Userspace doesn't necessarily need to care, right? I would stick with fact that it is currently unsupported. I can imagine fully software implementation in userspace e.g. very good sound card where sound software would do sampling of microphone input and would do whole decoding. But in any case (once support will be there) it results in input device and it would have exactly same problems and you wrote for USB headsets below. > > Other Nokia headsets (non-ECI) - again 3.5mm jack, but supports only one > > button press. Maybe similar to your "third" one. > > Yeah, probably. And either way, I think it's still the kernel's problem > to work out the hardware details and just emit events. Example is Nokia N900. Here kernel creates one input device and send BTN_something event when button is pressed. There is just one button and what pressing it means is up to the userspace. It can be used e.g. for accepting voice call or acts as play/pause... > > Bluetooth A2DP with AVRCP - but this should be already supported. > > With the possible exception of volume control, I suspect AVRCP support > is mostly outside the scope of PulseAudio. For volume controls we might > want to ensure that they affect the *correct* device volume, in the > A2DP+AVRCP case where there clearly is a "correct" device. But not the > case of a pure AVRCP remote control. Yes, I agree. > We have this problem with volume control on USB headsets already. They > provide a HID device which emits KEY_VOLUMEUP / KEY_VOLUMEDOWN events. > So right now as I'm listening to a podcast on my headset, if I press a > volume button not only does it immediately change the headset volume, > but the system *also* sees that "keypress" and adjusts the volume of > the laptop's built-in speakers too. Which is wrong. That volume > keypress should have been handled in the context of the device it came > from. We *do* get that right for HFP, I believe. > > Other than volume control, the main common headset control features > are: > > • on/off hook. > • mute (mic). > • ring > • Additional feature button(s) > > At least for the SfB-certified USB headsets, the hook and mute controls > need management. When the mute/hook buttons are pressed, userspace has > to update the mute/hook status on the device accordi
Re: [pulseaudio-discuss] Headset support
On Wednesday 04 April 2018 16:47:57 David Woodhouse wrote: > I've now counted three types of headset control that we should support, > ideally through a consistent interface. > > > • The first is Bluetooth HFP/HSP for which support is already present > and just needs to be connected up. > > • Second is the USB HID devices, including most "Skype for Business" > certified headsets. I have a Pidgin plugin which drives these > directly, but it would be better for PulseAudio to open the HID > device for itself and for the controls to be associated with the > specific hardware. > > • Third is the Android/etc. 3.5mm jack where button presses are > implemented as short-circuit or specific resistances from the mic > pin to ground: > https://source.android.com/devices/accessories/headset/plug-headset-spec > The Linux kernel has support for these (at least for a few codec > chips), and they appear as events on an input device along with the > jack insertion/removal events. Which I note we also don't support in > PA yet? Although there were patches in 2011 at > > https://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg09830.html > > > Are there any more? Nokia ECI headsets - 3.5mm jack with bi-directional ECI bus on MIC bias. In most cases those headsets contain buttons, but ECI bus supports also some memory read/write operations. But IIRC it is not possible to use them with ordinary sound cards (activating MIC bias is too slow for ECI) and Nokia implemented ECI protocol in their phones at ASIC level, some translation of ECI to I2C. ECI protocol itself is undocumented, but I saw some images from oscilloscope from which protocol could be decoded. Other Nokia headsets (non-ECI) - again 3.5mm jack, but supports only one button press. Maybe similar to your "third" one. Bluetooth A2DP with AVRCP - but this should be already supported. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] UI form enhancement (question)
On Friday 23 March 2018 23:03:29 Tanu Kaskinen wrote: > On Sat, 2018-03-24 at 01:03 +0500, Nikita Zlobin wrote: > > It appeared, that i already made commit, while email in git was set to > > nick877...@gmail.com. Should i revert and commit with current email, or > > this is acceptable? > > We don't mind what email address you use, but if there's some reason > why you don't want the gmail address appearing in the git history, > maybe it's best to resubmit the patch with the right address. Whoever > applies the patch could also fix the address manually, but it's easy to > forget to do that. git supports .mailmap, see: https://git-scm.com/docs/git-shortlog -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Switching bluetooth profile internally
Any pulseadio application? From application which uses pulseaudio there is no difference between intel HDA card or bluetooth headset. Both are just pulseaudio stream. On Friday 11 August 2017 17:33:49 Sathish Narasimman wrote: > Hi, > > Very thanks for the information. Also, may I know the right VOIP > application in Linux. where Bluetooth works well. > > > On Fri, Aug 11, 2017 at 3:09 PM, Pali Rohár <pali.ro...@gmail.com> wrote: > > So then just set media.role to phone and module-bluetooth-policy from > > pulseaudio 10.0 would take care for automatic switch between a2dp and > > hsp once your application stop resp. start recording sound. > > > > See about media.role: > > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/ApplicationProperties/ > > > > On Friday 11 August 2017 15:04:08 Sathish Narasimman wrote: > >> Hi, > >> > >> My application is almost similar to what VOIP application. > >> I am trying to create a communication between the laptop and headset. > >> That is Tx and Rx full-duplex communication between the laptop and > >> Bluetooth headset. > >> > >> Also can you please mention the VOIP application that works well with > >> Ubuntu. > >> I tried skype and it is not working with Bluetooth. > >> > >> > >> > >> > >> On Fri, Aug 11, 2017 at 2:49 PM, Pali Rohár <pali.ro...@gmail.com> wrote: > >> > On Friday 11 August 2017 11:02:15 Georg Chini wrote: > >> >> On 11.08.2017 10:09, Sathish Narasimman wrote: > >> >> >Hi, > >> >> > > >> >> >I want to switch the bluetooth profile using a dbus signal. > >> >> > > >> >> >I was successful to send the dbus signal and process it in pulseaudio. > >> >> > > >> >> >But unable to figure out how to use set_profile within PA. > >> >> > > >> >> >Please help to understand the pulseaudio. I need to switch the profile > >> >> >from a2dp to hsp and vice versa. > >> >> > > >> >> > > >> >> >Thanks, > >> >> >Sathish N > >> >> >___ > >> >> >pulseaudio-discuss mailing list > >> >> >pulseaudio-discuss@lists.freedesktop.org > >> >> >https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > >> >> > >> >> Hi, > >> >> > >> >> I wonder what you are trying to achieve. You can use pactl or pacmd > >> >> to change the card profile manually and module-bluetooth-policy will > >> >> automatically switch profile for you in some situations See here: > >> >> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index36h3 > >> > > >> > Also in pulseaudio 10 module-bluetooth-policy would automatically switch > >> > between a2dp and hsp if VOIP application want to record sound from > >> > microphone: > >> > > >> > https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/10.0/#automaticallyswitchbluetoothprofilewhenusingvoipapplications > >> > > >> > And starting with pulseaudio 11 (not released) module-bluetooth-policy > >> > could be configured with parameter auto_switch=2 (not by default) to > >> > automatically switch between a2dp and hsp based on heuristic, see: > >> > > >> > https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=3397127f0045d3c130b59e59b4ce6b3601b239b9 > >> > > >> > So why do you want to manually switch between hsp and a2dp mode? Is not > >> > this auto_switch support enough for you? > >> > > >> > -- > >> > Pali Rohár > >> > pali.ro...@gmail.com > >> > ___ > >> > pulseaudio-discuss mailing list > >> > pulseaudio-discuss@lists.freedesktop.org > >> > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > >> ___ > >> pulseaudio-discuss mailing list > >> pulseaudio-discuss@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > -- > > Pali Rohár > > pali.ro...@gmail.com > > ___ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Switching bluetooth profile internally
So then just set media.role to phone and module-bluetooth-policy from pulseaudio 10.0 would take care for automatic switch between a2dp and hsp once your application stop resp. start recording sound. See about media.role: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/ApplicationProperties/ On Friday 11 August 2017 15:04:08 Sathish Narasimman wrote: > Hi, > > My application is almost similar to what VOIP application. > I am trying to create a communication between the laptop and headset. > That is Tx and Rx full-duplex communication between the laptop and > Bluetooth headset. > > Also can you please mention the VOIP application that works well with Ubuntu. > I tried skype and it is not working with Bluetooth. > > > > > On Fri, Aug 11, 2017 at 2:49 PM, Pali Rohár <pali.ro...@gmail.com> wrote: > > On Friday 11 August 2017 11:02:15 Georg Chini wrote: > >> On 11.08.2017 10:09, Sathish Narasimman wrote: > >> >Hi, > >> > > >> >I want to switch the bluetooth profile using a dbus signal. > >> > > >> >I was successful to send the dbus signal and process it in pulseaudio. > >> > > >> >But unable to figure out how to use set_profile within PA. > >> > > >> >Please help to understand the pulseaudio. I need to switch the profile > >> >from a2dp to hsp and vice versa. > >> > > >> > > >> >Thanks, > >> >Sathish N > >> >___ > >> >pulseaudio-discuss mailing list > >> >pulseaudio-discuss@lists.freedesktop.org > >> >https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > >> > >> Hi, > >> > >> I wonder what you are trying to achieve. You can use pactl or pacmd > >> to change the card profile manually and module-bluetooth-policy will > >> automatically switch profile for you in some situations See here: > >> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index36h3 > > > > Also in pulseaudio 10 module-bluetooth-policy would automatically switch > > between a2dp and hsp if VOIP application want to record sound from > > microphone: > > > > https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/10.0/#automaticallyswitchbluetoothprofilewhenusingvoipapplications > > > > And starting with pulseaudio 11 (not released) module-bluetooth-policy > > could be configured with parameter auto_switch=2 (not by default) to > > automatically switch between a2dp and hsp based on heuristic, see: > > > > https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=3397127f0045d3c130b59e59b4ce6b3601b239b9 > > > > So why do you want to manually switch between hsp and a2dp mode? Is not > > this auto_switch support enough for you? > > > > -- > > Pali Rohár > > pali.ro...@gmail.com > > ___ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Switching bluetooth profile internally
On Friday 11 August 2017 11:02:15 Georg Chini wrote: > On 11.08.2017 10:09, Sathish Narasimman wrote: > >Hi, > > > >I want to switch the bluetooth profile using a dbus signal. > > > >I was successful to send the dbus signal and process it in pulseaudio. > > > >But unable to figure out how to use set_profile within PA. > > > >Please help to understand the pulseaudio. I need to switch the profile > >from a2dp to hsp and vice versa. > > > > > >Thanks, > >Sathish N > >___ > >pulseaudio-discuss mailing list > >pulseaudio-discuss@lists.freedesktop.org > >https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > Hi, > > I wonder what you are trying to achieve. You can use pactl or pacmd > to change the card profile manually and module-bluetooth-policy will > automatically switch profile for you in some situations See here: > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index36h3 Also in pulseaudio 10 module-bluetooth-policy would automatically switch between a2dp and hsp if VOIP application want to record sound from microphone: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/10.0/#automaticallyswitchbluetoothprofilewhenusingvoipapplications And starting with pulseaudio 11 (not released) module-bluetooth-policy could be configured with parameter auto_switch=2 (not by default) to automatically switch between a2dp and hsp based on heuristic, see: https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=3397127f0045d3c130b59e59b4ce6b3601b239b9 So why do you want to manually switch between hsp and a2dp mode? Is not this auto_switch support enough for you? -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] About extra A2DP codecs support in bluetooth module
On Thursday 06 July 2017 11:26:58 Qu Wenruo wrote: > At 07/06/2017 04:33 PM, Pali Rohár wrote: > > On Thursday 06 July 2017 01:54:10 Qu Wenruo wrote: > >> Is there any license problem blocking pulseaudio to implement > >> such codec? > > > > All patents for MP3 already expired, so there should not be any > > license problem. > > Well, I'm more interested to see AAC codec support. > > As my Bose QC35 only supports AAC and SBC, no MP3 support. In some countries software patents do not exists at all. Anyway, if there would be support for other audio codec I guess pulseaudio would just use another (system) library for encoding. And would not implement encoder/decoder itself. Therefore I think patent/license question would be moved to (system) library for encoding (ffmpeg?, gstreamer?, etc...). Now, when you open question about bluetooth A2DP codecs, more interested would be state of APT-X codec/support. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] About extra A2DP codecs support in bluetooth module
On Thursday 06 July 2017 01:54:10 Qu Wenruo wrote: > Is there any license problem blocking pulseaudio to implement > such codec? All patents for MP3 already expired, so there should not be any license problem. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v3 2/3] bluetooth: Remove BlueZ 4 support
On Thursday 01 June 2017 01:10:08 Tanu Kaskinen wrote: > On Wed, 2017-05-31 at 09:30 +0200, Pali Rohár wrote: > > On Wednesday 31 May 2017 07:00:54 Arun Raghavan wrote: > > > On Sun, 28 May 2017, at 08:05 PM, Pali Rohár wrote: > > > > On Thursday 25 May 2017 10:36:36 Luiz Augusto von Dentz wrote: > > > > > BlueZ 4 is no longer supported by BlueZ community for a long long > > > > > time, also by moving to BlueZ 5 it should make it even more clearer > > > > > that BlueZ 4 is no longer an option. > > > > > > > > It is a really big problem to have working bluez4 code in puleaudio? > > > > > > As Luiz points out, it's been a while since BlueZ 4 was current. Is > > > there a reason you ask about keeping support for it around? > > > > I'm still using it. > > > > > While it might seem like there is no cost to just keeping the code > > > around, each time we add code, either it is BlueZ 5 only, or there's > > > overhead to make sure it builds and/or works on a BlueZ 4 setup. > > > > bluex4 is still in use and I do not think it is a good idea to do some > > version lock for particular software version if there are still users. > > Why are people still using bluez4? I understand that some long-term > support operating systems may still have bluez4, but they will keep > using an old version of pulseaudio too. Sailfish OS was the last > operating system that I know of that kept using bluez4 for a long time > while upgrading other system components, but they too have moved on to > bluez5 now. Is there still some distribution that will use (or would > like to use) pulseaudio 11 with bluez4? What distribution are you > using? Debian wheezy has bluez4. But I do not know if some distribution is going to use bluez4 + new pulseaudio by default. Personally I'm using combination of bluez4 + new pulseaudio (compiled from source) as bluez4 and bluez5 are not API compatible (so bluez4 cannot be replaced by bluez5 without breaking whole system), but new pulseaudio has better bluetooth support... -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v3 2/3] bluetooth: Remove BlueZ 4 support
On Wednesday 31 May 2017 07:00:54 Arun Raghavan wrote: > On Sun, 28 May 2017, at 08:05 PM, Pali Rohár wrote: > > On Thursday 25 May 2017 10:36:36 Luiz Augusto von Dentz wrote: > > > BlueZ 4 is no longer supported by BlueZ community for a long long > > > time, also by moving to BlueZ 5 it should make it even more clearer > > > that BlueZ 4 is no longer an option. > > > > It is a really big problem to have working bluez4 code in puleaudio? > > As Luiz points out, it's been a while since BlueZ 4 was current. Is > there a reason you ask about keeping support for it around? I'm still using it. > While it might seem like there is no cost to just keeping the code > around, each time we add code, either it is BlueZ 5 only, or there's > overhead to make sure it builds and/or works on a BlueZ 4 setup. bluex4 is still in use and I do not think it is a good idea to do some version lock for particular software version if there are still users. (E.g. gnome in past dropped bluez4 support which lead to non-working bluetooth microphone, but that is an another story...) -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v3 2/3] bluetooth: Remove BlueZ 4 support
On Thursday 25 May 2017 10:36:36 Luiz Augusto von Dentz wrote: > BlueZ 4 is no longer supported by BlueZ community for a long long > time, also by moving to BlueZ 5 it should make it even more clearer > that BlueZ 4 is no longer an option. It is a really big problem to have working bluez4 code in puleaudio? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Thinking about pulseaudio for debian stretch
On Thursday 03 November 2016 14:53:42 Felipe Sateler wrote: > On 3 November 2016 at 10:41, Tanu Kaskinen <ta...@iki.fi> wrote: > > On Thu, 2016-11-03 at 10:03 -0300, Felipe Sateler wrote: > >> Hi, > >> > >> The release of debian stretch is getting closer so I'm starting to > >> plan for it. Currently we are shipping 9.0. The question would be > >> if I should try to get 10 into stretch, or just stay with 9. > >> > >> Currently, the freeze is planned for february 5th, with a > >> no-new-packages policy since january. How are things looking to > >> have at least an RC during this year? > >> > >> I suppose shipping stretch with pa 10.0~rcN + some cherry-picked > >> fixes (if required) is not that crazy. > > > > I'd estimate that we'll have RC1 out within a few weeks and final > > release ready well in time for the Debian freeze. No promises, of > > course. > > Excellent. Having the first RC within november/early december makes > me think having version 10 (or at least a late RC + cherry-picked > fixes) will be the best choice. In that case RC should be released... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v4] bluetooth: Add optional heuristic for switching between hsp and a2dp profiles
Anybody?
On Monday 19 September 2016 16:44:00 Pali Rohár wrote:
> Hi! Please let me know what do you think about this v4 version of my patch.
>
> On Sunday 11 September 2016 16:41:02 Pali Rohár wrote:
> > Not all VOIP applications (specially those which use alsa) set media.role to
> > phone. This means we need some heuristic to determinate if we want to switch
> > from a2dp to hsp profile based on number and types of source output
> > (recording)
> > streams.
> >
> > And also some people want to use their bluetooth headset (with microphone)
> > as
> > their default recording device but some do not want to because of low
> > quality.
> >
> > This patch implements optional heuristic which is disabled by default. It is
> > disabled by default to not break experience of current pulseaudio users
> > because
> > heuristic cannot be optimal. Heuristic is implemented in
> > module-bluetooth-policy
> > module and decide if pulseaudio should switch to a hsp profile or not. It
> > checks
> > if there is some source output with pass all these conditions:
> >
> > * does not have set media.role
> > * does not use peak resample method (which is used by desktop volume
> > programs)
> > * has assigned client/application (non virtual stream)
> > * does not record from monitor of sink
> >
> > And if yes it switch to hsp profile.
> >
> > By default this heuristic is disabled and can be enabled when loading module
> > module-bluetooth-policy with specifying parameter auto_switch=2
> >
> > Because it is disabled by default nobody will be affected by this change
> > unless
> > manually change auto_switch parameter.
> >
> > Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
> > ---
> > src/modules/bluetooth/module-bluetooth-policy.c | 43
> > ---
> > 1 file changed, 30 insertions(+), 13 deletions(-)
> >
> > diff --git a/src/modules/bluetooth/module-bluetooth-policy.c
> > b/src/modules/bluetooth/module-bluetooth-policy.c
> > index 68c8ab4..3f085b8 100644
> > --- a/src/modules/bluetooth/module-bluetooth-policy.c
> > +++ b/src/modules/bluetooth/module-bluetooth-policy.c
> > @@ -38,7 +38,7 @@ PA_MODULE_DESCRIPTION("Policy module to make using
> > bluetooth devices out-of-the-
> > PA_MODULE_VERSION(PACKAGE_VERSION);
> > PA_MODULE_LOAD_ONCE(true);
> > PA_MODULE_USAGE(
> > -"auto_switch= "
> > +"auto_switch= > media.role=phone, 2 - heuristic> "
> > "a2dp_source= "
> > "ag= "
> > "hfgw= DEPRECATED");
> > @@ -52,6 +52,7 @@ static const char* const valid_modargs[] = {
> > };
> >
> > struct userdata {
> > +uint32_t auto_switch;
> > bool enable_a2dp_source;
> > bool enable_ag;
> > pa_hook_slot *source_put_slot;
> > @@ -210,7 +211,8 @@ static void switch_profile(pa_card *card, bool
> > revert_to_a2dp, void *userdata) {
> > }
> >
> > /* Return true if we should ignore this source output */
> > -static bool ignore_output(pa_source_output *source_output) {
> > +static bool ignore_output(pa_source_output *source_output, void *userdata)
> > {
> > +struct userdata *u = userdata;
> > const char *s;
> >
> > /* New applications could set media.role for identifying streams */
> > @@ -219,16 +221,32 @@ static bool ignore_output(pa_source_output
> > *source_output) {
> > if (s)
> > return !pa_streq(s, "phone");
> >
> > -return true;
> > +/* If media.role is not set use some heuristic (if enabled) */
> > +if (u->auto_switch != 2)
> > +return true;
> > +
> > +/* Ignore if resample method is peaks (used by desktop volume
> > programs) */
> > +if (pa_source_output_get_resample_method(source_output) ==
> > PA_RESAMPLER_PEAKS)
> > +return true;
> > +
> > +/* Ignore if there is no client/application assigned (used by virtual
> > stream) */
> > +if (!source_output->client)
> > +return true;
> > +
> > +/* Ignore if recording from monitor of sink */
> > +if (source_output->direct_on_input)
> > +return true;
> > +
> > +return false;
> > }
> >
> > -static unsigned source_output_count(pa_core *c) {
> > +static unsigned source_output_count(pa_core *c, void *userdata) {
> > pa_source_output *source_output;
> >
Re: [pulseaudio-discuss] [PATCH v4] bluetooth: Add optional heuristic for switching between hsp and a2dp profiles
Hi! Please let me know what do you think about this v4 version of my patch.
On Sunday 11 September 2016 16:41:02 Pali Rohár wrote:
> Not all VOIP applications (specially those which use alsa) set media.role to
> phone. This means we need some heuristic to determinate if we want to switch
> from a2dp to hsp profile based on number and types of source output
> (recording)
> streams.
>
> And also some people want to use their bluetooth headset (with microphone) as
> their default recording device but some do not want to because of low quality.
>
> This patch implements optional heuristic which is disabled by default. It is
> disabled by default to not break experience of current pulseaudio users
> because
> heuristic cannot be optimal. Heuristic is implemented in
> module-bluetooth-policy
> module and decide if pulseaudio should switch to a hsp profile or not. It
> checks
> if there is some source output with pass all these conditions:
>
> * does not have set media.role
> * does not use peak resample method (which is used by desktop volume programs)
> * has assigned client/application (non virtual stream)
> * does not record from monitor of sink
>
> And if yes it switch to hsp profile.
>
> By default this heuristic is disabled and can be enabled when loading module
> module-bluetooth-policy with specifying parameter auto_switch=2
>
> Because it is disabled by default nobody will be affected by this change
> unless
> manually change auto_switch parameter.
>
> Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
> ---
> src/modules/bluetooth/module-bluetooth-policy.c | 43
> ---
> 1 file changed, 30 insertions(+), 13 deletions(-)
>
> diff --git a/src/modules/bluetooth/module-bluetooth-policy.c
> b/src/modules/bluetooth/module-bluetooth-policy.c
> index 68c8ab4..3f085b8 100644
> --- a/src/modules/bluetooth/module-bluetooth-policy.c
> +++ b/src/modules/bluetooth/module-bluetooth-policy.c
> @@ -38,7 +38,7 @@ PA_MODULE_DESCRIPTION("Policy module to make using
> bluetooth devices out-of-the-
> PA_MODULE_VERSION(PACKAGE_VERSION);
> PA_MODULE_LOAD_ONCE(true);
> PA_MODULE_USAGE(
> -"auto_switch= "
> +"auto_switch= media.role=phone, 2 - heuristic> "
> "a2dp_source= "
> "ag= "
> "hfgw= DEPRECATED");
> @@ -52,6 +52,7 @@ static const char* const valid_modargs[] = {
> };
>
> struct userdata {
> +uint32_t auto_switch;
> bool enable_a2dp_source;
> bool enable_ag;
> pa_hook_slot *source_put_slot;
> @@ -210,7 +211,8 @@ static void switch_profile(pa_card *card, bool
> revert_to_a2dp, void *userdata) {
> }
>
> /* Return true if we should ignore this source output */
> -static bool ignore_output(pa_source_output *source_output) {
> +static bool ignore_output(pa_source_output *source_output, void *userdata) {
> +struct userdata *u = userdata;
> const char *s;
>
> /* New applications could set media.role for identifying streams */
> @@ -219,16 +221,32 @@ static bool ignore_output(pa_source_output
> *source_output) {
> if (s)
> return !pa_streq(s, "phone");
>
> -return true;
> +/* If media.role is not set use some heuristic (if enabled) */
> +if (u->auto_switch != 2)
> +return true;
> +
> +/* Ignore if resample method is peaks (used by desktop volume programs)
> */
> +if (pa_source_output_get_resample_method(source_output) ==
> PA_RESAMPLER_PEAKS)
> +return true;
> +
> +/* Ignore if there is no client/application assigned (used by virtual
> stream) */
> +if (!source_output->client)
> +return true;
> +
> +/* Ignore if recording from monitor of sink */
> +if (source_output->direct_on_input)
> +return true;
> +
> +return false;
> }
>
> -static unsigned source_output_count(pa_core *c) {
> +static unsigned source_output_count(pa_core *c, void *userdata) {
> pa_source_output *source_output;
> uint32_t idx;
> unsigned count = 0;
>
> PA_IDXSET_FOREACH(source_output, c->source_outputs, idx)
> -if (!ignore_output(source_output))
> +if (!ignore_output(source_output, userdata))
> ++count;
>
> return count;
> @@ -248,7 +266,7 @@ static pa_hook_result_t
> source_output_put_hook_callback(pa_core *c, pa_source_ou
> pa_assert(c);
> pa_assert(source_output);
>
> -if (ignore_output(source_output))
> +if (ignore_output(source_output, userdata))
> return PA_HOOK_OK;
>
> switch_profile_all(c->card
[pulseaudio-discuss] [PATCH] bluetooth: bluez5: Add profile name to sinks and sources
See commit 380a7fc2401ea26151e0383adff05314a263ac31.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
I have this bluez5 patch on my HDD for a long time, but I have not tested
it yet. I think it can be useful so I'm sending it to list...
---
src/modules/bluetooth/module-bluez5-device.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/modules/bluetooth/module-bluez5-device.c
b/src/modules/bluetooth/module-bluez5-device.c
index b8b0493..a05ae8d 100644
--- a/src/modules/bluetooth/module-bluez5-device.c
+++ b/src/modules/bluetooth/module-bluez5-device.c
@@ -947,7 +947,7 @@ static int add_source(struct userdata *u) {
data.module = u->module;
data.card = u->card;
data.driver = __FILE__;
-data.name = pa_sprintf_malloc("bluez_source.%s", u->device->address);
+data.name = pa_sprintf_malloc("bluez_source.%s.%s", u->device->address,
pa_bluetooth_profile_to_string(u->profile));
data.namereg_fail = false;
pa_proplist_sets(data.proplist, "bluetooth.protocol",
pa_bluetooth_profile_to_string(u->profile));
pa_source_new_data_set_sample_spec(, >sample_spec);
@@ -1104,7 +1104,7 @@ static int add_sink(struct userdata *u) {
data.module = u->module;
data.card = u->card;
data.driver = __FILE__;
-data.name = pa_sprintf_malloc("bluez_sink.%s", u->device->address);
+data.name = pa_sprintf_malloc("bluez_sink.%s.%s", u->device->address,
pa_bluetooth_profile_to_string(u->profile));
data.namereg_fail = false;
pa_proplist_sets(data.proplist, "bluetooth.protocol",
pa_bluetooth_profile_to_string(u->profile));
pa_sink_new_data_set_sample_spec(, >sample_spec);
--
1.7.9.5
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] module-bluetooth-policy : How to use auto switch profile?
Hi Greg! Few days ago I sent patch for bluez5 support to ML. If you have time for testing, please let me know results. On Monday 05 September 2016 15:56:34 Greg wrote: > > No, you must use version from git. Not some stable with that patch, it > > is not enough. > > Sorry I missed that point! > > Now here I am, when I launche pulseaudio form the build tree > (./src/pulseaudio -n -F src/default.pa -p $(pwd)/src/) > > bluez4-util.c: org.bluez.Manager.GetProperties() failed: > org.freedesktop.DBus.Error.UnknownMethod: Method "GetProperties" with > signature "" on interface "org.bluez.Manager" doesn't exist > > I think that the bluez 5 limit you were talking about? > > Thanks & hope to hear about you soon :) > > Have a nice day, > > > > On 5 September 2016 at 15:38, Pali Rohár <pali.ro...@gmail.com> wrote: > > > On Monday 05 September 2016 15:32:51 Greg wrote: > > > What do you think about it? Is it cause by bluez5? > > > > No, you must use version from git. Not some stable with that patch, it > > is not enough. > > > > -- > > Pali Rohár > > pali.ro...@gmail.com > > > > > -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] bluetooth: Add support for automatic switch between hsp and a2dp profiles also for bluez5
Bluez5 uses different profile names as bluez4, so we need to check for
a2dp_sink and headset_head_unit too for bluez5 support.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
I have not tested this patch yet, but there are people who already wanted
bluez5 support so I'm sending my patch. If there are any problems let me
know and I could try to fix them... Btw, same check for profile names is
already done in code for loading loopback module.
---
src/modules/bluetooth/module-bluetooth-policy.c | 60 +--
1 file changed, 33 insertions(+), 27 deletions(-)
diff --git a/src/modules/bluetooth/module-bluetooth-policy.c
b/src/modules/bluetooth/module-bluetooth-policy.c
index 3f085b8..bedf011 100644
--- a/src/modules/bluetooth/module-bluetooth-policy.c
+++ b/src/modules/bluetooth/module-bluetooth-policy.c
@@ -145,23 +145,29 @@ static pa_hook_result_t sink_put_hook_callback(pa_core
*c, pa_sink *sink, void *
return PA_HOOK_OK;
}
-static void card_set_profile(struct userdata *u, pa_card *card, const char
*to_profile, bool revert_to_a2dp)
+static void card_set_profile(struct userdata *u, pa_card *card, bool
revert_to_a2dp)
{
pa_card_profile *profile;
void *state;
-/* Find available to_profile and activate it */
+/* Find available profile and activate it */
PA_HASHMAP_FOREACH(profile, card->profiles, state) {
-if (!pa_streq(profile->name, to_profile))
-continue;
-
if (profile->available == PA_AVAILABLE_NO)
continue;
-pa_log_debug("Setting card '%s' to profile '%s'", card->name,
to_profile);
+/* Check for correct profile based on revert_to_a2dp */
+if (revert_to_a2dp) {
+if (!pa_streq(profile->name, "a2dp") && !pa_streq(profile->name,
"a2dp_sink"))
+continue;
+} else {
+if (!pa_streq(profile->name, "hsp") && !pa_streq(profile->name,
"headset_head_unit"))
+continue;
+}
+
+pa_log_debug("Setting card '%s' to profile '%s'", card->name,
profile->name);
if (pa_card_set_profile(card, profile, false) != 0) {
-pa_log_warn("Could not set profile '%s'", to_profile);
+pa_log_warn("Could not set profile '%s'", profile->name);
continue;
}
@@ -176,18 +182,8 @@ static void card_set_profile(struct userdata *u, pa_card
*card, const char *to_p
/* Switch profile for one card */
static void switch_profile(pa_card *card, bool revert_to_a2dp, void *userdata)
{
struct userdata *u = userdata;
-const char *from_profile;
-const char *to_profile;
const char *s;
-if (revert_to_a2dp) {
-from_profile = "hsp";
-to_profile = "a2dp";
-} else {
-from_profile = "a2dp";
-to_profile = "hsp";
-}
-
/* Only consider bluetooth cards */
s = pa_proplist_gets(card->proplist, PA_PROP_DEVICE_BUS);
if (!s || !pa_streq(s, "bluetooth"))
@@ -197,17 +193,25 @@ static void switch_profile(pa_card *card, bool
revert_to_a2dp, void *userdata) {
/* In revert_to_a2dp phase only consider cards with will_need_revert
flag and remove it */
if (!pa_hashmap_remove(u->will_need_revert_card_map, card))
return;
-}
-/* Skip card if does not have active from_profile */
-if (!pa_streq(card->active_profile->name, from_profile))
-return;
+/* Skip card if does not have active hsp profile */
+if (!pa_streq(card->active_profile->name, "hsp") &&
!pa_streq(card->active_profile->name, "headset_head_unit"))
+return;
-/* Skip card if already has active profile to_profile */
-if (pa_streq(card->active_profile->name, to_profile))
-return;
+/* Skip card if already has active a2dp profile */
+if (pa_streq(card->active_profile->name, "a2dp") ||
pa_streq(card->active_profile->name, "a2dp_sink"))
+return;
+} else {
+/* Skip card if does not have active a2dp profile */
+if (!pa_streq(card->active_profile->name, "a2dp") &&
!pa_streq(card->active_profile->name, "a2dp_sink"))
+return;
+
+/* Skip card if already has active hsp profile */
+if (pa_streq(card->active_profile->name, "hsp") ||
pa_streq(card->active_profile->name, "headset_head_unit"))
+return;
+}
-card_set_profile(u, card, to_profile, revert_to_a2dp);
+card_set_profile(u, card, revert_to_a2dp);
}
/* Return true if we should ignore this source output */
@@ -305,11 +309,13 @@ static pa_hook_result_t
card_init_profile_hook_callback(pa_core *c
[pulseaudio-discuss] [PATCH v4] bluetooth: Add optional heuristic for switching between hsp and a2dp profiles
Not all VOIP applications (specially those which use alsa) set media.role to
phone. This means we need some heuristic to determinate if we want to switch
from a2dp to hsp profile based on number and types of source output (recording)
streams.
And also some people want to use their bluetooth headset (with microphone) as
their default recording device but some do not want to because of low quality.
This patch implements optional heuristic which is disabled by default. It is
disabled by default to not break experience of current pulseaudio users because
heuristic cannot be optimal. Heuristic is implemented in module-bluetooth-policy
module and decide if pulseaudio should switch to a hsp profile or not. It checks
if there is some source output with pass all these conditions:
* does not have set media.role
* does not use peak resample method (which is used by desktop volume programs)
* has assigned client/application (non virtual stream)
* does not record from monitor of sink
And if yes it switch to hsp profile.
By default this heuristic is disabled and can be enabled when loading module
module-bluetooth-policy with specifying parameter auto_switch=2
Because it is disabled by default nobody will be affected by this change unless
manually change auto_switch parameter.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
src/modules/bluetooth/module-bluetooth-policy.c | 43 ---
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/src/modules/bluetooth/module-bluetooth-policy.c
b/src/modules/bluetooth/module-bluetooth-policy.c
index 68c8ab4..3f085b8 100644
--- a/src/modules/bluetooth/module-bluetooth-policy.c
+++ b/src/modules/bluetooth/module-bluetooth-policy.c
@@ -38,7 +38,7 @@ PA_MODULE_DESCRIPTION("Policy module to make using bluetooth
devices out-of-the-
PA_MODULE_VERSION(PACKAGE_VERSION);
PA_MODULE_LOAD_ONCE(true);
PA_MODULE_USAGE(
-"auto_switch= "
+"auto_switch= "
"a2dp_source= "
"ag= "
"hfgw= DEPRECATED");
@@ -52,6 +52,7 @@ static const char* const valid_modargs[] = {
};
struct userdata {
+uint32_t auto_switch;
bool enable_a2dp_source;
bool enable_ag;
pa_hook_slot *source_put_slot;
@@ -210,7 +211,8 @@ static void switch_profile(pa_card *card, bool
revert_to_a2dp, void *userdata) {
}
/* Return true if we should ignore this source output */
-static bool ignore_output(pa_source_output *source_output) {
+static bool ignore_output(pa_source_output *source_output, void *userdata) {
+struct userdata *u = userdata;
const char *s;
/* New applications could set media.role for identifying streams */
@@ -219,16 +221,32 @@ static bool ignore_output(pa_source_output
*source_output) {
if (s)
return !pa_streq(s, "phone");
-return true;
+/* If media.role is not set use some heuristic (if enabled) */
+if (u->auto_switch != 2)
+return true;
+
+/* Ignore if resample method is peaks (used by desktop volume programs) */
+if (pa_source_output_get_resample_method(source_output) ==
PA_RESAMPLER_PEAKS)
+return true;
+
+/* Ignore if there is no client/application assigned (used by virtual
stream) */
+if (!source_output->client)
+return true;
+
+/* Ignore if recording from monitor of sink */
+if (source_output->direct_on_input)
+return true;
+
+return false;
}
-static unsigned source_output_count(pa_core *c) {
+static unsigned source_output_count(pa_core *c, void *userdata) {
pa_source_output *source_output;
uint32_t idx;
unsigned count = 0;
PA_IDXSET_FOREACH(source_output, c->source_outputs, idx)
-if (!ignore_output(source_output))
+if (!ignore_output(source_output, userdata))
++count;
return count;
@@ -248,7 +266,7 @@ static pa_hook_result_t
source_output_put_hook_callback(pa_core *c, pa_source_ou
pa_assert(c);
pa_assert(source_output);
-if (ignore_output(source_output))
+if (ignore_output(source_output, userdata))
return PA_HOOK_OK;
switch_profile_all(c->cards, false, userdata);
@@ -260,11 +278,11 @@ static pa_hook_result_t
source_output_unlink_hook_callback(pa_core *c, pa_source
pa_assert(c);
pa_assert(source_output);
-if (ignore_output(source_output))
+if (ignore_output(source_output, userdata))
return PA_HOOK_OK;
/* If there are still some source outputs do nothing (count is with *this*
source_output, so +1) */
-if (source_output_count(c) > 1)
+if (source_output_count(c, userdata) > 1)
return PA_HOOK_OK;
switch_profile_all(c->cards, true, userdata);
@@ -278,7 +296,7 @@ static pa_hook_result_t
card_init_profile_hook_callback(pa_core *c, pa_card *car
pa_assert(c);
pa_assert(card);
-if (source_output_count(c) == 0)
+if (source_outp
Re: [pulseaudio-discuss] Multi user access to PulseAudio
On Sunday 11 September 2016 13:10:53 Ralph Benzinger wrote: > Actually looking at "what is wrong with system mode?", all security > issues are moot for me, as I own all the users on the system. But > the point > > When in system mode, shared memory data transport is disabled for > security reasons, which means: much higher memory usage and CPU > load in system mode > > does sound bad. Could someone quantify this statement so that one > might see if this is an actual issue (rather than a mere fact) on a > modern desktop system? I already suggested some pulseaudio cmdline switch or config option to enable shared memory data transport also for system wide mode. But do not know if some actions were taken or not... It could really help in situations where admin wants to share pulseaudio daemon between multiple (or all) users. Is not system mode designed for such situations? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] module-bluetooth-policy : How to use auto switch profile?
On Monday 05 September 2016 15:32:51 Greg wrote: > What do you think about it? Is it cause by bluez5? No, you must use version from git. Not some stable with that patch, it is not enough. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] module-bluetooth-policy : How to use auto switch profile?
On Friday 02 September 2016 09:57:40 Greg wrote: > Hello community, > > I'm using a BT headset with a microphone. > > I'm using A2DP profile to listen music and HSP when using a softphone > (Jitsi). > Today, I have a key shortcut that toggle the profile when I'm receiving a > call (pacmd set-card-profile bluez_card.0C_E0_E4_8D_15_50 > headset_head_unit). > > This a manual intervention, and from what i understand, there seems to be a > way to do it automatically with module-blutetooth-policy? Yes, new patch for module-bluetooth-policy [1] can do that. But IIRC it is only in git, not in some released PA version. Once some application create recording stream with media.role=phone then that policy module automatically switch to HSP and after stream is destroyed it switch back to A2DP. But it is still not complete, I need to finish it. Currently I tested it only for bluez4. [1] - https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=bde2ff8794a9363b1f7f2c683b160268ce371770 -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5] bluetooth: Add support for automatic switch between hsp and a2dp profiles
On Tuesday 09 August 2016 13:15:17 Tanu Kaskinen wrote: > On Tue, 2016-08-09 at 09:04 +0200, Pali Rohár wrote: > > On Tuesday 09 August 2016 01:12:21 Tanu Kaskinen wrote: > > > These profile names work only with BlueZ 4. With BlueZ 5 the > > > profile names are "headset_head_unit" and "a2dp_sink". Pali, > > > would you be willing to write a patch makes the code handle both > > > BlueZ versions? > > > > I can look at it and write patch. But I do not have bluez5 so > > somebody else would need to test it. > > I can test it if that seems necessary after reviewing the code. Ok. Do you have an idea how to detect if pulse card is bluez4 or bluez5? I need that detection in bluetooth policy module... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5] bluetooth: Add support for automatic switch between hsp and a2dp profiles
On Tuesday 09 August 2016 01:12:21 Tanu Kaskinen wrote:
> On Fri, 2016-07-22 at 16:20 +0530, Arun Raghavan wrote:
> > > From: Pali Rohár <pali.ro...@gmail.com>
>
> > +if (revert_to_a2dp) {
> > +from_profile = "hsp";
> > +to_profile = "a2dp";
> > +} else {
> > +from_profile = "a2dp";
> > +to_profile = "hsp";
> > +}
>
> These profile names work only with BlueZ 4. With BlueZ 5 the profile
> names are "headset_head_unit" and "a2dp_sink". Pali, would you be
> willing to write a patch makes the code handle both BlueZ versions?
I can look at it and write patch. But I do not have bluez5 so somebody
else would need to test it.
--
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] Fix the conflict between bluetooth-policy and card-restore
On Friday 05 August 2016 17:42:00 Tanu Kaskinen wrote: > Do you know how to pair and connect a headset using just command line > tools with BlueZ 4? bluetoothctl seems to be a newer addition, and my > bluetooth GUI expects BlueZ 5. For connecting I have written shell script, which use qdbus: BT="XX_XX_XX_XX_XX_XX" # replace with your BT address # first disconnect everything qdbus --system org.bluez `qdbus --system org.bluez | grep $BT | head -1 2>/dev/null` org.bluez.AudioSink.Disconnect 1>/dev/null 2>&1 qdbus --system org.bluez `qdbus --system org.bluez | grep $BT | head -1 2>/dev/null` org.bluez.Headset.Disconnect 1>/dev/null 2>&1 qdbus --system org.bluez `qdbus --system org.bluez | grep $BT | head -1 2>/dev/null` org.bluez.Audio.Disconnect 1>/dev/null 2>&1 # connect qdbus --system org.bluez `qdbus --system org.bluez | grep $BT | head -1 2>/dev/null` org.bluez.AudioSink.Connect qdbus --system org.bluez `qdbus --system org.bluez | grep $BT | head -1 2>/dev/null` org.bluez.Headset.Connect # set pulseaudio profile to a2dp pactl set-card-profile bluez_card.$BT a2dp For pairing is possible to use bluez-simple-agent (python script, needs only python dbus packages). Some info is on arch wiki: https://wiki.archlinux.org/index.php/Bluez4#Pairing_with_bluez4 I guess, just download and extract that script from bluez4 package. Should work out-of-box as it does not depend on any bluez/bluetooth packages... Note that you can have registered only one bluez agent, so maybe killing some gnome/kde/... SW will be needed. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] Fix the conflict between bluetooth-policy and card-restore
On Thursday 04 August 2016 20:02:59 Felipe Sateler wrote: > Out of curiosity, what distro is this? Ubuntu 12.04 LTS with KDE4. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] Fix the conflict between bluetooth-policy and card-restore
On Thursday 04 August 2016 19:35:57 Tanu Kaskinen wrote: > This may very well cause a regression for BlueZ 4, because I didn't > make the corresponding changes there. The code isn't identical with > BlueZ 5, and it would be a bit difficult for me to test with BlueZ 4. > What do others think - should I nevertheless try to install BlueZ 4 > and update the BlueZ 4 code too, or can we let the BlueZ 4 code just > rot? I have only Bluez 4, so please do not drop Bluez 4 code. If you to do testing code for Bluez 4 setup, I can do that. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] bluetooth: When doing autoswitch call pa_card_set_profile with save=true
On Thursday 04 August 2016 10:00:00 Felipe Sateler wrote: > On 4 August 2016 at 06:59, Tanu Kaskinen <ta...@iki.fi> wrote: > > it doesn't make sense for module-card-restore to switch to a profile > > when an alsa profile becomes available due to the user plugging > > something in. > > Why doesn't it makes sense? I think it makes a lot of sense. One of > the things I miss from KDE is its capability to restore streams back > to HDMI when the cable is plugged, or when a bluetooth speaker becomes > available. I think that such functionality should be handled by other module (not card-restore). And to do it correctly you need to specify sound cards and port names with priorities to that module. So it do switching based on priorities and some random order (e.g. last used). In KDE there is GUI for specifying priorities (stored in persistent storage), so it work as expected. And switching make sense only immediately after profile is available. Not randomly at any time (which conflict with this bluetooth policy module). -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] bluetooth: When doing autoswitch call pa_card_set_profile with save=true
On Thursday 04 August 2016 14:59:59 Tanu Kaskinen wrote: > On Thu, 2016-08-04 at 13:37 +0200, Pali Rohár wrote: > > On Thursday 04 August 2016 13:59:33 Tanu Kaskinen wrote: > > > > > > I'd guess it's profile_available_changed_callback(). > > > > Yes, that one. Will you prepare fix? > > Since the broken code is from me, I suppose it's only fair that I get > to fix it too. So yes. Great! When you have a fix let me know. I can test it with my bluetooth headset... -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] bluetooth: When doing autoswitch call pa_card_set_profile with save=true
On Thursday 04 August 2016 13:59:33 Tanu Kaskinen wrote: > I'd guess it's profile_available_changed_callback(). Yes, that one. Will you prepare fix? -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] bluetooth: When doing autoswitch call pa_card_set_profile with save=true
On Thursday 04 August 2016 09:29:58 Arun Raghavan wrote:
> On Tue, 2 Aug 2016, at 12:50 AM, Pali Rohár wrote:
> > When pa_card_set_profile is called with save=false then
> > module-card-restore
> > start fight with module-bluetooth-policy and every second is profile
> > changing between hsp and a2dp.
> >
> > So when pulseaudiu is changing profile in module-bluetooth-policy we need
> > to save it and tell module-card-restore to not try to restore old
> > profile.
> >
> > Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
> > ---
> > src/modules/bluetooth/module-bluetooth-policy.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/modules/bluetooth/module-bluetooth-policy.c
> > b/src/modules/bluetooth/module-bluetooth-policy.c
> > index 68c8ab4..74ae898 100644
> > --- a/src/modules/bluetooth/module-bluetooth-policy.c
> > +++ b/src/modules/bluetooth/module-bluetooth-policy.c
> > @@ -159,7 +159,7 @@ static void card_set_profile(struct userdata *u,
> > pa_card *card, const char *to_p
> >
> > pa_log_debug("Setting card '%s' to profile '%s'", card->name,
> > to_profile);
> >
> > -if (pa_card_set_profile(card, profile, false) != 0) {
> > +if (pa_card_set_profile(card, profile, true) != 0) {
> > pa_log_warn("Could not set profile '%s'", to_profile);
> > continue;
> > }
> > --
>
> This is not actually what we want to do. Automatic switching should not
> make module-card-restore save the desired profile.
What is wrong with it?
> The short workaround for this is to register the hook in
> module-bluetooth-policy with priority later than module-card-restore.
I think that this does not work. That restore module is watching for
available profiles and after some delay (1s?) it change profile.
What is needed is to tell that restore module should not touch profiles
set by bluetooth policy.
> That said, I'm not sure it's a good thing for hooks to be fighting to
> set the profile. I would rather have them select the profile and at the
> end of running hooks, if something provided a profile, we set it.
I think this will not work too, as later restore module again see that
a2dp is available and switch to them...
> Tanu, since you added the original code -- wdyt?
>
> -- Arun
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] bluetooth: When doing autoswitch call pa_card_set_profile with save=true
When pa_card_set_profile is called with save=false then module-card-restore
start fight with module-bluetooth-policy and every second is profile
changing between hsp and a2dp.
So when pulseaudiu is changing profile in module-bluetooth-policy we need
to save it and tell module-card-restore to not try to restore old profile.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
src/modules/bluetooth/module-bluetooth-policy.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/modules/bluetooth/module-bluetooth-policy.c
b/src/modules/bluetooth/module-bluetooth-policy.c
index 68c8ab4..74ae898 100644
--- a/src/modules/bluetooth/module-bluetooth-policy.c
+++ b/src/modules/bluetooth/module-bluetooth-policy.c
@@ -159,7 +159,7 @@ static void card_set_profile(struct userdata *u, pa_card
*card, const char *to_p
pa_log_debug("Setting card '%s' to profile '%s'", card->name,
to_profile);
-if (pa_card_set_profile(card, profile, false) != 0) {
+if (pa_card_set_profile(card, profile, true) != 0) {
pa_log_warn("Could not set profile '%s'", to_profile);
continue;
}
--
1.7.9.5
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5] bluetooth: Add support for automatic switch between hsp and a2dp profiles
On Thursday 28 July 2016 08:58:25 Arun Raghavan wrote: > On Fri, 22 Jul 2016, at 04:48 PM, Pali Rohár wrote: > > On Friday 22 July 2016 16:20:51 Arun Raghavan wrote: > > > (I had to fix up your patch due to recent changes in how card > > > profiles are selected by policy modules. Also, the > > > will_need_revert_card_map would probably not have worked in your > > > patch since you were using the pa_card_new_data to put() into > > > the map, but looking up based on the pa_card. This should be > > > fixed by the hook change. If you could take a look and test, > > > I'll push this out.) > > > > Hi! I tested my v4 version of patch with pulseaudio 5.0 which I > > have on my Ubuntu 12.04 desktop. And with pulseaudio 5.0 it is > > working fine, I'm using it daily... > > > > I can try to install pulseaudio from git into system to have a > > test, but I do not know if my Ubuntu box does not refuse such > > giant upgrade... > > I've pushed this out now. You can see how to build it for 12.04 in: > > > https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/.travis.yml? > id=3033fec287c40ba5d0c862b9c3642fbc2b9bf0b0 That is for Ubuntu 14.04, not 12.04... but I was able to built last git master branch (small problem with switching to gcc-4.8 for C++11 support) and install it... > I'd appreciate some more testing from folks who're using BT headsets > regularly. I'll do some here as well. So... I tested pulseaudio from last commit in master branch on Ubuntu 12.04 with KDE4 desktop. Without module-card-restore it is working perfectly, no problem. With active module-card-restore there there is one big problem, both modules module-bluetooth-policy and module-card-restore start to fight with changing profile between a2dp and hsp. module-bluetooth-policy wants hsp, but module-card-restore wants revert back to a2dp. Anyway, fix for this is simple. I tested it and expect git format patch on mailing list in few minutes... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5] bluetooth: Add support for automatic switch between hsp and a2dp profiles
On Friday 22 July 2016 16:20:51 Arun Raghavan wrote: > (I had to fix up your patch due to recent changes in how card profiles are > selected by policy modules. Also, the will_need_revert_card_map would probably > not have worked in your patch since you were using the pa_card_new_data to > put() into the map, but looking up based on the pa_card. This should be fixed > by the hook change. If you could take a look and test, I'll push this out.) Hi! I tested my v4 version of patch with pulseaudio 5.0 which I have on my Ubuntu 12.04 desktop. And with pulseaudio 5.0 it is working fine, I'm using it daily... I can try to install pulseaudio from git into system to have a test, but I do not know if my Ubuntu box does not refuse such giant upgrade... -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
