Page 1 of 2

### Noise channel notes?

Posted: Sat Jun 04, 2016 10:37 am
Just a little question.

I can clearly hear different tone heights on the noise channel, and there's a formula in fceux that calculates its midikey for a given frame, and the resulting midikey seemingly reflects the tone height difference. But unlike the other channels, I can't figure out where this overall height is coming from. The noise channel is supposed to pseudo-randomly jump between a bunch of possible frequences, isn't it?

I also see noise channel is given values in things like famitracker.

So the question: are these values even notes, or just presences of those frequencies that are internal to the chip?

### Re: Noise channel notes?

Posted: Sat Jun 04, 2016 11:05 am
The noise channel is a linear-feedback shift register, clocked at the programmer's choice of one of sixteen pre-configured rates.

Maximal-period LFSRs are, in an audio context, perfectly "white"—they contain exactly equal amounts of all frequency energy below their Nyquist rate.

The hardware is changing the sample rate of the 32767-sample-long (or 93-sample-long, when in "tonal noise" mode), which changes the exact set of relative volumes at each frequency.

There's no fancy resampling going on, for different sample rates, so the acoustic effects are equivalent to a sample-and-hold lowpass.

### Re: Noise channel notes?

Posted: Sat Jun 04, 2016 11:33 am
So its "notes" are those optional frequencies? Like, it keeps looping random amplitudes at one of them, that you tell it to work at?

### Re: Noise channel notes?

Posted: Sat Jun 04, 2016 11:57 am
Yeah, approximately.

The table inside the CPU lets you choose one of these sixteen periods - http://wiki.nesdev.com/w/index.php/APU_Noise - corresponding to one of sixteen sample rates between 447kHz and 440Hz.

When used with the normal "white noise" mode, the effective sound is mostly a function of the sample-and-hold effect, on average it works out to your choice of corner frequency of a 1st-order lowpass (6dB/octave).

Of course, with the tonal noise mode, the baked-in frequencies actually do mean things. 447kHz ÷ 93 = 4.8kHz, i.e. rate 0 on NTSC in tonal noise mode is distinctly audible as a pitch.

### Re: Noise channel notes?

Posted: Sat Jun 04, 2016 12:00 pm
The noise pattern loops. If it loops slowly ("periodic" mode off) you get a repetitive whoosh noise, if it loops fast enough (periodic mode on) you get a tone.

The frequency of the tone produced just depends on the length of the loop; with the periodic mode on it's 93 samples long at whatever the current noise frequency is. You can think of it like a wavetable tone, like with N163 or FDS expansion audio. The actual waveform in periodic mode depends on whatever bits were in the LFSR when that mode was turned on. Sort of a randomly selected timbre.

In non-periodic mode it's a much longer loop, so it's no longer a tone but just a repeating sound. You can hear the looping easily at the higher frequency settings.

### Re: Noise channel notes?

Posted: Sat Jun 04, 2016 6:02 pm
Long mode noise

When the noise channel Mode flag is clear, the noise channel repeats a sound wave that is 32767 steps long. Each step is pseudo-randomly the minimum or maximum level. Although the sound wave eventually repeats, it's so long in duration that you don't hear it as a definite pitch.
feos wrote:I can clearly hear different tone heights on the noise channel
When you change the Rate bits, the long-mode noise does sound higher pitched or lower pitched compared to the noise at other rates. But if you try to compare the pitch of the long-mode noise at a specific rate to the pitch of, for example, a square channel tone at a specific pitch, you can't really tell which one is higher or lower in pitch, they're not really comparable.

Short mode noise

When the noise channel Mode flag is set, the noise channel repeats a sound wave that is 93 or 31 steps long. This is short enough to have a perceptible pitch.

For short mode noise, I calculate the pitch as the frequency of the repeating wave. See the attached test.zip under this paragraph. I'm interested in discussing with other people if my calculations are correct. (When I proposed changes to how FCEUX calculates the pitch of short mode noise, no one replied to my proposal. Now I'm excited someone else is wondering what FCEUX's pitch values mean for the noise channel.)
test.zip
Short Mode Noise Pitch Tests for FCEUX
feos wrote:on the noise channel [...] there's a formula in fceux that calculates its midikey for a given frame [...] I also see noise channel is given values in things like famitracker. [...] are these values even notes, or just presences of those frequencies that are internal to the chip?
FCEUX

