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...). 2) How should codec switching from pulseaudio API and pactl/pavucontrol looks like? 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? > 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 -------------- 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/20180708/dd00a354/attachment.sig>
