>What if a caching client for JACK was written? > >Basically you would tell it what file(s) you wanted to be cached and >how much cacheing you wanted. Then the EVO JACK client would do all >the layering and mixing, etc. and route it back to the JACK system >for what ever other processing you wanted.
this would definitely work. you'd create client with a single output audio port. anything that connects to it will read data from the file. how the client deals with the file data internally is completely internal to the client. the fact that it might do read-ahead caching would not be a part of the API, totally invisible to the client, and actually might change from time to time. the only problem i see is that the port can only serve one "view" of the file at a time. if you wanted to play two copies of the same sound, but offset from one another, you'd need different copies of the same client. JACK doesn't scale well for this kind of thing, so .... LADSPA! you could create a LADSPA streaming plugin. this could potentially get a bit thread heavy unless you do some fairly clever things behind the scenes of the plugins (like a single butler thread to server N instances of the plugin). this can be done, however, and would scale pretty well. it would basically be like taking the disk streaming code from ardour, removing the transport dependent stuff from it (which is a large part of it), and packaging it as a LADSPA plugin. since the plugin wouldn't actually play audio, or even be restricted to audio data, or be MIDI controlled, its hard to see how it could be said to violate the patent. and if they did come after the plugin, you could focus the code to use the OS for readahead caching right there, and make it almost impossible to get a claim against it. remember: working around patents is not illegal - its encouraged by the system and done very often. you cannot sue for someone working around your patent to accomplish the same goal, you can only sure for them actually violating the patent itself. --p
