Why there are so many bits in sigma-delta audio codec?

On 10/18/2012 7:08 PM, glen herrmannsfeldt wrote:
> robert bristow-johnson<rbj@audioimagination.com>  wrote:
>> On 10/18/12 4:02 PM, Vladimir Vassilevsky wrote:
>
> (snip, someone wrote)
>>>> Why convert to floating point?  32 bit fixed point should have enough
>>>> dynamic range for anything you would want to do to it.
>
>>> Floating point makes perfect sense for audio;
>
>> Vlad.  not always.
>
>> from a POV of code that might live in an FPGA (and i never, ever, ever
>> programmed one of them myself), there are problems with floating point
>> and alignment of bits you might want to keep track of.  regarding
>> quantization and noise shaping.
>
> Floating point is hard to do (efficiently) in an FPGA.
> Well, multiply isn't so bad now that they have hardware
> multiplier blocks, but the pre and post normalization
> for addition are huge!
>
> Well, a little better now with 6 input LUTs so you can do the
> barrel shifter two bits at a time instead of one, but they are
> still huge. (and slow).
>
> For multiply of normalized operands there might be a one bit
> post normalization shift. For add, you have to be able to shift
> either operand up to the full width, and then shift the sum
> to renormalize. (Well, maybe one bit less than full width.)
>
> -- glen


The pre and post normallization for floating point addition are just 
more multipliers.  Rather than multiply by a binary value, the binary 
value is turned into a one-hot value, the output of a binary decoder.

Rick

rickman <gnuarm@gmail.com> wrote:

(big snip on analog and digital level controls)

>> You could do that, and it might be that they do, but could also
>> do something similar to above, with a digital gain control on an
>> analog amplifier. For one, put the audio into the reference input
>> of an ADC and see what comes out the other side.

> Not sure I understand about the reference input.  Are you suggesting 
> that you can use audio into the reference to control the gain?

The usual DAC has an input when then goes through some combination
of switches and resisitors to come out the other side.

Normally the reference is constant, as close to constant as 
you can make it. If instead you put in an audio signal, the
output will be an appropriately scaled version of that signal.

(Likely with switch transients every time you change the level.)

-- glen

rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)
>> Floating point is hard to do (efficiently) in an FPGA.
>> Well, multiply isn't so bad now that they have hardware
>> multiplier blocks, but the pre and post normalization
>> for addition are huge!

(snip)

> The pre and post normallization for floating point addition are just 
> more multipliers.  Rather than multiply by a binary value, the binary 
> value is turned into a one-hot value, the output of a binary decoder.

If you are lucky enough not to need the multipliers for doing 
actual multiplication. 

For something that needs multiply and add, though, you want as
many of each as you can get. 

-- glen

On 10/18/2012 7:44 PM, glen herrmannsfeldt wrote:
> rickman<gnuarm@gmail.com>  wrote:
>
> (big snip on analog and digital level controls)
>
>>> You could do that, and it might be that they do, but could also
>>> do something similar to above, with a digital gain control on an
>>> analog amplifier. For one, put the audio into the reference input
>>> of an ADC and see what comes out the other side.
>
>> Not sure I understand about the reference input.  Are you suggesting
>> that you can use audio into the reference to control the gain?
>
> The usual DAC has an input when then goes through some combination
> of switches and resisitors to come out the other side.
>
> Normally the reference is constant, as close to constant as
> you can make it. If instead you put in an audio signal, the
> output will be an appropriately scaled version of that signal.
>
> (Likely with switch transients every time you change the level.)
>
> -- glen


Yes, I am familiar with that.  You said "ADC" so I didn't get that you 
meant DAC.  I think they refer to that type of device as a multiplying 
DAC.  The issue is bandwidth on the ref input.  Some are made with very 
little bandwidth and others with a lot.

Rick

On 10/18/2012 7:47 PM, glen herrmannsfeldt wrote:
> rickman<gnuarm@gmail.com>  wrote:
>
> (snip, I wrote)
>>> Floating point is hard to do (efficiently) in an FPGA.
>>> Well, multiply isn't so bad now that they have hardware
>>> multiplier blocks, but the pre and post normalization
>>> for addition are huge!
>
> (snip)
>
>> The pre and post normallization for floating point addition are just
>> more multipliers.  Rather than multiply by a binary value, the binary
>> value is turned into a one-hot value, the output of a binary decoder.
>
> If you are lucky enough not to need the multipliers for doing
> actual multiplication.
>
> For something that needs multiply and add, though, you want as
> many of each as you can get.
>
> -- glen

You have to break a few eggs if you want to make an omelet.  You want 
floating point, you need a few multipliers and who knows, maybe a 
carry-save adder or two...

Rick

On 10/18/12 7:00 PM, glen herrmannsfeldt wrote:
> robert bristow-johnson<rbj@audioimagination.com>  wrote:
>> On 10/18/12 5:22 PM, glen herrmannsfeldt wrote:
>
>>> Many C compilers for 32 bit systems (besides the fact that most now
>>> are actually 64 bits) allow for a 32x32 multiply with 64 bit product.
>
>> now that is without pre-casting?  does this work:
>
>>     long multiplier, multiplicand;
>>     ...
>>     long long  product = multiplier * multiplicand ;
>
>> or does it have to be
>
>>     long long  product = (long long)multiplier * multiplicand ;
>
> No, it is with casting but the compiler is smart enough
> to figure out what you meant, not what you said.
>
> Theoretically with the cast (assuming 64 bit long long) it
> should do a 64 x 64 -->  64 product, but since the compiler knows
> what is in the high half it can do it right.

