Proposed new model of sound output

[blargg]

I do think there is no right or wrong ways to emulate. I just find it very difficult to reason with people that feel that their ways are right, and all others are wrong.

Opinions just are, and don't offer much value to a discussion since they can't be discussed, simply stated. In an objective sense, some aspect of a system is either emulated accurately, or not. If it's "partly" emulated accurately, then one can simply divide the original aspect into two distinct parts, and find that one part is emulated accurately, the other not. In a practical sense, accuracy of some aspects of a system are more important than others for getting programs (games) running nearly the same as on the console.

Yeah, bsnes currently syncs to 32kHz, which means the SNES runs an eighth of a percent faster than it. In other words, after running both for 1001.25 seconds (16 minutes and 41.25 seconds), bsnes would be 1.25 seconds behind.

Oh I get it now. bsnes uses audio to set its overall speed, and emulates the APU at 32040 Hz but only plays it back at 32000 Hz, so it's 32000/32040 = ~99.88% of the proper speed.

The real brain buster is whether the SNES itself accurately represents its developer's intent. So what is more accurate, the ideal value or the measured value from a flawed delivery of that ideal value?

Developers probably set up the SNES console, a display, and speakers, and adjust the game code until the result is pleasing. Thus, everything about the SNES is taken into account, known or otherwise. I doubt developers designed and coded the game to a theoretical specification of the SNES, never seeing the result until it was shipped. They probably did code some things to the specification, and later found that the hardware's behavior differed, and adjusted their code based on hardware.

But let's suppose 32040 was the intent. That's not very PC friendly. Neither is 59.97 or whatever fps it runs at. Is an imperceptible speed discrepancy really more important than smooth video?

This is for each user to decide for himself, just as he decides what graphics filter to use. Also, why would 32000 Hz be any more PC-friendly?

[FitzRoy]

Well that's true provided that the extra 40hz is necessary for certain games to function properly.

Also, why would 32000 Hz be any more PC-friendly?

I dunno, why else would bsnes default to it?

[MisterJones]

The real brain buster is whether the SNES itself accurately represents its developer's intent. So what is more accurate, the ideal value or the measured value from a flawed delivery of that ideal value?

Developers probably set up the SNES console, a display, and speakers, and adjust the game code until the result is pleasing. Thus, everything about the SNES is taken into account, known or otherwise. I doubt developers designed and coded the game to a theoretical specification of the SNES, never seeing the result until it was shipped. They probably did code some things to the specification, and later found that the hardware's behavior differed, and adjusted their code based on hardware.

I think by developers, he meant the hardware developers, not the games developers. Maybe

[blargg]

I think by developers, he meant the hardware developers, not the games developers. Maybe

Even if the hardware differed from what the developers intended, the hardware is what game developers used to test their games. For example, even if the hardware developers intended for the SNES to use an RGB color scheme, the game developers would still end up using BGR since that's how the hardware interprets the bits. There are of course some intentions of game developers that couldn't be actualized in SNES games, due to hardware limitations or just lack of development time.

[grinvader]

Also, why would 32000 Hz be any more PC-friendly?

I dunno, why else would bsnes default to it?

Geeze, grow up a bit and detach yourself from byuu's ass.

It's the default because it's the closest to the real hardware, which means that it's extremely PC-unfriendly (the sound card will resample it to fit its need with a possibly awful resampler).
As already mentionned elsewhere, spitting the sound at the proper sampling rate emu-wise, THEN resampling it to the sound card's favourite flavour with a rock-solid custom resampler is the best way to have an accurate audio result.

[byuu]

It also keeps the end (perfect emulation) always out of sight, so that no matter how much work one does, it's never perfect, there's never anything accomplished (since levels of accuracy are not acknowledged).

I can certainly relate to that. Myself, I just find that when you start skipping details, they come back to bite you in the ass later on. When you really do need some obscure detail to fix a game, but it depends on details you didn't think mattered before, you end up in a bind. You go back to fix those and other stuff starts breaking. Do it enough at the start and you'll find it easier to rewrite your emulator than incrementally improve it.

I thought that one actually was bsnes' fault...

The linear filter, yes. But simply having a 1024x1024 texture, even though I'm only blitting a 256x224 window, should not result in an emulator running at 15fps instead of 60fps. It shouldn't make any difference since you aren't blitting the extra region, instead it becomes 4x more intensive than all of bsnes.

