Re: [Linuxsampler-devel] evo code

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

Il mar, 2002-11-26 alle 00:23, Christian Schoenebeck ha scritto:
> >
> > 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).

Keep in mind that with variable sample pitch (which is always the case
in a sampler) you will never be able to read an integral number of
samples from the source (the sample on disk or ram) resample them and
write it to as you call it to the "asio buffer". 
In my code I use OSS or ALSA writing data in chunks too (fragments),
thus it is excactly the stuff you described.
Thanks to the wraparound concept, the overhead is really small since the
buffer ptr updates are very infrequent and occur in a low priority
thread.(the disk thread).

> 
> > 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.
but this is user selectable , no problem here, ... As said before, I
successfully ran tests
with 3 x 32 sample audio buffers which leads to 2.1 msec latency. :)
> 
> > 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?

yes.

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

Not the function itself is inefficient, only the fact that it is called
relatively often from within the audiothread. The check_wrap can be
moved to the audio thread where it will be called less frequently thus
saving some cpu cycles (but not that much since it is inlined).

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

no, the disk thread "always writes faster than the audio thread reads",
or in short: there will be always some data in the ring buffer as long
as the disk is not overloaded (if that happens we must lower the max #
of voices or user more powerful hardware ... it is not our fault).
Anyway since in regular conditions there will always some data in the
buffer, resampling will work perfectly even at buffer boundaries thanks
to the check_wrap func that mirrors the data that is stored at the
buffer beginning to the position that resides past the buffer end.

cheers,
Benno


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