Bluetooth aptX codec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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 Rohár
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20180709/9e36ccfb/attachment.sig>


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux