On Thu, 21 Jun 2018, at 4:32 PM, Pali Rohár wrote: > On Thursday 21 June 2018 05:45:39 Arun Raghavan wrote: > > On Wed, 20 Jun 2018, at 9:05 PM, Jan Alexander Steffens wrote: > > > On Mon, Jun 18, 2018, 09:42 Pali Rohár <[email protected]> wrote: > > > > > > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > > > > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > > > > > Hi! As you may know lot of bluetooth headsets support not only SBC, > > > > > > but > > > > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > > > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > > > > > ffmpeg has clean-room implementation based on expired patent. What > > > > about > > > > > > adding support for aptX via ffmpeg into pulseaudio? > > > > > > > > > > > > -- > > > > > > > > > > I'd actually like to delete the SBC code and replace it with a generic > > > > GStreamer bin. That would allow us to be codec agnostic, and support > > > > any of > > > > the codecs that are supported by GStreamer (which includes those that > > > > ffmpeg provides). > > > > > > > > This does not sound like a good idea. The only two relevant bluetooth > > > > codecs for most people are SBC and aptX. > > > > > > > > > > Don't forget AAC. I've seen this one a lot in devices meant for use with > > > iPhones, which apparently don't have aptX. GStreamer has a lot of encoders > > > for it so this shouldn't be a problem unless it's some strange AAC > > > variant. > > > > > > There's also LDAC but I haven't seen it on a device yet. > > > > Right, there are multiple codecs that we can support, and we should not tie > > ourselves to a specific implementation. For this reason, and more > > generally, I'd like to have PulseAudio not have to deal with any codec > > implementations at all (nor even RTP, if we can help it), hence my > > preference to use something generic in the form of GStreamer. > > This is a good idea to let external service to do codec-specific > functions... I agree that it simplify pulseaudio code and other things > (like proving new codec by external library -- if properly implemented), > but in bluetooth context we should look at questions: > > 1) Has gstreamer support for SBC codec? > > 2) Has gstreamer support for aptX codec? > > These are two major codecs supported by bluetooth headsets. > > Answer is: NO > (SBC is now provided in the "bad" set which is not pre-installed by > gstreamer)
Pre-installed doesn't mean much tbh. It is easy enough for packages to depend on it. > So gstreamer in current state is not very useful for pulseaudio. Writing a plugin around an existing decoder is pretty trivial. As is exposing libav/ffmpeg codecs. > Important are also MPEG1/2 (which are defined as optional by A2DP) > and also AAC and LDAC which Jan wrote. But gstreamer has again only > plugins in "bad" and "ugly" sets for them; nothing preinstalled by > default. Again, -bad doesn't mean much in the current day (historically it was a staging ground). -ugly is for codecs that are known to be patent-encumbered (and how that's made available is up to packagers). > 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). -- Arun _______________________________________________ pulseaudio-discuss mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
