> Anyone who disagrees here ?
> If he disagrees then he has to show me that he has an alternative to
> run serveral concurrent apps with 2-3msec latency at the same time and without
> ANY dropout during heavy load.
i think you are overestimating the latency of a normal unix pipe.
it is very low; i bet it's mostly the associated context switch
that's slow...
depending on your soundcard (some don't support polling and don't
quite get this good), i usually run gdam with 9ms calculated
latency with no dropouts when set realtime. i suspect moving
the sound-card feeding into its own little thread (as opposed to
doing effect etc in that thread) with might get us down toward
2-3 ms, but frankly the x-window interface probably adds latency
on that order, so... the midi-soundcard latency is nice to
get low, but i really have to live with the x-interface.
we have about 80% done a `gdamdsp' whihc is like esddsp;
that is you can shovel other programs sound output to a
gdam-server, and manipulate that like any other soundstream
(mix, filter, resample, etc). (it more-or-less works but i haven't
finished the gui part for it...)
- dave
ps. gdam starts configured with rather high latency.
this is because we want people to try our program
out without having to run it as root.
