[pulseaudio-discuss] Bluetooth aptX codec
pali.rohar at gmail.com
Mon Jul 9 15:56:16 UTC 2018
On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote:
> Hi Pali,
> On Sun, Jul 8, 2018 at 11:47 PM, Pali Rohár <pali.rohar at gmail.com> wrote:
> > On Sunday 08 July 2018 22:51:38 Luiz Augusto von Dentz wrote:
> >> > In previous email I wrote about idea to move that codec stuff into bluez
> >> > itself as bluez code already handles it for android.
> >> We are not going to do a pulseaudio module in BlueZ, if it is even
> >> possible to have off the tree modules, in android we did that because
> >> it is the only option we had and Im quite sure it probably needs
> >> updating since code must have change since then... Any architecture
> >> that would involve copying data over would be bad for latency, though
> >> android does that, and Im pretty sure doing encoding/decoding on
> >> daemon would be rejected as well.
> > Ok.
> > But why is there already code for encoding/decoding directly in bluez
> > (even it is for android) and not in some separate library/project?
> > Then both android and pulseaudio can benefit from it. As basically now
> > pulseaudio needs to implement exactly same code and logic which is
> > already in bluez project, which is doing that audio encoding.
> >> The D-Bus interface already accounts to the parameter negotiation,
> >> obviously frameworks such as ffmeg or gstreamer would not do it for
> >> use but the module could take up the action to register the endpoint
> >> and respond to the method calls when necessary. Anyway, lets start
> >> with modularization of the endpoints/codecs, that way we can add
> >> native codec support or gstreamer/ffmpeg and each platform decides
> >> with what they want to go.
> > Ok. Prior I start splitting codec related code, I need to know:
> > 1) Cannot we reuse above bluez code for codec encoding which is already
> > used for android? If it needs some refactoring (like stop doing data
> > copying etc...).
> android does not use PulseAudio, what we have there is a plugin for
> the android audio server.
> > 2) How should codec switching from pulseaudio API and pactl/pavucontrol
> > looks like?
> Usually we don't force reconfiguration but perhaps we should, note
> though that we may end up with audio glitches since we have to
> disconnect A2DP stream to be able to reconfigure it with another
Glitches are already there if you switch from A2DP profile to HSP in
pavucontrol. So I do not see any problem if glitches happen also when
switching between A2DP (SBC) and A2DP (aptX).
> We would probably have to expose each endpoint so you could
> peek and choose what the codec to use.
Yes. I think this is required when pulseaudio is going to support more
then one codec.
> > 3) How to handle possible pass-through? E.g. I have already encoded
> > music in aptX format (or MP3 or AAC) and want to send it directly
> > without double decoding-encoding process. And how to handle MP3 input
> > when device supports both aptX and MP3, but currently is activated aptX?
> Afaik that usually requires the application to know that underline
> codec so PA needs to expose these details so it can avoid decoding and
> send it. Switching depending on the content will not work well so
> perhaps the only bet is if the device support multiplexing, which is
> something we don't support in BlueZ, otherwise it is better to use
> either aptX or SBC since those are simpler than going with AAC and MP3
> and possible encode any other audio.
> >> Btw, I guess you were on irc looking for how we prioritize the
> >> matching of endpoints, this is done in the order of endpoint
> >> registration,
> > Yes, but I have not got any answer so I sent incomplete/wIP patch to
> > this mailing list.
> > --
> > Pali Rohár
> > pali.rohar at gmail.com
> > _______________________________________________
> > pulseaudio-discuss mailing list
> > pulseaudio-discuss at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: not available
More information about the pulseaudio-discuss