Re: Proposal: replacing esound with polypaudio in 2.10

[Alan Cox <alan lxorguk ukuu org uk>]

On Iau, 2004-10-28 at 18:21, Lennart Poettering wrote:
>http://0pointer.de/lennart/projects/polypaudio/

I downloaded the code and took a look. I think its actually worse than
esd as an implementation. As a protocol well that may be a different
matter.

ESD has several key design flaws
- Its rate adaption code is crap
- It has no synchronization with X
- Its security model is broken (keys in home directory)
- It has no way to pass audio descriptions for the hearing impaired
  (who may want both audio and synchronized mark up).

Your code has weak floating point mixing code which is no better than
the esd code. It has no X synchronization. It has the same security
model (except it also forgets to use getpwuid as $HOME fallback). It has
the same lack of audio description passing.

It's not compatible with KDE while moving to arts would be.

> - Polypaudio provides an ESOUND compatibility module. When this is

I agree this is important

> What other requirements have to be met for inclusion of polypaudio in
> Gnome? I am strongly interested in getting polypaudio in shape for
> Gnome 2.10 in time: so please, don't hesitate to criticize polypaudio
> and especially its client API:

I would like to see the zillions of wrappers that make the code hard to
follow removed, all the pointer to point passing and argument poking
around cleaned up into proper objects and some commenting.

I tried to audit it and its currently near unauditable. To me if the
code isn't easily auditable as a daemon then that alone is a
showstopper.

I'd rather see Gnome use ARTS or someone take esd, rip out the broken
sound side stuff and use SDL_mixer to do the audio. That would give fast
floating point audio mixing thats very portable and reasonably correct
(it doesn't have a high quality mode which might be justified on modern
hardware - that is FFT and resynthesize) but its closer.

Alan