JACK will support a large number of simultaneous apps concurrently. there are still some problems in the codebase relating to what happens when a client disconnects and then the same app tries to reconnect later. it is not, however, a design problem, but almost certainly a "simple" coding bug. there are no limits to the number of clients JACK will support other than the number of ports, and the number of ports can be configured at runtime. au contraire: this means its purpose built *for* real time performance. the problem arises it when you're using it with apps that are not designed for real time performance. for some kinds of real time work, the "pops and clicks" that will be caused by a late stream are completely intolerable, for others, you might shrug them off. the folks involved in designing and writing JACK felt they were intolerable. thats very true. my position is very, very simple: OSS was a *HUGE* and monstrous mistake. in the guise of using The Unix Way (TM) for an audio API, it has saddled us with dozens of (mostly toy) applications that use a design model/architecture that is not appropriate for real time work. you can thank OSS for that. if we had started out with even a wrapper library around the system calls, it would easier (and in some cases, much easier) to fix the problem. instead, we have loads of apps that think that audio software looks like this: fd = open ("/dev/dsp", ...); while (some_condition) { ... generate data ... write (fd, audio_data, some_size); } this design is *fundamentally* incorrect for realtime work. you can't fix this without pops and clicks and all manner of obnoxiousness without fixing the API. --p

"Paul Davis" <pbd(a)op.net> wrote: Let me take a step back and ask a question that has plagued me for a while: what *is* the Unix way to solve new problems in new domains? I cringed a little when I read this in the Linus Torvalds autobiography: This simple design is what intrigued me, and most people, about Unix (well, at least us geeks). Pretty much everything you do in Unix is done with only six basic operations. [...] [They are fork, exec, open, close, read, write] Sure, there are tons of other system calls to fill in all the details. But once you understand the six basic ones, you understand Unix. Because one of the beauties of Unix is realizing that you don't need to have complex interfaces to build up something complex. You can build up any amount of complexity from the interactions of simple things. What you do is create channels of communications (called "pipes" in Unix-speak) between simple processes to create complex problem solving. An ugly system is one in which there are special interfaces for everything you want to do. Unix is the opposite. It gives you the building blocks that are sufficient for doing everything. That's what having a clean design is all about. I cringed because it struck me that this is exactly the kind of thinking that bore OSS. The idea that any new task (such as sound input and output) should be designed to use combinations of the simple interfaces we already have, so that we can use the tools we already have to do work in the new domain. The idea that "cat file.aiff > /dev/audio" should be an acceptable way to play audio files, or that JACK should be replaced by a complicated shell script that just pipes different programs together. :-) Audio I/O has a completely different set of assumptions and constraints than reading and writing files. It seems to warrant a different API and different system calls. But does this go against the Unix way? Is ALSA in line with the Unix way? Josh -- "Only Angels can sing that high, and only dogs can hear it." -- James Evans

On Wed, 16 Oct 2002, Ivica Bukvic wrote: I guess it's a time for little marketing speech. :) JACK should be just fine for your use. Basicly JACK can also be used for the not-so-hard-core-low-latency tasks. JACK just makes the real-time deadlines much more explicit - both to users and developers. One way of dealing with real-time deadlines is to ignore their existance. This the approach used in many existing audio apps (and I'm not just talking about Linux). If on the other hand the deadlines are explicitly taken into consideration, then there remains to be two alternative design approaches: 1) missing a deadline is an error, 2) missing deadlines is possible, so software implements a recovery mechanism. Now as it is, many of the active JACK developers and users are mostly interested in (1). For an application like Ardour this really is the only possible approach. It just isn't tolerable for the recording to skip once in a while. It's better to let the user know that the system simply doesn't work reliably enough (ie. client can be disconnected from the system during processing). But it is also possible to use JACK for (2). Currently, if you run jackd without the -R option, it will run in so-called soft-mode. In this mode clients are not kicked out, unless they are _really_ late (over 5 secs). There's room for improvement (for instance, make it possibly to have -R but with soft-mode timeouts), but this doesn't change the fact that that JACK is also viable for (2). I'm currently running jackd with 2x8192bytes of buffering ('-d hw:0 -r 44100 -p 2048 -n 2' w/ 24bit samples) and it works quite well as a general-purpose audio server. With these settings the latency is ~46ms, which is not bad (I'm not running it as root). I think this is just the kind of use most people use esd for. But what esd cannot do is to route the mp3 playback through an app like Freqtweak. ;) With JACK you can do that. Another source of trouble is utilization of buffering. Generally you should use much higher period/fragment sizes with JACK than what you are used to with other audio apps. While in many apps the total buffersize (x blocks of y samples each) is used to control latency/reliability, in JACK the effective block count really is always 2. So this means that you should increase the period size if you want to use JACK as a soft-realtime audio server. Yes, this really is a huge problem for all audio application frameworks that are not OpenSoundSystem. Technically it's not possible to get old OSS applications to work in a multi-app network like JACK without noticable increase in latency. On the other hand, it _is_ possible to write an LD_PRELOAD-based OSS-emulation for JACK. The basic idea: ** OSS-emulated calls ** - open() connects to the JACK server - create two buffers, each with room for one buffersize() worth of what_ever_OSS_format of data (only needed for - temp buffers for f32le non-interleaved data - read() - read data from the OSS-buffer at appl_ptr - write() - write data to the JACK-buffer at appl_ptr - ... and so on ** JACK-callback ** - process() - inputs: read from JACK client buffer, write and convert to the OSS-buffer at jack_ptr - outputs: read from OSS-buffer at jack_ptr, convert and write to the JACK client buffer ... that's it. If the emulated app is late, the JACK-client should behave just like a normal soundcard -> overwrite the (or read old) data or stop. The only big problem is who will implement this. Similarly lots of interesting stuff could be done using alsa-lib's PCM-plugins, but again, who will do the work. But still, these are all much easier/smaller tasks than writing yet another audio server from scratch. -- http://www.eca.cx Audio software for Linux!