Re: [Linuxsampler-devel] LinuxSampler as a stand-alone app vs. plugin

[David O. <da...@ol...>]

On Tuesday 21 January 2003 20.37, Mark Knecht wrote:
> Hi,
>    Reading through the thread from the last day or two, I did end
> up with a question about how LinuxSampler might be impacted by
> being a stand-alone app.
>
>    To start off, I'm only considering a Jack issue here. If the
> sampler engine was used in a plugin type app, more or less a soft
> synth, then I presume that this app would have to run with the same
> Jack requirements as my audio recording system. It either meets
> normal Jack latency requirements or we get xruns in the Jack audio
> stream, just like any other Jack app.

Correct.


>    If I want to push buffer numbers and sizes down to reduce real
> time audio latency, does this have any impact on the Soft Sampler's
> ability to stream from disk? Does this mean that it has to buffer
> more data, or do things differently, based on how this is set?

No, all it means is that the RT part (the "actual sampler") reads=20
smaller chunks of data more frequently from it's end of the lock-free=20
FIFOs. This may cause some extra memory stress, but it should have=20
little or no effect on the operation of the disk butler.


>    I presume that if we were able to stream sample libraries from
> disk, then we have to buffer enough data in DRAM to ensure the
> sample stream continues until the disk catches up. Is this driven
> only by the drive's response time? Or would there be advantages in
> running the sampler engine at higher Jack latencies to reduce
> buffering?

Disk buffering is basically the responsibility of the butler, and the=20
RT part doesn't even have to know much about this. It just reads the=20
# of samples it needs from the FIFO, and if they're there, it Just=20
Works. (As if playing was entirely from RAM.)

As to total disk latency and catch-up time, that's a function of seek=20
latency, transfer rate read block size, physical location of data,=20
number of files streamed at once, etc etc. Either way, just pre-cache=20
enough data and don't read too small or too big blocks at a time from=20
the disk, and the data will be there in time.


>    Seems to me that if I run this on a second machine (or have a
> second jack daemon on the same machine...) I get an extra degree of
> freedom. Does it help me?

Well, you get all CPU power, memory and disk bandwidth for yourself,=20
but if it actually *helps* probably depends more on the requirements=20
of the other software you need to use.

An OS with proper real time scheduling doesn't have a problem with=20
dispatching CPU time. OTOH, hard drives are still mechanical devices=20
that suffer severely from multiple simultaneous streams.

Also, plugins and RT applications with drastically varying CPU=20
utilization mean trouble. The closer to 100% CPU usage you get, the=20
greater the risk of too many plugins deciding to burn CPU at the same=20
time, causing a drop-out. Though, this kind of "nervous" plugins can=20
usually be considered more or less broken, because this is *really*=20
not the way to go if there's any way to avoid it. (And there usually=20
are ways. Large window FFTs and the like can be split and scheduled,=20
for example.)

[...]


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---