unless the compiler optimization is simply trained to look for this 
specific form, or moreso the MAC instruction:

   long coefficient, sample;
   ...
   long long  accumulator += (long long)coefficient * sample ;

that should optimize to a 32x32 -> 64 and an add, or a MAC if the 
instruction set has it.  and it should do it without doing the cast.

i can sorta see how an optimizer might do this from a more general rule 
of following the high word and seeing that it's not used and eliminating 
the temporary variable.

> (For IA32 that would be four multiplies and a bunch of adds
> to add up the partial products, usually done by subroutine call.)
>
> At least gcc for IA32 could do this right some years ago.
>

dunno IA32, but i thought that the gcc in linux for pc and the gcc used 
for a particular Renesas SH chip we had did *not* do it right, *maybe* 
with an optimizer, but i don't remember that.  my recollection is that i 
needed that cast to make it keep all 64, and then the casting 
instruction cost so i saved coefficients in long long so that they were 
just fetched and not re-cast.

i might've missed something.

> I haven't done much audio FFT, and if doing it in software on a
> traditional (non-DSP) I might do that. But otherwise, 32 bit fixed
> point has enough bits for a 65536 element transform before you
> run out of bits. (If you can do the appropriate multiply.)

i don't quite understand.  you *do* have to multiply by twiddles. 
regardless on how it's decimated, you will get to double-sized words by 
the second pass of the FFT.  i don't think that 16-bits is good enough 
for the twiddle factors, am i wrong about that?


> I wondered some time ago about an FFT for a whole CD.

oh, geepers.  that's a scary thought, numerically.  512 Meg FFT?

why would you want that?  i just can't imagine why the spectrum of the 
composite, intermixed tracks would be more useful than the separate 
spectra of each track.  probably more useful to bust it down further, to 
frames.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On 10/18/12 7:39 PM, Les Cargill wrote:
> langwadt@fonz.dk wrote:
>

>>
>> I've read in many places that people claim that floating point for
>> audio can cause audible modulation of the noise
>>
>>
>
> I'd be skeptical of that claim. Every DAW in the world uses float32
> for internal processing. Indeed, the last dominant 16 bit only DAW had
> trouble with truncation, which *is* highly audible.
>

there is always noise modulation with floating point.  dunno that it is 
so audible.  maybe, maybe not.

for float32, the quantization noise might be expected to be 144 dB lower 
energy than the audio signal, whether it's loud or very quiet.

but for some experimental or proprietary floating-point format with much 
fewer mantissa bits (i've seen this on something i worked on for some 
unnamed company), maybe the noise modulation is audible.  but the signal 
is being modulated the same way.

BTW, gotta compare apples-to-apples.  16-bit fixed cannot compare well 
to 32-bit *anything*, neither float nor fixed.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

robert bristow-johnson wrote:
> On 10/18/12 7:39 PM, Les Cargill wrote:
>> langwadt@fonz.dk wrote:
>>
>
>>>
>>> I've read in many places that people claim that floating point for
>>> audio can cause audible modulation of the noise
>>>
>>>
>>
>> I'd be skeptical of that claim. Every DAW in the world uses float32
>> for internal processing. Indeed, the last dominant 16 bit only DAW had
>> trouble with truncation, which *is* highly audible.
>>
>
> there is always noise modulation with floating point.  dunno that it is
> so audible.  maybe, maybe not.
>

My understanding is that it is not. I say that - it might be possible
to produce a test vector that exposes it, but for signals found in 
nature, it's just too far down.

> for float32, the quantization noise might be expected to be 144 dB lower
> energy than the audio signal, whether it's loud or very quiet.
>

Right - although properly managed digital audio has no audible
quantization noise ( it's dithered ).

> but for some experimental or proprietary floating-point format with much
> fewer mantissa bits (i've seen this on something i worked on for some
> unnamed company), maybe the noise modulation is audible.  but the signal
> is being modulated the same way.
>

Could well be. i have to wonder why anyone would do that, though :) Bog
standard what's-on-a-PC is pretty good for this.

> BTW, gotta compare apples-to-apples.  16-bit fixed cannot compare well
> to 32-bit *anything*, neither float nor fixed.
>
>

Not for math, no. I find 16 perfectly fine for
storage, though. I have the habit of normalizing
stored tracks to -25dB RMS ( all math in float ) and
storing as 16 bit wav.

--
Les Cargill

Robert Adams wrote:
> Another reason to keep those bits is that there is often a digital
> volume control in the Codec, so you would like to be able to turn
> down the amplitude by 20 db or so without losing any of your dynamic
> range. Analog volume controls are becoming a thing of the past.
>
>
> Bob
>

The volume control in the codec should be using floats for
math - no raise of the noise floor if you do it right.



--
Les Cargill

rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)

>>>> You could do that, and it might be that they do, but could also
>>>> do something similar to above, with a digital gain control on an
>>>> analog amplifier. For one, put the audio into the reference input
>>>> of an ADC and see what comes out the other side.

>>> Not sure I understand about the reference input.  Are you suggesting
>>> that you can use audio into the reference to control the gain?

(snip)

> Yes, I am familiar with that.  You said "ADC" so I didn't get that you 
> meant DAC.  I think they refer to that type of device as a multiplying 
> DAC.  The issue is bandwidth on the ref input.  Some are made with very 
> little bandwidth and others with a lot.

Oops. Both have been in this thread, and sometimes my fingers type
the wrong one. Well, could be an actual typo, but more often I am
thinking one and intending the other.

-- glen