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

[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

[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] Scanners

[Charles Forsyth]

>If Plan9 can 'plumb' a remote sound card, (a questionable example long
>publicized) I'm sure it can do so with a mouse.

it isn't plumbing, but export/import, and it's useful.
i had a usable sound system on my r3000 indigo, but my PC had none.
on the pc, i imported the indigo's /dev and played sounds that way.
i could imagine uses even a continent away (alarm system imports remote
/dev and announces trouble). next door might be more useful.

Re: [9fans] Scanners

[W B Hacker]

Charles Forsyth wrote:
>> If Plan9 can 'plumb' a remote sound card, (a questionable example long
>> publicized) I'm sure it can do so with a mouse.
>
> it isn't plumbing, but export/import, and it's useful.
> i had a usable sound system on my r3000 indigo, but my PC had none.
> on the pc, i imported the indigo's /dev and played sounds that way.
> i could imagine uses even a continent away (alarm system imports remote
> /dev and announces trouble). next door might be more useful.
>
>

Welll - in the same room, it would seem 'sneakernet' would do well enough. Point
of fact, I use three kdb,vid,mouse and ... a swivel chair... less confusing than
sharing/switching among three disparate OS'en.

;-)

And I've actually considered remote audio I/O as part of a system for monitoring
a house that sits empty for months at a time, and responding to the doorbell ..
intrusion, et al ... but.. 'edge cases', both, if ever were. Easy enough to do
without Plan9. 'Too easy' to be fair.

'export/import' applied to remote resources - especially 'scarce' or expensive
ones (sound cards no longer are..) that could *send back* the results might make
a better present-day example.

If we could identify a few...

Couple of thoughts:

- hardware crypto devices  (cheap and cheerful in recent VIA CPU, seldom seen
otherwise)

- fast, specialty (expensive) graphics processing engines for storage to file,
or streaming-back not (necessarily) remote display. Ray tracing comes to mind...

- a 'ration' - free or purchased - of grid or supercomputing resources? (several
experts here - I'm not among them)

In any case, given that audio codecs are near-as-dammit ubiquitous on commodity,
and even 'server grade' and 'embedded' system boards these many years, I think a
better example than sharing a Soundblaster-equivalent is overdue.

I'm well aware that 'marketing' Plan9 is not really on anyone's radar here ..
but there could be a bit more done to convey the availability and value to the
like-minded potential fellow-travelers [1]. One benefit might include more
current device driver import/devel..

JM2CW

Bill

[1] FWIW - the 'Blue Gene' Plan9 work deserves better publicity. If/as/when one
hears that a certain 'hobby' alleged-OS is being run on such expensive kit, one
tends to question why it was even built...

[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

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

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

[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

[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

[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

[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