Didn't you unsuccessfully try this resampling stuff before because of vsync?

That was different. That was taking a varying number of samples and reasampling to a fixed number. Something I still desperately need to do, but can't figure ti out. This would be taking a fixed number for input and writing a fixed number out. I actually succeeded at doing this when trying out the vsync thing. It was to test out the quality of my samplers. I couldn't tell a difference from linear to hermite, personally.

Exactly. Though for me, I do think there is no right or wrong ways to emulate. I just find it very difficult to reason with people that feel that their ways are right, and all others are wrong.

The only real problems I have are the attitudes created. By both sides, really. I hate that fast emulators cause so much grief for people not aiming for speed. Mostly from people claiming the fast emulators are "just as accurate" because they run the three games that user plays okay, and taking cheap shots because another emulator is slower.

Not meaning mine. Mine really is inefficient, partially by design.

Then with the vastly increased popularity of the fast emulator, people start developing with it, rather than real hardware or more accurate emulators. They end up doing things real hardware doesn't permit -- reading math registers too quickly, using DMA with HDMA active, writing to VRAM while the screen is drawing, etc etc. The games seem fine in the fast emulator. But hey, it doesn't work in the other one! The fast one must be more accurate! Let's go tell the "accurate" guy his emulator is buggy. I've gotten at least a dozen false bug reports because of this. That pisses me off, because it wastes the time of myself and of testers. Especially that 48Mbit Chrono Trigger hack one.

Oh I get it now. bsnes uses audio to set its overall speed, and emulates the APU at 32040 Hz but only plays it back at 32000 Hz, so it's 32000/32040 = ~99.88% of the proper speed.

Yeah, I tried unsuccessfully for two years to sync to video instead, and to just resample the audio. I can't pull it off, so I stick with the audio rate, and let the video tear. It sucks, but there's nothing I can do about it.

I dunno, why else would bsnes default to it?

Mostly because it works better with bad drivers.

Geeze, grow up a bit and detach yourself from byuu's ass.

In a bad mood this afternoon? He just asked a simple question.

[blargg]

I hate that fast emulators cause so much grief for people not aiming for speed. Mostly from people claiming the fast emulators are "just as accurate" because they run the three games that user plays okay, and taking cheap shots because another emulator is slower.

Fault the ones making invalid claims, not the fast emulators.

Then with the vastly increased popularity of the fast emulator, people start developing with it, rather than real hardware or more accurate emulators. They end up doing things real hardware doesn't permit -- reading math registers too quickly, using DMA with HDMA active, writing to VRAM while the screen is drawing, etc etc. The games seem fine in the fast emulator. But hey, it doesn't work in the other one! The fast one must be more accurate! Let's go tell the "accurate" guy his emulator is buggy. I've gotten at least a dozen false bug reports because of this. That pisses me off, because it wastes the time of myself and of testers.

Fault the ones making invalid claims, not the fast emulators.

Oh and fault authors of fast emulators who don't make it clear that they trade accuracy for speed.

[grinvader]

In a bad mood this afternoon? He just asked a simple question.

Come on, I'm always in a bad mood. I'm paid to be.

Also, that was way too exploitable not to be done:

Code: Select all

<byuu> ...they come back to bite you in the ass later on.
<grin> nah, that's just Fitzroy being naughty.

[byuu]

Fault the ones making invalid claims, not the fast emulators.

Right, I know. I was mostly making a point that the ignorance of a small number of end users works both ways. But it grates anyone's nerves after hearing the same bullshit repeated enough times.

What mudlord and Kevin (who discussed this with me earlier) don't agree with me on is that the slower emulators take a hell of a lot more flack than the fast ones. It's kind of annoying hearing those working on ultra-popular, ultra-successful emulators complain about what niche people with <1% market-share userbases are doing.

Oh and fault authors of fast emulators who don't make it clear that they trade accuracy for speed.

We all do, to an extent. Well, except for this guy, at least ;)

"Unfortunately the (1970 Pong) component level simulation is takes a lot of processing power so even on a very fast PC it probably will not produce a playable frame rate. On an AMD Athlon 64 3000+ system it takes about 8 seconds to render each frame."

Take that, "bsnes is too slow" assholes :P

Come on, I'm always in a bad mood.

Heh, fair enough :)

[FitzRoy]

Geeze, grow up a bit and detach yourself from byuu's ass.

