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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
