wmstatus: add an audible noise generator #1

New Issue

p · 2020-11-07T01:29:31+01:00

p commented

2020-11-07 01:29:31 +01:00

Subjectively, white noise seems to be harsh, pink and brown[ian] overall tolerable.

http://www.photonics.umbc.edu/Menyuk/Phase-Noise/kasdin_ProcIEEE_950501n.pdf
https://scicomp.stackexchange.com/questions/18987
https://www.firstpr.com.au/dsp/pink-noise/
https://www.firstpr.com.au/dsp/pink-noise/phil_burk_19990905_patest_pink.c
https://github.com/alsa-project/alsa-utils/blob/master/speaker-test/pink.c (± identical)
https://web.archive.org/web/20030727140057/http://www.ipo.tue.nl/homepages/dhermes/lectures/SD/Ch1/noisebp1.html
https://web.archive.org/web/20030302195119/http://www.sfu.ca/sonic-studio/handbook/Gaussian_Noise.html

Considering the apparent complexity, the best solution might be simply:
popen("sox --null -t raw -e unsigned-integer -r 44100 -c 2 - synth brownnoise")

Investigate the properties of the apparently trivial brown noise algorithm at
https://web.archive.org/web/20160710085846/http://vellocet.com/dsp/noise/VRand.h
which appears to integrate white noise but is not leaky and rather retries with new random numbers, in hope that the problem will fix itself. The constants appear to be meaningful. See how often it triggers the clipping measure. Try to understand what the Wikipedia-suggested "leaky integrator" actually means. See if multiplicative "leaking" of the accumulator is worth anything, and what the "y[t] = f·y[t–1] + (1–f)·white" thing does to the spectrum when we toy around with parameters—it seems that the "(1-f)·" thing is unnecessary or arbitrary (why should the increment be related in size to the rate of leaking?)

http://sepwww.stanford.edu/sep/prof/pvi/zp/paper_html/node2.html
https://www.coursera.org/lecture/dsp2/2-1-2-b-the-leaky-integrator-FNKpz
http://www.mbfys.ru.nl/~robvdw/DGCN22/PRACTICUM_2011/LABS_2011/ALTERNATIVE_LABS/Lesson_12.html

Findings: leaky integrators (multiplicative) change the frequency spectrum, attenuating the lower end. The method of retrying with another random number produces accurate brownian noise, as seen in Audacity's analysis--ten times the frequency means 20 dB weaker, as Wikipedia wants it. These two approaches can be combined, as excess rumbling can be unpleasant. Integrated random drift does occur with rand().

Try to compare the spectrum based on parameters.

Use the existing libpulse connection to play noise, switchable by a global hotkey. Consider making C-VolUp/Down increase or decrease a noise timer by an hour. Make note of this in the status like "Noise H:MM".

https://freedesktop.org/software/pulseaudio/doxygen/streams.html

It might be a good idea to create a standalone program to either generate noise data or even directly play it.

Subjectively, white [noise](https://en.wikipedia.org/wiki/Colors_of_noise) seems to be harsh, pink and brown[ian] overall tolerable. http://www.photonics.umbc.edu/Menyuk/Phase-Noise/kasdin_ProcIEEE_950501n.pdf https://scicomp.stackexchange.com/questions/18987 https://www.firstpr.com.au/dsp/pink-noise/ https://www.firstpr.com.au/dsp/pink-noise/phil_burk_19990905_patest_pink.c https://github.com/alsa-project/alsa-utils/blob/master/speaker-test/pink.c (± identical) https://web.archive.org/web/20030727140057/http://www.ipo.tue.nl/homepages/dhermes/lectures/SD/Ch1/noisebp1.html https://web.archive.org/web/20030302195119/http://www.sfu.ca/sonic-studio/handbook/Gaussian_Noise.html Considering the apparent complexity, the best solution might be simply: `popen("sox --null -t raw -e unsigned-integer -r 44100 -c 2 - synth brownnoise")` Investigate the properties of the apparently trivial brown noise algorithm at https://web.archive.org/web/20160710085846/http://vellocet.com/dsp/noise/VRand.h which appears to integrate white noise but is not leaky and rather retries with new random numbers, in hope that the problem will fix itself. The constants appear to be meaningful. See how often it triggers the clipping measure. Try to understand what the Wikipedia-suggested "leaky integrator" actually means. See if multiplicative "leaking" of the accumulator is worth anything, and what the "y[t] = f·y[t–1] + (1–f)·white" thing does to the spectrum when we toy around with parameters—it seems that the "(1-f)·" thing is unnecessary or arbitrary (why should the increment be related in size to the rate of leaking?) http://sepwww.stanford.edu/sep/prof/pvi/zp/paper_html/node2.html https://www.coursera.org/lecture/dsp2/2-1-2-b-the-leaky-integrator-FNKpz http://www.mbfys.ru.nl/~robvdw/DGCN22/PRACTICUM_2011/LABS_2011/ALTERNATIVE_LABS/Lesson_12.html **Findings:** leaky integrators (multiplicative) change the frequency spectrum, attenuating the lower end. The method of retrying with another random number produces accurate brownian noise, as seen in Audacity's analysis--ten times the frequency means 20 dB weaker, as Wikipedia wants it. These two approaches can be combined, as excess rumbling can be unpleasant. Integrated random drift _does_ occur with `rand()`. Try to compare the spectrum based on parameters. Use the existing libpulse connection to play noise, switchable by a global hotkey. Consider making C-VolUp/Down increase or decrease a noise timer by an hour. Make note of this in the status like "Noise H:MM". https://freedesktop.org/software/pulseaudio/doxygen/streams.html It might be a good idea to create a standalone program to either generate noise data or even directly play it.

p self-assigned this 2020-11-07 01:29:31 +01:00

p commented

2021-06-21 00:59:21 +02:00

8e0e84825f has essentially resolved this, though I'd still like to inspect the impact of various factors on the resulting spectrum.

8e0e84825f has essentially resolved this, though I'd still like to inspect the impact of various factors on the resulting spectrum.

p closed this issue

2021-06-26 08:12:25 +02:00

p commented

2021-06-26 09:18:54 +02:00

The results are satisfying.

noise-divisor-0.99.png

13 KiB