FCEUX assigns lua sound.get().rp2a03.noise.frequency and .midikey values based on the rate.

sound.cpp:

Code: Select all

``````static const uint32 NoiseFreqTableNTSC[0x10] =
{
4, 8, 16, 32, 64, 96, 128, 160, 202,
254, 380, 508, 762, 1016, 2034, 4068
};``````

Code: Select all

``const uint32 *NoiseFreqTable = NoiseFreqTableNTSC; // for lua only``
lua-engine.cpp:

Code: Select all

``freq = (39375000.0/44.0) / NoiseFreqTable[freqReg];``
Note: I think the (39375000.0/44.0) value represents the NTSC APU clock frequency, but the NoiseFreqTable values are in terms of NTSC CPU clocks.

Famitracker

Famitracker assigns "hex pitch" values in the noise channel: 0-# to 9-# then A-# to F-#. These values are based on the Rate bits. Edit: Like tepples says below, Famitracker displays values that are 15 - the PPPP bits, so that the lowest pitch (longest period, PPPP = 1111) is shown as 0 and the highest pitch (shortest period, PPPP = 0000) is shown as F.

### Re: Noise channel notes?

Posted: Sat Jun 04, 2016 6:08 pm
FamiTracker and Pently noise pitches go from 0 to 9 and A to F, where F is the shortest period and 0 the longest.

### Re: Noise channel notes?

