Subject: Re: [linux-audio-dev] design question for HDR
From: David Olofson (david_AT_gardena.net)
Date: Wed Apr 05 2000 - 04:08:29 EEST
On Mon, 03 Apr 2000, Iain Sandoe wrote:
> >>I successfully recorded 12 tracks simultaneously with VST & MacOS on
> >>604e/233 + SCSI-1 (i.e. nothing very spectacular by current standards) both
> >>to internal IBM scsi disk & external (JAZ) cartridge . No interleaving of
> >>files - however, there's no VM involved. This is the most I can do with my
> >>12/12 I/O card - but there did seem to be at least a little steam left.
> >
> > Recording is not a problem, and never has been. Playback is the
> > problem. Recording is easy - you just use enough memory to hide the
> > fact that the disk+controller+buffer-cache can't keep up in the
> > short term. But playback is different - if you don't have the data
> > when you need it, you don't have it ...
>
> Now this is interesting...
> I have (on the same system) played back many more than 12 tracks - when
> doing mix-downs [the most IIRC was 32 - although not with contiguous audio
> on all].
>
> On the "just use enough memory side" VST uses truly colossal buffers - I
> often set it to 256kb per track.
> When you hit stop or move the transport there is a massive burst of disk
> activity as the buffers are pre-filled - perhaps it is this (overkill?) that
> allows it to keep up on average.
That's not overkill. You have to use that kind of buffering to keep
seek overhead at a reasonable level. Something like
seeks/second = # of tracks * (1 / buffer duration)
should describe the problem, overhead for sector allocation and that
kind of things not taken in account.
> OTOH this does mean that a long looped section of replay gets a stutter when
> the loop wraps - accompanied by the same massive burst of disk activity.
This is a bug. (Cakewalk 8.0 and later doesn't do this, for example -
it loops perfectly with or without audio.) It's just a matter of
telling the "disk butler thread" about the loop, rather than doing
the quick'n'dirty stop/rewind/start hack.
> Another thought occurred - the possibility that the down-side of many
> threads (perhaps one per track - I'm sure VST uses the multiprocessing lib -
> which allows pre-emptive threads on MacOS) might be mitigated by an improved
> behaviour to blocking by IO.
I don't think any normal file system is capable of optimizing
multithreaded access of this kind to anything near the performance of
a singe disk butler thread per disk.
> How much seek optimisation does the Linux fs do?
> Is it possible to influence this from user space?
>
> I think that, maybe, I don't understand the behaviour that you want from
> your system - because large buffers is too obvious...
I think it might have to do with this play/record and punch in/out
thing...
BTW, I don't think it is obvious to everyone - just look at the
recommended settings for Cakewalk! My machine works fine with around
30 tracks, but would die at around half that load with the largest
buffer size they consider sensible. (And this is still a program
that's supposed to have separate threads for disk I/O and processing!)
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 06:49:59 EEST