I've been thinking about Paul's idea of letting the OS do the cacheing for the EVO app and I got to thinking about taking one step up from that.
(On a side note EVO really isn't a good name anymore since sevaral other projects have that name. I'm open to suggestions for a replacement) 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. IIRC the patents deal with the caching/streaming/playing as a whole. Breaking it up into descrete parts might be a way around things. You could argue that the cacheing client isn't really specific to audio but any file type data needed by any JACK client. My thinking is that something like this would not be so kernel dependant. But still yield acceptable performance. And by breaking up the system into piecies none of which infringe on the patent by themselves would allow people in the US to work on the code without fear of Nemesis slapping them with a lawsuit. Only when all the piecies are running together would the patent be infringed upon. Dunno.. I'll have to go back and re-read the Patents tonight and see if I think a individual piece would infringe. What do you think... Am I baked or what? -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.846.5777 x204 Sr. Design Engineer http://www.bitworks.com
