Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Tuesday 21 January 2003 00.57, Mark Knecht wrote:
> > > The problem of GS is that it is a
> >
> > [...]
> >
> > So, in short, GS is a Windows specific performance hack, while
> > Halion is a plugin sampler Done Right - only on the wrong OS.
>
> Ah, but GS has the library that the other's wish they had. (And
> that I've already invested a couple grand in, so let's not get
> religious and go some other direction! There would be huge value in
> being able to load GSt libraries into ANYTHING we do.

Well, I was talking about software design - not file formats. Of=20
course, LinuxSampler should load and play *anything*! :-)


> GSt crashes all the time when running on a PC with other apps. It's
> actually pretty stable on it's own machine.

That's to be expected when abusing an OS like that, it seems... And=20
that's why I gave up on audio programming on Windoze a few years ago.


> > > MIDI sequencing and a sampler/synth engine on the same box is
> > > not a problem since sequencing only takes a fraction of the
> > > available resources. If you add HD recording to the equation,
> > > then the workload increases significantly but nothing speaks
> > > against of runnning both the HDR and the sampler software in
> > > the same box.
> >
> > Except that they need separate disks, unless they share the disk
> > butler, I think... Just adding another disk would probably be
> > acceptable to most serious users, though.
>
> There's a lot going on these days on the sequencer side with
> notation. I expect that I will run 2-3 computers to really do what
> I want to do, but that's me.

Well, I use two with Audiality, because I have yet to find a Linux=20
sequencer that I can compile, that does what I need, and that doesn't=20
get on my nerves. Still using Cakewalk on Windoze, that is. (Although=20
that's getting on my nerves as well - and not only for political=20
reasons! *heh*)


> I can already bring my disks to their knees just running Ardour. I
> doubt my current, sub-2GHz Athlon XP would run this sampler at the
> level I push GSt, which is 10-15 stereo libraries and maybe 100
> voices sustained over time. Hans Zimmer, doing movie scores, has
> talked of pushing multiple copies of GSt to the level of 300-500
> voices sustained. Those guys are using arrays of SCSI drives. It
> can be a lot bigger than just another drive.

Sounds like they have some serious seeking overhead there... I had 16=20
stereo tracks playing on a 5 GB 5400 rpm drive under Windoze 3.11, so=20
I know for a fact that it's possible to get at least 60% of the=20
nominal sustained rate of the drive. IIRC, I used 400 kB of buffering=20
per track for that, and you need to multiply that with the number of=20
tracks to keep the seeking overhead constant. That is, 800 kB for 32=20
tracks, or 8 MB (!) for 320 tracks. Yes, this is *per track* buffer=20
size.

Indeed, SCSI disks are generally faster when it comes to access=20
times, but not *that* much faster. RAID arrays (with the same data on=20
all disks) only divide average access times by the number of drives,=20
or something like that.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- 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 -'
   --- http://olofson.net --- http://www.reologica.se ---