The $10000 Hi-Fi

On 5/7/2015 12:51 PM, Steve Pope wrote:
> rickman  <gnuarm@gmail.com> wrote:
>
>> I am also a doubting Thomas, but I'm willing to leave some room for
>> self-doubt (just not a lot).  I do know that truncation can do funny
>> things as the frequencies in the signal beat with the truncation as well
>> as each other, producing non-linear distortion.  But at -144 dBFS it is
>> hard to imagine it would be in any way audible.   In 16 bits (-96 dBFS)
>> I'm willing to acknowledge magic ears can hear it easily (my ears are
>> far from magic).
>
>> It is always possible that there was some flaw in the original design
>> that got fixed when switching to rounding.  I just can't imagine anyone
>> can hear the effects of 24 bit arithmetic.
>
> Within a digital algorithm that includes feedback, switching from
> undithered truncation to undithered rounding can make a large (generally
> beneficial) difference in behavior, or even stability.

Can you provide more info on this or possibly a reference?


> But viewed in isolation, truncation vs. rounding, without dithering,
> both introduce (often undesired) signal-correlated noise at similar levels.
>
> Steve
>


-- 

Rick

On 5/7/2015 9:07 AM, glen herrmannsfeldt wrote:
> robert bristow-johnson <rbj@audioimagination.com> wrote:
>
> (snip, I wrote)
>>> I use a pretty simple LFSR generator, based on CRC32, to generate
>>> bits, shift and add.
>
>> oooh, glen, that can't be good.  are you using the LFSR to just get
>> random *bits* (like +1 and -1) that are white.  then it works good.  but
>> if you're using the whole shift register for a random number, that's not
>> so good.  that's because 50% of the time the following register value is
>> related to the current by a factor of 2.  and the spectrum of this is
>> *not* white but is low-pass.
>
> It runs on the input data stream, so there are 24 shifts before
> the next one is used.

I would have thought one bit of noise would be enough.  I saw in a paper 
referred to earlier that the noise appeared to be as large as three bits 
(+3, -4).  Is multiple bits really needed?


> Most likely there is plenty of noise in
> the low bits of the input 24 bit data. If the input is really
> quiet, it could have some zeros in the high bits, but there should
> still be enough noise in the low bits. These are recorded with a
> live audience, but the amplifier noise is likely enough to keep
> the lowest bits pretty random.
>
> I could actually hear the difference, turning my 100W amplifier
> all the way up, and putting my ear right next to the speaker.
> If a normal signal came though, it might have destroyed the
> speaker, so it is pretty far down.

I think that is the point.  Even at 16 bits the noise is really low, but 
on 24 bit data how could anyone hear it?


> But yes, there are probably better sources. If I wanted to convert
> 16 bit down to 8 bit, I might worry more about it.
>
> -- glen
>


-- 

Rick

In article <mig5tr$4ok$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:

>On 5/7/2015 12:51 PM, Steve Pope wrote:

>> Within a digital algorithm that includes feedback, switching from
>> undithered truncation to undithered rounding can make a large (generally
>> beneficial) difference in behavior, or even stability.

>Can you provide more info on this or possibly a reference?

Good question.  This has been in my DNA for so long that
I can't remember where/if I encountered it in the literature.
Possibly in very standard DSP textbooks, but I'll have to
do some browsing to find it.

Steve

rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)
>>>> I use a pretty simple LFSR generator, based on CRC32, to generate
>>>> bits, shift and add.

(snip, Robert wrote)
>>> oooh, glen, that can't be good.  are you using the LFSR to just get
>>> random *bits* (like +1 and -1) that are white.  then it works good.  but
>>> if you're using the whole shift register for a random number, that's not
>>> so good.  that's because 50% of the time the following register value is
>>> related to the current by a factor of 2.  and the spectrum of this is
>>> *not* white but is low-pass.

>> It runs on the input data stream, so there are 24 shifts before
>> the next one is used.
 
> I would have thought one bit of noise would be enough.  I saw in a paper 
> referred to earlier that the noise appeared to be as large as three bits 
> (+3, -4).  Is multiple bits really needed?

I also use this for level adjustment. If the record level is a little
low, I can shift 7 or 6 bits. But the whole idea behind dithering
is to get some value out of the bits that are being left behind.
 
(snip)

>> I could actually hear the difference, turning my 100W amplifier
>> all the way up, and putting my ear right next to the speaker.
>> If a normal signal came though, it might have destroyed the
>> speaker, so it is pretty far down.
 
> I think that is the point.  Even at 16 bits the noise is 
> really low, but on 24 bit data how could anyone hear it?

For the test, I might have gone down to the point where only
about six bit were left. So, yes, most likely you won't hear it.
For the quite passages (in classical music), one could turn up 
the volume control, but then one might get surprised when it
gets suddenly loud. 

Also, I could use the low 16 bits of the 24 bit data.