Since when am I a brown-noser? I make criticisms all the time... normally on things that I understand. And when I don't understand, like the 32000 thing, I'm just going to assume that there's some reasoning behind it and ask whoever's challenging (blargg) to clarify why there isn't.

But instead, you read it as: "well, byuu does it this way, therefore he's right and you're wrong." Note the difference. And if you don't think there is one, I offer a private reading comprehension course for a small fee of $5000, which is coincidentally the same amount we need to decap every special chip.

[augnober]

I'm not sure I understand this -- discussion has been dragging on a bit. I could go back to the beginning.. but I recall that I didn't fully understand the situation when I read it the first time.

1. So the sound emulation generates a waveform which if unmodified, should for authenticity's sake, be output at a 32040Hz sample rate?
2. So you want to scale that waveform to something that the host system's hardware natively supports while preserving pitch?
3. Is it expected that the host's sound output device natively supports 32000Hz?
4. If outputting at 32000Hz, then another option would be to drop every (32040/40)=801st sample to keep things sync'd (but this would result in a slight reduction in pitch)?
5. If the waveform is left unmodified, and it's output at 32000Hz, then emulation will run slightly slower than a real SNES, and with slightly reduced pitch? (bonus: This is what bsnes currently does?)

And I could see where people might disagree on number 2. Personally, I'd be interested in seeing it done. I can already run any game I want in another emulator without complaint - so I'd feel good about there being another emulator that can get it all as authentic as possible (even if it's unplayably slow). My opinion doesn't particularly matter anyway.

Edit: I went back to the first post of this thread, and read byuu's follow-up comment about 32040Hz. Somehow I didn't realize this was a new thread, and had missed that. It answered most of my questions Anyhoo.. byuu mentioned that 1% difference might not be noticeable. Well, 1% pitch difference would be noticeable.. but fortunately, I think the real difference is closer to 0.1%. In any case, I think the more significant issue is not difference in speed, but difference in pitch. And because 32000Hz apparently isn't a native mode, then you may as well always do the rescaling yourself and do it correctly (in consideration of 32040Hz). (which seems to mean I agree with byuu)

[Verdauga Greeneyes]

That was taking a varying number of samples and reasampling to a fixed number. Something I still desperately need to do, but can't figure ti out. This would be taking a fixed number for input and writing a fixed number out. I actually succeeded at doing this when trying out the vsync thing. It was to test out the quality of my samplers. I couldn't tell a difference from linear to hermite, personally.

Why do you need to take a varying number of samples again? Or to put it differently: couldn't you get a fixed number of samples by using some buffering? (i.e. stick the computed samples in a queue and send a fixed amount of them onto the resampler whenever you have enough)

[byuu]

I can already run any game I want in another emulator without complaint - so I'd feel good about there being another emulator that can get it all as authentic as possible (even if it's unplayably slow).

God, why can't more people in the world be as reasonable as you :(

Well, 1% pitch difference would be noticeable.. but fortunately, I think the real difference is closer to 0.1%.

Yeah, I always screw up the decimal place on the calculator. It's a ~0.1% difference.

Or to put it differently: couldn't you get a fixed number of samples by using some buffering?

Then you either continue to create too many samples and your buffer grows forever as latency soars forever, you continue to deplete samples until your buffer is empty and your sound stutters forever after, or you drop samples and large chunks of audio simply cut out. You aren't in a situation where the sample count balances out perfectly. It's either always over, or always under how many you want each frame.

Or, you use the only logical approach and forcefully resample when your buffer reaches a critical point in either direction. Then audio sounds good. The bigger your buffer, the longer you go before this happens. But the second the buffer overflows, the bigger the immediate pitch shift is.

I've been completely unsuccessful at averaging out samples over time to keep it smooth, and I can't imagine doing so in a small enough amount of samples to avoid absolutely ridiculous latency.

[RedDwarf]

It'll probably be a bit of a pain to implement this, but if it's beneficial, I can always give it a try.

If the "32000hz vs real life 32040hz" thing compensates the pain then makes sense. But for speeds? Why anyone would select anything but 100% speed the 99% of time?
I see the speed regulation like something nice to have, but that I don't really use. So I have my doubts about the practical "beneficial" part.

[byuu]

If the "32000hz vs real life 32040hz" thing compensates the pain then makes sense. But for speeds? Why anyone would select anything but 100% speed the 99% of time?

