Le 19 mars 2012 à 15:20, Fons Adriaensen a écrit : > On Mon, Mar 19, 2012 at 01:19:25PM +0100, Stéphane Letz wrote: > >> I'm wondering how your code could replace the "adapter" mechanism that I did >> in JACK2 for that never worked fully reliably. Basically the "adapter" idea >> is a bit more general in the sense that it aims at "adapting" streams in >> different context: like network <==> Audio API (CoreAudio for OSX, ALSA for >> Linux, PortAudio for Windows...), or several ALSA devices..etc.. >> (The adapters are also developed as "in server" clients, this make a bit >> more easy to add them in a running session using "ladish" kind of studio >> management approaches...) > >> How complex do you think it would be? > > 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.
Well I think it does in some cases, and basically when controlled by the so called "Control API" > > 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. Do you mean having the sever "decide" to run a2j/j2a before others in a given cycle? > > > 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, > Well so now we are on the road for "another" netjack like application...; I'll still interested to see if your code can be used for the adapters, since it makes sense on others platforms than Linux. Stéphane _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
