On 24.04.2017 20:04, Tanu Kaskinen wrote:
> "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.
I was talking about the PA daemon.
We could have these components:
#1 PA library API (just the API w/ differernt possible implementations)
it would define:
a) abstract device / backend interface (basicly struct w/ call
vectors, some basic types etc)
b) entry point for backend instantiation, tiny wrappers for just
calling default instance, etc)
--> note: just the API - leave the actual logic to the individual
implementations
#2 a PA library w/ pluggable backends (eg. for the average desktop),
which also has a backend for PA protocol client side
#3 a PA daemon ontop of the PA library API, possibly directly linking
onto the #2.
>> 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.
No, but it allows various independent implementations of the PA library.
(eg. ones that just directly call platform APIs). I'd leave it to the
distro/operator which one to choose (at deployment time).
It's a bit like xorg does it w/ their *-proto packages.
> 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.
Right, in that case one would just take out the pieces he needs and
basicly write its own PA library implementation.
> I don't think libpulse itself will ever be a library that supports non-
> pulseaudio systems, although technically that would be possible.
My idea was moving out the PA protocol stuff to a separate library.
> 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.
That's basicly what I'm proposing - BUT: make the client API/ABI
(what's directly used by individual applications) it's own entity
and keep it stable.
> 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 dont like touching dozens of applications that already use libpulse
and create yet another wrapper. Instead make the current API it's own
standard interface and make it easier to maintain alternative
implementations. Most people would still keep "official" libpulse
(if they're happy w/ the daemon), but those who want to switch can do
that easily.
> 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.
Not just Linux, any unix, but also windows etc.
> Are you aware of the
> apulse project[1]? That lets you wrap libpulse-based applications so
> that they use ALSA instead.
I know - basicly an minimal libpulse implementation and a bit ld.so
for redirection. Nice for very experienced, but not well suited for
use in distro context.
The actual underlying problem is: application developers need some
stable API to code against. We've got lots of platform specific APIs
plus various daemons - and the possible configurations are faar to much
that application developers could ever care about (and it's simply not
their scope). Now applications introduce their own private wrapper
layers that bridge onto various audio systems. Imense amount of repeated
work again and again - a problem that deserves to be solved once and
for all.
What we really need is an API that fits for all platforms (exotic ones
like plan9 or android), where the application developers just don't
have to care about what audio system (or potentially daemon) is
actually running underneath - and leave hat decision to the operator.
I could just invent yet a new wrapper API, but that would fail as too
many applications would need to be patched first. That's why I'm
proposing the already existing / widely used PA API as the universal
API and make it easy to build write your own implementation for
whatever scenario you'd might have in mind.
So, the first and most important step would be splitting off API vs.
PA protocol stuff. Applications would still include the same client
API headers and link against libpulse, but the PA protocol stuff
doesn't need to be in here anymore. The rest of my proposals is more
optional (for consolidating the potentially many implementations)
--mtx
