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. We would probably have to expose each endpoint so you could peek and choose what the codec to use. > 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 > -- Luiz Augusto von Dentz
