[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules
From: |
Craig Ringer |
Subject: |
Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules |
Date: |
Thu, 04 Sep 2003 10:22:10 +0800 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 |
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
Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules, Carl Wilhelm Soderstrom, 2003/09/02
Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules, Alan Cox, 2003/09/02