Re: [pulseaudio-discuss] inserting filter module into PA-ofono-bluez system
On Thu, 5 Jul 2018, at 12:39 PM, d...@rivaretica.com wrote: > We have a relatively stable working setup behaving like a Bluetooth > headset (PA 11.1 + ofono 1.21 + bluez). > > When we try to insert a filter module (for example the original > module-virtual-sink.c) by simply loading the module, after few seconds > the module changes from "state: RUNNING" to "state: CORKED". Server log > output at level 4 is not saying much. The effect on the audio stream > during the few seconds of working varies from nothing (if using the > original module-virtual-sink.c) to clicking noise (if copy from src to > dst is omitted.) > > Is there anything special with this setup that prevents sample virtual > sink module from stable running ? The default configuration that PulseAudio ships with loads module-suspend-on-idle which suspends all sinks if there is no stream connected (not counting filter sink connections). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Thu, 21 Jun 2018, at 4:32 PM, Pali Rohár wrote: > 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) Pre-installed doesn't mean much tbh. It is easy enough for packages to depend on 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). > 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). -- Arun ___ 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 Wed, 2018-07-04 at 11:46 +0300, Tanu Kaskinen wrote: > On Mon, 2018-07-02 at 17:58 +0100, jnq...@gmail.com wrote: > > On Fri, 2018-06-29 at 16:06 +0300, Tanu Kaskinen wrote: > > > On Thu, 2018-06-28 at 04:08 +0100, jnq...@gmail.com wrote: > > > > It's possible for patches #21, #23 and #24 to be bumped down > > > > before > > > > the > > > > API change of #20, but as things are they are blocked by it and > > > > it > > > > would require a temporary hack... #23 and #24 (utils) depend > > > > upon > > > > pa_signal_init(), done in #21 which involves changing the > > > > underlying > > > > static; this depends upon changing pa_signal_destroy_cb_t > > > > (#20), > > > > because of the way pa_signal_free() works (passing that static > > > > api > > > > ref > > > > to the destroy callback which requires non-const). Getting > > > > around > > > > this > > > > would require injecting a temporary hack into pa_signal_free() > > > > giving > > > > alternate means of obtaining a non-const api pointer - i.e. api > > > > function pointer comparison would be necessary to tell us which > > > > mainloop is in use, to then get what we need using the correct > > > > *_get_api() with api->userdata. > > > > > > We can't change the signatures of publicly declared callback > > > types. > > > That will cause incompatibilities (compiler warnings at least, > > > which > > > is > > > bad enough) in applications. > > > > Sure > > > > > Therefore the only patch that I could > > > apply is the first one. > > > > But the types aren't changed until #19/26 ... > > Patch 4 changes the callback signatures. Right, but only in the mainloop api vtable, which user's only read values from, so I wasn't expecting that to be an issue. I've tested with gcc with `-Wall`, hacking the change into my locally installed headers and recompiling a test program which utilises `time_new`. No warnings resulted. ___ 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
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:
Only A2DP sink can use aptX codec. A2DP source is still restricted to SBC
codec.
Only standard aptX codec is supported for now. Support for other variants
like aptX HD, aptX Low Latency, FastStream may come up later.
FastStream and aptX Low Latency A2DP codecs are interested because they are
bi-directional (voice recording support). For now user needs to switch between
A2DP and HSP if he want voice recording or music playback. IIRC FastStream
codec is just rebranded SBC codec with fixed parameters. File a2dp-codecs.h
is now prepared for all of them.
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 :-(
So for now, when support for aptX codec is enabled at compile time, SBC
endpoint is not registered and therefore bluez daemon always choose only
registered aptX endpoint.
This needs to be investigated and properly implemented. Reason why this
patch is marked just as WIP. See TODO: and FIXME: comments in source code.
---
configure.ac | 19 ++
src/Makefile.am | 4 +
src/modules/bluetooth/a2dp-codecs.h | 121 +++-
src/modules/bluetooth/bluez5-util.c | 448 ++-
src/modules/bluetooth/bluez5-util.h | 8 +-
src/modules/bluetooth/module-bluez5-device.c | 319 ++-
6 files changed, 697 insertions(+), 222 deletions(-)
diff --git a/configure.ac b/configure.ac
index 8890aa15f..9077edb8e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1103,6 +1103,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],
@@ -1588,6 +1605,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)
@@ -1646,6 +1664,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 f62e7d5c4..9d6a1b03a 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -2141,6 +2141,10 @@ 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
+if HAVE_OPENAPTX
+module_bluez5_device_la_LIBADD += -lopenaptx
+endif
+
# Apple Airtunes/RAOP
module_raop_sink_la_SOURCES =
Re: [pulseaudio-discuss] bluetooth: HFP | WBS | pollfd->revent POLLOUT not hit
Hi Luiz, Yes, I am doing the polling. I an not changing that part of the code. In which it is default in which NBS also uses. Thanks, Sathish N On Wed, Jul 4, 2018 at 9:29 PM, Luiz Augusto von Dentz wrote: > Hi Sathish, > > On Mon, Jul 2, 2018 at 4:25 PM, Sathish Narasimman > wrote: > > Hi, > > > > I am trying to make WBS with PulseAudio. I am almost successful in > > establishing the connection and making a WBS traffic. > > > > But out of 10 attempts or sometimes the TX packets are not sent due to > > POLLOUT is not reflected in the pollfd > > /* Test if the stream is writable */ > > if (pollfd->revents & POLLOUT) > > writable = true; > > Are you sure you are polling with POLLOUT? > > > I would like to know what causes the stream as not writable. > > What are the connecting modules to resolve this? > > This happening only with WBS as NBS works good without any problem. > > > > > > Thanks, > > Sathish N > > > > ___ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > > > -- > Luiz Augusto von Dentz > ___ > 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
