| |||||||||||||
LPC: Linux audio: it's a messLPC: Linux audio: it's a messPosted Sep 22, 2008 0:12 UTC (Mon) by mezcalero (subscriber, #45103)In reply to: LPC: Linux audio: it's a mess by magnus Parent article: LPC: Linux audio: it's a mess
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
(Log in to post comments)
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.
|
|||||||||||||