Re: [linux-audio-dev] hdr disk throughput

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] hdr disk throughput
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Mar 16 2000 - 11:08:19 EST


On Thu, 16 Mar 2000, Paul Barton-Davis wrote:
>
> 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 ;)
>

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.

Ok 32 <---> 24 bit conversion burns power but it has to be determined how
much power this burns, compared to the disk bandwidth saving.

I am not sure if Intel CPUs allow writing 32bit values at unaligned data
locations (not multiple of 4) but using this technique ,
the only overhead you get while writing 32bit samples as 24bit values
to disk is the slower unaligned mem access.

let's take an example: assume we have several 32bit words
A , B , C , etc , and that 32bit data is organized in 4 bytes
(I use bigendian here, I am not sure if littleendian makes this impossible) ,
A3 A2 A1 A0 is the A 32bit word , assume A3 A2 A1 ( 3bytes contain the
relevant 24bit data).
In this case we will just write the B 32bit word at offset 3 instead of offset
4, which will overwrite the A0 which doesn't carry relevant data.

Or alternatively use: ( treat the input and output buffers as arrays of chars)

outbuf[outpos] = inbuf[inpos];
outbuf[outpos+1] = inbuf[inpos+1];
outbuf[outpos+2] = inbuf[inpos+1];
inpos += 4;
outpos += 3;

(hoping that the cache of modern CPUs speeds up this kind of operations)

I think the best way is to do perform some benchmarks in order too see
it it is worth the trouble.

Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Mar 16 2000 - 18:38:43 EST