3

I am working on an application that will send OSC control messages, which is, as I understand a datagram packet, from a web page to an OSC Receiver (server), such as Max/MSP or Node or any other.

I know typically UDP is used because speed is important in the realtime/ audio visual control work done with OSC (which is also the work I will be doing), but I know other methods can be used.

Right now for instance, I am sending OSC from the browser to a node.js server (using socket.io), and then from the node.js server to Max (which is where I ultimately want the data), also using socket.io. I believe this means I am using websockets and the delay/latency has not been bad.

I am curious though, now that WebRTC is out, if I should place the future of my work there. In all of my work with OSC I have always used UDP, and only used the Socket.io/Websockets connection because I didn't know about WebRTC.

Any advice on what I should do. Specifically I am interested in

1. How I could send OSC messages from the browser directly to an OSC server (as opposed to going through a node server first)

2. If I should stay with the Node/Socket.io/Websocket method for sending OSC data or should I look into WebRTC?

Startec
  • 12,496
  • 23
  • 93
  • 160

2 Answers2

4

Regarding your first question - if there is a solution for a direkt Websocket link between browser and server (for OSC) - you can have a look into this:

I published an osc-js utility library which does the same with a UDP/Websocket bridge plugin:

adz
  • 81
  • 5
3

This is not really a question about any specific technical challenge, but a discovery challenge. And is pretty much opinion based.

But I will try to provide my thoughts, as others can be useful too.

  • If OSC server support WebSockets or WebRTC connection, then you might use one of them directly to it.
  • Based on nature of browsers, you probably need to support many protocols rather than one specific. As many browsers have different support: http://caniuse.com/rtcpeerconnection unless your users can be "forced" to use specific browser.
  • WebRTC is meant to be high-performance. I'm not sure it is good to compare it with UDP at all, as it is much more than UDP in comparison as well as implementation vary (inside) per browser.
  • You need to talk to server rather than between clients, while WebRTC mainly is designed for peer-to-peer communications. So you need precisely investigate into benefits on performance from latency as well as CPU point of view on server side.

Benefit of UDP is the fact that some packets can be dropped/skipped/undelivered, as it is not "mandatory" data, like picture frames or piece of sound, that only results on reduced quality, which is "expected" behaviour in streaming world. WebSockets will ensure that data is delivered, and "price" for it is mechanics that at the end slows down the queue of packets, to ensure ordered and guaranteed delivery of data.

moka
  • 22,846
  • 4
  • 51
  • 67