Re: [Linuxsampler-devel] Supporting various sample library formats

[Matthias W. <mat...@in...>]

On Mon, Nov 04, 2002 at 09:30:07PM +0100, Benno Senoner wrote:
> >
> > If you set a reasonable target for a first release (but still with a
> > good, extensible API), you will get there quicker, you will get users
> for
> > testing earlier, and the devleopers will be more motivated.
> 
> not sure if this will bring us more long-term advantages ... what do
> others say ?
> As said for the beginning the recompiler can be very simple since we can
> extend it later
> without needing to introduce radical changes).
> 

Though the idea of the recompiler seems appealing to me, I'd like to see
some results against a "standard - hardcoded" solution that uses
techniques like inlining, function pointers ...
The disadvantages of compilation time, the need of a working compilation
environment don't have to outweight the benefit of some CPU cycles less.


> Regarding JACK we will probably need to use the in-process model (which
> is actually not used much AFAIK)
>  in order to achieve latencies at par with direct output so this needs
> further research.

Well this means we have to provide GUI implementations for every graphic
toolkit that is used by the available sequencers.
If it's right that processes and threads are handled very similar in the
Linux kernel there should be not alot of a performance difference
between in-process and out-of-process model, anyone knows more about
that?

> My tests with direct OSS output show that it is possibile to achieve
> 3msec latency on a PII+ with the sampler so
>  we want to get out these numbers from jack too so we need to test it
> first in a direct output enviroment and then
> in conjunction with jack (or better implement both backends from the
> beginning and allow you to switch it via cmdline).

I think it should be the target to achieve latency of one jack cycle.
That means in one cycle the midi events get read and the audio data is
prepared in a buffer. In the next jack cycle the processed audio data is
copied into the shared memory segment provided by jack.
In case of 48kHz and 64 samples/cycle this means 1.3 msec time to
finish. Well in fact it is less, because there should be room for other
jack clients ...

> 
> regarding the AKAI samples: Steve says akai samplers were quite limited
> in terms or RAM availabilty (32-64MB)
>  and since akai samplers allow some funny stuff like modulating the loop
> points I was wondering what you thing about not
> using disk streaming for this format.

Or caching enough audio data that covers the modulation range which
might impact RAM usage.

matthias