## brp-pacu-info

 Re: [Brp-pacu-info] Pink noise generator (accuracy) From: Brian Phelps - 2012-11-12 02:41:09 Attachments: Message as HTML ```It does appear that the pink noise is attenuated by some type of additive LPF action of the filtered sequence. If you read this link you'll see that the filter is not perfect but is supposed to be really close down to 9.5 Hz about +/- 0.05 dB. The code we use is pk3 from http://www.firstpr.com.au/dsp/pink-noise/ This is an approximation to a -10dB/decade filter using a weighted sum > of first order filters. It is accurate to within +/-0.05dB above 9.2Hz > (44100Hz sampling rate). Unity gain is at Nyquist, but can be adjusted > by scaling the numbers at the end of each line. > > (This is *pk3 = (Black) *Paul Kellet's refined method in Allan's > analysis.) > b0 = 0.99886 * b0 + white * 0.0555179; > b1 = 0.99332 * b1 + white * 0.0750759; > b2 = 0.96900 * b2 + white * 0.1538520; > b3 = 0.86650 * b3 + white * 0.3104856; > b4 = 0.55000 * b4 + white * 0.5329522; > b5 = -0.7616 * b5 - white * 0.0168980; > pink = b0 + b1 + b2 + b3 + b4 + b5 + b6 + white * 0.5362; > b6 = white * 0.115926; Here is the PN algorithm in BRP_PACU: white = ((float) (rand() % 10000) - 10000.0 / 2.0) / 999900.0; > // Shamelessly taken from > http://www.firstpr.com.au/dsp/pink-noise/ > // Based on a filter by Robert Bristow-Johnson > b0 = (0.99886 * b0 + white * 0.0555179) * scale_it ; > b1 = (0.99332 * b1 + white * 0.0750759) * scale_it; > b2 = (0.96900 * b2 + white * 0.1538520) * scale_it; > b3 = (0.86650 * b3 + white * 0.3104856) * scale_it; > b4 = (0.55000 * b4 + white * 0.5329522) * scale_it; > b5 = (-0.7616 * b5 - white * 0.0168980) * scale_it; > tmp_time = tmp_time + 1.0 / 44100; > if (fill_it->pink_muted) > pink_noise[k] = (b0 + b1 + b2 + b3 + b4 + b5 + b6 + (white > * 0.5362) * scale_it) * (pow(2.0, fill_it->volume_pink + 29) / (pow(2.0, > 32.0))); > else > pink_noise[k] = 0.0; > b6 = (white * 0.115926) * scale_it; > > > The application is intended to be used for the Transfer Function which technically could use any signal with a decent representative spectrum. A couple dB down at 60 Hz on the low end would make very little difference in TF or impulse response measurement due to the way the transfer function works. I typically use an external PN generator and I have never heard a difference between the internal PN gen in BRP_PACU and my Neutrik Minirator. The real question here is why is this claimed as +/- 0.05 dB/octave but turns out to have a rolloff below 120 Hz? Did we do something wrong in the implementation? Someone could inspect this further in Matlab and see whats going on here if they wanted to. There are other ways of generating pink noise. If someone submits a patch I'll take it ;) It could even be based on how they do it in Jabra. Otherwise I think I'll just put a disclaimer on the PN generator in the docs. The PN accuracy is really is not crucial to the intended use of the application. Other applications using a single FFT rely heavily on this though and someone could get themselves into trouble if they expect the PN to be exactly -3dB/octave 20-20kHz. So patches anyone or should I just update the docs to reflect this? ---- Sent using Manchester encoded voltage pulses over a link to form packets which contain other higher level packets along with this message and signature which also contains the IP address to the destination and passing through many router links which may queue the packets at different amounts and possibly arrive out of order only to be reordered by the TCP/IP stack in the kernel of the recipient's server and displayed by a program running in userspace on the device you are currently looking at. On Fri, Nov 9, 2012 at 2:11 PM, Brian Phelps wrote: > I will look at that this weekend. The pn algorithm is taken from some code > I found on the dsp news group > > sent from a touch screen with a tiny keyboard and speech to text. Please > don't judge me :) > On Nov 9, 2012 1:06 PM, "Knut Reichelt" wrote: > >> It's mesured directly though Jack. I didn't use the transfer function >> I've only connected in Jack the output from Brp-pacu to input canal 1 >> (measured) instead of canal 2 (reference) >> and captured the plot (red). Than I've done the same with the pink output >> from Japa (green). >> I've just done that because I heard a difference between the pink noises >> of the two programs. >> You can also see the difference when you capture the outputs with Japa. >> >> >> >> Am 09.11.2012 17:30, schrieb Brian Phelps: >> >> I wil check this on my home system tonight. I have never noticed a >> problem. Does it show up as flat when you use the transfer function? >> >> Also is this measured through your audio card I/o or using jack? >> >> sent from a touch screen with a tiny keyboard and speech to text. Please >> don't judge me :) >> On Nov 9, 2012 11:25 AM, "Knut Reichelt" wrote: >> >>> Hallo, >>> I've noticed that the pink noise from Brp-pacu is not really correct >>> below 120Hz. >>> See the attached picture: green is pink noise from japa and red from >>> Brp-pacu. >>> How it comes? >>> Is something wrong with my system or is it a program issue? >>> >>> sorry for my bad English. >>> >>> best >>> knut >>> >>> -- >>> °°° >>> Knut Reichelt >>> >>> Watergate Club >>> Oberbaum Gaststättenbetriebs GmbH >>> Falckensteinstr.49 >>> 10997 Berlin >>> >>> mob. +49179 293 63 99 >>> http://www.water-gate.de >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_nov >>> _______________________________________________ >>> Brp-pacu-info mailing list >>> Brp-pacu-info@... >>> https://lists.sourceforge.net/lists/listinfo/brp-pacu-info >>> >>> >> -- >> °°° >> Knut Reichelt >> >> Watergate Club >> Oberbaum Gaststättenbetriebs GmbH >> Falckensteinstr.49 >> 10997 Berlin >> >> mob. +49179 293 63 99www.water-gate.de >> >> ```