[pulseaudio-discuss] Bluetooth aptX codec

[Pali Rohár]

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?

[Arun Raghavan]

Post by Pali Rohár
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).

Cheers,
Arun

[Pali Rohár]

Post by Arun Raghavan

Post by Pali Rohár
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.

[Luiz Augusto von Dentz]

Hi Pali,

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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.

Post by Pali Rohár
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.

Post by Pali Rohár
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.

Post by Pali Rohár
--
Pali Rohár
_______________________________________________
pulseaudio-discuss mailing list
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[Pali Rohár]

Post by Luiz Augusto von Dentz
Hi Pali,

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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.

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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)

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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.

Post by Luiz Augusto von Dentz

Post by Pali Rohár
--
Pali Rohár
_______________________________________________
pulseaudio-discuss mailing list
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[Jan Alexander Steffens]

Post by Arun Raghavan

Post by Arun Raghavan

Post by Pali Rohár
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

Post by Arun Raghavan

Post by Pali Rohár
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.

[Arun Raghavan]

Post by Jan Alexander Steffens

Post by Arun Raghavan

Post by Arun Raghavan

Post by Pali Rohár
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

Post by Arun Raghavan

Post by Pali Rohár
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.

Cheers,
Arun

[Pali Rohár]

Post by Arun Raghavan

Post by Jan Alexander Steffens

Post by Arun Raghavan

Post by Arun Raghavan

Post by Pali Rohár
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

Post by Arun Raghavan

Post by Pali Rohár
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)

[Arun Raghavan]

Post by Pali Rohár

Post by Arun Raghavan

Post by Jan Alexander Steffens

Post by Arun Raghavan

Post by Arun Raghavan

Post by Pali Rohár
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

Post by Arun Raghavan

Post by Pali Rohár
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),
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.

Post by Pali Rohár
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.

Post by Pali Rohár
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).

Post by Pali Rohár
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

[Pali Rohár]

Post by Arun Raghavan

Post by Pali Rohár
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),
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?

Post by Arun Raghavan

Post by Pali Rohár
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.

Post by Pali Rohár
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?

Post by Arun Raghavan

Post by Pali Rohár
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.

[Alexander E. Patrakov]

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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),
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?

Post by Arun Raghavan

Post by Pali Rohár
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.

Post by Pali Rohár
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 ;)

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). If it
doesn't exist, create it and use it.

I fully understand the following technical difficulties:

1. It is unwise to use ffmpeg because it can be compiled improperly
and is difficult to replace in this case.
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.

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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]

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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),
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?

Post by Arun Raghavan

Post by Pali Rohár
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.

Post by Pali Rohár
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.

Post by Alexander E. Patrakov
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). If it
doesn't exist, create it and use it.
1. It is unwise to use ffmpeg because it can be compiled improperly
and is difficult to replace in this case.

Yes, this is the main problem which I'm pointing. Also I do not know if
ffmpeg has support for (mandatory) SBC codec...

Now you can either: 1) compile pulseaudio with bluetooth support and
bluetooth will work always (because it links to system sbc codec
library) or 2) compile pulseaudio without bluetooth support (and it
would not work). And for 1) dynamic linking ensure that needed codec
(sbc) is present/installed as primary dependency.

Post by Alexander E. Patrakov
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).

In previous email I wrote about idea to move that codec stuff into bluez
itself as bluez code already handles it for android.

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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.

[Luiz Augusto von Dentz]

Hi Pali,

Post by Pali Rohár

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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),
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?

Post by Arun Raghavan

Post by Pali Rohár
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.

Post by Pali Rohár
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.

Post by Alexander E. Patrakov
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). If it
doesn't exist, create it and use it.
1. It is unwise to use ffmpeg because it can be compiled improperly
and is difficult to replace in this case.

Yes, this is the main problem which I'm pointing. Also I do not know if
ffmpeg has support for (mandatory) SBC codec...
Now you can either: 1) compile pulseaudio with bluetooth support and
bluetooth will work always (because it links to system sbc codec
library) or 2) compile pulseaudio without bluetooth support (and it
would not work). And for 1) dynamic linking ensure that needed codec
(sbc) is present/installed as primary dependency.

Post by Alexander E. Patrakov
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).
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.

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.

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,

Post by Pali Rohár

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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]

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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.

Post by Luiz Augusto von Dentz
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?

Post by Luiz Augusto von Dentz
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.

[Luiz Augusto von Dentz]

Hi Pali,

Post by Pali Rohár

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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.

Post by Luiz Augusto von Dentz
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.

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.

