Noise channel notes?

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?

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.

So its "notes" are those optional frequencies? Like, it keeps looping random amplitudes at one of them, that you tell it to work at?

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.

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.

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.

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.)



FCEUX

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

sound.cpp:
lua-engine.cpp:
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.

FamiTracker and Pently noise pitches go from 0 to 9 and A to F, where F is the shortest period and 0 the longest.

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.

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.

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.

So it is initialized on reset, then?


Interesting that it would have this in addition to an initialization. Why initialize at all? Hmm.


Does setting this bit cause the noise to progressively fill with all 1s as it's clocked?

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)

Yeah, that is awfully suspect.

Setting it doesn't obviously stop the noise (edit:misspelling) prescaler, so ... looks likely?

Code:

;;; xa65

;;; iNES header
   .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

Tiny test ROM audio recording (from hardware, directly off pin 2):

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)

Woah, very interesting.

OH silly me, I was expecting some kind of pulse-like tone similar to the "periodic" mode of the SN76489 but of course the 2A03 merely moves the taps around where as the SN76489 makes the output bit the feedback bit as well as resetting the sequence any time the Noise mode/period register receives a write. Maybe they were planning to reset the 2A03 LFSR upon writes to $400F? It would make sense considering the pulse channels resetting their phase upon $4003/$4007 writes, and the noise does actually reset on the Gameboy as well.