[pulseaudio-discuss] About extra A2DP codecs support in bluetooth module

Qu Wenruo quwenruo.btrfs at gmx.com
Fri Jul 14 01:20:12 UTC 2017

On 2017年07月12日 17:57, Arun Raghavan wrote:
> On Fri, 7 Jul 2017, at 08:35 PM, Tanu Kaskinen wrote:
>> On Fri, 2017-07-07 at 20:33 +0800, Qu Wenruo wrote:
>>> After a quick glance into the code (without much knowledge about
>>> pulseaudio), I found that pulseaudio is just using sbc library to do the
>>> encode.
>>>   From a2dp_process_render():
>>> ---
>>>       while (PA_LIKELY(to_encode > 0 && to_write > 0)) {
>>>           ssize_t written;
>>>           ssize_t encoded;
>>>           encoded = sbc_encode(&sbc_info->sbc,
>>>                                p, to_encode,
>>>                                d, to_write,
>>>                                &written);
>>> ---
>>> So there is really nothing blocking us to implement other codec.
>>> For AAC codec, just (well, without tons of preparation and setup) call
>>> faacEncEncode() will be the core part.
>>> Copyright sh*t will only restrict the related library, not the PA module.
>>> (So if we could create a aptX codec library, then it will be possible to
>>> support)
>>> While the really hard part would be the preparation part, including
>>> creating a structure for faac encoder to contain a faacEncHandle and
>>> other needed info from sample rate to profile, just like sbc_info_t.
>>> Although I have a basic idea of what to do, I'm still figuring out how
>>> to handle all the details.
>>> Like how to create an endpoint for AAC codec (codec 0 is registered at
>>> register_endpoint, but shouldn't it be A2DP_CODEC_SBC instead of
>>> intermediate number 0?)
>> I don't know bluetooth details enough to answer. I'll add Luiz to Cc in
>> case he knows. You could try asking on the bluez mailing list too.
> I would suggest just hiding away the entire RTP payloading and encoding
> using GStreamer here. That neatly sidesteps the issue of
> hardware/software codecs, IP-sensitive codec libraries, and so forth. We
> probably want to keep the SBC path available the way it is right now to
> avoid GStreamer as a hard-dep, but otherwise, I think that's the more
> sensible approach to this.

I'm still fighting against dbus and bluez5 things, so GStreamer is not 
my primary goal.
But the idea to let a framework to handle everything indeed looks neat 
and clean.

However I'm more concerned about how the final A2DP profile is determined.

 From what I can see, pulseaudio bluetooth modules just register 
endpoint for bluez, with Codec, UUID and codec specified capabilities.
However I didn't see how codec selection is done.

Is it done by bluez5 or pulseaudio?

My currect understanding to implement a new codec will need:
1) Register a new codec in register_endpoint() of bluez5-util.c of PA.
    Instead of codec 0 (shouldn't it be A2DP_CODEC_SBC?), we must also 
register codec
    A2DP_CODEC_MPEG24 with a2dp_aac_t as capability.

   Well, updated a2dp-codec.h header will be needed, as there is no 
a2dp_aac_t in PA.

2) Handle codec capabilities negotiation
    endpoint_set_configuration() seems to be responsible to send out the 
    SetConfiguration AVDTP packet.
    But which codec will bluez5 choose? Just highest codec number of 
both SINK and SOURCE

    endpoint_select_configuration() seems to be related to handle the 
response from the SINK

    But for multi-codec support, how do we distinguish one codec 
capability from another?

3) Record final codec profile into some structure of userdata in 

4) Call codec encode function in thread_func()

Any comment is welcomed.


> -- Arun
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

More information about the pulseaudio-discuss mailing list