I use uncapped to blaze through games to get to testing points for bug fixing, I use the faster modes to get good audio and a consistent framerate, when I want an extra challenge (eg Street Fighter Alpha 2), and I use slower modes when I want to decrease the difficulty level (eg Mega Man X2.)

[Verdauga Greeneyes]

Then you either continue to create too many samples and your buffer grows forever as latency soars forever, you continue to deplete samples until your buffer is empty and your sound stutters forever after, or you drop samples and large chunks of audio simply cut out. You aren't in a situation where the sample count balances out perfectly. It's either always over, or always under how many you want each frame.

Or, you use the only logical approach and forcefully resample when your buffer reaches a critical point in either direction. Then audio sounds good. The bigger your buffer, the longer you go before this happens. But the second the buffer overflows, the bigger the immediate pitch shift is.

I've been completely unsuccessful at averaging out samples over time to keep it smooth, and I can't imagine doing so in a small enough amount of samples to avoid absolutely ridiculous latency.

Thanks for your reply. You had a lot of trouble resampling arbitrary numbers of samples, so how can you guarantee the fixed number of samples needed for resampling? (this question is probably just a consequence of my lack of knowledge about audio drivers)

[mudlord]

We all do, to an extent. Well, except for this guy, at least

"Unfortunately the (1970 Pong) component level simulation is takes a lot of processing power so even on a very fast PC it probably will not produce a playable frame rate. On an AMD Athlon 64 3000+ system it takes about 8 seconds to render each frame."

Take that, "bsnes is too slow" assholes

Hey, I still use BSNES 0.16 for my shader experiments (I would use a higher version if I knew the build version of the build that last had PGO working), I hope I don't fit into the "bsnes is too slow" category. D: I never really badmouthed BSNES and I even helped out with the initial OpenGL implementation. So, I hope that phrase isn't aimed at me .

What mudlord and Kevin (who discussed this with me earlier) don't agree with me on is that the slower emulators take a hell of a lot more flack than the fast ones. It's kind of annoying hearing those working on ultra-popular, ultra-successful emulators complain about what niche people with <1% market-share userbases are doing.

Hmmm, I suppose I see your point. Though I do hear a fair bit of bashing of speed orientated emus, and I see lots of people praise accuracy orientated ones...

But meh, we all have different opinions.

[_willow_]

3. Is it expected that the host's sound output device natively supports 32000Hz?

The native 32khz support should NOT be expected. Never!
Look datasheets for most codecs and HDA codecs. (And i mind you the OS's and API's can make things more complicated)
AC97 codecs natively support only 48000hz[x1] and HDA codecs natively support 44100hz[x1,x2,x3,x4] and 48000hz[x1,x2,x3,x4] Moreover the native clock for HDA codecs is 48000hz[x1,x2,x3,x4] and 44100hz emulating through 48khz.. huh still playing with imperfect pitch.
Audigy got fixed onboard DSP resampler to 48000hz. I can go on but really don't see a point in this. From my experience the best clocks is the highest supported rate from 48000hz and it's integer multipliers, that is the easy way to go. It's very PC friendly clocks that safely passing most of a traps.

[byuu]

how can you guarantee the fixed number of samples needed for resampling?

Because the video sync isn't interfering with the process. It's pretty simple, actually. I just need a class that you give samples to, and once it gets enough, it will output filtered real samples to the audio device. Since only the audio device regulates speed, it will always be smooth, just as it is now.

Imagine it with 64khz output. I'd just write two samples for each SNES sample, instead of one. But I'd be a bit fancier and blend the points between the previous and next samples to make it a bit nicer to bats with sonic hearing capabilities.

I hope I don't fit into the "bsnes is too slow" category.

Not at all, I was referring to people like this, this, this and this.

I never really badmouthed BSNES and I even helped out with the initial OpenGL implementation.

Yeah, definitely not. In fact, I'm extremely grateful for your contributions! :D
I actually really hate that we bicker over the emulator feedback thing. I'd hate to offend you with any of that stuff, because I really value your help with things. And the shader plugin thing is awesome, too!

[FitzRoy]

Not at all, I was referring to people like this, this, this and this.

I like the last one the best. Hehe, clearly your emulator is not advanced because "there's not many config settings to mess with!" Clearly!

