Subject: Re: [linux-audio-dev] design question for HDR
From: Iain Sandoe (iain_AT_sandoe.co.uk)
Date: Mon Apr 03 2000 - 19:32:38 EEST
>>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.
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.
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.
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...
Iain.
This archive was generated by hypermail 2b28 : Mon Apr 03 2000 - 20:45:50 EEST