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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss