[OSC_dev] OSC bandwidth

[Andy W. Schmeder]

On Jul 16, 2008, at 7:14 PM, Angelo Fraietta wrote:

>> With respect to the original query, note that OSC has a protocol
>> overhead of 400% for transmission of single bytes (3-bytes padding  
>> + 1
>> typetag)
>
> This statement implies that it only takes four bytes to transmit a  
> byte
> of information over OSC. Apart from the four bytes needed for the
> typetag (you need the comma +  any padding top keep at the four byte
> boundary), the address space has not been taken into account.

To be precise: everything in the header is worst-case a constant  
overhead, i.e., O(1) in space (the "worst-case" qualifier includes the  
padding of address and typetag sections), and everything in the data  
section is O(n)...

I am well aware that the O(1) overhead of the header can be a rather  
large fraction of the total in practice--but this depends greatly on  
the message, which is why for analysis it should be considered  
separately.  Incidentally, a compression strategy applied to OSC would  
likely approach this part of the protocol first--e.g. by using a  
lookup table of common strings.  Also, because OSC addresses are human- 
readable they are an obvious target for compression due to their low  
information-density (english being only ~1 bit per character).

Arguments considered separately, the overhead of transmitting n 4-byte  
datums (e.g. float32, int32) is +1 byte, or 5/4*n.  For a null- 
terminated string length n, worst case is n + 5.  A blob length n is  
worst-case n + 9 (when n == 0). Datums smaller than the 4-byte  
boundary will obviously have the highest cost--for example, n single  
bytes, packed individually gives 5*n.  For n single bits, 8*n using  
the "T" and "F" typetags.

It is possible that a future version of OSC will recommend a vector  
typetag that makes transmission of floats something more like that of  
the blob -- that has been requested here before.

OSC does not claim to be optimized for low-bit depth integers  
(contrast to MIDI). There is an assumption that float32 is a  
preferable format for gesture data, e.g. for uniform representation  
over multiple bit depths. A specific use-case for this was described  
in the micro-OSC paper at NIME08, which presents functionally  
identical data-streams for two variants of a microprocessor having 10-  
and 12-bit ADCs [1].  This is an example of convenience over  
compactness, which is also a justifiable design decision in terms of  
the "carbon footprint" -- in 2002 NIST estimated that software bugs  
cost the US economy $60 billion annually [2].


1: http://cnmat.berkeley.edu/publication/uosc_open_sound_control_reference_platform_embedded_devices
2: http://www.nist.gov/public_affairs/releases/n02-10.htm


---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu