[LAU] open hw soundcard

[Paul Davis]

On Sun, Nov 15, 2009 at 6:38 AM, Karl Hammar <karl at aspodata.se> wrote:
> 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.

> ...
>> 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
> 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.