On Wed, 2017-04-26 at 16:56 +0200, Enrico Weigelt, metux IT consult wrote: > 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. Is #3 the same idea that you earlier described like this: > *MAYBE*, with a bit more in-depth analysis, we could even find a way > for using the same API for PA's backends themselves. But that's a whole > different exercise. (not a at all on my scope right now). > > > 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. I see, so the library provided by the pulseaudio project would be renamed to libpulse2 or whatever, and your project would take over the "libpulse" name. Probably the symbol names of libpulse2 would have to be changed too to avoid conflicts between libpulse and libpulse2 when they are used in the same process. In this scenario you don't have the luxury of removing anything from the API, because that would break applications. Not that I think this is a huge problem, I'm just making a note. > > 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. What do you mean by stable? libpulse already keeps backwards compatibility. Do you mean "stable" as in "new features require approval from a standards committee"? In this brave new world, where libpulse is managed by a standards committee, and the pulseaudio client library is renamed to libpulse2, what if libpulse2 gets a new feature and an application wants to use it? The application has to port its code from libpulse to libpulse2, and we're back to square one - the application depends on pulseaudio again. To make the application again cross-platform, maybe you'll take over libpulse2 too and tell the pulseaudio project to create yet another library. > > 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. It wouldn't take very much to change apulse so that its libpulse implementation could be installed directly to /usr/lib/libpulse.so.0. > The actual underlying problem is: application developers need some > stable API to code against. libpulse is stable in this sense. Applications can rely on new libpulse versions to be compatible with old application code. > 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. I'm not sure there are that many pulseaudio-only applications. I've heard of Skype and Firefox. > 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) -- Tanu https://www.patreon.com/tanuk
