🚀 go-pugleaf

Christian Huitema writes (forgot where):

>>Except one little detail. The first thing that "audioserver" does is to try to
>>connect to the local X server, and it aborts if it cannot.

No. I checked and it never connects to X in it's whole lifetime.

In article <53069@dime.cs.umass.edu> hgschulz@gaia.cs.umass.edu (Henning Schulzrinne) writes:
>One more little detail: It doesn't work. While XMedia may be a superb
>tool for playing sound bites for a multimedia kiosk or such, we have not
>been able to get it (Version 1.1, that is), to work in anything
>approaching real-time. We need to read audio data in 22.5 ms chunks for
>delay reasons and the XMedia alib interface doesn't seem to be able to
>handle that type of call frequency and leave processing power for other
>system chores.

This is a different statement than "it's all bulls**t". Yes, there
are areas for which even the XMedia 1.1 audio server does not work
well enough. There is more than a performance problem, it has
to do with the philosophy of handling client side data streams that
make it hard/impossible to a good job with very short latencies. This
problem will be rectified in the future, but it would be somewhat
overkill to get rid of the entire concept of a audioserver because
of that.

Apart from that, I will try to do my best (now putting down my head as
a somewhat proud XMedia engineer and taking my hat as european EERP
manager) I will try and see what we can do to provide both you and
Christian Huitema with an interim solution (maybe even device interface
descriptions as Christian Huiteman originally pointed out). No promises
but at least I will ask what the conditions would be.

		Burkhard Neidecker-Lutz

Multimedia Engineering, CEC Karlsruhe	   EERP Portfolio Manager
Software Motion Pictures		   Multimedia Base Technology
Digital Equipment Corporation
neidecker@nestvx.enet.dec.com