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

[David Saunders]

Well RTP are only good as the latency of the network they are on :)



On Sat, Jan 16, 2016 at 9:17 PM, Jeff Kelley  wrote:

> At 12:08 PM -0500 1/16/16, David Saunders wrote:
>
>  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.
>>
>
>
> Hi David.
>
> Yes, audio streaming latency is a pain and breaks the action/result loop
> in a bad way. You can't even try to compensate, since latency differ from
> viewer to viewer. Your are never sure what your listeners hear.
>
> There is nothing we can do here. HTTP streaming is not real-time. RTP is,
> but that's another story.
>
> Happy DJ'ing (with delay).
>
>
>
> -- Jeff
> ___
> Opensim-users mailing list
> Opensim-users@opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
___
Opensim-users mailing list
Opensim-users@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users

Re: [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  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@opensimulator.org
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> >
> ___
> Opensim-users mailing list
> Opensim-users@opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
___
Opensim-users mailing list
Opensim-users@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users

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

[Jeff Kelley]

At 12:08 PM -0500 1/16/16, David Saunders wrote:

 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.



Hi David.

Yes, audio streaming latency is a pain and breaks the action/result 
loop in a bad way. You can't even try to compensate, since latency 
differ from viewer to viewer. Your are never sure what your listeners 
hear.


There is nothing we can do here. HTTP streaming is not real-time. RTP 
is, but that's another story.


Happy DJ'ing (with delay).


-- Jeff
___
Opensim-users mailing list
Opensim-users@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users

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

[Jeff Kelley]

At 9:50 AM +0100 1/15/16, Tom Frost wrote:


Out of curiosity, how well does this scale? I remember in SL there was a
limit to the number of URL's a resident can have (38 from
http://wiki.secondlife.com/wiki/LSL_http_server#Resource_Limitations),
which implies that url's don't scale that well in SL. How does the http
server in opensim scale?



Hi Tom.

In opensim, in a region with no url allocated, llGetFreeURLs() returns 100.

In a real app, you probably don't want to manage as many. Rather one, 
and dispatch commands via chat or MessageLinked.



-- Jeff
___
Opensim-users mailing list
Opensim-users@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users

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

[Jeff Kelley]

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@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users

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

[Melanie]

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@opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> 
___
Opensim-users mailing list
Opensim-users@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users