Subject: Re: [linux-audio-dev] int16 <--> int32 conversion speed: Was: Re: ardour design question
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue May 30 2000 - 20:17:01 EEST
On Tue, 30 May 2000, Paul Barton-Davis wrote:
> Unfortunately, this is necessarily not the correct conversion. It
> certainly is not portable. To quote Harbison & Steele:
>
> "Because different implementations may use different representations
> for signed integers, and because implementations using the same
> representation may nevertheless differ in their handling of right
> shifts on signed integers, the result of applying the shift
> operators << and >> to signed operands may not be portable. We
> recommend using << and >> only on unsigned operands for portable
> code."
>
> The problem is that the 24-bit-in-32 system uses the sign
> bit. Preservation of the sign-bit on right-shift is
> compiler-specific.
normally, when you cast a signed int16 to a signed int32
it's sign extended , that means you should be able to apply the shift
without problems.
But for saeftly the configure script should check this before the actual
compilation happens.
Anyway my intention was to show the order of magnitude of performance
loss when doing conversions.
And I think that it's clear that the loss is not substantial on today's boxes
( a few %)
>
> Moreover, its far from clear that this is the correct way to do this
> conversion. You're just truncating the sample to include the high 16
> bits. There are other options, which some people might argue make more
> sense.
make it configurable so everyone will be happy.
( like mapping 16bit word to the lower bits (or with an arbitrary factor) of the
24bit word etc)
>
> Still, these are probably all nit-picking details. I take your point.
that was my goal.
:-)
>
> >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.
>
> OK, this is a legitimate attitude, and one I will try to
> support. Perhaps it will be a compile-time option. That way, if people
> (like me) want to build a version optimized for use with no
> conditional format conversion, we can.
Why a compile time option ?
How about simply embedding the conversions in your
memcpy_* functions so that you can use the optimized (no conversion at
all) version in the case that src and target datatypes correspond.
In this case the runtime overhead is zero (or almost) compared to your
version with the hardcoded S32 datatype.
PS: forget the Hammerfall + DMA problem issue :-)
I thought my drive would die right now, because there was either a powercable
not functioning properly and/or the stalled CPU fan on the same cable which
may have caused some weird interferences that caused all the mess.
(IDE reset etc)
And because of Murphy's Law, I was just fiddling around with the Hammerfall ,
and obviously thought it would be the soundcard's fault.
:-)
Benno.
Benno.
This archive was generated by hypermail 2b28 : Tue May 30 2000 - 21:13:19 EEST