[pulseaudio-discuss] Can pulsaudio client API become a crossplatform standard ?

[Tanu Kaskinen]

On Thu, 2017-04-20 at 19:45 +0200, Enrico Weigelt, metux IT consult
wrote:
> On 17.04.2017 19:40, Tanu Kaskinen wrote:
> 
> > As you're planning to create yet another cross-platform audio
> > abstraction API, 
> 
> No, no, I dont wanna create yet another one. I'm just trying to find
> out, whether the exist PA API could become one (as it's AFAIK already
> crossplatform), even for cases where no audio server is running at all.
> 
> > it seems crucial to do some in-depth research about why none of the
> > existing APIs haven't become "the standard". Maybe it's
> > impossible to create an abstraction that works well on all platforms?
> 
> That would imply, that it wouldn't be possible to make PA itself cross
> platform (which, according to the website, it already is).

Fair point.

> > Maybe many applications just don't want an extra layer that they don't
> > have control over?
> 
> That would be more the 'not invented here'-syndrome. Eg. on FF that's
> my impression - they already support PA as a backend (along w/ others)
> and now dropping ALSA - that implies, PA API is sufficient for them.
> 
> > Or maybe the existing solutions are just lacking the
> > manpower to become really good (AFAIK, portaudio is still lacking a
> > pulseaudio backend)? 
> 
> Probably. But that would even more call for building that *API* out of
> an existing, working crossplatform solution. All it now takes is
> separating out the daemon specific stuff from the generic, move the
> API (IOW: headers) into an own package (similar to xorg-proto-*
> packages) and let PA sit ontop of that.

"Let PA sit ontop of that", with "that" referring to a bunch of
headers, doesn't make sense to me. I understand your proposal so that
the existing PA library would be one backend for the new API. So the
new API is a layer above the existing PA stuff, not vice versa.

> Then we would also have a
> working solution for vast majority of usecases.

What do you mean by this? Just putting the headers into a separate
package won't magically make any use case work that didn't work before.

> Now, if somebody wants
> eg. an ALSA-only (completely serverless) backend, he already has a
> good starting place and cut out all the stuff he doesn't need.

Cutting out stuff isn't enough, most things behind the API have to be
reimplemented. Most of the code in libpulse is about implementing the
client-server protocol of PA, and all that code needs to be replaced
when implementing other backends.



I don't think libpulse itself will ever be a library that supports non-
pulseaudio systems, although technically that would be possible. The
purpose of libpulse is to implement the client side of the client-
server communication protocol, and I have no desire to drastically
extend the scope.

If the main problem you're trying to solve is that some applications
choose to support only pulseaudio and some people don't like the
pulseaudio daemon, that can be solved by writing alternative libpulse
implementations. No need to create new standards - if an application
chooses to use libpulse, the libpulse API/ABI is the standard.

If the main problem you're trying to solve is that all existing cross-
platform APIs suck, and you think the libpulse API doesn't suck, and
pulseaudio-only applications would switch to a cross-platform API if
the API looked approximately like libpulse, then a new library can be
created on top of libpulse. In the beginning it could be identical to
the libpulse API if that seems like a good idea to you, but it would
have to be a separate library nevertheless, and applications would have
to explicitly choose to use it.

I get the impression that you might be mostly interested in making
applications that on Linux only support pulseaudio to work on ALSA-only 
systems, without modifying the applications. Are you aware of the
apulse project[1]? That lets you wrap libpulse-based applications so
that they use ALSA instead.

[1] https://github.com/i-rinat/apulse

-- 
Tanu

https://www.patreon.com/tanuk