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

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

On Mon, Nov 04, 2002 at 10:10:21PM +0000, Steve Harris wrote:
> > 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?
> 
> One idea was that linuxsampler UI's would communicate with the main engine
> over a (non X) socket of some kind.

I see, this complicates the implementation but would have the benefit
that a crashing GUI wouldn't ruin the recording. It also forces a clean
seperation off GUI code and engine code.

> 
> The problem with out-of-context is the the cache has to be cleared and
> refilled (well the part touched, and I imagine a big sample set would use
> a lot of cache) and the context switch time is small, but non-zero. As you
> pointied out we dont have very long to write out 64 samples for every
> active sample of every active note.

The situation of a context switch before the sampler finished its work
for the given jack cycle depends whether linuxsampler runs in 
SCHED_FIFO mode and if there is a higher priority process preempting the
sampler process. This shouldn't happen within one jack graph, but it
could happen if there are parallel jack graphs.
In both cases, if linuxsampler is in-process of a host app (let's say a
sequencer) or if it's running in a seperate process there would be the
same context switch to another client. So the only benefit would be that
there is no process context switch between the host application and the
sampler, but still a thread context switch. Steve, does the cache
clearing also apply to thread switches?

> 
> > > 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.
> 
> The 3000 series were limited to 32meg, generaly the samples were small,
> but in either case the point is that the optimal implementation isn't disk
> streamed. Its just an example though, dont get hung up on AKAIs.

Hehe, I'm not hung up on AKAI's in anyway ;-), rather stick with
software samplers :)) .

matthias