Re: Proposal: replacing esound with polypaudio in 2.10

[Lennart Poettering <mztabzr 0pointer de>]

On Thu, 28.10.04 19:49, Alan Cox (alan lxorguk ukuu org uk) wrote:

> ESD has several key design flaws
> - Its rate adaption code is crap
> - It has no synchronization with X

Please explain what exactly you mean with this.

> - Its security model is broken (keys in home directory)

Come on. Your beloved arts does it the same way, as far as I know (ok,
they store the key in /tmp instead of $HOME, but where's the
difference?). The only real difference i see is that they use a MD5 auth,
instead of plain like esd and polypaudio. However, that's trivial to
fix.

The Polypaudio API isn't fixed yet. So: what would you suggest? 

> - It has no way to pass audio descriptions for the hearing impaired
>   (who may want both audio and synchronized mark up).

What do you expect from a sound server to do with this data? 

I see no problem in adding a path for such meta data to be passed down
to the sound driver, if that makes you happy.

> 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.

Come on. Arts is dead. By coincidence Stefan Westerfeld (the author of
arts) studies at the same university as I do, so I had some
discussions with him about sound servers, and especially about
polypaudio and what the requirments are to make it a better replacement
for esd as well as arts. Yes, even the author of arts wants to see
artsd replaced. And yes, the current polypaudio API adresses most of the
issues we discussed.

Since polypaudio is embeddable into other applications (as long as
they have an event loop) it wouldn't be to difficult to create a patch
for arts which makes it compatible with polypaudio. So much to arts
compatibility.

BTW: The KDE projects is currently working actively on replacing arts
with another solution.

> > 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.

Execuse me? Please elaborate! "zillions of wrappers"? "pointers to
point"? "argument poking around"? What do you mean?

> 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.

What does it need to make it auditable to you? 

> 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.

In the same way you can replace the current, basic mixing
implementation of polypaudio. So, what's your point?

Lennart

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