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.
-- Arun
