Re: [linux-audio-dev] int16 <--> int32 conversion speed: Was: Re: ardour design question

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

Subject: Re: [linux-audio-dev] int16 <--> int32 conversion speed: Was: Re: ardour design question
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ti touko  30 2000 - 17:23:33 EEST


In message <00052701591903.03727_AT_smp>you write:
>Mr. Benchmark never sleeps:
> :-)

converting 32bit to 16 bit:

> 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;
> }
> }
>
>}
>-------

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.

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.

Finally, your conversion is only doing in one direction. The
corresponding one:

              dest[n] = src[n] << 8;

has a similar set of problems. Its also arguably not the best one,
since it maps a peak 16bit signal to a peak 24bit signal. Sometimes,
this would be the right thing to do, sometimes it would not.

Still, these are probably all nit-picking details. I take your point.

>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.

--p


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

This archive was generated by hypermail 2b28 : ti touko  30 2000 - 18:13:01 EEST