On Friday 13 December 2002 15.29, Steve Harris wrote: Well, that's asynchronous communication for you... (And this isn't even including QoS, which you should have in any RT system doing this kind of stuff.) Yeah - but the problem with having this *completely* outside the API is that people will start reinventing the wheel in various, incompatible ways. I'd much rather provide a standard framework for the basic services needed, much like the host provides memory and audio buffer allocation features. Anyway, what made me consider this is the Linuxsampler project, which (to me) demonstrates that it may make a lot of sense to be able to split the waveform loading/streaming from the actual sampleplayer. Both are pretty generic units that could be reused - but only if there is a common interface for their interaction. //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 ---

On Friday 13 December 2002 18.53, Steve Harris wrote: *hehe* 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.) Next, you need to request at least the number of frames required for each waveform, that you can produce N buffers of finished output at the highest allowed pitch for the respective waveform, where N is the feedback latency caused by your sending the request events "backwards" in the net. Normally, this will be exactly 1. When the requested data has been delivered to you, you're ready to go. You're basically a standard sample player, and in fact, you could just have requested *all* of the waveform data right away, and be done with it - but then this wouldn't be all that interesting, would it? :-) So, you have only the first fraction of each waveform; just enough that you have time to ask the disk butler plugin for the rest - and get it - before you run out of data to play. Since the disk butler is aware of what it's doing (acting as a streaming server with QoS "guarantees"), it will obviously have yet some more data loaded and prepared for delivery. The disk butler is the right place to keep track of the amount of buffering required for streaming a suitable number of files at once, be it for traditional hard disk audio playback, or direct-from-disk "zero latency" playback. When you start playing a note, you simply start playing the data you have (like any sampler), but at the same time, you also push your "I may need data until this point in the waveform N blocks ahead" variable, and tell the disk butler to send the data you do not already have. Of course, doing everything inside one plugin would be a bit easier, but then you have an integrated disk butler in the sampler, which may well end up figthing with the hard disk recorder's disk butler over the disk... And of course, running *two* different direct-from-disk samplers would be problematic as well. You need one physical drive per plugin that streams from disk, since standard file systems are terrible at handling multiple tasks reading or writing simultaneously. //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 ---

With this I agree. Simpler is better, and this is not simple to do generically. I propose we leave this until such time as it actually becomes important. We can always add and extend later. I think there is enough sense on this discussion to NOT make extensions into a mess like too many commercial products :) Tim

On Friday 13 December 2002 20.54, Steve Harris wrote: 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. 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 ---