Subject: Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Jan 15 2002 - 20:54:40 EET
>Well being one of those people I guess I should speak up and debunk
>the nasty rumor that I have "vanished off the face of the earth"
>before it spreads. I'm just happen to be in lurker mode now.
sorry for seeding misinformation.
>I have also been in contacted by Nemesis and they have indicated that
>if I were to do anything that infringes on thier patent(s) they
>_WILL_ litigate. My initial inquiries with a patent attorney
>indicates that a typical patent fight runs about a Million dollars.
>A little more than I can afford currently.
i wonder what's going on with steinberg. halion clearly uses the same
technology; i seem to recall a story on harmony central about a
lawsuit, or maybe it was in sound on sound. not sure though.
>There is an option where you can request the patent to re-evaluate
>the patent. However, if they still don't find any problems then you
>just made the patent _much_ harder to invalidate. Better to actually
>challenge it. Just more $$
>
>Originally I was all about messing with the sampler stuff despite the
>patents. But after all the stuff with the Dmitry Sklyarov case I am
>a little leery of any public involvement with the sampler code.
this is definitely a problem. let me make two suggestions.
1) i will try to arrange a time to talk to fairly good
friend of mine who is a patent attorney, and see if i can
flush out the options a little more.
2) i can see no reason not to write EVO so that it doesn't
explicitly do anything like the patent's claim. this can
be done very easily by the most obvious (yet inapplicable
prior art): use the kernel's own disk caching.
let me expand on (2) just a little bit. the main reason why the patent
should not have been granted is that it takes a generic method
(readahead with a cache) and applies it to a specific domain without
actually changing or improving the generic method. we can use this to
our advantage. instead of writing code that infringes on the patent,
simply write code that uses the facilities of the OS to do the same
thing completely transparently.
there are a couple of easy ways to do this. to infringe the patent, my
recollection is that it will be necessary to explicitly read the data
from disk, keep it in a special location, and use that location at the
onset of audio synthesis. it might be enough to just read the data and
throw it away. a clever patent attorney might be able to argue that
this was infringing because we knew that the kernel would keep the
data around and we still read the data. in this case, use mmap, and
access the data via a pseudo-random pointer walk without any explicit
pointer loading. it will be easy to point out that a change in the
behaviour of the kernel will break the readahead behaviour, and
therefore it cannot be true that readahead is being done by the
program. i cannot see how a lawyer could possibly argue that we are
infringing the patent when there will be no code in the program that
does anything like what the patent describes. the fact that our OS of
choice happens to do readahead, using a methodology that predates the
patent by at least 25 years, seems to me be unimpeachable. its true
that we will still be left with code whose only purpose is to initiate
readahead by the kernel. that then raises tricky legal questions about
infringement: since we don't do the readahead, we aren't infringing,
but since we initiate the readahead, perhaps we are.
the result of both methods are that the kernel will have stuffed a
certain amount of data into the buffer cache, and the next time we go
to read it, although access will not be as fast as it being in user
space already, it won't be much different (and will definitely be
orders of magnitude faster than it coming from the disk). the only
problem is that over an extended period of time, the kernel might
throw away the data from the buffer cache. i think there may be ways
to deal with that, but i will need to think about them carefully.
i will also discuss this strategy with my patent lawyer friend to see
just how watertight or pathetic it may actually be.
>As far as the GUI goes... There actually was some initial work done.
>Just no code. I have lots of prototype interface screens that my
>buddy Mike Bailey designed using Word 2000. Its actually quite
>impressive what he was able to do. The screens are all graphic
>images he built and they are linked together so that if you click on
>a "button" it actually brings up another screen. I despise MS
>products but never-the-less I was impressed. I would post it
>somewhere but its huge like 50 Megs or so and the conversion to html
>mucks it all up. (Thats MS for you)
the problem with demos like this is that represent only a tiny
fraction of the real work, and once the working version is
operational, many changes typically become necessary from testing.
writing complex GUIs like this is a huge amount of work, and
prototyping screen transitions is a tiny part of that in my experience.
>I would like to code up a proto of the interface though. I was
>planning on trying to do it with python and something like wxPython.
>Mostly because Python is my new favorite language and I need a good
>graphics project to work on.
any chance you'd consider using pyGTK and python?
--p
This archive was generated by hypermail 2b28 : Tue Jan 15 2002 - 20:45:08 EET