linuxaudio.org

On Sun, Nov 15, 2009 at 6:38 AM, Karl Hammar  wrote:

quoted text
> fons:

>> On Sun, Nov 15, 2009 at 10:03:24AM +0100, Karl Hammar wrote:

> ...

>> > As an unix guy, I'd skip the encoding and send the whole thing as

>> > space separaed text, since then you could simply do a telnet to the

>> > other host and run it by hand. Compare e.g. to smtp.

>> > The performance loss of printf() and scanf() at sending/receiving

>> > sides are minimal, and plain text is much easier to debug.

>> > But, this is of cause moot, since OSC is already there.

>> This 'telnet style' has existed for almost as long unix has,

>> and clearly there was a need for something more efficient in

>> some types of application.

>

> It might be so, but I think is more a question of how this or that

> group of people think. Unix guys thinks "text protocol", others are

> prone to think "binary protocol", not because it is a proven

> performance issue, but because they are used to it, and they don't

> have the big/little endian thing or differing floating point formats

> to care about.

OSC is not a new thing - its been around for more than a decade. It is

widely known that its text-based format represents significant,

measurable overhead when the message rate is high, primarily calls to

strcmp (or any equivalent function that you want to write - one way or

another, you have to do byte-by-byte comparisons to identify the

message and its destination). OSC is a remarkably flexible protocol

that has many potential uses, but as fons noted if you increase the

message rate to the level that would be needed for some kinds of less

conventional control, and the text based format is demonstrably a

*proven performance issue*. does that mean that OSC is useless? far

from it. this is much less of an issue than the lack of any clear

semantics. but its still an issue to be aware of depending on the use

case.
> ...

quoted text
>> In many cases (if only a limited set of commands is required,

>> no wildcards, no timed commands) OSC encoding/decoding can be

>> done almost 'zero-copy' and using just a few lines of very

>> simple code. The biggest error you can make in such cases, if

>> efficienty is an issue, is to use a general purpose 'full'

>> implementation such as e.g. liblo.

actually, the "lo" in liblo stands for "lightweight OSC", and is very

specifically NOT a full implementation of the protocol. steve chose to

implement just the parts that seemed actually useful. i have not come

across anything that liblo can't handle, but its a mistake to think

that its the whole thing. it is, though, as fons notes, more expensive

than a custom designed codebase that delivers primarily preformatted

messages to a socket.
> Ok, I'll try liblo first, if that is to slow, I'll implement it

quoted text
> myself.

i strongly suggest that you spend time defining precisely what you

want the control protocol to be able to do before you start this kind

of experiment.

_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user