Re: [Linuxsampler-devel] evo code

[Christian S. <chr...@ep...>]

Es geschah am Sonntag, 24. November 2002 22:25 als Benno Senoner schrieb:
> 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).

I wasn't able to determine any performance benefit of it, nevertheless at 
least a typef won't hurt. 

> > 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 compared both and got exactly the same results wether asm or normal type 
cast and wether integral or rational number (Athlon). But the performance is 
in fact a point.

> > 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
> ?

AFAIK ASIO uses two buffers which are isolated. One buffer is only accessed 
for wether reading or writing, never both at the same time. So buffer A gets 
filled by the disk stream while buffer B is read by the audio thread. After 
that buffer B gets filled while buffer A is read and so on...
The time for one period is fixed by the buffer size, sampling rate and audio 
channels.

Somebody already posted an article about that, but I haven't found it anymore.

The advantage of those simple buffers is that you can always expect a fixed 
buffer size for reading/writing at any time. Whereas with you approach, you 
always have to check how many bytes are left to read/write and if you have to 
continue from the beginning of the buffer after accessing some pieces at the 
end. That's why your way is a bit more CPU hungry but circumvents those 
latency problems ASIO and Gigasampler has (latency fixed to the buffer size 
and latency jitter or even higher latency to correct that jitter).

> 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).

Yes I found the latter a very clever and efficient trick to keep the pointer 
within the boundaries.

> 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.

Of course not, I meant those ASIO/Giga Buffers.

> 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.

I guess you mean these audio_sum, audio_buf arrays [audiothread.cpp] to 
calculate the mix and send it to the audio device, right?

> > 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".

Why is this inefficient? Do you mean because of the memcpy() in check_wrap() 
that copies a portion within the buffer?

> 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.

I'm not sure what you're getting at. Do you mean that it's more likely that 
read/write access to the buffer won't interfere/overlap, because the audio 
thread reads faster than the disk buffer can fill up the space, due to the 
higher priority of the audio thread?

Regards,
Christian