-- glen

On Thu, 7 May 2015 16:59:21 +0000 (UTC), spope33@speedymail.org (Steve
Pope) wrote:

>>The code works in double precision floating point, scales as necessary
>>to make 2^(N-1) represent full-scale, adds the dither (a fractional
>>value), rounds [add 0.5 then floor()], and then re-scales to 16 bits.
>
>That would be correct.

RB-J generally gets things like this right.

Steve Pope <spope33@speedymail.org> wrote:

(snip)
> That would be correct.
 
> Tangentially, a vast range of fixed-point values and operations
> can be cast to and from doubles without deviating from 
> bit-exactness, that is, the result will be the same as if
> you tediously programmed it entirely in fixed point.  Eseentially all the 
> projects I've worked on in the past decade or so have been simulated
> in this manner.

It isn't all that tedious.  Verifying that the floating point
implementation actually does what you say might be tedious, though.

-- glen

Greg Berchin  <gjberchin@chatter.net.invalid> wrote:

>On Thu, 7 May 2015 16:59:21 +0000 (UTC), spope33@speedymail.org (Steve

>Pope) wrote:
>
>>>The code works in double precision floating point, scales as necessary
>>>to make 2^(N-1) represent full-scale, adds the dither (a fractional
>>>value), rounds [add 0.5 then floor()], and then re-scales to 16 bits.
>>
>>That would be correct.
>
>RB-J generally gets things like this right.

Okay, I guess I lost track and didn't realize you were 
describing RB-J's code.

Steve

On Thu, 7 May 2015 17:12:37 +0000 (UTC), spope33@speedymail.org (Steve
Pope) wrote:

>In article <mig5tr$4ok$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>
>>On 5/7/2015 12:51 PM, Steve Pope wrote:
>
>>> Within a digital algorithm that includes feedback, switching from
>>> undithered truncation to undithered rounding can make a large (generally
>>> beneficial) difference in behavior, or even stability.
>
>>Can you provide more info on this or possibly a reference?
>
>Good question.  This has been in my DNA for so long that
>I can't remember where/if I encountered it in the literature.
>Possibly in very standard DSP textbooks, but I'll have to
>do some browsing to find it.
>
>Steve

Truncation is biased, and feeding back truncated signals can lead to a
growing DC offset.   I'm always very careful in comm systems to make
sure that accumulated pipeline stages get rounded whenever possible,
since even a small DC bias can cause substantial performance
degradation.

Not sure if that's what you're thinking about, but forgetting to round
in some stage buried somewhere has caused a lot of grief for this
reason.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:

>Steve Pope <spope33@speedymail.org> wrote:

>> Tangentially, a vast range of fixed-point values and operations
>> can be cast to and from doubles without deviating from 
>> bit-exactness, that is, the result will be the same as if
>> you tediously programmed it entirely in fixed point.  Eseentially all the 
>> projects I've worked on in the past decade or so have been simulated
>> in this manner.

>It isn't all that tedious.  Verifying that the floating point
>implementation actually does what you say might be tedious, though.

Yes, in some scenarios.  Ususally for me the design flow requires 
matching such data against the implementation (RTL) anyway, so it's 
not really an extra verification step. And in practice
I actually can't recall a case where a mismatch could be traced to 
imprecision within the double-precision arithmetic.  

But I have sometimes used the "double double" type if I saw this might
be a concern.  If for example you had a 24x24 multiplier and then
accumulated many values of the output of this multiplier,
it could lose precision by overflowing a 53-bit word.  (This
situation could arise, for example, when one is computing a second-order
statistic on a long stream of data.)

If you really want to avoid any tedium, in a way that is air-tight, you 
can use a full implementation of the IEEE 1666 fixed-point types.


Steve

rickman  <gnuarm@gmail.com> wrote:

>I would have thought one bit of noise would be enough.  I saw in a paper 
>referred to earlier that the noise appeared to be as large as three bits 
>(+3, -4).  Is multiple bits really needed?

RPDF (which is historically what "dithering" would mean without
further qualifiers) uses a theoretical rectangular distribution
between [-1/2,+1/2], scaled by the weight of the least significant
bit after dithering/rounding.

If you had one bit, you might use the values -1/4, +1/4 to
approximate this distribution.

If you had two bits, you might use values from among -3/8, -1/8,
+1/8, +3/8.

If you had three bits, you might use values from among -7/16, -5/16,
-3/16, -1/16, 1/16, 3/16, 5/16, 7/16.  As you can see the more
bits, the better you are approximating the theoretically-sound
rectangular distribution.

Or you might consider over-dithering for one of any number of reasons.

"Mild 3-bit overdithering" could use the set -5/8, -7/16, -1/4, -1/16,
1/16, 1/4, 7/16, 5/8.

Absent futher information, the latter (or its 4- or 5- bit variant)
might be my first choice, but who knows, one bit might work.

Steve