> > If it is possible, can you guys settle details about linker communication > > (and probably finish it)? We can integrate both projects then. > > I didn't know about Peter's ld10k1 existence, but it seems to be what I thought > initially of emufxtool, before starting to improve the assembly/disassembly core and > the file format. > > I think it is a good idea, at least there will not duplicated code and, if I > understand correctly, emufxtool might use ld10k1 as a "backend" to load patches onto > the DSP. > > I am just downloading ld10k1 from sf. Will take more than a look at that.
I took a look at ld10k1/lo10k1. Its architecture is well thought and offers lots of possibilities. I can remove from emufxtool the "direct" access to the driver by IOCTL and use the pipe to communicate to ld10k1 server. Before doing that, maybe we should define well the "communication protocol" between clients and server, as suggested by Jaroslav. This system solves also the problem of multiple patch loading and code relocation, which my emufxtool solves at compile time (to use more than one patch you have to compile and load them as a whole). The same method could be used by the disassembler code to fetch DSP content (or loader server-side DSP "images"). The next step could be a MIDI based loader, that allows you to store/fetch patches using SYSEX messages sent to /dev/sequencer or alsa midi virtual ports, or anything else (a new device that replaces the pipe?), maybe requiring some work on the modules... (Not a choice I can make, anyway...) I ignore if Peter Zubaj can receive this message, but I think it would be a good idea if we merged our projects into a single one ( : ). A good start may be the definition of the "protocol" above. The protocol can be "message based", each "message" may be defined, for instance, by primitive types and surrounded by a header/footer standard pair (containing a message id, the length of the message, and something like a checksum to avoid "garbage"). Client and server "speak" through a sequence of "Request"/"Response" message pairs, usually initiated and closed by the client. I.E. Message: SET PATCH Offset Length (in bytes) Type Value 0 2 unsigned short (*) 0004 (ID_SET_PATCH) 2 4 unsigned (*) total length of message 6 30 character string name of the patch 36 2 unsigned short (*) number of DSP instr. .... length+36 4 unsigned checksum (*) endianness to be defined and so on... -- Ciao, Nicola -------------------------------------------------------------------- * Nicola Orru' - Via Dei Tulipani, 9 - 09034 Assemini (CA) - ITALY * -------------------------------------------------------------------- ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
