[sdiy] Digital Noise, FYI

[Magnus Danielson]

On 02/16/2011 04:25 PM, Tom Wiltshire wrote:
>
> On 16 Feb 2011, at 14:58, Magnus Danielson wrote:
>
>> The main problem they had was that they where too short. Bad implementation, but not necesserilly a bad solution as such.
>
> They were too short, but also too slow.

That becomes a side-consequence of them being too short. . . . . . . . .

> The MN5837 is a 17-bit LFSR, and runs at 24-56KHz according to the
> datasheet I found. That's 131,072 samples which will be over in
> 2.34 seconds at 56KHz.

That will be 131,071 states, since you can't have the state with all 
zeros in there, since it would only wrap around onto itself. The 
polynomial avoids this if stated in any other state...

> Richie B. suggested recently that 80KHz is a reasonable minimum
> clock rate for noise which is flat (white) in the audio band.
> That fits with my own experiments.

I would use higher clock-rates than that. A fixed 1 MHz or something.

(Oh, and please write 80 kHz and not 80KHz. - you do need a space 
inbetween the numbers and the prefix, and the k for kilo shall be the 
small one and not K)

> If you use a 32-bit LFSR, you get 2^32 samples = 4.3 billion, which
> takes 11.9 hours even at 100KHz. By the time you're up to Scott G's
> 64-bit LFSR (can you tell he uses FPGAs?!) you're getting into tens
> of millions of years.

No, it would be 4,3 miljards samples... but this only shows that the 
designator for 10^9 is ambiguous in the English language and maybe we 
should just avoid it?  4,29 GSamples is more accurate.

But regardless, you are preaching to the choir... I'm already convinced. 
See the archives...

Also, you do miss out one particular detail... when filtering digital 
noise with a resonance for instance, the noise density needs to be of 
such density that it actually haves as noise and not just a cluster of 
orderly sines.

> So if you make it about twice as long and twice as fast as the
> MN5837, you'd actually have a very good source.

Indeed. This is why I have argued that just moderate increases in length 
allows for higher clock rate, denser noise and removal of beating.

So, maybe now you grasp what I quite dryly concluded as:

"The main problem they had was that they where too short. Bad 
implementation, but not necesserilly a bad solution as such."

Cheers,
Magnus