Post by Pali Rohár
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. We would probably have to expose each endpoint so you could
peek and choose what the codec to use.

Post by Pali Rohár
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.

Post by Pali Rohár

Post by Luiz Augusto von Dentz
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
_______________________________________________
pulseaudio-discuss mailing list
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[Pali Rohár]

Post by Luiz Augusto von Dentz
Hi Pali,

Post by Pali Rohár

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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.

Post by Luiz Augusto von Dentz
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.

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.

Post by Pali Rohár
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).

Post by Luiz Augusto von Dentz
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.

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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.

Post by Pali Rohár

Post by Luiz Augusto von Dentz
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
_______________________________________________
pulseaudio-discuss mailing list
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[Pali Rohár]

Post by Pali Rohár

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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).

Post by Luiz Augusto von Dentz
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.

[Luiz Augusto von Dentz]

Hi Pali,

Post by Pali Rohár

Post by Pali Rohár

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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).

Post by Luiz Augusto von Dentz
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.

[Pali Rohár]

Post by Luiz Augusto von Dentz
Hi Pali,

Post by Pali Rohár

Post by Pali Rohár

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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).

Post by Luiz Augusto von Dentz
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]

Post by Luiz Augusto von Dentz
Hi Pali,

Post by Pali Rohár

Post by Pali Rohár

Post by Luiz Augusto von Dentz

Post by Pali Rohár
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).

Post by Luiz Augusto von Dentz
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.

[Arun Raghavan]

Post by Pali Rohár

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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),
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?

Does not need to, that can be taken care of at packaging time, and potentially at module load.

Post by Pali Rohár

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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.

Post by Pali Rohár
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.

This is a package problem, and can be addressed with either load-time arguments for what is supported, or by probing.

[...]

Post by Pali Rohár

Post by Alexander E. Patrakov
1. It is unwise to use ffmpeg because it can be compiled improperly
and is difficult to replace in this case.

Yes, this is the main problem which I'm pointing. Also I do not know if
ffmpeg has support for (mandatory) SBC codec...
Now you can either: 1) compile pulseaudio with bluetooth support and
bluetooth will work always (because it links to system sbc codec
library) or 2) compile pulseaudio without bluetooth support (and it
would not work). And for 1) dynamic linking ensure that needed codec
(sbc) is present/installed as primary dependency.

Post by Alexander E. Patrakov
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).

Post by Pali Rohár
In previous email I wrote about idea to move that codec stuff into bluez
itself as bluez code already handles it for android.

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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 already, which was the basis for my original suggestion on how this should be done.

-- Arun

[Pali Rohár]

Post by Arun Raghavan

Post by Pali Rohár

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan
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?

Post by Arun Raghavan

Post by Pali Rohár

Post by Alexander E. Patrakov
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.

Post by Arun Raghavan

Post by Pali Rohár
In previous email I wrote about idea to move that codec stuff into bluez
itself as bluez code already handles it for android.

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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.

[Arun Raghavan]

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan
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.

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár

Post by Alexander E. Patrakov
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.

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
In previous email I wrote about idea to move that codec stuff into bluez
itself as bluez code already handles it for android.

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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.

-- Arun

[Pali Rohár]

Post by Arun Raghavan

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan
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.

Post by Arun Raghavan

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár

Post by Alexander E. Patrakov
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.

Post by Arun Raghavan

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
In previous email I wrote about idea to move that codec stuff into bluez
itself as bluez code already handles it for android.

Post by Alexander E. Patrakov

Post by Pali Rohár

Post by Arun Raghavan

Post by Pali Rohár
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.

[Arun Raghavan]

On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote:
[...]

Post by Pali Rohár
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.

-- Arun

[Pali Rohár]

Post by Arun Raghavan
[...]

Post by Pali Rohár
I looked and there is absolutely nothing about A2DP codec parameter
selections. So really does not help.

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.

[Arun Raghavan]

Post by Pali Rohár

Post by Arun Raghavan
[...]

Post by Pali Rohár
I looked and there is absolutely nothing about A2DP codec parameter
selections. So really does not help.

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.

Will do. Note that I'm not just talk about modularity w.r.t. codecs, but also codec implementations.

Post by Pali Rohár
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.

That's still not problematic from a GStreamer perspective. It is possible to set up parameters via caps if needed after the negotiation stage. And wrapping your library in a GStreamer plugin would be a trivial effort.

-- Arun

[Pali Rohár]

Post by Jan Alexander Steffens

Post by Arun Raghavan

Post by Arun Raghavan

Post by Pali Rohár
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

Post by Arun Raghavan

Post by Pali Rohár
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.

