Subject: Re: [linux-audio-dev] hdr disk throughput
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Mar 15 2000 - 23:41:25 EST
>> thus, in a record-all-tracks situation, to offer this feature, you
>> have to be able to stream the given data rate both to *and* from the
>> disk.
>
>Well, I can't se any way around this. Even though you can use any
>amount of buffering you need to reduce the seek stress from
>recording, the data still has to be written to disk, eventually.
That wasn't quite my point. Sure, recorded data has to be written to
disk. The question is: is there any way to avoid *reading* the
data that is just ahead of what you're about to overwrite ?
I conclude that the answer is no, because if we punch out on that
track, we need the playback data to be audible immediately.
Note also the "click" that happens in some programs when they do
this. Its obvious why - they are doing software monitoring, and they
have to switch from monitoring the input signal during the record, to
the output signal during playback. Since these two are necessarily not
in sync with each other (no single-sample processing here, dude!),
there's a click, even though whats been recorded is just fine.
>Of course, you could use that "Pre-Arm" thing some systems use, but
>I'd prefer not see that ever again, if it can be avoided... *Stop*
>playback to select what tracks will record when you press REC during
>playback!? Naah... Cludge. Also, it doesn't protect from overloading
>the disk any better than checking the load before engaging each during
>playback track would do.
Ardour supports dynamic punch in/out just like an Alesis ADAT or M20,
or a Mackie HDR, or a Fostex ... so you can punch in/out *during* recording.
Like the Alesis, you have to enable it (just press a button, only a
boolean in the code) if you want to use it; when disabled, tracks can
only be record-enabled when the transport is in playback or stop
states. The "All Safe" button disables record-enabling any track.
Using Andrew Clausen's test case, it looks to me as though a regular,
moderately fragmented ext2 filesystem on an Ultra 2 disk with nominal
5.2ms seek time can support a lower bound of 14MB/sec throughput from
the disk. That's enough to handle about 38 32 bit/48kHz tracks with
simultaneous read/write On the other hand, it can't support even 24
32/96kHz tracks.
Why 32 bits ? Because the data from most 24bit cards comes in 32 bit
chunks, and unless you want your CPU to burn cycles converting 3 byte
values into 4 bytes ones and back again, I suggest you just burn some
more disk space, and be glad that your HDR program is ready for 32 bit
data when it really shows up ;)
As for fragmentation, I plan to avoid this by using a set of
preallocated "tape" files on each of a dedicated series of
drives. Basically, I'll fill up the filesystem (more or less), and
then you get to pick which "tapes" you want to use. We may well just
have 2 40 minute 24 track tapes per 18Gb disk, for example. This then
more or less removes all fragmentation from the FS.
--p
This archive was generated by hypermail 2b28 : Thu Mar 16 2000 - 07:05:37 EST