I can't imagine why this would piss you off. These people sound like they're 12, why would they know any better? You got a surprising amount of defense. And in five years when the average system is twice as fast as it is now, the "Omigodz, sound is choppy" stuff will disappear. Unless, of course, people are on ten year upgrade cycles which sometimes seems to be the case.

[mudlord]

Hehe, clearly your emulator is not advanced because "there's not many config settings to mess with!" Clearly!

LOL. But surely, is it better design to have a minimum of options, as then to not clutter things? I personally think BSNES is advanced enough as is.

[byuu]

I can't imagine why this would piss you off. These people sound like they're 12, why would they know any better? You got a surprising amount of defense.

It doesn't really upset me that much. But you have to keep in mind that word of mouth is the way software catches on. People see that shit and then repeat it, like the guy in the second to last example. Not good.

Do note that all of those are just the ones in my referral logs for the past three days. No doubt there's twice as many posts without links. Probably more negative posts than ZSNES gets, with 100x the users. The majority of forum posts have disparaging remarks in them, too.

My point isn't that it bothers me so much, it's that I take a lot more shit, and lose a lot more users than fast emulators do. People only get pissed when the game they're trying to play freezes up. So when people say that they're tired of the accuracy zealots bugging them -- they don't realize how easy they have it :P

LOL. But surely, is it better design to have a minimum of options, as then to not clutter things? Razz I personally think BSNES is advanced enough as is.

I agree. I may move the checkboxes on the path settings window back to the advanced screen, since they're not very useful in general.

Now I have to come up with a way to stick a volume slider into a new panel ... it's going to be ridiculously empty, but adding things like resampling algorithm filter seems like bloat. Just use the best one, it causes no performance hit.

(I would use a higher version if I knew the build version of the build that last had PGO working)

I forgot to comment on this one last time ...

Yeah, I understand wanting to get 60fps. I wouldn't use an emulator, including my own, if I got less than 60fps. Nor would I if I had to use even a frameskip of one. It's just zero fun like that.

My only concern here is that there's not much point. The IRQs are so badly broken (okay it only breaks two known games, still) that you're better off simply using SNESGT. Coincidentally, fixing that is what caused the greatest speed hit of all, twice as much as losing PGO.

Of course, I'd hate that. I would greatly miss your feedback and contributions.

[Snark]

I hope I don't fit into the "bsnes is too slow" category.

Not at all, I was referring to people like this, this, this and this.

Nope byuu, he has a point: "The SNES could run without a G5's capabilities, then an emulator surely should too..."

Then an emulator SURELY SHOULD TOO people!

Seriously though, taken literally, the above didn't even make sense but he probably meant "if the SNES ran on a 3mhz cpu then it should require no more than a 3mhz cpu to emulate...maybe 3x10=30mhz - max."

Imo that's "Youtube" level criticism and shouldn't even be considered in the first place. Critics by respected emu authors or by end users that actually aren't morons, fine, they should count as "critics" (although of course you're still free to disagree with them or to share a different opinion) but this is not even worth considering...

[mudlord]

My only concern here is that there's not much point. The IRQs are so badly broken (okay it only breaks two known games, still) that you're better off simply using SNESGT. Coincidentally, fixing that is what caused the greatest speed hit of all, twice as much as losing PGO.

Of course, I'd hate that. I would greatly miss your feedback and contributions.

Well, if I could hussle up some cash for a decent Core 2 Duo (like the 8xxx series) or Quad and a new motherboard, then I wouldn't be in this mess.

[FitzRoy]

Hehe, clearly your emulator is not advanced because "there's not many config settings to mess with!" Clearly!

LOL. But surely, is it better design to have a minimum of options, as then to not clutter things? I personally think BSNES is advanced enough as is.

To clarify, it's not really a matter of "minimizing" useful options, it's a matter of omitting redundant and pointless options. So said the curious beast himself, he wants his nuclear switchboard. Then in his ignorance he will do as he said he would and mess with them, perhaps in a foolish attempt to fix something totally unrelated, break something else without realizing what did it, and then come on these forums and complain with a shitty bug report at our expense.

I'm looking at snes9x sound menu ATM and shaking my head. I can't make sense of most of it. Frame advance mute, fake mute desync workaround, mix interval, anti-resonance's sampling method (if it's better, why not just use it?), reverse stereo (how about just hooking up the speakers correctly?), interpolation (as if anyone actually prefers this be disabled), etc. And the irony is, for all these bajillion pointless options, the one thing I can't get is accurate, crackle free sound.