| |||||||||||||
LPC: Linux audio: it's a messLPC: Linux audio: it's a messPosted Sep 20, 2008 9:47 UTC (Sat) by magnus (subscriber, #34778)Parent article: LPC: Linux audio: it's a mess
PulseAudio seems like a well thought-out project and I have nothing against it, but every audio API "solution" adds another layer to the Linux audio mess.
The only way a standard application audio API could ever be created is if someone writes an abstraction layer that can talk to Alsa, OSS, Jack, PulseAudio, ESD, aRts, MAS, etc, with autodetection of which one to use and dlopen:ing all relevant libraries to avoid broken dependencies. This code should then be included in source form in every program that uses it, because making a shared library out of it would just make it just another API that needs to be supported.
(Log in to post comments)
LPC: Linux audio: it's a mess Posted Sep 22, 2008 0:12 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
libsydney is supposed to be one part of that API you ask for.
Please note however that the audio/mm stack we are heading too is far less complex than you suggest. And the depth of the stack is not more than 3 (i.e. Gst on PA on ALSA at most)
Lennart
LPC: Linux audio: it's a mess Posted Sep 22, 2008 13:23 UTC (Mon) by nhippi (subscriber, #34640) [Link]
That's ignoring at least phonon and jack, that will continue to exist. Also, how does libsydney fall in? And the embedded people will have openmax...
Still, a good start would be a aggressive purge of legacy solutions - arts, esd, mas, various parts of libalsa.
LPC: Linux audio: it's a mess Posted Sep 22, 2008 17:09 UTC (Mon) by drag (subscriber, #31333) [Link]
Jack is solving a different problem domain. There is very very significant differences and requirements between people wanting to do real time audio editing vs multimedia playback.
Plus it's possible to play regular applications through PA and into Jack, if you want to use a familiar application or media source.
> Still, a good start would be a aggressive purge of legacy solutions - arts, esd, mas, various parts of libalsa.
Ya. Unfortunately that requires rewriting applications that depend heavily on those API.
For very modern-style applications that use things like Phonon or Gstreamer, this shouldn't be a big problem since those things are designed to be modular. Arts is being taken care of through the KDE folks, who are forced to rewrite their applications to work with QT4 anyways. Mas isn't popular. PA is compatible with Esd.
Then there is OpenAL, SDL, and numerous other much more minor sound APIs.
|
|||||||||||||