Re: [Linuxsampler-devel] RAM sampler module proposal

[Steve H. <S.W...@ec...>]

On Thu, Nov 07, 2002 at 05:14:46 +0100, Benno Senoner wrote:
> I'd like you to comment about the design of a simple RAM sample playback
...
> At a later stage we can introduce the disk based sample playback module
> which will act in a similar way as the RAM version but with some
> limitations (eg loop point modulation will not be possibile etc)

Good :)
 
> Regarding the note On/Off triggers I would propose to use timestamped
>  events which allow sample accurate triggering.
> For example without timestamped events, when using not so small buffer
> sizes, note starts/stop would get quantized to buffer boundaries
> introducing unacceptable timing artifacts.

That is true in principle, but bear in mind that in many cases the note on
events will be coming in over real time MIDI, and therefore will have to
be processed as soon as posible ie. at the start of the next process()
block.

It could be that there will also be non realtime triggering, but if we
know there isn't, only handling note on at the start of process() is
signiciantly more efficient.

If you think about it, handling timestamped events is a pathological case
of the branch you describe later. Its worse because the branch predictor
can't know which way to go.

> In the latter case it is perhaps more efficient to provide a continuous
> stream of control values (one for each sample) (Steve does CV models
> work like that ?)

Yes, though generally the CV signals run at a lower rate than the audio
signals (eg. 1/4tr or 1/16th). Like Krate signals in Music N. Providing
pitch data at 1/4 audio rate is more than enough and will save cycles.
 
> Or perhaps both models can be used ? (a time stamped event that supplies

I think a mixture ofhte two is neccesary.

> That way we save CPU time and can avoid the statement
> if(sample_ptr >= loop_end_pos) reset_sample_ptr();   
> within audio rendering loop.

As long as the compiler issues the branch prediction instruction correctly
(to hint that the condition will be false), it will be fine. You can check
this by looking at the .s output.

> IIWU/Fluid sounds quite nice but it seems to be quite CPU heavy.
> I took a look at the voice generation routines and it is all pretty much
> "hard coded" plus it uses integer math (integer,fractional parts etc)
> which is not that efficient as you might think.

If you are refering to phase pointers, then its not an efficientcy issue,
if you use floating point numbers then the sample will play out of key,
only slightly, but enough that you can tell.

> I know some of you want quick results or say "if we set the target too
>  high we will not reach it and developers might loose interest etc",
> but I think the open source world still lack a very well thought out,
>  flexible and efficient sampling engine and this takes some time.

I think the starting point of a simple RAM based playback module is good.
It alays my fears about this.

> Regarding the JACK issues that Matthias W raised:
> I'm no JACK expert but I hope that JACK supports running a JACK client
> directly in it's own process space as it were a plugin.
> This would save unnecessary context switches since there would be only
> one SCHED_FIFO process runnnig. 
> (Do the JACK ALSA I/O modules work that way ? )

Yes, but there is currently no mechanism for loading an in process client
once the engine has started, however that is merely because the function
hasn't been written. Both the ALSA and Solaris i/o clients are in process,
but they are loaded when the engine starts up.

- Steve