unknown
1970-01-01 00:00:00 UTC
<br>
That said there are numerous protocols from the IETF that handle such requi=
rements without resorting to TCP. =A0For example SCTP, RUDP, etc. =A0In the=
2004 meeting Lazzaro showed how to use the RTP family to tunnel OSC (slide=
s should still be online at <a href=3D"http://opensoundcontrol.org" target=
=3D"_blank">opensoundcontrol.org</a>). =A0Note that he did not recommend tu=
nneling OSC over RTP-MIDI.<br>
<br>
In the AVBC work we put a control for minimum and maximum packet rates on s=
tream subscriptions. =A0This can be seen as a frequency-bandwidth limitatio=
n on control signals. =A0I believe this mitigates many potential problems i=
ncluding feedback loops and also provides crude bandwidth management and ad=
vises the clients what peak sample rate the endpoint might actually support=
.<br>
<br>
Also, for those concerned about bandwidth, it is a simple matter to impleme=
nt an adaptive sampling filter that only forwards a message if the minimum =
retransmit interval elapses, or if >n bits change in the data portion--f=
or integer data usually it will be n=3D0 and for floating point one can use=
a moving estimate of the noise to determine when the signal portion change=
s. =A0My informal experiments with this found that the approach easily achi=
eves compression rates of 10:1 or better on typical "gesture" dat=
a streams where the source has a relatively high sample rate (e.g. 1000hz).=
=A0Correct implementation of this requires timestamps as does any use of a=
synchronous sampling rates.<br>
<br>
Finally, the AVB working group has a defined target for how fast their netw=
ork audio control system should recover its connection-graph after a node h=
as been reset. =A0I think its around 10 seconds? =A0This gives a rough idea=
of how often the stream subscriptions need to be retransmitted.<br>
<div class=3D"im"><br>
<br>
<br>
On Aug 22, 2010, at 9:06 AM, Adrian Freed wrote:<br>
<br>
>> On the slider fighting side, I really like the idea of takeover/re=
lease but it might be hard to implement for silly (but eventually useful) c=
ases where we have multiple non-human sources (captors, oscillators, etc) s=
ending changes to the same target. Moreover, a lost "release" mes=
sage (failing hardware, device power off before release) can be disastrous.=
<br>
> The solution to these sorts of problems is a "lease". The id=
ea is there is an implied "release" at some short time in the fut=
ure that can be deferred by subsequent messages.<br>
> Then if the sender fails the desired state is returned to. This concep=
t-if carefully thought through - avoids a lot of problems people encounter =
attempting to synchronize state between two or more distributed systems. In=
fact in many situations you can avoid polling to try to synchronize states=
(an impossibility in practice anyway) altogether.<br>
<br>
<br>
<br>
</div>---<br>
<br>
Andy W. Schmeder<br>
email: andy [at] <a href=3D"http://cnmat.berkeley.edu" target=3D"_blank">cn=
mat.berkeley.edu</a><br>
skype: andy.schmeder<br>
<br>
Programmer/Analyst II<br>
Research Group<br>
Center for New Music and Audio Technologies<br>
University of California at Berkeley<br>
<a href=3D"http://cnmat.berkeley.edu" target=3D"_blank">http://cnmat.berkel=
ey.edu</a><br>
<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
OSC_dev mailing list<br>
<a href=3D"mailto:***@create.ucsb.edu">***@create.ucsb.edu</a><br>
<a href=3D"http://lists.create.ucsb.edu/mailman/listinfo/osc_dev" target=3D=
"_blank">http://lists.create.ucsb.edu/mailman/listinfo/osc_dev</a><br>
</div></div></blockquote></div><br></div>
--0016e6469b0cdf2d3b048ea04424--
That said there are numerous protocols from the IETF that handle such requi=
rements without resorting to TCP. =A0For example SCTP, RUDP, etc. =A0In the=
2004 meeting Lazzaro showed how to use the RTP family to tunnel OSC (slide=
s should still be online at <a href=3D"http://opensoundcontrol.org" target=
=3D"_blank">opensoundcontrol.org</a>). =A0Note that he did not recommend tu=
nneling OSC over RTP-MIDI.<br>
<br>
In the AVBC work we put a control for minimum and maximum packet rates on s=
tream subscriptions. =A0This can be seen as a frequency-bandwidth limitatio=
n on control signals. =A0I believe this mitigates many potential problems i=
ncluding feedback loops and also provides crude bandwidth management and ad=
vises the clients what peak sample rate the endpoint might actually support=
.<br>
<br>
Also, for those concerned about bandwidth, it is a simple matter to impleme=
nt an adaptive sampling filter that only forwards a message if the minimum =
retransmit interval elapses, or if >n bits change in the data portion--f=
or integer data usually it will be n=3D0 and for floating point one can use=
a moving estimate of the noise to determine when the signal portion change=
s. =A0My informal experiments with this found that the approach easily achi=
eves compression rates of 10:1 or better on typical "gesture" dat=
a streams where the source has a relatively high sample rate (e.g. 1000hz).=
=A0Correct implementation of this requires timestamps as does any use of a=
synchronous sampling rates.<br>
<br>
Finally, the AVB working group has a defined target for how fast their netw=
ork audio control system should recover its connection-graph after a node h=
as been reset. =A0I think its around 10 seconds? =A0This gives a rough idea=
of how often the stream subscriptions need to be retransmitted.<br>
<div class=3D"im"><br>
<br>
<br>
On Aug 22, 2010, at 9:06 AM, Adrian Freed wrote:<br>
<br>
>> On the slider fighting side, I really like the idea of takeover/re=
lease but it might be hard to implement for silly (but eventually useful) c=
ases where we have multiple non-human sources (captors, oscillators, etc) s=
ending changes to the same target. Moreover, a lost "release" mes=
sage (failing hardware, device power off before release) can be disastrous.=
<br>
> The solution to these sorts of problems is a "lease". The id=
ea is there is an implied "release" at some short time in the fut=
ure that can be deferred by subsequent messages.<br>
> Then if the sender fails the desired state is returned to. This concep=
t-if carefully thought through - avoids a lot of problems people encounter =
attempting to synchronize state between two or more distributed systems. In=
fact in many situations you can avoid polling to try to synchronize states=
(an impossibility in practice anyway) altogether.<br>
<br>
<br>
<br>
</div>---<br>
<br>
Andy W. Schmeder<br>
email: andy [at] <a href=3D"http://cnmat.berkeley.edu" target=3D"_blank">cn=
mat.berkeley.edu</a><br>
skype: andy.schmeder<br>
<br>
Programmer/Analyst II<br>
Research Group<br>
Center for New Music and Audio Technologies<br>
University of California at Berkeley<br>
<a href=3D"http://cnmat.berkeley.edu" target=3D"_blank">http://cnmat.berkel=
ey.edu</a><br>
<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
OSC_dev mailing list<br>
<a href=3D"mailto:***@create.ucsb.edu">***@create.ucsb.edu</a><br>
<a href=3D"http://lists.create.ucsb.edu/mailman/listinfo/osc_dev" target=3D=
"_blank">http://lists.create.ucsb.edu/mailman/listinfo/osc_dev</a><br>
</div></div></blockquote></div><br></div>
--0016e6469b0cdf2d3b048ea04424--