Re: [9fans] remote access to audio devices

Re: [9fans] remote access to audio devices

[erik quanstrom]

> Java sometimes does turn up trumps where C code struggles on machines
> which were recently considered powerful. Other examples would be web

what?

- erik

Re: [9fans] remote access to audio devices

[Jorden Mauro]

On Dec 25, 2009, at 4:57 AM, erik quanstrom <quanstro@quanstro.net>
wrote:

>> Java sometimes does turn up trumps where C code struggles on machines
>> which were recently considered powerful. Other examples would be web
>
> what?
>

Could be talking about GC? I saw a paper once that described speedups
in X11 when hooked up to the Boehm collector.

I'm always sceptical about these kinds of claims.

Re: [9fans] remote access to audio devices

[Anthony Sorace]

On Dec 25, 2009, at 04:57, erik quanstrom wrote:

>> Java sometimes does turn up trumps where C code struggles on machines
>> which were recently considered powerful. Other examples would be web
>
> what?

from the rest of his post, i gather that the claim isn't that Java vs.
C code of equivalent
quality has C lagging, but rather that some application written in
Java can beat an
application of vaguely equivalent description written in C. the VNC
examples given
say, basically, that the Java app performs better out of the box than
the C app, but it
seems to just be about picking better (for that particular case)
defaults.

i guess my question is really what this observation is intended to
illustrate.

Re: [9fans] remote access to audio devices

[Ethan Grammatikidis]

On 26 Dec 2009, at 3:39 am, Anthony Sorace wrote:

> On Dec 25, 2009, at 04:57, erik quanstrom wrote:
>
>>> Java sometimes does turn up trumps where C code struggles on
>>> machines
>>> which were recently considered powerful. Other examples would be web
>>
>> what?
>
> from the rest of his post, i gather that the claim isn't that Java
> vs. C code of equivalent
> quality has C lagging, but rather that some application written in
> Java can beat an
> application of vaguely equivalent description written in C. the VNC
> examples given
> say, basically, that the Java app performs better out of the box
> than the C app, but it
> seems to just be about picking better (for that particular case)
> defaults.
>
> i guess my question is really what this observation is intended to
> illustrate.
>
>

Yes, that would be what I meant. Thanks for writing that Anthony,
these things are all pretty clear in my head, but writing them out
clearly is quite hard work.


--

Ethan Grammatikidis
eekee57@fastmail.fm

Re: [9fans] remote access to audio devices

[Enrico Weigelt]

* Jorden Mauro <jrm8005@gmail.com> wrote:

> I saw a paper once that described speedups
> in X11 when hooked up to the Boehm collector.

hmm, do you know how did it and if there's any code on that yet ?

cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 174 7066481   icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] remote access to audio devices

[Ethan Grammatikidis]

On 2 Dec 2009, at 3:00 am, Sam Watkins wrote:

> Ethan Grammatikidis wrote:
>> I've had responsiveness issues when the viewing machine hasn't
>> enough CPU
>> power to decode the screen data in real-time. A lot of  power
>> seems to be
>> needed, my PDA, a 416MHz ARM can't cope with any  compression at
>> all, I have
>> to limit vncviewer to copyrect and raw  encodings only.
>
> The Java tightvnc client works fine on my little eee pc, so I would
> think the
> native client should run well enough on a toaster.  Maybe it uses
> floating
> point and the ARM pda in question doesn't have hardware floating
> point.
>
> Sam
>


Java sometimes does turn up trumps where C code struggles on machines
which were recently considered powerful. Other examples would be web
browsing and Flash video. Now the web supports alternative style
sheets to present a simpler layout on mobile devices and Flash
supports a supports a video format which takes less work to decode -
YouTube offers it as an option. Perhaps the Java TightVNC client
declines the trickier encodings, exactly as I have to pass options to
the C client to do. By default the C TightVNC and RealVNC clients
assume "we can has cycles," which leaves me wondering quite what
situations have sufficient computing power with such measly bandwidth
as to make the 'heavy' encodings worthwhile.

Sorry for the late reply, had to ignore email to get other things in
order.

--
freedesktop.org, because unix doesn't make things harder enough.

Ethan Grammatikidis
eekee57@fastmail.fm

Re: [9fans] remote access to audio devices

[Sam Watkins]

