[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
gimble:
> 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
observation.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
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