On Sat, 28 Jul 2018, at 9:01 PM, Pali Rohár wrote: > On Monday 23 July 2018 18:42:52 Arun Raghavan wrote: > > On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote: > > > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: > > > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár <pali.ro...@gmail.com>: > > > > > > > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages > > > > > > to depend on it. > > > > > > > > > > Can pulseaudio build process enforce it? > > > > Does not need to, that can be taken care of at packaging time, and > > potentially at module load. > > Ok, I would ask differently: Can pulseaudio at packaging time enforce it?
That depends on the packaging system, but broadly the answer is yes. > > > > 2. GStreamer can, in theory, wrap the needed libraries, and does > > > > support third-party plugins, but does not properly encapsulate the > > > > "give me packets ready to send via bluez" part. > > > > > > And until this is supported by external library (ffmpeg, gstreamer, > > > whatever), pulseaudio needs to implement it itself. > > > > > > And encapsulating encoded data for bluez is not enough. It is needed > > > also to negotiate codec selection with bluez and codec parameters (which > > > are codec specific). > > > > GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be > > used (and again, less codec-specific stuff that needs to be in PA). > > But it does not solve above problem when it is needed to do A2DP codec > selection and negotiation. I don't get what you mean here. > > > In previous email I wrote about idea to move that codec stuff into bluez > > > itself as bluez code already handles it for android. > > > > > > > > > > > > > > > To have working bluetooth support in pulseadio, pulseaudio needs > > > > > > > to use > > > > > > > external library for encoding which *always* provides support for > > > > > > > SBC. > > > > > > > And not only if user manually installs some special plugin for > > > > > > > 3rd party > > > > > > > library. (And not only SBC, but also those other aptX, MPEG1/2, > > > > > > > AAC and > > > > > > > LDAC codecs) > > > > > > > > > > > > So I continue to disagree. Using a generic framework and letting > > > > > > other parts of the system select the codec implementation is what > > > > > > makes sense for the widest set of use-cases (this also allows > > > > > > products to ship their own implementations of a codec without > > > > > > changing the PulseAudio code). > > > > > > > > > > Still this is not enough for bluetooth codec. For specific codec you > > > > > need to create bluez dbus endpoint with codec specific parameters. > > > > > Plus > > > > > implement select and set methods to decide on codec parameters between > > > > > pulseaudio and bluetooth headset. And finally to send encoded data you > > > > > need to know how to send them. To which endpoint, how header looks > > > > > like > > > > > etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must > > > > > not > > > > > have RTP (e.g. aptX). And after that comes data from codec encoder > > > > > function. > > > > > > > > > > So is there any library which all above support? I have not find > > > > > anything. Nor ffmpeg nor gstreamer. > > > > > > > > > > Which means that pulseaudio cannot delegate codec selection, codec > > > > > initialization and codec encoding to some external library (yet). > > > > At least for SBC and presumably AAC, this is all possible with GStreamer > > No, it is not possible -- or at least I have not found any way how. I > spend more time with it and Gstreamer does not support it. If you still > think that it is possible, post a gstreamer code or link how to do that. Look at the rtpsbcpay/rtpsbcdepay elements, for example. -- Arun _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
