This part is general in the sense that it teaches you on what it needs to integrate the Chimaera into your setup, but does not tell you how and therefore is platform independent.
Networks and Firewalls
In order that the Chimaera can talk to your host and your host can talk to the Chimaera, the IP of the Chimaera has to be whitelisted in the firewall settings of your host and the Chimaera has to know where to send its messages to.
Whitelisting the IP of the Chimaera can be done in different ways. On one hand, you can give the Chimaera an arbitrary IP (or just use the default one which is 192.168.1.177) and specifically whitelist it so that all messages coming from this IP are not blocked. On the other hand, you can integrate the Chimaera into your local network by assigning it an IP that will be recognized as a valid IP of the local network for which traffic has previously been unblocked in your firewall settings.
The IP of the Chimaera and the IP of the host the Chimaera sends its messages to, can be changed by means of the configuration system.
The Chimaera can send its touch messages timestamped, so you exactly know when a specific message has been created/transmitted by the Chimaera (this is important when sending the messages over complex networks where messages may get lost or misordered and to generally prevent jitter by postponing the dispatching of the messages at the host). But timestamped messages only make sense when the source and destination of the communication path refer to the same time in the first place. If you want to make use of timestamped messages (you don’t have to, of course), the Chimaera therefore needs to synchronize its time with the one of time master.
The Chimaera offers two means of time synchronization to a time master, via the network time protocol for coarse resolution synchronization at low sensor update rates and via precision time protocol for fine resolution synchronization at high sensor update rates.
Network time protocol
The problem of synchronizing two devices over network has long since been solved by the network time protocol (NTP). The Chimaera can make use of it, too. However, there is no need to run a fully fledged NTP client on the Chimaera, the simplified network time protocol (SNTP) is enough for our application. The SNTP client on the Chimaera can be enabled or disabled by means of the configuration system. In order for it to work properly, you need to tell the Chimaera the IP address of a host that runs a NTP daemon. The Chimaera then will send SNTP requests to the server at a configurable rate (e.g. 4 seconds by default), wait for the answer and synchronize its clock to the server.
The server which runs the NTP daemon may be the same host the Chimaera sends its messages to, or it may be an other server on the LAN which both the Chimaera and the host synchronize time with.
NTP has been designed for synchronizing devices across the internet down to a few milliseconds at best. The Chimaera sends SNTP requests at high rates and can synchronize to a nearby time master down to a 10th millisecond at best. Synchronization via SNTP therefore is only recommended for low sensor update rates of the Chimaera, e.g. up to 1-1.5 kHz.
Precision time protocol
For higher sensor update rates, e.g. 1.5-3 kHz, there is a need for a more accurate means of synchronization down to a few dozen microseconds at least. The Chimaera can be synchronized via the precision time protocol (PTPv2), aka IEEE 1588-2008, to a master timebase on a local area network.
PTP is relatively new (2002) compared to NTP and was developed to synchronize e.g. measurement equipment across a local area network. PTP of course also excels at networked audio. For its much better performance compared to NTP, we recommend it as the method of choice to synchronize the Chimaera to a time master (e.g. the machine your software synthesizer runs on).
That’s all to get the Chimaera communicate with your setup - driverlessly, so to speak.
This part is specifically about the setup on Linux and BSD. In a great part this can be adapted to other Unix flavors, too (e.g. OS X).
The Chimaera has its own IP address and needs to be incorporated into your local network. So you have to make sure that the Chimaera is not blocked by a firewall and that the various ports used for communication are open (at least for the Chimaera). The default IP of the Chimaera is 192.168.1.177. In order to receive data from the Chimaera, you have to enable communication from and to that specific address, or an address space where the Chimaera’s IP falls into, e.g. you can define a LAN with addresses 192.168.1.0 - 192.168.1.255 and whit-list it in your firewall configuration.
If you don’t run an Avahi daemon (or don’t want to run one), you may want to add the following line to your /etc/hosts, so your system knows the Chimaera and you can just use its alias instead of its IP when establishing connections with it.
By default, the Chimaera is running a mDNS (multicast DNS) responder. So if you have Avahi running (and did not disable the mDNS responder on the device), the Chimaera will be known as #name#.local on the local network, whereas #name#=chimaera by default, e.g. chimaera.local. You can send a ping to check for a connection.
Ping the factory-set IP
$ ping 192.168.1.177
Ping the alias (resolve via /etc/hosts)
$ ping chimaera
Ping on .local domain (resolve via Avahi/mDNS)
$ ping chimaera.local
On Linux, you definitely want to use PTP for synchronization. If you happen to have a system that supports hardware timestamping (becoming the norm for new network interfaces), you want to go with linuxptp. If you only look for a software PTP implementation, you can do with linuxptp, too or use ptpd, which also supports other POSIX systems.
PTP communication takes place over multicast, to enable the Chimaera as PTP slave and configure it, you can use the configuration system via /ptp/enabled, /ptp/multiplier, /ptp/offset_stiffness and /ptp/delay_stiffness .
To get a NTP daemon up and running on Linux is simple, just install the corresponding package and optionally enable it in your init system so it starts at boot. But you may have to enable the request handling for a given set of IP’s. By adding the following line to your NTP daemon configuration file (/etc/ntp.conf), you’re NTP server is enabled to answer NTP requests from IP addresses 192.168.1.0 - 192.168.1.255.
/etc/ntp.conf ------------- . . restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap . .
As OS/X is a BSD/Unix derivate, most things said about the latter two should be applicable analogously.
As we never have, do not currently and never ever will call an Apple product our own, we cannot give detailed explanations on steps needed to configure firewall, NTP server, PTP time master, Bonjour services and process thread scheduling. Please refer to the manuals.
A standard setup of Windows will most probably be worse at networking than Linux/BSD/OS X affecting latency of the Chimaera to host connection. Windows always tries (and sometimes fails) to be smart, e.g. it may throttle its networking through-put while running audio/video applications which is really bad if audio is sent over and/or controlled via the network as in the case of the Chimaera, obviously. Windows' soft real-time capabilities are not accessible to the user which makes tuning of process thread priorities a non-option, either.
So, the one thing that can be done from a user perspective to get the best out of the system is to change registry entries to boost network performance and disable network throttling in audio setups. Tools exist that do that for you. They were created for real-time networked games to solve the identical issues as in our case, e.g. to have low-latency networking with concurrent low-latency audio and video. Hence, it may be best to look up the needed tricks on gaming sites.
Adding the right rules to the firewall settings should be straight forward. You may want to use a fixed IP or the MAC address of the Chimaera or define a trusted IP range, the device will be part of. Consult the manual of your firewall software.
You will have to look far to find any hardware support for PTP on windows and windows lacks the needed real-time capabilities for a robust software implementations in the first place. Most probably you will have to fall back to NTP or do without timestamping altogether when using the Chimaera on windows, which is no problem per-se.
There is an open-source NTP server available for windows at timesync tool.