Re: esd

[Robert Bihlmeyer <robbe orcus priv at>]

Hi,

>>>>> On Sun, 03 Jan 1999 14:28:02 +0000
>>>>> "Yo 'Ric Dude" <ericmit@ix.netcom.com> said:

 ebm> Encoding mpeg3 audio is a bit too CPU intensive for a compress
 ebm> at the client, decompress on the server,

Sure compression is slow as molasses, but many people have lots off
already compressed mp3s lying around, and decompression is reasonably
fast (plus needs to be done anyway).

 ebm> but i now see the special "mpeg3-esd" that simply sends the mp3
 ebm> data over to the server for decompression.

What I envisioned is more like this:

You can tell the what format the data is in. Apart from RAW, and the
already present (but unimplemented) ADPCM, there could be things like
MPG3, S3M, you name it. Support for all these beasts should probably
not be compiled into the server itself, but reside in shared objects
or even external filters ("mpg123 -s -" is already such a thing).

esdcat could take the format on the commandline and just set the right 
flags before sending the thing. esdplay would use libaudiofile or
other magic to autodetect the type of data and do the right thing.

 ebm> Except of course for the potiential patent probelms with mpg3
 ebm> audio (?)

I am not sure, but I think *de*compressors are not patented. Putting
the mpg3 code into a seperate shared object or binary should protect
esd from those problems.

 ebm> The only potential problem there is then you also wind up with
 ebm> s3m-esd, it-esd, other-mod-format-esd, realaudio-esd, etc.

Sure, support for those formats would have to be written, but your
average user would just download & install the right backends, and
issue esdplay on everything (or say to the control-center: "Play this
mod file when I log in, and this mp3 when I log out").

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>