Proposed new model of sound output

[byuu]

First, I'll explain the current process.

For each emulation speed mode, it sets a certain audio frequency. The speed regulation is a result of waiting for samples to play, so the frequency directly affects speed. Eg:
50% = 16khz
75% = 24khz
100% = 32khz
150% = 48khz
200% = 64khz
Uncapped = 32khz, but without waiting for samples to fully play

The biggest downside is having to kill and re-initialize the audio device on lesser APIs. The other downside is that the worst of the worst don't support uncommon sampling rates, such as 24khz.

So, my idea was to use one global sampling rate: be it 32khz, 48khz, 96khz or otherwise. I would probably default to 32khz, but allow any value. It'd be up to the audio driver to support it.

From here, I'd use a 4-tap hermite sampling algorithm to scale the audio to the requested frequency. Obviously, the filter would be bypassed on a 1:1 conversion. So by default, no hermite filter would be applied to normal, 100% emulation speed mode.

200% speed would end up losing half the fidelity it enjoys in the current bsnes builds (well, assuming your sound card was even capable of outputting at 64khz.) 150% mode would be half that bad. 50% and 75% should be nearly identical. Kind of the difference between the point filter and a linear filter, but for video.

Now, nearly all sound cards output at either 44050hz or 48000hz, and resample any audio handed to them to this rate. So you're basically getting resampled audio anyway. The quality of that can vary wildly.

It's possible that bsnes outputting at 48khz and using its own high-quality resampler would sound a bit better. Then again, the sound card may have an even better resampler and it'd sound worse.

And yet then again, we're around the Nyquist limit for audio already, so no human will probably be able to perceive the difference. Though that won't stop lots of people from saying they do, of course. Audio is well known for placebo effects.

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

[FitzRoy]

The biggest downside is having to kill and re-initialize the audio device on lesser APIs. The other downside is that the worst of the worst don't support uncommon sampling rates, such as 24khz.

And this is bsnes' problem to fix because...? I use an ATi card with shitty OpenGL drivers and if OpenGL were the only option, I would harass ATi or buy a new card before asking every program to give me special treatment.

[Snark]

Could this new model be used to "fix" the slight difference in emulation speed you mentioned due to the 32000hz vs real life 32040hz output? (sorry if I got some things all mixed up)

[byuu]

And this is bsnes' problem to fix because...?

Sadly, it usually falls on every software author to work around driver problems. Remember the D3D stuff? But yeah, I'm not too worried in this case. ALSA will never be the primary driver, since it doesn't exist for BSD, Solaris or Unix. And RedDwarf has a workaround for that, too.

Could this new model be used to "fix" the slight difference in emulation speed you mentioned due to the 32000hz vs real life 32040hz output? (sorry if I got some things all mixed up)

I knew I was forgetting something. Yes, it can compensate for the fact that bsnes runs 1% slower than a real SNES. But doing so might cause a bit more aliasing than usual. Think of it like resizing a 320x240 image to 640x480 and then again to 644x483. The latter would be blurrier because it's not an even multiple.

But then again, a really high quality resampler and being around the Nyquist limit, I doubt it'd be noticeable. Nor would emulation running 1% too slow be.

I can make 32040hz an option with either mode, though. The only difference here is either: I do the work and avoid having to change audio driver frequencies on emulation speed changes, or the driver does the work and I re-initialize sound every time you switch emu speeds. It's hard to say which will sound audibly better, unless I make a blind test for people to try. The former will definitely work on more hardware, eg 64khz mode on AC'97 codecs tends to freeze up.

[Snark]

But then again, a really high quality resampler and being around the Nyquist limit, I doubt it'd be noticeable. Nor would emulation running 1% too slow be.

I know, and to be honest I don't perceive any differences myself. But from a purist perspective it could theoretically be argued that it could ever so slightly change the timing of jumps/fighting games combos etc so that someone who knows a game by heart would feel the difference.

I can make 32040hz an option with either mode, though. The only difference here is either: I do the work and avoid having to change audio driver frequencies on emulation speed changes, or the driver does the work and I re-initialize sound every time you switch emu speeds. It's hard to say which will sound audibly better, unless I make a blind test for people to try.

If it's possible or feasible (or not too unpractical) a 32040hz option would be nice.

[mudlord]

If it's possible or feasible (or not too unpractical) a 32040hz option would be nice.

Why? Does BSNES have to be 100% perfect or something?

This is what reminds me of MAME, and the issues they have with ANYTHING that is not accurate. And to them, "accurate emulation" is 100% perfection, with only cycle accuracy being the way.....

To be honest, it pisses me off so much that some people can be so obsessive over a minor thing.

[byuu]

