Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules

[Arwed von Merkatz]

You might want to take a look at MAS:
http://www.mediaapplicationserver.net/

It's basically a network transparent server for all types of media, with
support for network transparent audio/video synchronization and support
for X integration. I haven't looked more deeply into it, but it seems
like a good idea.

On Thu, Sep 04, 2003 at 10:22:10AM +0800, Craig Ringer wrote:
> >>Sound does not need to be handled in the X server, full stop. A sound 
> >>server is quite fine - look at aRts, esd, etc. At least esd, and 
> >>probably others, are quite capable of having clients on remote hosts - 
> >
> >I wouldn't be so confident about that.  Historically, the X11 standard
> >doesn't allow sound, so we have always used sound servers.  But they
> >have incompatibilities, and differ from box to box, and applications
> >need special support for them.
> 
> [snip]
> 
> > Consider this; if X is a video server, fine.  But it is not.  It is also
> > a keyboard and mouse server.  In other words, the X server is intended
> > to make all "desktop" hardware accessible over the network.  In modern
> > times this has come to include sound.
> 
> Hmm... you got me there. [attempts to remove foot from mouth]. I think 
> my point that remote sound does not /require/ X server support stands, 
> but your point about the X server supporting a 'desktop' not just a 
> display does make sense. It becomes increasingly clear that I didn't 
> think anywhere near enough about this - sorry.
> 
> My main concerns with using X as a sound server would be non-XFree86 X 
> implementations and buggy sound hardware/drivers. If you were working 
> on, say, an SGI Indy, you're unlikely to have the 'XSOUND' ext 
> available. It would be a great deal less fuss to quietly add esd or a 
> similar dedicated sound daemon than it would to install XFree86 (and 
> with many fewer side-effects).
> 
> Ideally, of course, the other X implementations would begin using the 
> extension too, but this wouldn't help older products much.
> 
> I suppose that if the X11 sound was handled via a client library with 
> the smarts to use (or at least support) a fallback like esd if 'XSOUND' 
> wasn't supported on the target server, then it wouldn't be too bad.
> 
> After all, I guess there would be some significant advantages in terms 
> of sound synchronisation for remote video, etc. Hmm... a client library 
> might also be able to do things like negotiate for streaming of 
> still-compressed MP3 / Vorbis to the server, and fallback to PCM if 
> needed. So long as the 'libxsound' could be built in esd-only  (or 
> whatever) mode without needing an 'XSOUND' capable X server (to support 
> newer apps on older X11 environments) then I guess that'd be cool from 
> my perspective.
> 
> Buggy sound hardware is another issue, though. I have a laptop that 
> occasionally freezes any client writing to /dev/dsp, forcing me to kill 
> and restart the client. This sort of thing shouldn't happen, true, but 
> given the common need (at least under Linux and the other free *NIXes) 
> to reverse-engineer drivers for hardware, drivers won't always be 100%. 
> Currently, I can just kill and restart the client - but if the client 
> was instead using the X server to handle sound, it'd be the X server 
> that'd hang. I guess offering the alternative to not use 'XSOUND' would 
> do the trick. One would just not load the XFree86 module for XSOUND, and 
> the smart client-side lib would fall back to direct access to /dev/dsp, 
> esd, or some other method.
 

-- 
Arwed v. Merkatz
Grimoire Guru for video
Grimoire Guru for xfce
Sourcemage GNU/Linux
http://www.sourcemage.org