13 Dec
2002
13 Dec
'02
7:01 p.m.
On Friday 13 December 2002 20.54, Steve Harris wrote:
On Fri, Dec 13, 2002 at 07:46:37 +0100, David Olofson
wrote:
Theres more to it than that, you have to also be aware of loop
points, layers etc.
Loop points are basically extra start points that need to be cached,
and layers mean more waveforms to deal with. The logic is still the
same, though.
Linuxsampler requires very tight interaction between the
streaming code and playback code to work.
Yes. You need to be able to tell the "butler thread" which files
to load/cache, and it may need to know the maximum bandwidth you
will use, so it can set up sufficient caching - if there's a
point in being that picky, that is. (Streaming from disk is
nondeterministic enough that the difference in latency between
starting a 48 ksamples/s stream and a 96 ksamples/s stream
becomes insignificant.) Realisticly it has to run as a mutithreaded process.
Well, people used to say that about real time music software in
general... Things change.
Either way, a plugin with a bunch of worker threads (created by the
plugin directly, or via a host provided API) wouldn't be a problem.
It's basically what you have already; just different APIs.
Splitting the butler thread and the sampler isn't required, of
course, although it would be cool if you could use the same butler
for all streaming from disk, be it for the sampler or HDR. (Though
the latter implies that there has to be streaming *to* disk as
well... *hehe*)
//David Olofson - Programmer, Composer, Open Source Advocate
.- 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 -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---