Talk:Namco 163 audio

Point of terminology: Namco 106 vs. Namco 163

A regular on another wiki, who might not qualify for trusted on wiki.nesdev.org because he isn't active on the BBS, sent me a message on my talk page at that wiki that Namco 106 audio might need a rename. --Tepples 14:52, 15 December 2010 (UTC)

Mechanism

Is the cycle-by-cycle behavior known? I can guess it's something like "ld_7f ld_8 add_9 st_9 ld_a add_b st_b ld+mask_c add_d bound_c st_d add_e ld_indirect mult_f st_dac"—Lidnariq (talk) 13:41, 11 February 2013 (MST)

I think that would require a decap; it would be hard to determine this externally. The pseudocode I put as an example seems to give very accurate results though. - Rainwarrior (talk) 14:16, 11 February 2013 (MST)

Should be able to figure out which cycle 9, b, and d are updated. But otherwise, yeah.—Lidnariq (talk) 14:45, 11 February 2013 (MST)

How do you intend to do that? They're write-only registers. You can sort of read them by setting the waveform position to sit on the registers and recording the audio out (this is how the contents were determined), but the output only changes every 15 cycles, so there's no way I can think of to see anything getting updated at a finer granularity than that. - Rainwarrior (talk) 02:05, 12 February 2013 (MST)

The same way blargg's tests test the timing of write-only PPU registers: very precisely timed writes. --Tepples (talk) 09:50, 12 February 2013 (MST)

Hmm, so you're saying to devise a test for each of the control bytes, to be executed at each of the 15 cycle alignments, and then deduce from the signal collected what happened in each of these tests? I suppose you could mark your starting alignment with a $4011 write as well. Anyhow... I can see how it would be possible in theory. The real question I suppose is whether anyone will do it? - Rainwarrior (talk) 11:31, 12 February 2013 (MST)

I'm not convinced they're write-only. Certainly the interface as a whole isn't (e.g. games use it as save memory). In order for the control registers to be write-only, they'd have to be shadowed from the 128b actually presented...—Lidnariq (talk) 13:21, 12 February 2013 (MST)

Ah, yeah I hadn't thought about how they are down in the $4000 range. Reading might be possible then. Well, if you test it out, let me know what you find. - Rainwarrior (talk) 18:31, 12 February 2013 (MST)

Mixing noise approximation

A reasonable approximation of the switching noise, and cheaper than full resampling, is to sum the channels as though there were no switching noise, resample to the soundcard's native rate, and then multiply the output by (1+sin(k·n)), where k is chosen to produce a sine wave at the switching rate. (In the case of rendering audio at a rate higher than 48kHz, you may also add sine waves at every multiple of the switching rate that's below the nyquist rate. But none of those should be audible)

Justification: if the sound through each channel is uncorrelated, then it can be treated as though each channel is sounding while all others are silent. In which case, this is standard DSP upsampling, which produces modulated copies of the baseband signal at every multiple of the switching rate. —Lidnariq (talk) 15:30, 17 July 2013 (MDT)

Honestly, I don't think most people will want to listen to the switching noise, so a performance-saving approximation of it probably isn't that desirable. People who want the switching noise are probably interested in accuracy at the expense of performance. Though, in my NSFPlay implementation, it seems that it's not really a performance problem either way, emulating and mixing the N163 is faster/simpler than most of the other chips. - Rainwarrior (talk) 12:11, 18 July 2013 (MDT)