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
final
SetConfiguration AVDTP packet.
But which codec will bluez5 choose? Just highest codec number of
both SINK and SOURCE
device?
endpoint_select_configuration() seems to be related to handle the
response from the SINK
device.
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
module-bluez5-devices.c
4) Call codec encode function in thread_func()
Any comment is welcomed.
Thanks,
Qu
>
> -- Arun
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>