Re: [Linuxsampler-devel] evo code

[Benno S. <be...@ga...>]

On Sat, 2002-11-23 at 22:00, Christian Schoenebeck wrote:
> 
> Is there a reason that int types were always used for actually bool types or 
> is it just some kind of habit?

Not sure if ints are faster than bools, but OTOH I agree with you that
bools are more elegant. (somethimes I write inelegant code, sorry).

> 
> Is there any benefit of using this double_to_int() function [audiovoice.cpp] 
> and the asm code in it, instead of a normal type cast?

See Steve's reply, this hack is needed only on x86, PPCs and most of the
other archs can use simple casts.

> 
> I was a bit surprised about the ring buffer. I expected a buffer similar to 
> the ones which are used in ASIO or Gigasampler. These consume less CPU time 
> but on the other hand of course, latency values are dependent on the buffer 
> size. How about giving the user the choice which kind of buffer to use?

What does mean expected buffers similar to ASIO etc ? Can you elaborate
?
The ringbuffer is very very efficient, basically the audio thread can
access the ringbuffer as it were a linear sample, at the end of the
processing of a fragment you simply do read_ptr = (read_ptr +
fragment_size) & (ringbuf_size-1);  (ringbuf_size is a power of two to
avoid relatively slow % (modulus) ops).
If you you have a more efficient scheme in mind please tell us.
The final latency does not depend on the ringbuffer size since this
buffer is only for compensating disk latency.
The bigger this ringbuffer the smaller the risk of ending up in an
"empty disk voice buffer" situation.
The disk buffer size can be smaller for low-msec disk access times.
On the audio side we simply use regular fragment-based audio output.
This means usually only 2-3 fized sized buffers so no ring buffers are
involved.

> 
> And finally I was a little bit unsure about the purpose of the check_wrap() 
> method in the RingBuffer template. It ensures a sequential reading of 
> 2*WRAP_ELEMTS = 2048 elements, right???
> If so, shouldn't there a be a check if there are enough elements available 
> for reading?

The check_wrap is suboptimal since it checks for when it is about time
to replicate some data past the buffer end so that the interpolator can
fetch samples past the "official ring buffer end boundary".
This check can be moved within the disk thread which accesses the buffer
with a much lower frequency and where it is easy to figure out when the
last read reached the ring buffer end position. (in that case read the
data from disk and write it at ring buffer start and replicate some
samples past the ring buffer end).

If you have more question or if some of the issues are not clear please
let us know on the mailing list.

cheers,
Benno

-- 
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.