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

[Craig Ringer]

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

Consider my poorly-thought-out flat objection to the idea withdrawn (for 
all that it matters). I do hope, though, that any such plans would 
carefully consider the additional issues introduced by having the X 
server handle another kind of hardware access, of older X 
implementations, and of older client software.

> Hear hear.  And we should take out X support for the mouse and keyboard
> as well. They really bloat the code; ideally X should just give you
> network access to a raw video buffer, and you should use separate mouse
> and keyboard servers for purposes of stability and to reduce code bloat.

Yeah, you got me there.

Craig Ringer