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>
