[pulseaudio-discuss] couple with vnc

Colin Guthrie gmane at colin.guthr.ie
Wed Dec 10 01:24:18 PST 2008

'Twas brillig, and John A. Sullivan III at 10/12/08 04:38 did gyre and 
> On Tue, 2008-12-09 at 23:24 -0500, Brian J. Murrell wrote:
>> On Tue, 2008-12-09 at 23:21 -0500, John A. Sullivan III wrote:
>>> Yes, FreeNX or the original NoMachine NX is a little lighter.
>> But will FreeNX or the original NoMachine NX remote the sound to the
>> thin client too?
>>> This is
>>> designed for pretty heavy many to one machine usage, i.e., serving up
>>> many virtual desktops per one system.
>> The session suspend/resume like SunRays is nice though.  I bet that
>> doesn't happen with FreeNX.  :-(
>> I guess I will have to play and see.  :-)
> <snip>
> They do but they use esd :(  That's one of the principle reasons why we
> are switching to X2Go - their pulseaudio work.
> I believe the suspend/resume does work with all the NX based products
> including FreeNX although I have never used FreeNX.  Take care - John

This is interesting, I'll have to look into this.

I've not looked but I always though that NX stuff used the X11 protocol. 
If this is the case then the x11props support in pulse should be 
sufficient, although I'm guessing it's way more complex than that.

Just to answer Brian's original question, yes, it is possible to hook 
into the remote machines sound device to grab the output while still 
playing it on the machine... there are several ways to do this in fact, 
depending on needs. The easiest way is to connect to the "monitor 
source" of each sink (each sink or output device also has a 
corresponding "monitor" source. This allows you to read back what is 
currently playing. It's quite useful for e.g. shoutcast publication etc. 
but would serve equally well here). This would have to be supported by 
the VNC server which would then (presumably) compress the audio and 
transmit it over the VNC data channel to the client who would then 
decode and display.

An alternative would be for the VNC server/client to negotiate another 
comms TCP port to use and just tunnel the audio data over that. This may 
be a bit of a bandwidth hog tho'.

No idea how the X2Go folks are doing it.. this is just an outside 



Colin Guthrie

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

More information about the pulseaudio-discuss mailing list