[Opensim-users] LSL HTTP server is slow (part II)

[David Saunders]

I been working with a few DJs, and written several boards and other stuff
for them.   But on the things they noticed is the song board update faster
then there stream does. :) I take that as a complement that I can get the
boards updating faster then them listing to the stream.  I even added a
trim command to them to "delay" the update.  If you DJ and listen to your
output from you mixer and listen in the client as the same time you get an
echo effect :) This is due to the time it takes to mixer->encoder -> stream
server -> decoder -> listener.  This delay can be up to 15 sec depending on
how everything is setup.  The only way to get a good sync with objects is
to have the client proved the control with there own client.



On Fri, Jan 15, 2016 at 8:09 PM, Melanie <melanie at t-data.com> wrote:

> Don't forget one very important thing: osMessageObject!
>
> It's as fast as link messages but spans objects. I have made a club
> lighting system that uses actual DMX hardware controllers and MIDI
> controllers and send the data to inworld. Turns out the limiting
> factor isn't the data pipeline but the speed at which ObjectUpdate
> gets sent out. Also, streams are typically not in sync with events.
> HTTP-in was plenty fast for this.
>
> - Melanie
>
> On 16/01/2016 02:03, Jeff Kelley wrote:
> > At 10:21 PM +0100 1/15/16, Tom Frost wrote:
> >
> >>Wouldn't dispatching commands coming in from http over chat and
> >>MessageLinked make things slow again?
> >
> > MessageLinked and chat are fast enough. We are not targeting 200
> > events/sec. ~20/30 are enough for smooth control, that is no
> > perceivable discontinuity.
> >
> >>I must say, i've never considered using incoming http requests.
> >
> > Once upon a time, we had mail. Then we had XML-RPC. Finally, HTTP in.
> >
> > In my opinion, HTTP is the most flexible of all when you want to
> > shuttle data in and out. The main pain is to track URL's (they change
> > each time the sim restarts). You need to register to a database via a
> > web service, and resolve names to changing URL's. Thus, an object can
> > call the resolver, get the URL of another object (possibly on another
> > grid) and initiate a direct communication.
> >
> > Fun story : when I was scripting on a public grid, my objects were
> > inadvertently included in oar's then replicated onto other grids.
> > Suddenly, I was receiving registration requests from unknown grids.
> > Since that, I have included a remote kill feature.
> >
> >>The in-world scripts I made that need interaction outside of the sim are
> >>low-frequency and generally pull-based.
> >
> > I'm a real-time guy, so I was interested from the beginning to push
> > the limits. Years ago, I was using UDP and C# scripts to communicate.
> > I'm doing all over HTTP now.
> >
> >>Curious to see though, where you're endeavours are going to lead :)
> >
> > This is opensimulator, so we are probably going to simulate
> > something. Maybe a factory, a nuclear plant, an industrial process, a
> > physics experiment... We want things that work when we act on them.
> > And we want nice control panels, dont' we? The time of prim buttons
> > and xyText is over. Design in HTML and cast it inside opensim.
> >
> >
> >
> > -- Jeff
> > _______________________________________________
> > Opensim-users mailing list
> > Opensim-users at opensimulator.org
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> >
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20160116/66384d15/attachment.html>