[pulseaudio-discuss] Can pulsaudio client API become a crossplatform standard ?
tanuk at iki.fi
Mon Apr 17 17:40:43 UTC 2017
On Sun, 2017-04-16 at 22:33 +0200, Enrico Weigelt, metux IT consult
> On 15.04.2017 20:39, Tanu Kaskinen wrote:
> > The feature set of libpulse will necessarily track the features of the
> > pulseaudio daemon. Is the idea to take a subset of the libpulse API and
> > make that work on non-pulseaudio platforms?
> Haven't sorted out which features really require a daemon like PA yet.
> (any input appreciated).
> Maybe we can devide it into basic functions and *optional* daemon
> related ones. If there's no daemon, the basic ones still must work.
> > What makes libpulse a better starting point for a cross-platform API than
> > some of the existing cross-platform APIs?
> From what I see here, the PA API should be enough for the vast majority
> of applications, and it's already well established, even crossplatform.
> Those who already require others, eg. jack, will continue to do so
> anyways (we cant make everybody happy w/ one-fits-all API). I'd just
> like to have an common API, which is independent from the actual
> implementation behind.
> I know there're several other APIs, but they dont seem to be widely
> adopted and lots of people have strong objections (haven't sorted out
> the exact reasons yet), but none against PA. Some folks even invent
> their own ones, that finally bridge to others like PA - just look at
> mozilla folks (who now drop ALSA completely).
> Of course, we can only count in the pure C APIs, C++ ones are limited
> to C++ only and even make it really hard to provide binary
As you're planning to create yet another cross-platform audio
abstraction API, 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?
Maybe many applications just don't want an extra layer that they don't
have control over? Or maybe the existing solutions are just lacking the
manpower to become really good (AFAIK, portaudio is still lacking a
pulseaudio backend)? If you don't understand why the existing solutions
haven't gained wide popularity, it seems very likely that you'll repeat
the same mistakes in your project.
I haven't done the research myself, so I don't have the answers.
More information about the pulseaudio-discuss