Subject: Re: [linux-audio-dev] hdr disk throughput
From: Jaroslav Kysela (perex_AT_suse.cz)
Date: Thu Mar 16 2000 - 18:14:57 EST
On Fri, 17 Mar 2000, Benno Senoner wrote:
> 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)
Yes, you described the difference between ?24?E and ?32?E formats.
Check manual for alsa-lib. The setup structure also offers 'used most
significant bits per sample' to determine which bits are physicaly
connected.
Jaroslav
-----
Jaroslav Kysela <perex_AT_suse.cz>
SuSE Linux http://www.suse.com
ALSA project http://www.alsa-project.org
This archive was generated by hypermail 2b28 : Fri Mar 17 2000 - 01:51:39 EST