On Sat, Nov 14, 2009 at 10:31:00PM +0000, Folderol wrote: > > And where do you get the 'quite significant overhead' ? > > It just depends on how you use it. > > Well, maybe I'm wrong, but looking through the info I could find I got > the impression there was a lot of identification stuff going on before > you got anywhere near actual data. Anywhere where packets of different types have to be transmitted over the same channel you need to add some data to identify the packet type. It can be a simple as a single byte or int. OSC does two things: 1. It encodes packet type in textual strings, which can be structured in the same way as pathnames in file system are. 2. It defines a way to describe and encode the data that follows, so you are not limited to a set of predefined formats. Both are done in a way that make the conversion from/to a textual representation very simple, which is some cases is a desirable feature. Neither of these is essential in the application we are discussing, it could as well use a fixed set of binary formats. If the limits of doing that are acceptable then you don't need OSC or anything similar. If you don't want such limitations then OSC is a good choice. That's all. And anyway, until the fundamental hardware design issues are solved, all this is in fact quite irrelevant. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