Ethan Grammatikidis wrote:
>I've had responsiveness issues when the viewing machine hasn't  enough CPU
>power to decode the screen data in real-time. A lot of  power seems to be
>needed, my PDA, a 416MHz ARM can't cope with any  compression at all, I have
>to limit vncviewer to copyrect and raw  encodings only.

The Java tightvnc client works fine on my little eee pc, so I would think the
native client should run well enough on a toaster.  Maybe it uses floating
point and the ARM pda in question doesn't have hardware floating point.

Sam

Re: [9fans] remote access to audio devices

[Patrick Kelly]

On Dec 1, 2009, at 17:28, Ethan Grammatikidis <eekee57@fastmail.fm>
wrote:

>
> On 1 Dec 2009, at 8:44 pm, Steve Simon wrote:
>
>>> VNC can (has been) be a butt-saver' - but pales in comparison to
>>> remote desktop
>>> / remote X for relative responsiveness and seamlessness.
>>
>> My experience of serving a Windows desktop to a plan9 terminal
>> is that TightVNC with the DFMirage "Mirror driver" works really well.
>
> I've had responsiveness issues when the viewing machine hasn't
> enough CPU power to decode the screen data in real-time. A lot of
> power seems to be needed, my PDA, a 416MHz ARM can't cope with any
> compression at all, I have to limit vncviewer to copyrect and raw
> encodings only. Encoding doesn't seem to need half as much CPU
> power. I ran Xvnc on a headless server with a 400MHz AMD K6 with no
> issues that I recall.

Now I don't have any expertise with VNC, but decoding anything, is
supposed to take less time than encoding it. I would check into that.
>
> All that gear was using either TightVNC or the plain vnc-
> x.y.z.tar.gz from RealVNC. When using Vine Server on a 466MHz Apple
> screen updates are not really adequate,  while the mouse pointer
> lags if I use the VNC server supplied with OS X Tiger on the same
> machine. x0vncserver is a known problem server which I haven't used,
> IIRC it basically works by taking screenshots continuously and
> sending those.
>

Re: [9fans] remote access to audio devices

[Ethan Grammatikidis]

On 1 Dec 2009, at 8:44 pm, Steve Simon wrote:

>> VNC can (has been) be a butt-saver' - but pales in comparison to
>> remote desktop
>> / remote X for relative responsiveness and seamlessness.
>
> My experience of serving a Windows desktop to a plan9 terminal
> is that TightVNC with the DFMirage "Mirror driver" works really well.

I've had responsiveness issues when the viewing machine hasn't enough
CPU power to decode the screen data in real-time. A lot of power
seems to be needed, my PDA, a 416MHz ARM can't cope with any
compression at all, I have to limit vncviewer to copyrect and raw
encodings only. Encoding doesn't seem to need half as much CPU power.
I ran Xvnc on a headless server with a 400MHz AMD K6 with no issues
that I recall.

All that gear was using either TightVNC or the plain vnc-x.y.z.tar.gz
from RealVNC. When using Vine Server on a 466MHz Apple screen updates
are not really adequate,  while the mouse pointer lags if I use the
VNC server supplied with OS X Tiger on the same machine. x0vncserver
is a known problem server which I haven't used, IIRC it basically
works by taking screenshots continuously and sending those.

Re: [9fans] remote access to audio devices

[Steve Simon]

> VNC can (has been) be a butt-saver' - but pales in comparison to remote desktop
> / remote X for relative responsiveness and seamlessness.

My experience of serving a Windows desktop to a plan9 terminal
is that TightVNC with the DFMirage "Mirror driver" works really well.

-Steve

Re: [9fans] remote access to audio devices

[W B Hacker]

Sam Watkins wrote:
> VNC or similar "remote desktop" with sound support can be useful for things
> like pair-programming over then internet, if you are working on an app or game
> that uses sound.
>
> Sam
>
>

VNC can (has been) be a butt-saver' - but pales in comparison to remote desktop
/ remote X for relative responsiveness and seamlessness.

(And we are speaking cross-platform, as Plan9 <=> Plan9 doesn't necessarily need
either..)

Bill

[9fans] remote access to audio devices

[Sam Watkins]

VNC or similar "remote desktop" with sound support can be useful for things
like pair-programming over then internet, if you are working on an app or game
that uses sound.

Sam