🚀 go-pugleaf

The remote app is generating two streams of output -- to X and to 
/dev/dsp (or /dev/audio, depending on your app).

Your X output is designed to be redirected.  The X protocol packetizes
your video events and ships them around as packets.  Other forms of
video output are not redirectable, such as immediate SVGA output (which
is memory-mapped I/O, not unlike I/O through a device driver).
Your dsp device is not redirectable because it is device-mapped I/O.

To route audio between hosts, you'd have to do two things: 

1) rewrite the device driver to be a server (like X), 

2) invent a way to packetize/depacketize audio, comparable to how the 
   X protocol packetizes output graphics and input mouse/keyboard events.

I'm not aware of any non-proprietary way to do this.  Maybe you could hack
Shoutcast to create an audio server of your own.  But you'd also have to
insert your server between the app and the /dev/audio driver so that you
could redirect the app's audio output, by converting it into Shoutcast's
packets, and then passing it to the Shoutcast server.  

And as you suggest, you'd still have problems with synchronization.

Sounds to me like a major project.  Good luck.

    Randy


Tiny Human Ferret wrote:
> 
> Okay, here's the question:
> 
> I've got one Linux box (very steady, AMD K6 MMX, 2.2.17 kernel, most recent
> X) which I use for my main workstation. It's got a nice display card,
> damned-fine soundcard (SoundBlaster Platinum Live 5.1 with the front patch
> panel, etc), and generally it works great.
> 
> I have two servers, and generally I get to them with 'ssh' or Kerberos
> 'rlogin'. They've got much better bandwidth, and work where "runsocks
> <application>" won't quite deal with the situation, as in streaming video,
> etc.
> 
> As a rule, if I am Kerbed into one of the other servers, and I want to run
> Netscape or something else that relies on "X", I just login and export the
> display, as in
> 
> export DISPLAY="10.0.0.1:0.0" ; netscape
> 
> etc etc etc., 10.0.0.1 being the localhost X IP address.
> 
> Now, this is just fine, unless of course I'm trying to run something like
> RealPlayer or 'xanim', in which case I get the video component delivered to
> me with no problems... however, the audio component doesn't transfer; I get
> messages to the effect of "can't access /dev/dsp" which isn't surprising,
> since those servers don't have soundcards.
> 
> So, the final question is, "how the heck do I get the sound, as well as the
> video, redirected to the local workstation?"
> 
> Will I have to do goofy stuff like running ShoutCast or somesuch, and
> redirecting the audio output from the RealPlayer (etc) to ShoutCast or
> IceCast, and then picking up the audio locally, doubtless with total loss of
> synchronization?
> 
> Ideas, anyone?
> 
> --
> Whom thou'st vex'd waxeth wroth:  Meow. <-----> http://earthops.net/klaatu/

--
Randy Crawford
crwfrd@umich.edu
http://www.engin.umich.edu/labs/cpc
http://www-personal.engin.umich.edu/~crwfrd