Last Thu, 17 Apr at 17:08:55
Greg Sullivan wrote:

> - What is the typical polyphony for wavetable synthesis, on, say, a Pentium
> 133, outputting at 44.1kHz,  when it is used with real time MIDI input
> events to drive it? (just a rough idea will do)

If for 'wavetable synthesis' you mean simple sample reading and
amplitude envelope without filters, polyphony depends by cache size
installed to your computer. With small samples, a polyphony of up to 50
voices (or more if no interpolation is used) should be achieved if
buffer and cache are big enaugh (cache size must be greater than sample
size). Ideally a computer should have only cache and no standard ram for
the best performance with realtime Csound. If not, I suppose EDO ram
should help a bit.

 
> -  Is there a noticeable delay between a MIDI input event (e.g note-on)
> to the resultant output? 

Yes, there is

> Can this delay be reduced by reducing
> the output buffer size? 

Yes, the delay can be reduced a lot if you use rounded sr and kr(i.e.
sr=40000hz and kr=400, sr=32000hz and kr=320, sr=10000hz and kr=100)
setting the -e flag with soundcard supporting non standard sample rates.
In my p133 computer I reduced the delay to less than 1/30 of second with
sr=40000hz.

> Is the polyphony reduced if the buffer
> size is reduced (within reason)?

Yes, a bit.

 
> - Please confirm that it uses the generic Windows 95 WAV output
> drivers - i.e, that it doesn't use a more direct method to
> output to the soundcard.

Yes this version uses standard win95 card drivers.

Bye and...happy Csounding
-- 
Gabriel Maldonado

mailto:g.maldonado@agora.stm.it
http://www.agora.stm.it/G.Maldonado/home2.htm

Hi Gabriel. I've been trying to get realtime-Csound to work
satisfactorily as well, not on Win95, but on Linux.
Many of the problems are the same.

On Thu, 17 Apr 1997, Gabriel Maldonado wrote:

> With small samples, a polyphony of up to 50
> voices (or more if no interpolation is used) should be achieved if
> buffer and cache are big enaugh (cache size must be greater than sample
> size). 

I think that that's a good approximation if the sample size is much larger
than ksamps. You still would like to cache all the other ram usage - the
audio rate var arrays, etc. And I think this is true if you're not also
doing any other disk I/O. I was hoping to set something up where I can
play one voice in real-time while mixing it with a soundfile of previously
recorded voices, and also saving the real-time audio to disk for future
"overdbubs". Sort-of a primitive multi-track deck using Csound. Does
anyone have any idea how to minimize cache needs on Linux in this
scenario? I suppose that it would be a difficult situation.

Also, as far as cache size goes, I wonder, if in cases that do not involve
large wavetables read from disk, if using smaller ksamps
might significantly help cache needs, due to the smaller audio arrays.

Oh wait, (thinking as I type), what about code accesses? These get cached
too, don't they?  How does this figure in?


> Yes, the delay can be reduced a lot if you use rounded sr and kr(i.e.
> sr=40000hz and kr=400, sr=32000hz and kr=320, sr=10000hz and kr=100)
> setting the -e flag with soundcard supporting non standard sample rates.
> In my p133 computer I reduced the delay to less than 1/30 of second with
> sr=40000hz.
> 

What's your opinion of the "feel" of the 33ms delay? I guess it wouldn't
feel like a delay, but still would give a "sluggish" feeling?

And I'm curious to know why "rounded" kr and sr would help! Is this
something to do with the Win95 driver? What?


> > Is the polyphony reduced if the buffer
> > size is reduced (within reason)?
> 
> Yes, a bit.
> 

Is this due to the instrument setup time causing dropouts? Some tests on
my P100 Linux box with strace showed that simple instruments could take 10
or 20 ms to get setup, but I think that this is only for new allocations.
So I've been pre-allocation the voices by firing of as many as I need
simultaneously, at time 0 in the score, at zero volume. 

In general, Gabriel, and anyone else, what is your experience with
dropouts? Linux appears to have some problems with scheduling somewhere,
so that other tasks are stealing too much time from Csound. I'm actually
considering implementing something in rtlinux instead.

Larry

--  Larry Troxler  --  lt@westnet.com  --  Patterson, NY USA  --