To be honest, it pisses me off so much that some people can be so obsessive over a minor thing.

Why does what other people do with their software upset you? I could see if they were bothering you personally about it.

To be fair, I ask myself the same question when I get upset over closed source emulators.

[Snark]

If it's possible or feasible (or not too unpractical) a 32040hz option would be nice.

Why? Does BSNES have to be 100% perfect or something?

This is what reminds me of MAME, and the issues they have with ANYTHING that is not accurate. And to them, "accurate emulation" is 100% perfection, with only cycle accuracy being the way.....

To be honest, it pisses me off so much that some people can be so obsessive over a minor thing.

I'm not obsessive, as I've already said I don't notice the difference myself. But technically, this impact the basic gameplay of all games, if even in an extremely subtle way. Yes, it's imperceptible to most (including for me) but it's the basic principle.

And yes, I think it's one of the main point of bsnes, to be as accurate as possible. (Or to aim for accuracy)

I didn't said ALL emulators have to strive for perfect accuracy or that an emulator making a compromise between speed and accuracy is wrong either.

[mudlord]

Why does what other people do with their software upset you? I could see if they were bothering you personally about it.

Well from my experiences with some people, they feel that thier methods are superior to others. I had run ins, with the MAME team for this reason, and this is why I personally can't stand the project. (I recall having a flamewar with MooglyGuy over HLE and labelling people as "ROM kiddiez")

Thats when it really upsets me what they do: is that they make it a personal agenda how they do things. And they think thier way of doing things is the only way to do it. Which of course isn't true.

[_willow_]

I'm just happy for you slightly changed your mind, byuu! So there is my 2¢.

Now, nearly all sound cards output at either 44100hz or 48000hz, and resample any audio handed to them to this rate. So you're basically getting resampled audio anyway. The quality of that can vary wildly.

My basic estimation is based on the fact resampling taking place anyway. That is the nature of PC, everything gets resampled to a common frequency. Most likely neither 32040hz nor 32000hz. You getting screwed up audio one way or another.

That is not good approach to assume every single PC application speaking directy to DAC as it's just ruin the multitasking ideology.

Just to think of 32000hz that is already distorted sound. And 32040hz sounds better to me. The common game experience is more like on a real console. I do respect right clocks more then academic SRC aliasing problem.

Besides the modern API's tends to upmix the application streams virtually to the DAC codec highest rate. Just look at native Vista WASAPI. It is actually a great step forward not only bacause of i do not have a single problem with my audio get's upscaled to 192000hz but also i do not have cracks, pops and i'm right sure what's going on with all legacy and modern audio applications on my system.

So i do suggest:
1) if the API can report the DAC supported frequencies use the highest
2) if the API can't report the DAC supported frequencies just blindly use 32040hz and it's multipliers directly but in secondary mix buffers.

[DOLLS (J) [!]]

Secret Rabbit Code Resampler is known for its exceptional sound quality, if the license is compatible you should be able to use it.

[DancemasterGlenn]

I'd definitely help out in a blind test, if you're up for making one. And I do personally see the work on your part paying off, either way.

Mudlord, I wish situations like this didn't upset you so much. You're an extremely talented individual, and you shouldn't let other people's choices get under your skin unless they're really getting in your face about it. You're too cool a guy to let that happen.

[mudlord]

Secret Rabbit Code Resampler is known for its exceptional sound quality, if the license is compatible you should be able to use it.

AFAIK, it is under a dual license, GPL or proprietary. Meaning that you need to pay the developer $1000 AUD if you want to use it without your code being open sourced.

I remember the dev of SRC having a flaming match with some people on HydrogenAudio about it, due to the licensing of it in a foobar2000 resampler DSP plugin.

[byuu]

A hermite resampler is six lines of code, and is very high quality. I've no need for adding more library and license dependencies to bsnes. It's complicated enough already >.>'

Thanks for the suggestion, though.

[creaothceann]

Is there a way for end users to find out the native frequency of the soundcard?
Maybe a hardware info tool or something like that...

[Verdauga Greeneyes]

Can you make any predictions about the amount of latency that buffering + resampling will introduce?

[_willow_]

Is there a way for end users to find out the native frequency of the soundcard?
Maybe a hardware info tool or something like that...

Oh, that is simple, you need to check the datasheets for your card first.
But then you need to know the internals of audio stack for your OS, you need to know how the API works. Drivers and onboard audio DSP can change frequency too. That needs a lot of experience. After all the API can be wrapped through the other API. There is always dependency chains because every application and api wants to exclusively sit on top of drivers (creators ego). Exclusivity is very unwise thing in real time OS as it makes the things uncertain, so the most audio stack layers should go tricky way for sometimes providing real info and other times stealing the real info to make concurrent applications to work. Layers can even steal real info from each other. So far the frequency uncertainty solved in Vista where you must select the native frequency yourself. Don't know about the same linux feature.

