On Mon, Mar 19, 2012 at 01:19:25PM +0100, Stéphane Letz wrote: I'd never consider writing a2j and j2a as 'in-server' clients, they are far too complex for that. An 'in-server' client should be so simple that there is essentially no risk that it could ever malfunction and take the entire server down. As as long as it does simple audio processing that can probably be the case (but even that isn't given - consider an app sending Nans and Infs to an internal client). Apart from Jack's thread, a2j and j2a have two other threads. One runs at a higher priority than Jack (reading and writing the ALSA device), the second is the 'main event loop', ATM only providing text output to the user, but I'm considering GUI versions as well. There is also some non-trivial state management involving messages between these threads - required mainly to recover cleanly from anything that disrupts regular period timing, xruns, skipped cycles, freewheeling, etc. So the idea of making these 'in-server' was rejected quite early, also because really nothing is gained by it. Also, apps like these are 'fixed infrastructure', not something managed on project/session level. In my 'ideal world' they would run as system daemons, as would Jack itself. What would be an interesting addition to Jack would be the possibility to reduce the timing uncertainty for certain clients. At the moment a client can run anywhere between the start of a cycle and the start of the next one - no assumptions can be made. If a2j would always run near the start of a cycle, and j2a never before e.g. 90% of the cycle has passed, that would enable to reduce the minimum required latency. Network versions (j2n and n2j) are in development. They are meant for use on a LAN (not for the Internet at large). They use multicasting, so you can e.g. distribute an audio signal to all machines in a lab or classroom. Resampling is done by the receiver(s). I'll be doing a real-life test in a few weeks, recording a concert in the CdS auditorium. Eight mic signals will be sent by j2n connected to the nearest network rack, from there using optical links to another network rack, and from there to n2j running in the LABEL studio. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Mon, Mar 19, 2012 at 10:20 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote: re: the j2a part ... given that the server may be otherwise done with the period after less than 5% of the period time has elapsed, this seems hard to guarantee and counter-productive (it would require a double wakeup of the server).