How can I confirm the emulator sound output pitch is correct?
Are you referring to the pitch of the generated waveform relative to the sample rate, or the sample rate that the operating system is actually using relative to the sample rate that you specified when opening an audio stream for output? For the former, you can add a feature to log sound output to a .wav file, and then count how many samples it takes for the waveform to rise and fall a given number of times. For the latter, you may have to use operating-system-specific APIs to determine the playback state of an output voice.
Or are you referring to conversion of tone generator parameters to a musical pitch in A440 equal temperament tuning?
I mean the
resample method. According to my notes,
the exact sample rate of the NES audio DAC itself is 39375000/22 Hz = 1.7898 MHz. So, I did some math...
Code:
resample to PC 48MHz, but assuming values in Hz:
(39375000 / 22) / 48000 =
= 39375000 / 48000*22 =
= 393750 / 480*22 =
= 393750 / 10560 =
= 39375 / 1056 = 37.286 samples per sync.
DIV 3 => **13125 / 352**
At every CPU cycle, the APU generates a sample.
Code:
const total_samples = 13125;
int divisor = 352;
//at every update:
sample_counter -= divisor;
sample_adder += generated_APU_sample;
num_updates++;
if(sample_counter <= 0) {
sample_counter += total_samples;
apu_output_sample = sample_adder / num_updates; //usually, 37 updates.
sample_adder = 0;
num_updates = 0;
}
Looks correct, but I sense a bit high pitched... probably because of my... headphones?
Headphones shouldn't by themselves be able to change the pitch of anything.
The rates of everything on the Wiki are correct, AFAIK. How are you comparing your pitch?
I get the same values for the CPU clock rate and resampling ratio for output to 48 kHz.
Dumb question, but are you accounting for the APU square running at half the clock rate? That would make the output one octave too high.
Alternatively, playing a PAL or Dendy ROM at NTSC rate would also raise the pitch.
Approaching it from a stupid end-user POV, three things:
1. If something sounds off, I can record audio from an actual NTSC NES if you need it for comparison -- just let me know which game (ROM filename would be great) and part of the game and I can get you a .zip of 44 or 48kHz 16-bit WAV of whatever's relevant.
2. I have actually encountered audio drivers which have incorrectly done some portion of their mixing -- but ONLY when using MME with 44kHz 16-bit audio files (11kHz and 22kHz were fine, and DirectSound was fine) -- resulting in audio that sounded off by about half an octave. Issue was 100% reproducible using Audacity by switching between MME and DirectSound, and was not specific to Audacity (i.e. mIRC notification audio is where I first noticed the problem). Switching to another sound card resolved the issue. I used to have actual Stereo Mix/WhatUHear recordings of the bug, but I can't find the dang files...
3. ...Rahsennor covered PAL and Dendy. :D
koitsu wrote:
Approaching it from a stupid end-user POV, three things:
1. If something sounds off, I can record audio from an actual NTSC NES if you need it for comparison
Another thing to try is a test ROM that generates a known pitch, such as the 125, 250, 500, 1000, and 2000 Hz beeps in
240p test suite. I too can provide recordings from an NTSC NES.
Rahsennor wrote:
Dumb question, but are you accounting for the APU square running at half the clock rate? That would make the output one octave too high.
Hmm... it makes sense, but the things here are NOT so high pitched - it's slightly off. So, the math must be redone for HALF CPU clock rate.
How about recordings or something? They don't need to be pristine or anything, even a cell phone held up to headphones is probably good enough.