Subject: Re: [linux-audio-dev] design question for HDR
From: Iain Sandoe (iain_AT_sandoe.co.uk)
Date: Mon Apr 03 2000 - 10:56:41 EEST
> It increasingly appears to me that Linux, even with Ultra-2 SCSI
> disks, cannot keep up the required data flow for 24 channel recording
> when the channels go to *individual files* instead of being
> interleaved.
* These observations are more related to avoiding seeks that are unrelated
to the audio files directly - I'm assuming that the performance of the disk
is theoretically sufficient for the audio.
--- 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.I guess that, effectively, the OS, application etc. is on a separate physical controller from the audio data - maybe that will help.
Not very helpful maybe - apart from an 'existence theorem' - although Steinberg did make a fairly big deal about selecting disks with <12ms seek times.
--- In other data acquisition systems I've built [a.k.a. instrumentation HDR] (using much less powerful processors - 25Mhz 68020) I've used pre-allocation of disk space to avoid some of this.
--- I'm not familiar enough with Linux's fs to know about allocation strategies - but another trick (with Microware's OS-9) was to fix up the block allocation rules (it had to be done per physical disk rather than per file descriptor) so that the audio chunks could not get too small.
This also helps avoid: fragmentation the (equivalent of) creating and filling up many Inode tables. many accesses to the bitmaps describing physical disk cluster usage.
--- I've always worried slightly about the Inode approach for real-time data acquisition... maybe an audio fs?... ;-)
>Therefore, I feel that this (interleaving) is a crazy design for an > HDR system,
100% behind avoiding this - it would be a nightmare for some of the apps I have in mind.
Iain.
This archive was generated by hypermail 2b28 : Mon Apr 03 2000 - 11:25:59 EEST