[linux-audio-dev] Quick and efficient sound daemon idea -- why not do it this way?

[Kai Vehmanen]

On Wed, 16 Oct 2002, Ivica Bukvic wrote:

> Jack works only with Jack apps and from what I heard, does not tolerate
> many simultaneous apps running concurrently, furthermore it permanently
> drops a stream if it is late for whatever reason, which basically means
> it is useless for the real-time performance (last thing I need in the
> middle of the concert for JACK to drop one of my streams -- 

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.

> assuming I am only interested in using JACK apps, which is a huge 
> assumption in itself), and this mix plugin is yet to be seen at work.

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!