Subject: Re: [linux-audio-dev] hdr disk throughput
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Mar 16 2000 - 18:40:17 EST
On Thu, 16 Mar 2000, Paul Barton-Davis wrote:
> >> 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.
Ok , I know that it doesn't scale in a linear fashion,
you will not gain 25% but I think at least 15% in terms of disk throughput.
>
> 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?
>
little effect on the seeking but 25% on disk i/o transfer,
it's a combination of both.
I can't give you exact numbers but I suspect around 15%.
Of course it has to be determined if the 24bit conversion doesn't
kill your CPU.
Anyway I agree: designing for 32bit isn't a bad idea,
with your approach you get 32bit sample support for free.
BTW: how does the hammerfall encapsulate the 24bits into the 32bits.
( are the least significant 8bits zeroed, or the 8 most significant bits all
zero ?)
I think ALSA should pay attention to these formats (24bits into 32bit
encapsulation) , so that channel_info functions can give you accurate infos
about the format to use,
since the app has to know this, when it wants to perform some operations on the
data.
Does ALSA already distinguish between these two formats ?
[ DDD_ ] and [ _DDD ] format (assume D= data byte , _ = padding byte)
Benno.
This archive was generated by hypermail 2b28 : Fri Mar 17 2000 - 01:24:10 EST