The Polypaudio sound server

[Lennart Poettering]

On Thu, 09.09.04 14:26, Mike Hearn (m.hearn at signal.QinetiQ.com) wrote:

> >ALSA is limited to Linux, it is everything else than portable. ALSA is
> >not network transparent. ALSA ist not esound compatible. ALSA is a
> >driver API, not a sound server API.
> 
> Well, what I'm saying is that maybe this problem sits at a layer below 
> the desktop. Sure ALSA is Linux specific but both Windows and MacOS can 
> *also* do their own software mixing and resampling without apps having 
> to use 3rd party sound servers.

A nifty feature of polypaudio is that it is possible to write plugins
that implement audio sinks where all mixing/resampling is not done
inside of polypaudio but delegated to an underlying audio layer. With
polypaudio you can do the following: if only OSS or any other simple
audio driver API is available use polypaudio's internal mixing. If
ALSA's dmix plugin in configured use that. Another example: a jack
plugin for polypaudio could do 1:1 mapping from audio streams to jack
ports. 

polypaudio does minimal buffering in this case, but you have full
control on this buffer, since polypaudio allows "future
cancellation", what means that every "write()" call has a "delta"
parameter which may be used to modify the write pointer in the
buffer. (Similar to libc's pwrite())

> Don't get me wrong. I'm not criticising Polypaudio, I've not used it but 
> judging from the webpage it looks like a nice piece of work.

Thanks. 

> >Polypaudio is intended for replacing esound/arts, not OSS or ALSA. So
> >I see no need in adding a compatibility layer for OSS/ALSA superseding
> >esddsp.
> 
> I don't see how it solves the problem of apps randomly blocking or 
> failing on busy DSP devices then. That is the problem you're trying to 
> solve, right? (along with network transparency etc ..)
> 
> Unless *everything* goes via Polypaudio it'll have the same problem that 
> esd, arts, and the rest already do. Arbitrary and random applications 
> won't play audio because the device is already in use by the sound 
> server, and we haven't really moved forward.

OK. let's see. The following APIs are or could be supported by
polypaudio:

* esound: through polypaudio's compatibility module
* NAS: could be implemented the same way
* ALSA: through a plugin for alsalib similar to the one available for jack
* OSS: An LD_PRELOAD trick like esddsp (or even esddsp itself)
* SDL, PortAudio, libao, gstreamer, (xmms, mplayer): through drivers
* arts: either by embedding polypaudio into artsd (one of the nifty
  features of polypaudio is that you can embedd the daemon it into
  other software) or by using artsd on top of polypaudio

Did I forget anything?

Sure, at the moment I only have: esound, libao, gstreamer, xmms,
mplayer. Missing are NAS, ALSA, PortAudio. Through already existing esound
drivers I have SDL, arts, OSS. 

I am currently finalizing the gstreamer driver, next on my todo list
is portaudio.

Lennart

-- 
name { Lennart Poettering } loc { Hamburg - Germany }
mail { mzft (at) 0pointer (dot) de } gpg { 1A015CC4 }  
www { http://0pointer.de/lennart/ } icq# { 11060553 }