sound server

[Alan Cox]

On Thu, Oct 28, 2004 at 02:11:06PM -0400, Havoc Pennington wrote:
> A competing proposal I've heard is to just use ALSA directly.

I wasn't aware that ALSA supported network audio. If you were going for a
'direct ALSA' type setup I'd actually suggest also stealing SDL_mixer.

> - Polypaudio provides an ESOUND compatibility module. When this is
>   enabled polypaudio emulates an esound server, including autospawning

Good

As to the code - no synchronization interface with X property changes, so
you can't stream sync the tcp session with the X tcp session. Thats one of
the real "doh!" problems with esd. I also can't find an accessibility 
interface to pass audio descriptons.

There are lots of dubious looking pieces of code that deal in terms of
multiplication without overflow checks. So far they look ok but make
me jumpy.

Code is hard to read with lots of pointer and pointer to pointer spaghetti
most of it uncommented.

pa_authkey_load_from_home assumes the file system is shared rather than
putting the auth key on the X root window. It also doesnt use getpwnam
as fallback for home. Means it cannot be run chrooted.

pa_drop_root doesn't properly drop saved setuid bit on some systems.
Does use capabilities which is good, although its not obvious why it
actually needs any.

Uses access() which never gives the right answer to anything because
its implicitly racy

I see no code trying to ensure that a lot of connects that dont bother
authenticating but just wait are cleaned up quickly.

Lots of stuff like esd connection_write seem to have no sane handling
for memory limits (eg when network is slower than reader)

It's got fairly dubious looking portability code (although maybe its
inherited esd suckiness)

"strncpy(name, (char*) data + sizeof(int)*2, sizeof(name));"

No rate adaption

It seems very overcomplex, unauditable, lacking functionality and
far inferior to arts (or to be honest in some ways to esd).