linuxsampler-devel

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

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

Steve wrote:
> > Well assume you write a GIG loader and engine. But now you discover
the
> > giga engine is
> > too limited. Fire up the signal editor enhance the signal
> > routing/processing features of the engine,
> >  compile and play your .GIG files with the new enhanced engine.
>
> Thats very compelling, but my feeling is that its better to support
> features like that in principle, but target a more reasonable feature
set
> for an initial release. My experience of large projects with big
ambitions
> is that people loose interest and they never get finished.

I agree that about the unfinished projects I tend to loose interest too,
but
this time I will concentrate only on this project since it would be very
nice
 of being able to deliver something that is usable in the real world.

Regarding the recompiler a too big task:
I would not say that: the streaming engine is more or less ready, just
take the
routines and algorithms and encapsulate them into a cleaner framework.
For the signal  processing part we have most stuff ready to use
(reverb,filters,ladspa plugs) and I don't think that writing a framework
that
is able to build simple signal networks is such a big task.
Speaking of GIG I think it will take a bit of time to figure out all
params embedded in the
file (although Ruben van Royen  and Paul K. have already done some work
in this field)
 and map them correctly to the engine. (correct emulation of envelopes,
filters ecc).

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

>
> OK, you will have to throw away some code when you want to generalise
the
> engine, but I think this is very mworth it. Espcially as you will
learn
> things from the first (or in Benno's case second :) implementation.
>
> I would like to see a first milestone of a realtime, jacked sampler
that
> can receive midi and play a subset of GIG samples fomr disk, with a
clean
> and extensible deisgn.

The problem is this clean and extensible design ... personally I think
it is represented
 by the recompiler. Perhaps I am wrong , that's why we are discussing
these issues on the list here.

> PS I'm not sure that I agree with supporting OSS, it imposes design
> decisions that don't make much sense in the long term.

> - Steve

Juan says when using JACK, instead of exporting only the stereo output
we should export each
MIDI channel (so that we can route instruments to arbitrary
destinations). This is ok for JACK and
 introduces flexiblity but I do notsee supporting  OSS as a problem:
just export the stereo output
and use a simple OSS backend that simulates callback:

while(1) {
  data=audio_call_back();
  output_oss(data);
}

The prefered method will be of course JACK but I think for testing,
debugging and tuning purposes
 OSS and ALSA are ok. (plus in case you want to dedicate a machine only
for sampling you can work
 without jack).

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

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.
How about the s5000/6000 series ? what is the maximum RAM configuration
? Do they allow nasty loop point modulation too ?

And since we speak about looping  I was wondering how looping is handled
in most hardware and software samplers:

do most of them use loop-until-release (eg looping part is looped and
after release the sample gets played as it was not looped)

or infinite looping: when you release the loop is still played but the
volume fades to zero within a certain time. (release part not used)

When implementing these kind of looping techniques in a disk streaming
sampler, the first looping technique requires caching a region (let's
say 64k samples)
past the final loop point in order to give the engine the time to refill
the ring buffers from disk. This means the memory consumption almost
doubles
for looped samples over oneshot samples. With very large sample
libraries this could mean that RAM can become scarce. (but I am not sure
if large
libraries of looped samples exist).

The second looping method is easy to implement since you can let the
disk thread refill re ringbuffers with the looped areas and then when
you release
the key the volume simply fades to zero within a certain amount of time.

Anyway it is not hard to implement loop-until-release and the engine can
easily be designed to support both in order to give the user the best of
both
 worlds.

If you have experience with hardware or software samplers please share
your thoughts on the issues I mentioned on the list.
thanks,
Benno

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

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

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

On Mon, Nov 04, 2002 at 10:15:56 +0100, Matthias Weiss wrote:
> > 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?

One idea was that linuxsampler UI's would communicate with the main engine
over a (non X) socket of some kind.

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.

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

- Steve

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

[Juan L. <co...@re...>]

On Mon, 4 Nov 2002 22:10:21 +0000
Steve Harris <S.W...@ec...> wrote:

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

Sorry, I didnt get the parent mail to this, could you please explain me where
does this out-of-context issue comes from?

thanks!

Juan Linietsky

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

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

On Tue, Nov 05, 2002 at 02:42:25 -0300, Juan Linietsky wrote:
> > 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.
> > 
> 
> Sorry, I didnt get the parent mail to this, could you please explain me where
> does this out-of-context issue comes from?

It was a braino, I meant out-of-process.

The previous person was discussin why it was neccesary to go in process
for linuxsampler.

I think the short answer is that it isn't neccesary, but its damn hard as
it is any we dont need anything to make it any harder.

- Steve

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

[Linuxsampler-devel] =?iso-8859-1?Q?Re=3A=20=5BLinuxsampler=2Ddevel=5D=20Supporting=20various=20sample=20library=20formats?=

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

On Mon, Nov 04, 2002 at 10:10:21PM +0000, Steve Harris wrote:
> 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 tha=
t
> 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?

Depends on the kind of thread you're using. User level threads don't
flush the cache on a context switch. About kernel level threads I'm not
really sure, because there is a also a mode switch (user mode <-> kernel
mode) whenever a context switch happens on this kind of threads.

But I wouldn't put the sampler in another 'host' application's process
anyway.




________________________________________
Online Fotoalben - jetzt kostenlos bei http://www.ePost.de

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

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

On Tue, Nov 05, 2002 at 09:04:04 +0100, Matthias Weiss wrote:
> 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.

Its still a needless overhead.

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

I dont know if it applies to threads as well.

- Steve 

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