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

[Jerry Westrick]

If some one did write this "sound extension", VNC could also
implement it, allowing for the "local" sound card to be available to 
remotetly run applications.

Of course, the sound card would have to have some sort of "Plug and
play" since the disconnecting from vnc and reconnecting from another 
machine may present another sound card or maybe none.

Hmmm, It would be nice if the window resolution could be truly re-sized
also...


Jerry Westrick...





On Thu, 2003-09-04 at 19:58, Arwed von Merkatz wrote:
> 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.
>