[sdiy] Uniformly distributed noise generator?
rburnett at richieburnett.co.uk
rburnett at richieburnett.co.uk
Mon Jun 17 15:42:57 CEST 2013
Brian, as far as I know that should result in truely white noise, but I
haven't tried it! As long as you clock the shift register enough times
to completely "flush through" each newly injected noise bit, then I
think each output value spat out will be decorrelated from the previous.
It's kind of like oversampling the LFSR and then only keeping every
n'th value, (decimating the output by n.)
I like Tom's suggestion. If you're going to run the LFSR algorithm 8
times between spitting out each noise byte, then it's defintely worth
shifting chunks of the LFSR around in whole bytes and doing the eight
XOR calculations in parallel with a single microcontroller instruction.
That's a neat implementation optimisation.
Of course any oversampling does burn instruction cycles, but you can't
have everything for nothing.
For synthesis applcations where I can get away with 1-bit noise I
personally just take a single bit from a long LFSR noise generator in
the knowledge that the spectrum is flat. (It will sound white even if
the amplitude distribution is not even, or Gaussian, or whatever.) If I
need a 16-bit random word for something like a control signal, I can
usually live with the less than perfect spectrum, or will correct it
with an IIR post-filter.
I also find the sound of the LCG noise generator somwehat more pleasing
than LFSR. Although the mathematicians and cryptanalysts say it has
terrible randomness properties it somehow sounds cleaner to my ears, and
doesn't have those occasional little pitched chirps that you hear in
On 2013-06-17 13:32, Tom Wiltshire wrote:
> If you're careful about the design of your LFSR, you can get
> considerable savings by setting things up to do multiple shifts at
> once like this, at least for software LFSRs.
> Let's say we've got a 32-bit LFSR and we want a 8-bit random byte. We
> could shift the LFSR a single bit 8 times, which gives us 8 "clean"
> bits to use for our random byte. This is fairly slow.
> The quicker way is to do a combined 8-bit shift, so we can move the
> bytes of the register along one place, rather than having to use
> shifts, and stick the XORd byte in the bottom. This gives a good
> efficiency saving, but involves finding tap sequences that won't get
> screwed up by the combined shifting operation.
> There's a PIC ASM example on my website:
> On 17 Jun 2013, at 12:52, rsdio at sounds.wa.com wrote:
>> Thanks for the clarification, Richie.
>> A good solution for the problem described is to run the binary noise
>> multiple times so that all bits are fresh each time. If you want a
>> 16-bit noise
>> sample, then run the shift and XOR operation 16 times before grabbing
>> 16 bits.
>> You can use a noise source of any length, and pull any number of bits
>> out of it
>> provided that you avoid taking "all" of the bits. For a 24-bit bit
>> noise sample
>> you could run the noise source through 24 iterations between each
>> use. This way
>> all the bits are random, not just one. I assume that the spectrum
>> would be flat
>> in this manner.
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
> Synth-diy mailing list
> Synth-diy at synth-diy.org
More information about the Synth-diy