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