Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

[<be...@ga...>]

Scrive Mark Knecht <mar...@co...>:

> On Tue, 2003-10-28 at 09:31, be...@ga... wrote:
> 
> > excellent !
> > the mlock and sched_setscheduler warnings are becaue a regular user
> > cannot call these functions.
> > It might occur you get mlock errors as root too, but this means
> > that the preloaded RAM size (preloadsize * number of samples in a GIG
> file)
> > exceeds the available physical memory.
> > See my response to Robert.
> > 
> 
> Sorry that I haven't gone back through the archives yet, but educate me.
> Is this revision streaming from disk? I understand the architecture
> where the first portion of the loaded gig files are in memory and then
> GSt has to do a seek and start getting the rest of all notes being
> played. 
> 
> Is this what you are doing in this revision? 

Yes any disk based sample must use that method (Kontakt, Halion etc) because
the disk is too slow to provide low latency sample triggering.

> 
> And what's the current legal state of the 'stream from disk' patent? Has
> anyone determined if this is a problem for this tool? 


In 1991-1992 I worked for a small italian multimedia company
Digimail S.r.l that wrote games and CDROM multimedia for the Amiga
and CD32 (A set top box based on the Amiga).

They produced the italian version of the "Grolier Encyclopedia" multimedia
CDROM.
At that time I wrote low level routines needed for the audio part
of the encyclopedia.
One of them was exactly a set of routines that permitted to preload a small
 initial part of samples in RAM (in 8bit 8SVX format) and then when the
high level encyclopedia software requested it,
it could to trigger and start them them with low latency.
 while streaming the samples from a mass storage device (either HD or CDROM).

at that time PCs were only able to produce annoying BEEEEPs :-)

precaching initial parts in RAM is basically done by any kind of application
that streams data from an external source (be it from mass storage, network
etc). This is "technology" is as old as the mass storage device.
So then people talk about the RAM caching patent I'm amazed that people
take it seriously and have concerns if linuxsampler uses ram caching.

Should I sue the world because I have prior art in that field ? 
(the whole streaming routines were only a couple of dozen lines of 
MC68000 assembly).

You know pure software patents are illegal in EU anyway and most of our
developers (me, Christian, Steve H.) are living there so we are not doing
anything unlawful here.
(plus keep in mind I have prior art so even if I resided in the US I would
be 100% ok).
The disk streaming part was entirely developed by me (see old evo sampler
versions about 3 years ago), I take the full resposibilities for that,
so other developers do not need to fear anything related to this topic.

If you feel you are breaking a patent just don't use linuxsampler or if you
want we firewall the server in a way that only EU people can download the code.
Do you want this ?
(of course the previous sencence was meant to put between <SARCASM></SARCASM>
tags :-) )

Plus try to think logically: if this patent was really non bogus then
why were not Steinberg (Halion) and NI (Kontakt) sued out of the market.
NI appeared very late on the audio scene but seems that most of 
disk based sampling users are switching to Kontakt.
A potential killer for Giga.
(think about LS .... a bunch of poor open source developers, no money
to extract)

BTW: did you know Invision patented the playback of samples from RAM on a PC ?
This would probably make all softsynths/samplers in existence
(probably hundreds) illegal.
OTOH there is certainly lots of prior art here too and this is why 
Invision did not go against competitors ?
Seriously, I don't care.

I think the US is risking to be leaved behind the rest of the world in terms
of IT because the current bogus US software patent system is killing
 innovation.

Can we get back to linuxsampler technicals ?


> I typically load
> 16 libraries in GSt as a starting point. (Good Sounds.gsp) They
> encompass about 6GB of disk space - obviously too much for memory...
> 
> (And I do understand that you are only handling a single gig file and
> not a performance file at this time.)

We will use our own performance file format (perhaps XML).
LS is not a GSt copy it only loads GIG files just like many other
softsamplers.

PS: Mark do not take my rant personally it is just that I hear the same
questions popping up again and again and I'm amazed that people do not
realize how weak a patent about "loading a piece of file in RAM"  is.

I'd be curious where the world would be if Euler, Newton, Leibnitz etc all
patented their stuff  :-)

cheers,
Benno




-------------------------------------------------
This mail sent through http://www.gardena.net