[blargg]

I knew I was forgetting something. Yes, it can compensate for the fact that bsnes runs 1% slower than a real SNES. But doing so might cause a bit more aliasing than usual. Think of it like resizing a 320x240 image to 640x480 and then again to 644x483. The latter would be blurrier because it's not an even multiple.

Except that unlike graphics, audio can be perfectly resampled to a higher rate. I can never remember why bsnes doesn't use an internal resampler to go from 32040 to 44100. A resampler can be coded as a black box that you feed samples at one rate, and get samples out at another rate.

But then again, a really high quality resampler and being around the Nyquist limit, I doubt it'd be noticeable. Nor would emulation running 1% too slow be.

I know, and to be honest I don't perceive any differences myself. But from a purist perspective it could theoretically be argued that it could ever so slightly change the timing of jumps/fighting games combos etc so that someone who knows a game by heart would feel the difference.

The audio rate doesn't affect speed of the game, rather the speed the APU is run at (either 32000 or 32040 Hz, I believe). The speed of the game is determined by the frame rate.

This is what reminds me of MAME, and the issues they have with ANYTHING that is not accurate. And to them, "accurate emulation" is 100% perfection, with only cycle accuracy being the way.....

To be honest, it pisses me off so much that some people can be so obsessive over a minor thing.

I think I know what you're talking about; it's the attitude that nothing less than perfection in every way is acceptable. This leads to an inability to see the different levels of accuracy, and deteremine what aspects of emulation are more important than others for these levels of accuracy. So for example some obscure extra clock somewhere is treated as having the same significance of something really basic. 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).

[FitzRoy]

Remember the D3D stuff?

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

Anyway, it's not that big of an issue if it works. Who cares if non-standard speeds get resampled? I just question it being worth the trouble because the current system seems to work pretty well.

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

[Snark]

But then again, a really high quality resampler and being around the Nyquist limit, I doubt it'd be noticeable. Nor would emulation running 1% too slow be.

I know, and to be honest I don't perceive any differences myself. But from a purist perspective it could theoretically be argued that it could ever so slightly change the timing of jumps/fighting games combos etc so that someone who knows a game by heart would feel the difference.

The audio rate doesn't affect speed of the game, rather the speed the APU is run at (either 32000 or 32040 Hz, I believe). The speed of the game is determined by the frame rate.

Ok, the speed of the APU then.(most of this stuff goes way over my head most of time I'm not pretending otherwise)

But basically, it's my understanding that if you leave bsnes and the real console running the intro loop of a game for a long time -many hours, bsnes (currently) should be "behind" a few seconds/minutes compared to the game running on the Snes, and the "gap" should widen as time pass. Someone correct me if I'm wrong on this one.

[mudlord]

I think I know what you're talking about; it's the attitude that nothing less than perfection in every way is acceptable. This leads to an inability to see the different levels of accuracy, and deteremine what aspects of emulation are more important than others for these levels of accuracy. So for example some obscure extra clock somewhere is treated as having the same significance of something really basic. 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).

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. It really doesn't sit right with me. Plus, to me, it isn't fair.

[Verdauga Greeneyes]

But basically, it's my understanding that if you leave bsnes and the real console running the intro loop of a game for a long time -many hours, bsnes (currently) should be "behind" a few seconds/minutes compared to the game running on the Snes, and the "gap" should widen as time pass. Someone correct me if I'm wrong on this one.

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.

[FitzRoy]

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? I doubt when it was developed, the creators said "let's do 32040." It probably was "32000" from a specification standpoint, but the hardware put in the unit just wasn't dead-accurate. What if 32005 had been measured from another unit, would we be arguing for that instead of 32000?

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?

I think that when you're translating oddball video and audio specs to a platform that is fundamentally different, certain things just HAVE to give.

[Verdauga Greeneyes]

The real brain buster is whether the SNES itself accurately represents its developer's intent. I doubt when it was developed, the creators said "let's do 32040." It probably was "32000" from a specification standpoint, but the hardware put in the unit just wasn't dead-accurate. What if 32005 had been measured from another unit, would we be arguing for that instead of 32000?

As far as I know the variance between units wasn't big enough to say 'oh, they probably meant to use 32000'.. but I'll leave this one to the experts.

[FitzRoy]

For all we know, the part that nintendo decided upon for manufacturing was never changed throughout the life of the unit, explaining the constance between units. Maybe it was just one of those things they could get away with being slightly imperfect as perfect may have cost them double what this company was offering.

I'm no expert either, I'm just guessing.