Menu
▾
▴
linuxsampler-devel
|
From: Christian S. <chr...@ep...> - 2003-12-31 07:59:05
|
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 |
|
From: <be...@ga...> - 2003-12-31 11:22:33
|
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
|
|
From: Rui N. C. <rn...@rn...> - 2003-12-31 11:23:30
|
Christian Schoenebeck wrote: > 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. ACK. My first comment goes to literal syntax of some commands, as for making them a bit more structured-wise. It resumes to dropping a underscore character, in favor to a space one. For example, on "3.8 Getting channel information", having the syntax: GET CHANNEL_INFO <sampler-channel> it should be: GET CHANNEL INFO <sampler-channel> Like wise, I'll suggest: 3.9 GET CHANNEL_VOICE_COUNT -> GET CHANNEL VOICE_COUNT 3.10 GET CHANNEL_STREAM_COUNT -> GET CHANNEL STREAM_COUNT 3.11 GET CHANNEL_BUFFER_FILL BYTES -> GET CHANNEL BUFFER_FILL BYTES 3.12 GET CHANNEL_BUFFER_FILL PERCENTAGE -> GET CHANNEL BUFFER_FILL PERCENTAGE I hope you get th picture. Thus get general format would be: -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Rui N. C. <rn...@rn...> - 2003-12-31 12:20:49
|
Christian Schoenebeck wrote: > > 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. > ACK, read and assimilated :) My early comment would go on future extensibility. Thus the general command syntax should be rather be a litle more consistent, e.g. GET ENGINE {INFO|<engine-param-name>} <engine-name> SET ENGINE <engine-param-name> <engine-name> <engine-param-value> ... GET CHANNEL {INFO|<channel-param-name>} <channel-number> SET CHANNEL <channel-param-name> <channel-number> <channel-param-value> ... Some engine or channel parameters might be read-only (GET), others read-write (GET|SET). The INFO instruction would return the CRLF separated list of read-only parameters, either for the given ENGINE or CHANNEL respectively. Note that on GET CHANNEL commands the <channel-number> is specified _before_ the <channel-param-value>, which leaves open the possibility to an array or ordered series of parameter values (look above at the intended ellipsis notation). IMHO this leads to a more uniform and structured syntax that leaves open every other parameter one will come about in a near future--quite unavoidable isn't it? :) Accordingly, some notification events would take some general format: CHANGE ENGINE {INFO|<engine-param-name>} <engine-name> CHANGE CHANNEL {INFO|<channel-param-name>} <channel-number> I hope you get the picture. That was my EUR0.02 :) CU-l8er -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2003-12-31 19:53:52
|
Es geschah am Mittwoch, 31. Dezember 2003 13:19 als Rui Nuno Capela schrieb:
> IMHO this leads to a more uniform and structured syntax that leaves open
> every other parameter one will come about in a near future--quite
> unavoidable isn't it? :)
>
> Accordingly, some notification events would take some general format:
>
> CHANGE ENGINE {INFO|<engine-param-name>} <engine-name>
> CHANGE CHANNEL {INFO|<channel-param-name>} <channel-number>
Yes, that would be acceptable, at least from my side.
Es geschah am Mittwoch, 31. Dezember 2003 12:22 als be...@ga... schrieb:
> As said ASCII is elegant etc but does it pay off to waste
> network and cpu resources (and programming resources because ASCII requires
> parsers) ?
The command grammar defined in the initial draft is so far simply of Chomsky
type 3, means it can simply be resolved from left to right. That's really,
really simple and the parser would thus be very simple to implement and
efficient. Ok, not as efficient as a binary protocol solution of course.
> 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.
I definitely vote at least for ASCII commands. I want to be able to even
telnet the LinuxSampler box in case. But we could add commands where
LinuxSampler will response with a binary answer if the frontend prefers this,
e.g.:
GET CHANNEL BUFFER FILL_STATE_BINARY
so the client doesn't has to parse a response ASCII string and will just get
(as you suggested) a binary array representation.
Regarding the events e.g. for sliders. this is not that stressful. In case
e.g. a effect setting has been changed by a MIDI slider for example, the
engine will just send a small UDP event packet and we could even add the new
value with this event packet:
CHANGE CHANNEL EFFECT_DEPTH <sampler-channel> <new-value>
The client doesn't have to send a command to get this information it will
automatically be informed by the engine and on the other side, LinuxSampler
doesn't have to parse such a "request-for-update" ASCII command.
Again, we can go a parallel way (ASCII an binary), but at least I also like to
be able to send plain ASCII commands.
Other opinions?
CU
Christian
|
|
From: David O. <da...@ol...> - 2004-01-01 14:51:45
|
On Wednesday 31 December 2003 20.49, Christian Schoenebeck wrote: [...] > Again, we can go a parallel way (ASCII an binary), but at least I > also like to be able to send plain ASCII commands. How about introducing two layers; pre and post lexer? That is, if you want more efficient parsing, at the expense of a=20 slightly more complicated interface, use tokens and binary values=20 instead of string identifiers and decimal numbers. We could have a per-connection switch for both directions, one switch=20 for each direction, or even per-command "signal bytes" (maybe in the=20 128..255 range) to select ASCII or binary requests and replies on a=20 per-command basis. I think the first option makes most sense (a=20 single switch per connection), but it might turn out handy to be able=20 to mix ASCII and binary commands. The parsing of a protocol like the proposed one can be made very=20 efficient (a few levels of nested switch()es or similar tree=20 structure), so I don't think a "pure" binary protocol would be much=20 faster. It's the lexing that burns cycles, especially if there are=20 many and/or user defined "keywords" that require symbol table lookups=20 for tokenization. Decimal ASCII parsing is also pretty expensive, at=20 least on weaker CPUs with slow divisions. I haven't looked hard into=20 optimizing that kind of stuff, but I'm quite sure binary doubles and=20 even MIDI style variable length integers or similar is faster than=20 decimal ASCII. //David Olofson - Programmer, Composer, Open Source Advocate =2E- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se --- |
|
From: Rui N. C. <rn...@rn...> - 2004-01-01 14:49:00
|
benno wrote:
> As said ASCII is elegant etc but does it pay off to waste
> network and cpu resources (and programming resources because ASCII
> requires parsers) ?
>
> I'd like to hear your opinions about ASCII vs binary from you guys.
IMO assuming the lscp service is implemented on a different thread than
the midi/audio ones, the performance penalty of ASCII vs. binary parsing
is cheap nowadays.
On the client side it is even cheaper, if the command and response strings
are reasonably and elegantly structured, as I think they're coming about.
Of course the binary would be much more CPU and network effective but
regarding general interoperability I certainly prefer the ASCII route :)
As I've said once before, I will/can try to wrap lscp by an higher-level
API which would be asynchronous and event oriented. It will be implemented
as liblscp.so (lscp would stand for LinuxSampler Control Protocol).
Christian Schoenebeck wrote:
>> Accordingly, some notification events would take some general format:
>>
>> CHANGE ENGINE {INFO|<engine-param-name>} <engine-name>
>> CHANGE CHANNEL {INFO|<channel-param-name>} <channel-number>
>
> Yes, that would be acceptable, at least from my side.
>
Glad you liked :)
>
> I definitely vote at least for ASCII commands. I want to be able to even
> telnet the LinuxSampler box in case. But we could add commands where
> LinuxSampler will response with a binary answer if the frontend prefers
> this, e.g.:
>
> GET CHANNEL BUFFER FILL_STATE_BINARY
>
Same with me. Following my rationale, this later command would be better
written generically as :
GET CHANNEL BUFFER_FILL_STATE {BYTES|PERCENTAGE|BINARY} <sampler-channel>
> Regarding the events e.g. for sliders. this is not that stressful.
> In case e.g. a effect setting has been changed by a MIDI slider for
> example, the engine will just send a small UDP event packet and we
> could even add the new value with this event packet:
>
> CHANGE CHANNEL EFFECT_DEPTH <sampler-channel> <new-value>
>
Quite reasonable! And on my generic syntax form:
CHANGE CHANNEL <channel-param-name> <sampler-channel>
[<channel-param-value>]
We're getting there... nirvana :)
>
> Again, we can go a parallel way (ASCII an binary), but at least I also
> like to be able to send plain ASCII commands.
>
> Other opinions?
I would suggest that we first specify and implement on ASCII. If someone
would take the task, the binary dialect might be also an alternative (e.g.
via different tcp and udp ports).
Happy new year!
--
rncbc aka Rui Nuno Capela
rn...@rn...
|
|
From: David O. <da...@ol...> - 2004-01-01 14:59:51
|
On Thursday 01 January 2004 15.48, Rui Nuno Capela wrote: > benno wrote: > > As said ASCII is elegant etc but does it pay off to waste > > network and cpu resources (and programming resources because > > ASCII requires parsers) ? > > > > I'd like to hear your opinions about ASCII vs binary from you > > guys. > > IMO assuming the lscp service is implemented on a different thread > than the midi/audio ones, the performance penalty of ASCII vs. > binary parsing is cheap nowadays. Yes, we are talking about hundreds of cycles per command, which is=20 practically nothing - *provided* there are only tens or maybe=20 hundreds of commands per second. So, what kind of traffic volumes are we expecting? What kind of=20 relation does the traffic volume have to the CPU power of the server=20 machine? (You probably wouldn't be chatting about the states of 128=20 channels if the server only has CPU power for 32 voices.) [...] > I would suggest that we first specify and implement on ASCII. If > someone would take the task, the binary dialect might be also an > alternative (e.g. via different tcp and udp ports). Makes sense. Let's not optimize before we're actually sure it could=20 make a difference. :-) //David Olofson - Programmer, Composer, Open Source Advocate =2E- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se --- |
|
From: Christian S. <chr...@ep...> - 2004-01-03 00:06:10
|
Hi! I updated the protocol document: http://www.linuxsampler.org/api/draft-linuxsampler-protocol-01.pdf http://www.linuxsampler.org/api/draft-linuxsampler-protocol-01.sxw Major changes: - updated with Rui's proposals (Rui check if I forgot something) - Error responses now look like this: ERR:<errorcode>:<errormessage> That way frontends have an easier opportunity to e.g. show an error message already translated to a certain language just by doing a error code lookup - introduced warnings as possible return messages: WRN:<warningcode>:<warningmessage> A warning means the command was successful, but there are noteworthy issues to report, e.g. after a "LOAD INSTRUMENT" command, a warning might be returned because the deployed engine on that channel doesn't provide a certain feature to accurately playing back the instrument I have not added binary extensions so far. Should I? Again, send your suggestions for further improvements and corrections! CU Christian |
Thanks for helping keep SourceForge clean.
X