Menu
▾
▴
linuxsampler-devel
|
From: Christian S. <chr...@ep...> - 2004-01-18 20:45:35
|
Changes: - added JACK support; you'll need to have libjack headers and pkg-config installed in order to be able to compile LinuxSampler with JACK support. If you have not, it will compile with Alsa support only. If compiled with JACK support, LinuxSampler will first try to connect to the JACK server. If this fails it will automatically fallback to Alsa output. - applied the patch from Vladimir which fixes the mentioned small bug with hanging notes in conjunction with the sustain pedal CU Christian |
|
From: Christian S. <chr...@ep...> - 2004-03-05 15:24:23
|
Changes:
- Implemented parser for the LinuxSampler control protocol (LSCP) by
using flex / bison (where src/network/lscp.l is the input file for lex /
flex and src/network/lscp.y is the input file for yacc / bison). Parser and
scanner can be regenerated by 'make parser' (only necessary though if one
of the two input files where modified).
To be honest I'm not quite sure so far if this parser solution is a good
choice, especially because I'm a bit disappointed about it's runtime
efficiency (a main problem is that lexical analyzer and semantic analyzer
are separated which is a big disadvantage for the parser generator in
regards of optimization), but this lex/yacc soultion has the advantage
of defining the protocol on a higher level and is thus easier to maintain
in regards of a growing and possible complex protocol. We'll see...
If somebody's not familiar with lex/yacc, I can give an introduction to the
current LSCP implementation in a short mail if demanded.
If somebody has a suggestion for another parser generator, let me know!
- Implemented LSCP network server (only single threaded so far, thus is only
capable to handle one connection at one time), LSCP server will be launched
if LinuxSampler was started with the new "--server" flag. So far I
implemented the following LSCP commands:
* "LOAD INSTRUMENT"
* "GET CHANNEL VOICE_COUNT"
* "GET CHANNEL STREAM_COUNT"
* "GET CHANNEL BUFFER_FILL"
* "SET CHANNEL VOLUME"
* "RESET CHANNEL"
In src/network/lscpserver.cpp there already all methods which will be
called in case of the respective network command. But most of them
currently just return a "ERR:0:Not implemented yet" error message, so these
methods need to be "wired" now with the engine and have to return a
meaningful response message. If anybody likes to implement one of those
methods I would appreciate that! (Vladimir perhaps?)
- disk thread now started within the engine
CU
Christian
P.S. It's time for a frontend... :)
|
|
From: Mark K. <mar...@co...> - 2004-03-05 17:39:13
|
On Fri, 2004-03-05 at 07:09, Christian Schoenebeck wrote: <SNIP> > CU > Christian > > P.S. It's time for a frontend... :) > Boy did that P.S. put a smile on my face! ;-) |
|
From: Rui N. C. <rn...@rn...> - 2004-03-05 21:53:22
|
Hi, > - I'm a bit disappointed about it's runtime efficiency In terms of code-path and resource efficiency, I humbly think that my raw approach, based on strtok can't be beaten ;) > - Implemented LSCP network server (only single threaded so far, > thus is only capable to handle one connection at one time), My liblscp code (http://www.rncbc.org/ls) has all this put together; is multi-client and multi-threaded. Remember that you shall only code the server-side callback function? OK. Now that some server code is already on linuxsampler I can dig it and probably reimplement it using "my" liblscp approach :) Of course I'll welcome comments on this. > > P.S. It's time for a frontend... :) > Yes it is ;) -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2004-03-05 23:08:22
|
Es geschah am Freitag, 5. M=E4rz 2004 22:35 als Rui Nuno Capela schrieb: > Hi, > > > - I'm a bit disappointed about it's runtime efficiency > > In terms of code-path and resource efficiency, I humbly think that my raw > approach, based on strtok can't be beaten ;) I suggest we'll wait until we have a GUI so we can really test how it acts.= If=20 it performs really bad than we'll replace the parser by another solution, b= ut=20 I would still then use another parser generator instead of a hand crafted=20 parser implementation. Keep in mind that the current protocol (as defined i= n=20 the current, 4th draft) has only about perhaps 10% or less of the complexit= y=20 it will have in one or two years (e.g. think about the planned recompilatio= n=20 feature, all the modularity features...). And finally compare e.g. a Pascal= =20 compiler written in BNF with a hand crafted Pascal compiler. > > - Implemented LSCP network server (only single threaded so far, > > thus is only capable to handle one connection at one time), > > My liblscp code (http://www.rncbc.org/ls) has all this put together; is > multi-client and multi-threaded. Remember that you shall only code the > server-side callback function? > > OK. Now that some server code is already on linuxsampler I can dig it and > probably reimplement it using "my" liblscp approach :) The actual problem is not the server itself, but synchronization issues wit= hin=20 the engine and modifications that have to be done to the scanner when it=20 comes to more than one nework connections. Not a big deal either, but it=20 means work and I would rather spend the time in other things at the moment. Regarding efficiency of a multi threaded server I was thinking if a 0..n=20 threads solution would be good idea at all. It might be better to use a fix= ed=20 amount of threads (e.g. 10 for max. 10 fronteds simultaniously) _ALL_ start= ed=20 when LS is launched, then sending them all to sleep and just wake up one of= =20 them in case of a connection. This avoids memory allocation on runtime and= =20 avoids that our realtime thread might get in trouble. If you like to work on the multi-threaded extension of the server Rui, I wo= uld=20 appreciate that (less work for me ;) but I would definitely prefer you to= =20 work on a basic GUI first. We really lack some screenshots. ;) And one last thing: I would prefer to keep the server implemented in C++. Rui, if you like to checkin a new module to CVS (e.g. liblscp or your GUI),= =20 please let me know before you do it, because I have to set up a script on t= he=20 CVS server before. > > P.S. It's time for a frontend... :) > > Yes it is ;) That's what I wanted to hear! Now it's your turn! :) CU Christian |
|
From: Vladimir S. <ha...@so...> - 2004-03-06 05:45:10
|
Christian, Good stuff! I agree parser solution is suboptimal but i think it probably is good enough for now. ASCII protocol is also suboptimal, but i'm pretty sure it is worth it. BTW, some folks will argue that strcmp is also suboptimal and you must have hashtable(s) . . . Then again some folks will argue that C++ or C is suboptimal and you must write your parsers in assembly to have greater control over your pipelines and caches :))) We can always optimize parser later in case it ever becomes an issue. Engine stuff should be designed for performance from the very beginning, but parser doesn't really matter. I'll start implementing other commands then . . . Regards, Vladimir. Christian Schoenebeck wrote: >Changes: > > - Implemented parser for the LinuxSampler control protocol (LSCP) by > using flex / bison (where src/network/lscp.l is the input file for lex / > flex and src/network/lscp.y is the input file for yacc / bison). Parser and > scanner can be regenerated by 'make parser' (only necessary though if one > of the two input files where modified). > To be honest I'm not quite sure so far if this parser solution is a good > choice, especially because I'm a bit disappointed about it's runtime > efficiency (a main problem is that lexical analyzer and semantic analyzer > are separated which is a big disadvantage for the parser generator in > regards of optimization), but this lex/yacc soultion has the advantage > of defining the protocol on a higher level and is thus easier to maintain > in regards of a growing and possible complex protocol. We'll see... > If somebody's not familiar with lex/yacc, I can give an introduction to the > current LSCP implementation in a short mail if demanded. > If somebody has a suggestion for another parser generator, let me know! > > - Implemented LSCP network server (only single threaded so far, thus is only > capable to handle one connection at one time), LSCP server will be launched > if LinuxSampler was started with the new "--server" flag. So far I > implemented the following LSCP commands: > > * "LOAD INSTRUMENT" > * "GET CHANNEL VOICE_COUNT" > * "GET CHANNEL STREAM_COUNT" > * "GET CHANNEL BUFFER_FILL" > * "SET CHANNEL VOLUME" > * "RESET CHANNEL" > > In src/network/lscpserver.cpp there already all methods which will be > called in case of the respective network command. But most of them > currently just return a "ERR:0:Not implemented yet" error message, so these > methods need to be "wired" now with the engine and have to return a > meaningful response message. If anybody likes to implement one of those > methods I would appreciate that! (Vladimir perhaps?) > > - disk thread now started within the engine > >CU >Christian > >P.S. It's time for a frontend... :) > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > |
|
From: Rui N. C. <rn...@rn...> - 2004-03-06 11:18:44
|
Hi, Last night I've merged "my" liblscp (http://www.rncbc.org/ls) into linuxsampler code tree and made some tests on rewritting network/lscpserver.{h,cpp}, and apparentely things worked out fine. The biggest problem was, as always, adapting the autocrap stuff :) OK. My parser is still strcmp based FWIW, and tonight I'll try it to be functional, that is processing real LSCP commands. Chris, Vladimir, could you look into my code also? It boils down to applying the 'linuxsample-0.1-cvs20040305b.patch.gz' with 'patch -p1' and peek on lscpserver.cpp. On LSCPServer::server_callback member function is where all the action is (or would be). Maybe it wouldn't be a bad idea to fork an experimental branch on CVS. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Rui N. C. <rn...@rn...> - 2004-03-06 19:58:23
Attachments:
linuxsampler-0.1-cvs20040306b.patch.gz
|
Continuing from my last post, > > OK. My parser is still strcmp based FWIW, and tonight I'll try it to be > functional, that is processing real LSCP commands. > The latest patch (see http://www.rncbc.org/ls, or attached to this post) is almost complete. That is, it already maps to every LSCPServer method, although some of them aren't implemented yet. This makes it on par of current "official" linuxsampler CVS, but patched to use "my" liblscp stuff for the server-side of the linuxsampler control protocol. Chris, Vladimir, forgive me if I seem to rush you, but could you check this out and comment on this? Whenever you get the time, of course. Why I'm rushing you? 'Coz it's GUI time ;) Happy weekend. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Vladimir S. <ha...@so...> - 2004-03-07 06:47:58
|
Hi Rui, I think you may need to add liblscp.a as part of "all" in liblscp/Makefile. Otherwise only .so is built and make failes when trying to link. But more importantly . . . I sort of agree with Christian that a hand crafted parser might not be the best fit for this application. Having said that, i also believe that parser is not that important and we could easily replace it later with another one that will call the same callbacks. So as long as we've written those callbacks we should be OK no matter what the parser looks like. I'll just try to write a few callbacks here and there and let you guys sort out your design differences (as far as hand crafted parser, yacc/bison or any other solution you see fit). Or . . . if you want me to participate in this discussion then just let me know and i'll be at your service :) Short summary of my position is: Parsers may be less efficient, but they make code much easier to maintain and enhance. Hand crafted code may be more efficient, but strcmp isn't the most efficient solution (if by efficient we mean runtime speed). Regards, Vladimir. Rui Nuno Capela wrote: >Continuing from my last post, > > > >>OK. My parser is still strcmp based FWIW, and tonight I'll try it to be >>functional, that is processing real LSCP commands. >> >> >> > >The latest patch (see http://www.rncbc.org/ls, or attached to this post) >is almost complete. That is, it already maps to every LSCPServer method, >although some of them aren't implemented yet. > >This makes it on par of current "official" linuxsampler CVS, but patched >to use "my" liblscp stuff for the server-side of the linuxsampler control >protocol. > >Chris, Vladimir, forgive me if I seem to rush you, but could you check >this out and comment on this? Whenever you get the time, of course. > >Why I'm rushing you? 'Coz it's GUI time ;) > >Happy weekend. >-- >rncbc aka Rui Nuno Capela >rn...@rn... > > |
|
From: Rui N. C. <rn...@rn...> - 2004-03-07 15:59:18
|
Hi Vladimir, > > I think you may need to add liblscp.a as part of "all" in > liblscp/Makefile. Otherwise only .so is built and make failes > when trying to link. > I guess you're talking about the Makefile that's included with liblscp source tarball. By applying my patch you'll get all liblscp source files under src/network/liblscp and linuxsampler statically linked with liblscp.a. Of course, all relevant automake files are also patched to this effect, so the original liblscp Makefile is completely overriden on configure. Have you tried the patch? To make it easier, these are straight steps: LS_CVSROOT=:pserver:ano...@cv...:/home/schropp/linuxsampler cvs -z3 -d$LS_CVSROOT export -r HEAD linuxsampler cd linuxsampler gzip -dc ../linuxsampler-0.1-cvs20040306b.patch.gz | patch -p1 make -f Makefile.cvs ./configure make Then run it... src/linuxsampler --server --gig /path/to/yourfile.gig You build the stand-alone test client separatelly: tar -zxvf liblscp-0.0.6.tar.gz cd liblscp-0.0.6 make Run it right away: LD_LIBRARY_PATH=. ./lscp_client_test There you can enter LSCP commands and communicate to current running server (linuxsampler). Enter command like this: lscp_client> RESET CHANNEL 0 lscp_client> SET CHANNEL VOLUME 0 0.5 lscp_client> LOAD INSTRUMENT /path/to/another/file.gig 0 0 Hope you enjoy. > > But more importantly . . . I sort of agree with Christian that a hand > crafted parser might not be the best fit for this application. Having > said that, i also believe that parser is not that important and we could > easily replace it later with another one that will call the same > callbacks. Yes, that's my idea too. For the current specification of LSCP the simple and raw approach is quite enough, and it works too ;) > So as long as we've written those callbacks we should be OK no matter > what the parser looks like. > I'll just try to write a few callbacks here and there and let you guys > sort out your design differences (as far as hand crafted parser, > yacc/bison or any other solution you see fit). > Guess that the priority now are those LSCPServer methods that aren't currently implemented, that map directly to each LSCP command. Everything else is already handled by liblscp. > Or . . . if you want me to participate in this discussion then just let > me know and i'll be at your service :) Short summary of my position is: > Parsers may be less efficient, but they make code much easier to > maintain and enhance. Hand crafted code may be more efficient, but > strcmp isn't the most efficient solution (if by efficient we mean > runtime speed). > OK. See you then. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Vladimir S. <ha...@so...> - 2004-03-07 19:01:02
Attachments:
testlscp
|
Hi Rui, >Yes, that's my idea too. For the current specification of LSCP the simple >and raw approach is quite enough, and it works too ;) > > But . . . bison also works and it is easier to maintain :) Could you give me a quick summary of why you dislike bison? I wrote a simple netcat script to test the parser (attached) and i'm having some issues with your parser, while bison generated code appears to be working correctly. First of all, netcat gets stuck after first command. So my script is not working and i have to input command manually. Then some specific commands didn't work correctly: GET CHANNELS GET AVAILABLE_ENGINES SET CHANNEL AUDIO_OUTPUT_TYPE QUIT Regards, Vladimir. |
|
From: Rui N. C. <rn...@rn...> - 2004-03-07 20:55:32
|
Vladimir, >> > But . . . bison also works and it is easier to maintain :) > Could you give me a quick summary of why you dislike bison? > Yeah I know, but I don't have a clue about all that bison/flex/yacc stuff. I know the principles and theory but completely lack in the practice. > I wrote a simple netcat script to test the parser (attached) and i'm > having some issues with your parser, while bison generated code appears > to be working correctly. Hmm. If I may put this way, that's not a parser question but a network protocol one, AFAICT. On liblscp, each command must be isolated on each send/recv exchange and does not rely on being CR/LF terminated, which I think is an "undocumented" feature of the bison one :) I think netcat sends the whole buffer of commands in one send(), and that is not accepted on liblscp (probably only the first line is). AFAICT the protocol draft doesn't mention that we can send more than one command, as CRLF delimited lines. IIUC, the bison implementation does, as it parses a whole multi-line buffer, which I think is not conformant with the draft, although both were written by the same author ;) If you send each command at a time, liblscp works as well but still not equivalent with Chris' original one. OTOH, the parsing code used on the liblscp version is not complete nor thoroughly tested (e.g the ADD CHANNEL command isn't being recognized at the time of this writing, same happens with other commands that have no parameters). Many thanks for the feedback. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2004-03-07 22:41:59
|
Es geschah am Sonntag, 7. M=E4rz 2004 21:37 als Rui Nuno Capela schrieb: > Vladimir, > > > But . . . bison also works and it is easier to maintain :) > > Could you give me a quick summary of why you dislike bison? > > Yeah I know, but I don't have a clue about all that bison/flex/yacc stuff. > I know the principles and theory but completely lack in the practice. As already said, I can give a short introduction if anybody's interested,=20 constrained to the things we actually need. It's really simple. > > I wrote a simple netcat script to test the parser (attached) and i'm > > having some issues with your parser, while bison generated code appears > > to be working correctly. > > Hmm. If I may put this way, that's not a parser question but a network > protocol one, AFAICT. On liblscp, each command must be isolated on each > send/recv exchange and does not rely on being CR/LF terminated, which I > think is an "undocumented" feature of the bison one :) Undocumented? src/network/lscp.y is the LSCP definition, given in Backus-Na= ur=20 =46orm (BNF), which is commonly used in all protocol definition documents (= e.g.=20 HTTP) and many file format references, so this file _is_ a document and fro= m=20 lscp.y: input : line | input LF line | input CR LF line ; > I think netcat sends the whole buffer of commands in one send(), and that > is not accepted on liblscp (probably only the first line is). AFAICT the > protocol draft doesn't mention that we can send more than one command, as Page 3 from the LSCP document: "The frontend application establishes a TCP connection to the LinuxSampler= =20 instance on a certain host system. Then the frontend application will send= =20 certain ASCII based commands" But you're right. It's not clear enough. I will fix that. That was an impli= ed=20 assumption fault by me, because usually network protocols allow this multi= =20 line behavior, because it doesn't make sense to establish a new connection= =20 for every single network command. CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2004-03-07 23:29:33
|
Hi Christian, > > But you're right. It's not clear enough. I will fix that. That was an > implied assumption fault by me, because usually network protocols allow > this multi line behavior, because it doesn't make sense to establish a > new connection for every single network command. > It's not a question of just allowing multi-line/command or not, is also that "feature" that whether every command must be CRLF terminated. On my recent tests, your bison-based parser only recognizes a command if there's a CRLF terminator. If one's missing, you do nothing, don't even respond to a client that issues a single command but without terminating it with CRLF. It was this "undocumented" behaviour that I was referring to. Cheers, -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Rui N. C. <rn...@rn...> - 2004-03-08 11:26:42
|
Hi Christian, >> >> But you're right. It's not clear enough. I will fix that. That was an >> implied assumption fault by me, because usually network protocols allow >> this multi line behavior, because it doesn't make sense to establish a >> new connection for every single network command. >> > > It's not a question of just allowing multi-line/command or not, is also > that "feature" that whether every command must be CRLF terminated. > > On my recent tests, your bison-based parser only recognizes a command if > there's a CRLF terminator. If one's missing, you do nothing, don't even > respond to a client that issues a single command but without terminating > it with CRLF. > > It was this "undocumented" behaviour that I was referring to. > To make myslef a little bit more clear, about this behavioral issue: Current linuxsampler server does NOT respond as soon as a valid syntax command is received. For example, when a client sends just "ADD CHANNEL", the server seems to wait for an additional character before it responds. If otherwise the client sends "ADD CHANNEL\n", the server recognizes the command properly and responds right away. In fact, it ONLY responds when any other character is present, not necessarily "\n". Again, if a client only sends e.g. "GET CHANNELS" and nothing more, it will hang forever for a reply that will never arrive. Think this is wrong. My suggestion is either: 1) fix the server parser to reply immediately as soon a valid command is detected, OR 2) make that LF/CR+LF command terminator officially part of the command protocol, at least for client request strings. I do prefer the first solution, as it complies by default with the current LSCP document draft (rev.03), but can surely live with second if it's made "official" :) Please note that my complaint is not about whether the server can handle more that one command in a batch or single tcp transaction. That's fine with me, although liblscp was primarily designed with a single-command-per-transaction semantics in mind. Note that current liblscp does not make a new connection on each command. It connect()'s, then for each command transaction a send() and recv() sequence pair is performed. The session would be only close()'d when the client is done. OTHO, the problem with Vladimir's netcat test was that several commands were being buffered and stuffed in one send(), for which the latest liblscp patched linuxsampler version does not work -- my LSCPServer::server_callback was designed to handle and parse only one command buffer at a time. That can be changed of course. And I will try to comply to it. Chris, I'm willing to devel into your bison/yacc nightmare :) I'm still insisting in patching liblscp into the linuxsampler server, but this time using the bison based parser. Yes, I'm telling you that I can get rid of my handcrafted-pseudo-parser but sticking with liblscp. So, as a first timer, I wish to make liblscp's oriented LSCPServer::server_callback() to pump all received data into your parser. Note that this callback is called whenever the server recv()'s data from the client. No translation is done to the data between recv() and the callback. A session handle that uniquely identifies a client, is also given on each callback, which shall be used when responding back to the client, so it must be preserved along the whole parsing. Now we've got an emerging problem: if we expect to have several clients simultaneously, together with support for multi-line/command buffering, we must preserve the parser state between each callback (or recv() for that matter). That makes for the server maintaining a pool of parser instances, one instance for each client connection and identified by an opaque connection handle? OK. Why I'm in insisting on liblscp? Mainly 'coz of reusability and it already does multi-client, multi-threading and also because the UDP event notification stuff is already there too: you have only to call lscp_server_broadcast() when an change event pops up, liblscp takes care of all the rest ;) Hope to have made my position clear. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... P.S. Chris I'll try to be on IRC this afternoon and/or evening. |
|
From: Vladimir S. <ha...@so...> - 2004-03-08 14:56:09
|
Hi Rui, Christian, I think we should rely on line termination rather than the fact that someone does one send() or several. Think about eventually proxying those connections, all kinds of automation, etc, etc. And of course connection should be kept up for as long as client needs it. I think liblscp (or server part of it) needs to be merged with bison parser in some way and checked in at some point. I'm up for testing and writing callbacks. When some of these callbacks are complete I was thinking about creating a test setup driven by an expect script where test gigs could be loaded, LS and JACK could be configured such that the output be recorded into a file, some sort of midi over network driver be loaded, LS be connected to it, midi commands be sent into LS and then output files be stored and some sort of QA be done on those files. In other words, we should be able to automate EG testing, etc. test gigs should be perhaps generated but I don't think we currently have support for that in libgig . . . Regards, Vladimir. -----Original Message----- From: lin...@li... [mailto:lin...@li...] On Behalf Of Rui Nuno Capela Sent: Monday, March 08, 2004 6:10 AM To: lin...@li... Subject: Re: [Linuxsampler-devel] Lates CVS commit Hi Christian, >> >> But you're right. It's not clear enough. I will fix that. That was an >> implied assumption fault by me, because usually network protocols >> allow this multi line behavior, because it doesn't make sense to >> establish a new connection for every single network command. >> > > It's not a question of just allowing multi-line/command or not, is > also that "feature" that whether every command must be CRLF > terminated. > > On my recent tests, your bison-based parser only recognizes a command > if there's a CRLF terminator. If one's missing, you do nothing, don't > even respond to a client that issues a single command but without > terminating it with CRLF. > > It was this "undocumented" behaviour that I was referring to. > To make myslef a little bit more clear, about this behavioral issue: Current linuxsampler server does NOT respond as soon as a valid syntax command is received. For example, when a client sends just "ADD CHANNEL", the server seems to wait for an additional character before it responds. If otherwise the client sends "ADD CHANNEL\n", the server recognizes the command properly and responds right away. In fact, it ONLY responds when any other character is present, not necessarily "\n". Again, if a client only sends e.g. "GET CHANNELS" and nothing more, it will hang forever for a reply that will never arrive. Think this is wrong. My suggestion is either: 1) fix the server parser to reply immediately as soon a valid command is detected, OR 2) make that LF/CR+LF command terminator officially part of the command protocol, at least for client request strings. I do prefer the first solution, as it complies by default with the current LSCP document draft (rev.03), but can surely live with second if it's made "official" :) Please note that my complaint is not about whether the server can handle more that one command in a batch or single tcp transaction. That's fine with me, although liblscp was primarily designed with a single-command-per-transaction semantics in mind. Note that current liblscp does not make a new connection on each command. It connect()'s, then for each command transaction a send() and recv() sequence pair is performed. The session would be only close()'d when the client is done. OTHO, the problem with Vladimir's netcat test was that several commands were being buffered and stuffed in one send(), for which the latest liblscp patched linuxsampler version does not work -- my LSCPServer::server_callback was designed to handle and parse only one command buffer at a time. That can be changed of course. And I will try to comply to it. Chris, I'm willing to devel into your bison/yacc nightmare :) I'm still insisting in patching liblscp into the linuxsampler server, but this time using the bison based parser. Yes, I'm telling you that I can get rid of my handcrafted-pseudo-parser but sticking with liblscp. So, as a first timer, I wish to make liblscp's oriented LSCPServer::server_callback() to pump all received data into your parser. Note that this callback is called whenever the server recv()'s data from the client. No translation is done to the data between recv() and the callback. A session handle that uniquely identifies a client, is also given on each callback, which shall be used when responding back to the client, so it must be preserved along the whole parsing. Now we've got an emerging problem: if we expect to have several clients simultaneously, together with support for multi-line/command buffering, we must preserve the parser state between each callback (or recv() for that matter). That makes for the server maintaining a pool of parser instances, one instance for each client connection and identified by an opaque connection handle? OK. Why I'm in insisting on liblscp? Mainly 'coz of reusability and it already does multi-client, multi-threading and also because the UDP event notification stuff is already there too: you have only to call lscp_server_broadcast() when an change event pops up, liblscp takes care of all the rest ;) Hope to have made my position clear. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... P.S. Chris I'll try to be on IRC this afternoon and/or evening. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Linuxsampler-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Rui N. C. <rn...@rn...> - 2004-03-08 15:16:14
|
Chris, Vladimir, I'm facing a problem with this yacc/bison monster: How do you think we can feed the parser with input from a callback? I know that the redefined YYINPUT macro is the place to look, but it does not seem to accomodate the callback model, at least directly. I'm affraid that double-buffering is one solution, or using a pipe maybe another one. What do you think and hopefully suggest? -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2004-03-08 21:55:03
|
Hi Rui, hi Vladimir! I reply to your mails together in one... Am Montag, 8. M=E4rz 2004 12:09 schrieb Rui Nuno Capela: > Current linuxsampler server does NOT respond as soon as a valid syntax > command is received. > > For example, when a client sends just "ADD CHANNEL", the server seems to > wait for an additional character before it responds. > > If otherwise the client sends "ADD CHANNEL\n", the server recognizes the > command properly and responds right away. In fact, it ONLY responds when > any other character is present, not necessarily "\n". The parser waits until the command line is terminated, this can either be=20 "\r\n" or "\n" or EOF, thus if you just send "ADD CHANNEL", the parser=20 actually calls the AddChannel() function when you close the network=20 connection. You will see that on server side when you increment the debug=20 level. But to solve this misapprehension now once and forever; every command line= =20 should be CRLF terminated. I updated the protocol document therefore today. > Chris, I'm willing to devel into your bison/yacc nightmare :) I'm still > insisting in patching liblscp into the linuxsampler server, but this time > using the bison based parser. Yes, I'm telling you that I can get rid of > my handcrafted-pseudo-parser but sticking with liblscp. Why do you think bison is a nightmare? Of course, things you are not used t= o=20 are always less convenient than things you know, but you will see that this= =20 solution is pretty simple, very easy to maintain and it will definitely pay= =20 off when this protocol grows in complexity. Regarding your liblscp code migrating on server side, these are the issues = I'm=20 complaining about: a) I'm against a hand-crafted parser. b) There should be a fixed amount of threads, created on application start = and awaken as needed, instead of creating a new one on every client connecti= on. c) I don't want to see client code in the LS codebase. d) I prefer the server side completely to be implemented in C++. Regarding c) and d) I suggest to split liblscp into two parts, so liblscp j= ust=20 contains the client side and will be commited into CVS as separate module,= =20 whereas the server side goes directly into the LS codebase. I really don't= =20 want to blow the LS codebase with code we don't need in the LS engine anywa= y.=20 There's only one file that should be shared by liblscp (the client side) an= d=20 the server side in LS: one header file containing defines for warning and=20 error codes (currently meant to be the empty file src/network/lscp.h). The= =20 last point d) is of course more a matter of taste, but as the whole=20 application is written in C++, I also like the server to be and it should=20 take you only a couple of minutes to refactor your server code from C to C+= +. If you'll solve these four issues, than I'm very happy to accept your=20 solution. Am Montag, 8. M=E4rz 2004 15:39 schrieb Vladimir Senkov: > In other words, we should be able to automate EG testing, etc. test gigs > should be perhaps generated but I don't think we currently have support > for that in libgig . . . It's not currently. It would perhaps take about 2 - 4 days to extend the li= b=20 so it's also capable to create and edit .gig files. I thought about it, but= I=20 don't think it's important at the moment. Am Montag, 8. M=E4rz 2004 15:58 schrieb Rui Nuno Capela: > How do you think we can feed the parser with input from a callback? I know > that the redefined YYINPUT macro is the place to look, but it does not > seem to accomodate the callback model, at least directly. That's one of the points why I left the server single threaded. As it's not= on=20 my priotity list, I haven't really looked into this subject, but there is o= ne=20 solution that comes to my mind: a fifo, then we can even completely drop to= =20 override YY_INPUT and just set the input file descriptor to the fifo (inste= ad=20 of the standard one, which is stdin). We should research for other solution= s,=20 I don't think we're the first ones using flex/bison within a network server. CU Christian |
|
From: Vladimir S. <ha...@so...> - 2004-03-08 00:19:25
Attachments:
lscp1.patch.gz
|
Here is a patch with a few more callbacks: GetAvailableEngines() GetEngineInfo() GetChannelInfo() (except for OUTPUT_CHANNEL and INPUT_CHANNEL) I've also fixed a bug that i've previously put in --alsa_output command line processing. I've noticed that ls consistenly crashes if: 1) i try to load a gig and fail (no file found) 2) i reset the channel 3) i try to play something on the keyboard. Unfortunately, i can't open the corefile . . . gdb crashes :( I'll try to figure this out later. I've also noticed that output from GetBufferFill often prints out empty lines. I'll keep looking into implementing other commands. This weekend was busy and i couldn't do much but hopefully next weekend will be better. Regards, Vladimir. Christian Schoenebeck wrote: >Changes: > > - Implemented parser for the LinuxSampler control protocol (LSCP) by > using flex / bison (where src/network/lscp.l is the input file for lex / > flex and src/network/lscp.y is the input file for yacc / bison). Parser and > scanner can be regenerated by 'make parser' (only necessary though if one > of the two input files where modified). > To be honest I'm not quite sure so far if this parser solution is a good > choice, especially because I'm a bit disappointed about it's runtime > efficiency (a main problem is that lexical analyzer and semantic analyzer > are separated which is a big disadvantage for the parser generator in > regards of optimization), but this lex/yacc soultion has the advantage > of defining the protocol on a higher level and is thus easier to maintain > in regards of a growing and possible complex protocol. We'll see... > If somebody's not familiar with lex/yacc, I can give an introduction to the > current LSCP implementation in a short mail if demanded. > If somebody has a suggestion for another parser generator, let me know! > > - Implemented LSCP network server (only single threaded so far, thus is only > capable to handle one connection at one time), LSCP server will be launched > if LinuxSampler was started with the new "--server" flag. So far I > implemented the following LSCP commands: > > * "LOAD INSTRUMENT" > * "GET CHANNEL VOICE_COUNT" > * "GET CHANNEL STREAM_COUNT" > * "GET CHANNEL BUFFER_FILL" > * "SET CHANNEL VOLUME" > * "RESET CHANNEL" > > In src/network/lscpserver.cpp there already all methods which will be > called in case of the respective network command. But most of them > currently just return a "ERR:0:Not implemented yet" error message, so these > methods need to be "wired" now with the engine and have to return a > meaningful response message. If anybody likes to implement one of those > methods I would appreciate that! (Vladimir perhaps?) > > - disk thread now started within the engine > >CU >Christian > >P.S. It's time for a frontend... :) > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > |
|
From: Vladimir S. <ha...@so...> - 2004-03-08 01:21:38
|
jfyi, I was able to get rid of gdb crashes by rebuilding ls with -O0. I have a total of two cores: 1) RESET after failing to load .gig file. (pInstrument was NULL when RenderAudio() was running. My understanding was that RenderAudio() should not have been called since instrument loading failed, so this should be simple to fix) 2) core when running out of voices (i think this started happening after last EG changes, looks like Stream object got corrupted when RenderAudio() was running. pRingBuffer is bad) Both cores are reproducible. I'll look into both of them next weekend, unless you guys happen to figure them out by then. Regards, Vladimir. Vladimir Senkov wrote: > Here is a patch with a few more callbacks: > GetAvailableEngines() > GetEngineInfo() > GetChannelInfo() (except for OUTPUT_CHANNEL and INPUT_CHANNEL) > I've also fixed a bug that i've previously put in --alsa_output > command line processing. > > I've noticed that ls consistenly crashes if: > 1) i try to load a gig and fail (no file found) > 2) i reset the channel > 3) i try to play something on the keyboard. > Unfortunately, i can't open the corefile . . . gdb crashes :( I'll try > to figure this out later. > > I've also noticed that output from GetBufferFill often prints out > empty lines. > > I'll keep looking into implementing other commands. This weekend was > busy and i couldn't do much but hopefully next weekend will be better. > > Regards, > Vladimir. > > > Christian Schoenebeck wrote: > >> Changes: >> >> - Implemented parser for the LinuxSampler control protocol >> (LSCP) by >> using flex / bison (where src/network/lscp.l is the input file >> for lex / >> flex and src/network/lscp.y is the input file for yacc / >> bison). Parser and >> scanner can be regenerated by 'make parser' (only necessary >> though if one >> of the two input files where modified). >> To be honest I'm not quite sure so far if this parser solution >> is a good >> choice, especially because I'm a bit disappointed about it's >> runtime >> efficiency (a main problem is that lexical analyzer and >> semantic analyzer >> are separated which is a big disadvantage for the parser >> generator in >> regards of optimization), but this lex/yacc soultion has the >> advantage >> of defining the protocol on a higher level and is thus easier >> to maintain >> in regards of a growing and possible complex protocol. We'll >> see... >> If somebody's not familiar with lex/yacc, I can give an >> introduction to the >> current LSCP implementation in a short mail if demanded. >> If somebody has a suggestion for another parser generator, let >> me know! >> >> - Implemented LSCP network server (only single threaded so far, >> thus is only >> capable to handle one connection at one time), LSCP server will >> be launched >> if LinuxSampler was started with the new "--server" flag. So far I >> implemented the following LSCP commands: >> >> * "LOAD INSTRUMENT" >> * "GET CHANNEL VOICE_COUNT" >> * "GET CHANNEL STREAM_COUNT" >> * "GET CHANNEL BUFFER_FILL" >> * "SET CHANNEL VOLUME" >> * "RESET CHANNEL" >> >> In src/network/lscpserver.cpp there already all methods which >> will be >> called in case of the respective network command. But most of them >> currently just return a "ERR:0:Not implemented yet" error >> message, so these >> methods need to be "wired" now with the engine and have to >> return a >> meaningful response message. If anybody likes to implement one >> of those >> methods I would appreciate that! (Vladimir perhaps?) >> - disk thread now started within the engine >> >> CU >> Christian >> >> P.S. It's time for a frontend... :) >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Linuxsampler-devel mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel >> >> > |
Thanks for helping keep SourceForge clean.
X