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

Paul Davis pbd at op.net
Thu Oct 17 01:58:59 UTC 2002


>Sarcasm aside, esd sucks -- introduces all kinds of pops and clicks when
>engaging a new stream or disengaging streams, artsd cannot share the
>input (or at least I was unable to get it to do that), and does not work
>with all apps across the board (esp. when it comes to input sharing),
>Jack works only with Jack apps and from what I heard, does not tolerate
>many simultaneous apps running concurrently, furthermore it permanently

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.

>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

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.

>I have no idea why you are mentioning Portaudio, when it again
>introduces a problem of porting apps into its API, and that again poses
>the same problem of excluding a lot of older audio apps that do not have
>that framework implemented.

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.

>with a reason -- regardless of recent developments, things are still NOT
>working in the Linux audio world on one of the most fundamental
>levels...

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



More information about the Linux-audio-dev mailing list