| |||||||||||||
Gotta say "I told ya so!"Gotta say "I told ya so!"Posted Sep 19, 2008 1:47 UTC (Fri) by jmorris42 (subscriber, #2203)Parent article: LPC: Linux audio: it's a mess Last year when Pulse Audio went into Fedora 8 I posted this: http://lwn.net/Articles/256647/ Wherein I joked about the next shiny thing attracting their attention. It was called FUD. Note how it isn't a year later and we read an announcement about yet another audio API for everyone to port to is the works. This is insane. Is it any wonder every application that uses audio does it through an abstraction layer?
(Log in to post comments)
Gotta say "I told ya so!" Posted Sep 19, 2008 3:37 UTC (Fri) by jmspeex (subscriber, #51639) [Link]
PulseAudio is still the way to go. The real problem is at the API level. That's what libsydney is trying to solve. It's just an API that would talk to PulseAudio -- or any other audio subsystem (there's already an imcomplete implementation for Windows and maybe MacOS).
Gotta say "I told ya so!" Posted Sep 19, 2008 5:16 UTC (Fri) by bronson (subscriber, #4806) [Link]
What will libsydney provide that PortAudio doesn't?
Trying to find an answer, at the bottom of the libsydney link above triton asks, "As for the lib, wouldn't it be easier to fix PortAudio? Why reinvent yet another audio lib? NIH syndrome?"
Overall I'm really happy with Pulse but I'm very skeptical about libsydney... Does this world need yet another audio API for developers to choose from?
Gotta say "I told ya so!" Posted Sep 20, 2008 0:14 UTC (Sat) by jmspeex (subscriber, #51639) [Link]
I remember there were a couple of issues, but I don't remember the details. I think low-latency support was one of these issues. libsydney is designed to be usable both by media players and by applications that require a very low delay (few ms).
Gotta say "I told ya so!" Posted Sep 20, 2008 20:42 UTC (Sat) by salimma (subscriber, #34460) [Link]
Hope they come up with a good name for it too. libsydney and libcanberra are both very.. obsfuscating.
Gotta say "I told ya so!" Posted Sep 21, 2008 23:20 UTC (Sun) by mezcalero (subscriber, #45103) [Link]
The buffering model in PortAudio is too simple, too hardware-bound. A modern audio API should be a deparature of hw-specific fragment-based buffer metrics. Instead, we need to allow applications to set values that are actually understandable (such as "latency" and stuff) and default to a model that defaults large playback buffers with the option to rewrite them on request. Why? This will save us power (in conjunction with 'glitch-free' PA that is) and will greatly enhance network-transparent audio playback.
That is one of the more fundamental issues I don't think that PortAudio is the way to go. There are more. And it's a feeling shared by a couple of other audio related people.
Fixing the fact that we have to many competing audio APIs on Linux by adding another one is of course paradox. But still, after discussing this forth and back I believe this is the right way.
Lennart
|
|||||||||||||