It's been just about four days since someone posted in here.

[I.S.T.]

So, I will.

I have something of an odd question(or three). One thing I've noticed is that sound emulation seems to be hard to get right, no matter what platform you're emulating. Is is true, or am I simply wrong?

Also, how processor intensive would it be to get an snes emulator that gets sound right, but is otherwise an opcode based emulator?

Sorry if I have some of my terminology wrong here.

[Snark]

So, I will.

I have something of an odd question(or three). One thing I've noticed is that sound emulation seems to be hard to get right, no matter what platform you're emulating. Is is true, or am I simply wrong?

Also, how processor intensive would it be to get an snes emulator that gets sound right, but is otherwise an opcode based emulator?.

Good question, especially for the portable devices. I don't know if you can independently emulate the sound core accurately and still remain with a relatively high level core CPU emulation.

[blargg]

Graphics work more simply, and the main functionality is used by most games. Sound chip behavior is more intricate, more "maze-like", with areas used by some games and not others. Sound hardware also differs quite a bit between systems, so it's less predictable and requires more reverse-engineering. It's also harder to observe the results, since it's not a simple static image. Sound emulation differences can be harder to track down and find the cause of, even if they are very noticeable. The sound output itself has a more complex information encoding than an image, so it's more involved decoding the sound output and determining how the change in inputs affected it. Whereas most graphics registers have the same effect every displayed frame, the effect of sound registers depends more on past actions/internal state. Programmers in general seem less adept at sound programming, since it involves more timing elements and a more complex signal encoding than graphics. Maybe the visual nature of graphics coupled with the largely visual nature of human perception and processing is a factor.

Or maybe sound emulation isn't any harder, just less of a priority. After all, an emulator which only did graphics would be far more useful than one that just did sound (video game music players excluded).

[Nightcrawler]

I can also add from SNES sound programming experience that you need to have some knowledge in sound synthesis. You're dealing with ADSR envelopes. I found it a little bit difficult to really understand what's going on. Even now, while I've successfully composed and play back music for the SNES, I still don't quite have a 100% grasp on what's going on. Sometimes I can't get a sample to sound the way I want or understand why a note isn't working as I expected.

So, even though I know how to program and have very strong understanding of CPU internals, I would have a difficult time emulating the SNES sound hardware because I lack some full conceptual understanding of the functionality of the DSP which is directly related to sound synthesis.

I believe byuu has hit the same kind of obstacle which was why he did not code the sound core in BSNES and used anomie's and now blargg's instead.

[AamirM]

Hi,

Sound emulation differences can be harder to track down and find the cause of, even if they are very noticeable.

I'll give an example of this. The famous blip sound produced in many Megadrive games (Ariel, Shaq Fu, Spiderman the animated series etc..) was a complete mystery. Many (including myself) tried to find out what was causing that problem but failed. Strangely, this problem won't appear in blargg's modified Gens' YM2612 core used in his Game music emu library. It turned out to be due to an overflow in the frequency register. Blargg accidentally fixed it because he used a different data type which recreated that overflow. It was small problem but still nobody was able to figure out what it was until very recently Nemesis found that out (again with help from blargg's modified Gens core).

stay safe,

AamirM