sopwith at redhat.com
Fri Oct 29 16:29:11 UTC 2004
On Thu, 28 Oct 2004, Bill Nottingham wrote:
> Havoc Pennington (hp at redhat.com) said:
> > Do we have any comments on the sound server topic from a broader
> > perspective than only GNOME?
> > A competing proposal I've heard is to just use ALSA directly.
> Well, you'd need to set up ALSA to use dmix first. Once you do
> that, native ALSA usage could work.
> There's also jack, arts, and other mixers of that sort. Note
> that mixing jack and polypaudio doesn't look like it will work
> The fact that polypaudio's client API/ABI hasn't actually stablized
> at an initial version is worrisome.
The API doesn't currently provide many real benefits over esound. More
specifically, it doesn't have the synchronization features that are needed
for anything non-trivial. The basic idea is that to get realtime right,
you *have to specify a timestamp with all commands and events*. This
'get_latency()' junk isn't useful - it's the same paradigm that we've
already had with esd.
I don't know where it currently is at, but MAS
(http://www.mediaapplicationserver.net/) was supposed to have the proper
API for synchronization/timing/etc, based on the ideas of the old AF
server. It at least compiles & runs for me. The main drawbacks are lack of
ALSA support (easy enough to fix), and use of imake (also fixable). The
code seems a little cleaner than polypaudio at a brief glance.
Another alternative is to use gstreamer as 'the' framework, and then
create a gstreamer plugin that bridges sound to a daemon which does the
actual mixing and playing. That daemon could also use gstreamer internally
to perform the mixing etc. so the only really hard part would be bridging
the gstreamer plugin interactions between processes. This approach should
give the realtime/synchronization support needed for games and multimedia
apps, but make use of all the good gstreamer work that has been done so
far. It also would allow us to get rid of the sound server altogether on
hardware where it isn't needed and where the user doesn't care about sound
NMM has been mentioned in the context of a sound server, but it seems to
be almost a 'networked gstreamer in C++' concept (I assume we're talking
about Network-Integrated Multimedia Middleware when saying NMM...)
More information about the devel