Posted: Sat Jun 04, 2016 8:51 pm
Bavi_H wrote:Note: I think the (39375000.0/44.0) value represents the NTSC APU clock frequency, but the NoiseFreqTable values are in terms of NTSC CPU clocks.
Yes the noise samplerate is the CPU clock (~1789772 Hz) divided by the period in the table. (The same table is on the wiki, and it's been independently verified on many occasions).

The periodic mode ones should again be divided by 93 to give a musical pitch.

The non-periodic mode ones shouldn't be divided by 32767, though, because this doesn't produce musical pitches; they are too low frequency to be perceived that way. However, the base samplerate of the non-periodic noise does generate harmonics at its samplerate which produce a faint but noticeable musical pitch, at least for the lower frequency settings. The higher frequency settings are too high to be perceived as musical pitch.

As such, if you're looking for perceived pitch frequency, use CPU / (table * 93) for the periodic mode, and just CPU / table for the non-periodic mode.

### Re: Noise channel notes?

Posted: Sun Jun 05, 2016 2:40 am
Bavi_H wrote:Now I'm excited someone else is wondering what FCEUX's pitch values mean for the noise channel.
Me too.

### Re: Noise channel notes?

Posted: Sun Jun 05, 2016 4:06 am
Now another interesting thing to know would be if it's possible to reliably get the same timbre every time by immediately setting the mode flag when the NES is powered on, hopefully before the LFSR receives its first clock. Losing the static would not be an issue if there's an expansion chip present like the 5B, which has its own noise or alternatively it's also possible to create noise-like sounds by playing back random data or code as DPCM samples.

### Re: Noise channel notes?

Posted: Sun Jun 05, 2016 9:17 am
za909 wrote:Now another interesting thing to know would be if it's possible to reliably get the same timbre every time by immediately setting the mode flag when the NES is powered on, hopefully before the LFSR receives its first clock. Losing the static would not be an issue if there's an expansion chip present like the 5B, which has its own noise or alternatively it's also possible to create noise-like sounds by playing back random data or code as DPCM samples.
It must be seeded with at least one 1 bit in it, so it has to initialize at least one bit at power-on (or reset). Perhaps Visual 2A03 could help understand this.

Because of this, I expect it is at a consistent state on reset, and you can probably do what you're proposing.

CopyNES installation would interfere with this, since it runs BIOS code on reset. There might be other situations that would compromise a user's system for this purpose too.

The NSF format can't use such a trick either, because the player is supposed to set up the system prior to any code run from the NSF, so there's no guaranteed time-since-reset there. I did implement an option for randomized vs consistent noise initialization, though, in my NSF player, but that's really just so that you can get consistent results if you need tehm.

### Re: Noise channel notes?

Posted: Sun Jun 05, 2016 11:11 am
rainwarrior wrote:It must be seeded with at least one 1 bit in it, so it has to initialize at least one bit at power-on (or reset). Perhaps Visual 2A03 could help understand this.
Visual2A03 tells me that it is seeded with all ones ... which would be the easiest thing to do.

Interestingly, the noise LFSR appears to contain a self-recovery flag (node 11464) that, if every single bit inside the LFSR is 0 (and thus it would stop making noise), it'll instead clock in a 1 instead of a 0. i.e., the feedback term being fed into noi_c0 is not noi_+c14 XOR SELECT(noi_lfsrmode,noi_+c13,noi_+c8) but instead

n11464 = NOR15(noi_+c[0..14]) = 'safety'
n11454 = SELECT(noi_lfsrmode,noi_+c13,noi_+c8) = 'FB2'
n14042 = NOR3(noi_+c14,n11464,n11454)
n14046 = NOR3(snd_halt, n14042, AND2(noi_+c14,n11454) = bit to be clocked into noi_c0

→ /n14042·(/noi_c14+/FB2)
→ (noi_c14+safety+FB2)·(/noi_c14+/FB2)

(noi_+c14 XOR SELECT(noi_lfsrmode,noi_+c13,noi_+c8)) OR NOR15(noi_+c[0..14])

snd_halt is a bit in the usually-unavailable register at \$401A.

### Re: Noise channel notes?

Posted: Sun Jun 05, 2016 12:51 pm
lidnariq wrote:Visual2A03 tells me that it is seeded with all ones ... which would be the easiest thing to do.
So it is initialized on reset, then?
lidnariq wrote:self-recovery
Interesting that it would have this in addition to an initialization. Why initialize at all? Hmm.
lidnariq wrote:snd_halt is a bit in the usually-unavailable register at \$401A.
Does setting this bit cause the noise to progressively fill with all 1s as it's clocked?

### Re: Noise channel notes?

Posted: Sun Jun 05, 2016 1:23 pm
rainwarrior wrote:So it is initialized on reset, then?
It's not explicitly initialized. I vaguely fear that the power-on value is an artifact of the simulator, so I guess we should make a tiny test ROM to play with this on hardware. (goes and does that, will post with results later)
rainwarrior wrote:Interesting that it would have this in addition to an initialization. Why initialize at all? Hmm.
Yeah, that is awfully suspect.
rainwarrior wrote:Does setting [snd_halt in \$401A] cause the noise to progressively fill with all 1s as it's clocked?
Setting it doesn't obviously stop the noise (edit:misspelling) prescaler, so ... looks likely?

### Re: Noise channel notes?

Posted: Sun Jun 05, 2016 2:29 pm
lidnariq wrote:tiny test ROM

Code: Select all

``````;;; xa65

.byte "NES",\$1A
.byte 1     ; # 16 KiB PRG
.byte 0     ; # 8 KiB CHR
.byte 0,0
.dsb 8,0

.text
*=\$c000
.dsb (\$ffe0-*),\$ff
reset:
;; AS EARLY AS POSSIBLE
ldy #8
sty \$4015   ; enable noise channel
ldx #\$FF
stx \$400C   ; dc dc OnForever ContVol 4-MaxVal
stx \$400E   ; Tonal 3-dc 4-LowestPitch
stx \$400F   ; unnecessary? relevant?

sei
cld
lda #0
sta \$2000
sta \$2001

forever:	brk

.dsb (\$fffc-*),\$ff
.word reset
.word forever
``````
[/size]

Tiny test ROM audio recording (from hardware, directly off pin 2):
power-on-noise-lfsr-tonal-mode.png (2.17 KiB) Viewed 12095 times
This is definitively starting from the all-0s state. Musically, that's kinda interesting: this sequence has equal power at every overtone (except the 31xfundamental one, which is 15dB louder)