Subject: Re: [linux-audio-dev] Re: disksampler ...
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri Jul 14 2000 - 00:58:44 EEST
On Thu, 13 Jul 2000, David Benson wrote:
> > 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.
The key point here is that 2msec is a damn small time, and
assuming your app uses 80% of the CPU for audio rendering plus
some scheduling jitter occurs , having a few pipes between a couple
of tasks can screw up things.
Yes if the scheduling jitter would be zero then the easiest thing
to do is to would to have a soundserver which simply collects the
streams from N apps via a pipe , mixes the stuff together and then
outputs to the audio device.
Plus how ensures us that one of the app releases the CPU after each
700usecs (I am using 3x128 fragments = 3 x 700usec buffers) ?
With the soundserver protocol I described, the app runs basically as
a plugin and is required to make any syscall which could block for
an undetermined amount of time.
As long we stay in the 7-10msec domain, approaches like yours work
well, but pro-audio users will not be very satisfied with a softsynth with
10msec latency.
One of my goals is being able to run synths , harddisk recorders
and MIDI sequencers all in parallel without perceptible evet delays
(like note-on to audio out) and without glitches.
Yes it is damn hard, but the lowlatency kernel can do it ,
provided you do it in the right way.
Benno.
>
> 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.
This archive was generated by hypermail 2b28 : Fri Jul 14 2000 - 00:49:50 EEST