On 2013-11-04 16:14, Stéphane Letz wrote: we've been successfully using it within the CO-ME-DIA project to connect 8 (or was it 16) channels between belfast, paris and graz (and less successfull with hamburg). while on our side we were using linux, the partner institutions were pushing hard towards OSX (so it does work, but my personal experience is limited). jacktrip itself is very lightweight and puts low-latency over reliability: there is no error-correction, buffering is thin. iirc, there is a switch to turn on redundancy (which is supposed to make the signal more reliable), but this made things worse, so i would recommend to not use it. the main parameters you can play around with, are blocksize, sample-width and channel number, to get a decent packet size. it helps if you have a degree in networking (or at least some basic knowledge). the main parameter you have to assert (but which there is usually little possibility to "play around with"), is a reliable network. our project involved insitutions sitting on the european university fibre-backbone (geant), so bandwidth was not an issue. please keep also in mind, that jacktrip does not resampling whatsoever. it simply assumes that remote soundcards are synched (which is obviously a naive assumption). in praxis this was not a real problem for us (once i figured that the clock in my old RME9652 had gone bonkers, and that i was better of using the clock of reasonably new RME AD/DA instead): the occasional click could as well come from a sudden packetstorm (cylie mirus' new video or whatever) gfmdsar IOhannes PS: as the debian maintainer of jacktrip, i would also like to hear comments, esp. running on debian.