On 22/07/18 10:31, Pali Rohár wrote:
On Sunday 22 July 2018 10:14:21 Georgi Boiko wrote:
Hi Pali,
Does it have to be codec switching?
Without codec switching it is not possible to "force" specific codec.
And when bluetooth headset initiate connection, then headset choose
codec. My testing shown me that my bluetooth headset chooses codec
"randomly" when pulseaudio declares that support both SBC and aptX.
And no, it is not a good idea to have "random" codec selection without
possibility to switch it.
So the only possible solution for now for enforcing aptX codec is to
disable SBC codec registration to bluez. And codec registration is
global for all headset and is done when initializing pulseaudio
bluetooth module.
Have you tried debugging that with hcidump? It sounds like a codec
negotiation issue with a particular set of equipment.
A simpler to implement alternative to codec switching via GUI could be
to add a config option to enable/disable codecs when the Bluetooth
module starts and negotiate using only enabled codecs. That would
provide reasonable defaults with an option for power users such as
yourself to force a specific codec according to their needs. This would
also cut off a large chunk off the scoped changes, as no GUI-related
code would have to be changed.
If there was to be an implementation
that settles on the best quality codec available that is supported by both
sides of communication
This is possible to implement, but only in the case that
pulseaudio/bluez initiate connection to bletooth headset.
For my tested headset, this is possible only when putting headset into
bluetooth "pairing" mode. Very unpractical. In normal case, that headset
is what initialize connection.
The 3 market leading Bluetooth headsets (Apple, Sony, Bose) all make the
first connection through pairing mode. If you meant recurring
connections, is there a way for PA to memorize which codec was used
during the initial session and only supply that option later? As a user,
that is what I would expect for recurring connections.
it would already be over and beyond what currently
exists. The order is obvious as of today:
For me it is not such obvious as you specified.
LDAC
AptX HD
AptX
AAC
In case I have music already in MPEG/AAC then this codec should have the
higher priority as music could be passed as-is without decoding and
reencoding. In this case it is the best possible quality. Same would be
for MPEG/MP3 codec.
Technically there are also other codecs supported by bluetooth headset,
see my research:
https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030199.html
I have no clue right now where to put aptX Low Latency and FastStream
codecs. Plus both codecs are somehow special that misuse A2DP protocol
and optionally supports backchannel for microphone voice. So you can use
them instead of HFP for voice calls. I have there a headset with
FastStream codec and IIRC it is just some variant of SBC, so I would try
to play with it.
And I'm still in doubt if MPEG/AAC does not provide better quality as
aptX.
As long as the end result is consistent with other major platforms, you
don't have to make that call. It looks like Android, for example,
decided not to bother with the fine detail and with the low latency
codecs, probably for the same reasons that you stated:
https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/res/values/config.xml#84
+ http://androidxref.com/8.0.0_r4/xref/system/bt/stack/a2dp/
I understand the desire to do it properly and to support everything with
account for the fine detail, but that overcomplicates the immediate
problem at hand: falling behind other platforms and being stuck with
SBC. Adding logic to account for re-encoding can be left for future
enhancements. It would also have a lower entry barrier on skills in C to
implement than a full Bluetooth module revamp needed to get the initial
support in.
Given that all additional codecs are niche, I would drop them from the
scope of the first milestone too.
For ATRAC, I would follow the guidance here if I had to add it:
http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
For codecs focusing on latency over sound quality, if I absolutely had
to support them, I would put AptX LL between AptX and AAC. FastStream
seems to be even more niche and focused purely on voice over HiFi audio
on just a handful of Creative headsets that don't seem to support any
other codecs. I would put it between SBC and AAC. If someone prefers SBC
over it, they know enough about Bluetooth operation to qualify as a
power user capable of using the config file to disable FastStream.
SBC
BlueZ already follows this logic, it is just that PA does not register any
capabilities other than SBC.
Allowing forced codec selection through the GUI is nice to have, but given
the complexity of implementing it, may not be worth the hassle for the
initial milestone.
On 22/07/18 09:51, Pali Rohár wrote:
Hi!
On Sunday 22 July 2018 00:10:47 Georgi Boiko wrote:
Hi,
Does anybody know what happened after this discussion? Is this long overdue
upgrade on the roadmap?
https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-July/028398.html
See this thread:
https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030198.html
Basically there is a patch for aptX support, but that one just replace
SBC by aptX. So need to decide which codec to support at compile time.
This is current limitation of bluez - linux bluetooth daemon - which
does not support codec switching.
See also this thread:
https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030253.html
So until bluez is extended to support switching and configuring A2DP
codec, there would not be support for any other codec then SBC.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