[ValdikSS]

Post by Pali Rohár
I did some investigation and basically this is the list of all known
0x00 - SBC
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC
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".

[Pali Rohár]

Post by ValdikSS

Post by Pali Rohár
I did some investigation and basically this is the list of all known
0x00 - SBC
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC
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/
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.

[ValdikSS]

Post by Pali Rohár

Post by ValdikSS

Post by Pali Rohár
I did some investigation and basically this is the list of all known
0x00 - SBC
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC
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/
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.

"0xFF 0x0075 0x0102" is a Samsung HD codec. Scalable codec and UHQ-BT are two another codecs from Samsung. You can choose between Samsung HD and Scalable Codec A2DP codecs on Samsung Android devices.
Loading Image...

Bose headset where unknown CSR codecs have been found has no license for aptX. It supports only SBC, AAC and these two unknown codecs.

Scalable codec should be supported in Samsung U Flex and Samsung Gear IconX 2018. UHQ-BT could be found in Samsung LEVEL on pro.
I'll try to make a dump of Samsung U Flex or Samsung Gear IconX 2018, but Samsung LEVEL on pro are rather rare nowadays.

[ValdikSS]

Post by ValdikSS

Post by Pali Rohár

Post by ValdikSS

Post by Pali Rohár
I did some investigation and basically this is the list of all known
0x00 - SBC
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC
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/
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.

"0xFF 0x0075 0x0102" is a Samsung HD codec. Scalable codec and UHQ-BT are two another codecs from Samsung. You can choose between Samsung HD and Scalable Codec A2DP codecs on Samsung Android devices.
https://img.gadgethacks.com/img/32/08/63656409124633/0/improve-bluetooth-audio-your-galaxy-s9-with-custom-codecs.w1456.jpg
Bose headset where unknown CSR codecs have been found has no license for aptX. It supports only SBC, AAC and these two unknown codecs.
Scalable codec should be supported in Samsung U Flex and Samsung Gear IconX 2018. UHQ-BT could be found in Samsung LEVEL on pro.
I'll try to make a dump of Samsung U Flex or Samsung Gear IconX 2018, but Samsung LEVEL on pro are rather rare nowadays.

0xFF 0x0075 0x0103 — Samsung Scalable Codec
Raw value: 7a

Connection established (SetConfiguration) with raw value 28.
Dumped from Samsung Galaxy S7 edge - Samsung U Flex

[ValdikSS]

Post by ValdikSS

Post by Pali Rohár

Post by ValdikSS

Post by Pali Rohár
I did some investigation and basically this is the list of all known
0x00 - SBC
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC
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/
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.

"0xFF 0x0075 0x0102" is a Samsung HD codec. Scalable codec and UHQ-BT are two another codecs from Samsung. You can choose between Samsung HD and Scalable Codec A2DP codecs on Samsung Android devices.
https://img.gadgethacks.com/img/32/08/63656409124633/0/improve-bluetooth-audio-your-galaxy-s9-with-custom-codecs.w1456.jpg
Bose headset where unknown CSR codecs have been found has no license for aptX. It supports only SBC, AAC and these two unknown codecs.
Scalable codec should be supported in Samsung U Flex and Samsung Gear IconX 2018. UHQ-BT could be found in Samsung LEVEL on pro.
I'll try to make a dump of Samsung U Flex or Samsung Gear IconX 2018, but Samsung LEVEL on pro are rather rare nowadays.

0xFF 0x0075 0x0103 — Samsung Scalable Codec
Raw value: 7a
Connection established (SetConfiguration) with raw value 28.
Dumped from Samsung Galaxy S7 edge - Samsung U Flex

0xFF 0x053A 0x484C — Savitech LHDC

https://www.hwa-lhdc.org/how-it-works

[ValdikSS]

Post by ValdikSS

Post by Pali Rohár
I did some investigation and basically this is the list of all known
0x00 - SBC
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC
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/
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".

0xFF 0x000A 0x0106 — Unknown codec found on LEVN SK-BTI-031 bluetooth receiver
Value hex dump: 07 09 00 ff 4f 00 00 00 01 00 32

This receiver also supports unknown codecs 0x0103 and 0x0104 with the same values as shown in previous message.

[ValdikSS]

Post by Pali Rohár
I did some investigation and basically this is the list of all known
0x00 - SBC
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC
0xFF 0x004F 0x01 - aptX
0xFF 0x000A 0x01 - FastStream
0xFF 0x000A 0x02 - aptX Low Latency

aptX Low Latency is also 0xFF 0x00D7 0x02.

Post by Pali Rohár
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.