Subject: Re: [linux-audio-dev] hdr disk throughput
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Mar 16 2000 - 16:38:10 EST
>> 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 ;)
>>
>
>wasting 25% of the total bandwidth, by writing 32bits instead of 24, is quite
>some bandwidth, that means instead of 38 32bit tracks you would get
>50 24bit tracks, that would be equivalent to your required 24 tracks at 96kHz.
Sorry, wrong numbers Benno.
The limitation on disk bandwidth in a non-interleaved HDR app comes
primarily from disk seeking. As I mentioned in the past, I can get
about 40MB/sec from my 80MB/sec drives when I do random seeks between
fairly big reads. Running Andrew Clausen's test program, it goes down
to 14MB/sec for read+overwrite operations.
Changing the disk sample size from 32 to 24 bits will have very little
effect on the seeking that is needed. And besides, 32 bit sample data
can't be very far away right now. So why not design for it?
--p
This archive was generated by hypermail 2b28 : Fri Mar 17 2000 - 00:16:36 EST