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


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]