1
------------------------------------------------------------------------
4
(edi-27): NetECI - network interface for controlling ecasound operation.
5
- submitted: kaiv, 28.06.2002
6
- done: kaiv, 31.10.2002
8
------------------------------------------------------------------------
12
- current ecasound frontends are not good at giving real-time
13
status information; using separate monitor clients could
15
- list of goals/requirements that should be reached
16
- to allow control of an ecasound session from multiple
17
indepedent client instances
18
- functionality available to clients equivalent to
22
- see screenshot at...
23
http://www.eca.cx/screenshots/ecasound-2.2.0-pre4_neteci_ecamonitor.png
25
------------------------------------------------------------------------
26
[kaiv on ecasound-list, 28.06.2002]
30
NetECI is a slightly modified version of the ECI API that allows
31
applications to communicate with remote ecasound sessions. The
34
(machine-1) (machine-3)
35
'NetECI App A' <-- TCP/IP --> 'ecasound -c --daemon'
38
'NetECI App B' <-- TCP/IP ---------|
42
The only required API change is extending the init function. So instead of
43
'eci_init(void)' you'd have 'neteci_init(const char* hostname, int port)'.
44
The NetECI library will handle all the network communication. App using
45
NetECI can just issue EIAM commands as usual and not worry about the
46
implementation details.
50
NetECI is really just a RPC-version (remote procedure call, or
51
remote-invocation (RMI) for you java-men) of ECI. I could use any of the
52
numerous available RPC mechanisms (Sun's RPC, CORBA, SOAP, KDE's DCOP,
53
GNOME's Bonobo, XML-RPC, etc, etc) for the implementation, but I'm pretty
54
certain won't. Instead the protocol will be a straightforward, text-based
55
protocol using TCP/IP or UNIX-sockets. I can once again reuse the EIAM
56
parser code in libecasound and use it this time as a protocol parser. This
57
way there's really not that much new code for me to write.
59
One interesting thing is that it will be quite easy to write a native
60
implementation of the NetECI client side in perl, python, C, java, etc.
61
You just need to handle the TCP/IP communication with the ecasound daemon
62
and that's it, no need to link against libecasound or install glue-code
63
like pyeca. Of course, using the C++ NetECI implementation would still be
66
The protocol itself will probably be a request-response system, where the
70
<eiam-command> <arg1,...,argN><crlf>
76
<return-code> <type> <return-value>
79
So extremely simple. One possible problem is bandwidth usage, so I don't
80
want to make the protocol overly complex. Any comments?
82
------------------------------------------------------------------------
83
[kaiv on ecasound-list, 30.06.2002]
85
First version of the NetECI daemon code is now in the CVS.
86
There's also a simple client program written in python
87
in the examples directory (netecimonitor.py). To test it out:
90
ecasound -c --daemon -i foo.wav -o alsa -ea:100 -kl:1,80,120,0.2
96
You should get a status screen of ecasound operation that is updated once
97
a second. You can exit and restart the ecasound instance and
98
netecimonitor will try to reconnect automatically to the new server
99
instance. If you run ecasound without --daemon, everything works like
102
NetECI binds to the TCP port 2868 and is able to handle multiple clients
103
at the same time. While it does work, the server currently crashes once in
104
a while for some unknown reason. I suspect there're problems in the
105
multithread locking code.
107
------------------------------------------------------------------------
b'\\ No newline at end of file'
added
removed
Documentation/archived/edi-27.txt
