Subject: [linux-audio-dev] int16 <--> int32 conversion speed: Was: Re: ardour design question
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat May 27 2000 - 02:40:43 EEST
Mr. Benchmark never sleeps:
:-)
I ran a quick test: ( int16 <--->int32 conversions)
-------------
#include <stdio.h>
#include <stdlib.h>
#define NUM 1000000
main()
{
signed long src[1000];
signed short dest[1000];
int i,u;
for(i=0;i<1000;i++) src[i]=i;
for(i=0;i<NUM;i++) {
for(u=0;u<1000;u+=4) {
dest[u]=src[u] >> 16;
dest[u+1]=src[u+1] >> 16;
dest[u+2]=src[u+2] >> 16;
dest[u+3]=src[u+3] >> 16;
}
}
}
-------
It takes about 19 secs on my Celeron 366
It simulated int32 to int16 conversions
(int16 to int32 takes the same amount of time)
now a little bit of quick math:
1e6 * 1e3 = 1e9 of total samples processed
1e9 / 19 = 52million samples per second
assume a Hammerfall working with the full 52 channels
and working at 48KHz
52million samples /sec / 52 channels =
1million samples/sec per channel
that means since the samplingrate is 48000 Hz
the CPU usage is:
48000 / 1000000 = 4.8 % CPU
and that on a Celeron 366
On a PIII 550 we would have:
4.8 / 550 * 366 = 3% CPU
I prefer to throw away 3-4% CPUI (which will become 1-2% with 700-1000Mhz
machines) in converting int16<--->int32 and being allowed to read and write
tapefiles from a SB16 which were created on a Hammerfall.
And converting gigabytes worth of data form/to 16/32bit to save 3% CPU is not
very useful.
(Plus on an SMP box this become even a smaller issue, since the man load you add
to do conversions is 1.5% )
So Paul , think about it , use the on-the-fly conversion when needed, they add
very little overhead and will make everyone of us happy.
PS:
as for your byteswapping concerns:
in /usr/include/asm/byteorder.h
static __inline__ __const__ __u16 ___arch__swab16(__u16 x)
{
__asm__("xchgb %b0,%h0" /* swap bytes */ \
: "=q" (x) \
: "0" (x)); \
return x;
}
that means swap primitives which use inline assemlby ( xchg)
I have not tested these macros yet,
but I expect similar speeds as in the case above.
In summary: INT16<-->INT32 and BYTE-SWAPPING are not a
problem when using audio datarates, even when using 52 channels simultaneously.
therefore: please use them when needed
I agree that you want to squeeze out the maximum of your Linux box,
but what you are doing here is just overkill.
thoughts ?
Benno.
On Fri, 26 May 2000, Paul Barton-Davis wrote:
> I just added support to ardour for non-interleaved cards. I still have
> to work on the slightly more difficult issue of the sample size, so
> that ardour can be used on 16bit cards (and 20bit), instead of just
> 24bit cards.
>
> One thing that I could do that would make this much easier to
> implement, and more importantly from my perspective, is to require
> that the "tape format" matches the chosen "device format". That is, if
> you are using a "tape" that is using 32 bit samples (or 24-in-32 like
> all current 24 bit soundcards do), you are required to use a soundcard
> that can handle this. Contrarily, if you are using a 16 bit soundcard,
> the "tape" must use 16 bit samples.
>
> In theory, I could convert the data before sending it the card, but
> I'd rather spend those CPU cycles running LADSPA plugins than do
> int32->int16 conversions, for example. It would be even worse if I
> supported endianness swaps too.
>
> Given that most people will be able to use the same soundcard for
> different occasions when they use ardour, and given that the "tapes"
> are just directories containing conventional soundfiles (RIFF/WAVE
> right now) so that external conversion programs can be used, this
> seems to me like an acceptable compromise.
>
> Ardour will give you a nice warning, and perhaps even suggest "sox" as
> a solution, if you try to mix/match tape+hardware formats.
>
> The key design goal is to be able read data from the soundfile into
> memory, and then copy that directly to the soundcard without any
> conversion. Likewise for the other direction.
>
> What do you all think ? Does this sound OK ? If so, I can probably
> have ardour running on 16 bit interleaved soundcards sometime next
> week. Otherwise, it will take a bit longer, but not much :)
>
> --p
This archive was generated by hypermail 2b28 : Sat May 27 2000 - 03:21:04 EEST