Re: [Linuxsampler-devel] LinuxSampler control protocol (initial draft)

[<be...@ga...>]

Hi, I briefly browsed the protocol looks interesting.
Some comments about performance:
While ASCII is nice, human readable and endian neutral it's
sometimes a bit too heavy for a realtime protocol.
While I agree that some commands like "load new sample" etc
are not time critical, other kind of commands like
"client requests the buffer fill status of 200 buffers (200 active voices)"
 which might be issued 30 times/sec (to produce a fluid animation of
fillstatus idicators) could add some overhead in both the client and
 server not to mention that it requires an ASCII parser which makes the
code more complex.
On the other hand if you use a binary format, transfering the fill status
 of buffers is just a matter of sending an array of ints (with some small
 header) to the network. 
The client code is simple too: just read the array from network and start
 accessing it.

Ok if the server is little endian and the client GUI runs on a big engian
box then byteswapping is needed, but this could be handled easily by a macro.

typedef {
  short cmdtype;     // type of command
  short datalength;  // length of the payload (can be 0)
  } cmd_header_t;

enum {
        CMD_GET_FILLSTATUS,
        CMD_FILL_STATUS
     };

           

typedef {
          cmd_header_t cmdheader;
        } cmd_get_fillstatus_t;

typedef {
          cmd_header_t cmdheader;
          int fill_amount[MAXVOICES];
        } cmd_fillstatus_t;


when the client wants to request the fillstatus it sends


cmd_get_fillstatus  
and sets
cmdheader.cmdtype=CMD_GET_FILLSTATUS 
cmdheader.datalength=0 (because there is no payload attached).

the datalength field can be used by server or client to read
the right amount of data or to skip over unknown commands.

the server simply sits in a loop reading
sizeof(cmd_header_t) bytes from network.
then it looks at cmd_header_t.cmdtype and performs actions based
on the type of command.

For example when it sees CMD_GET_FILLSTATUS
it simply sends back a CMD_FILLSTATUS packet
(with attached payload that contains the buffer fill values).

As you see it's very simple and what's more important
extremely efficient in both terms of CPU usage (no complex parsing required) and
network bandwidth  utilization.
You can send thousands of commands per second without using sensible
amounts of CPU on the server or client.

You can define easy to use macros like this

#define set_cmd_get_fillstatus(a) (a)->cmdtype=MCMD_MP_START_PLAY; (a)->datalength=0

that way to send the CMD_GET_FILLSTATUS the client can simply do:

cmd_get_fillstatus_t cmd;
set_cmd_get_fillstatus(&cmd);
write(socketfd, &cmd, sizeof(cmd));

Same for the server side responses.

As said ASCII is elegant etc but does it pay off to waste
network and cpu resources (and programming resources because ASCII requires
 parsers) ?

For example client B could change parameters in linux sampler eg,
 reverb amounts, FX send levels continuously while client A (a GUI)
 display the faders which should be moving constantly.
With ASCII we send a lot of data around need to parse it in to LS engine
and then parse back in client A etc. 

I'd like to hear your opinions about ASCII vs binary from you guys.

cheers,
Benno







Scrive Christian Schoenebeck <chr...@ep...>:

> Hi!
> 
> Here is the promised initial draft for the LinuxSampler control protocol:
> 
> 	http://www.linuxsampler.org/api/draft-linuxsampler-protocol-00.pdf
> 	http://www.linuxsampler.org/api/draft-linuxsampler-protocol-00.rtf
> 
> I expect you to post your suggestions for improvements / corrections for the
> 
> protocol. Sorry that I've not created a plain text version yet.
> 
> CU
> Christian
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 




-------------------------------------------------
This mail sent through http://www.gardena.net