Snes9x.com

Hi all,

After switching to 1.52 (mac version) I've had consistently bad sound -- lots of popping and crackling. To be specific, I would estimate I hear a noticeable crackle once every 5 to 10 seconds. This is very detrimental to the experience and does *not* happen in 1.51.

I've compared the same sequence (opening music in Chrono's room) many times on both 1.51 and 1.52, and the sound is flawless in 1.51, but the 1.52 version has many instances of crackles. Same thing for other games I've tested.

Another big difference between the two versions:
when I hit the turbo key, the sped-up sound in 1.51 is actually very smooth -- just like the normal music in that you can hear all the notes/sounds, but extremely fast -- whereas the 1.52 turbo music is primarily pops and crackles, as if many of the notes are being lost/skipped.

This is a pretty major regression since 1.51 for OS X. Does anyone have any solutions or recommendations? Yes I know I could "just use 1.51" but I would like to migrate to the new savestate format sooner rather than later...so please don't give that suggestion!

Many thanks for any help that you can give!

The old inaccurate sound core of 1.51 was removed and replaced in 1.52. The new one emulates SNES sounds perfectly, but may cause the problem like yours in some situations.

See Help menu - Snes9x Help - Problems - Problems with Sounds and adjust your sound settings. Input Rate will help you.

Hi, thanks for your reply. I tried changing around the settings you suggested -- cranked up mix buffer length and played with output interval, checked "allow lag" etc.

Couple of issues, still:
1.) it reduced the frequency of crackles and hiccups, but did not eliminate them
2.) the changes I made introduced massive sound delay (e.g. Mario is almost 1/2 way up his jump by the time I hear the jump sound play).

Are these problems with the new sound core known / under consideration, or is this kind of noise considered acceptable? Would it be possible to leave the old sound core as an option in future releases? It sounded beautiful and I never experienced these issues of jarring sound corruption.

I appreciate that the new sound core was added because it is "more accurate" BUT it is really hard to care about any small increase in accuracy when it comes at the expense of all the crackling/hiccuping. That totally nullifies any benefit of add'l accuracy, in my opinion.

Thanks again for your thoughts / suggestions.

Try to set Input Rate to around 31000-32000.
The old sound core never comes back in the future releases.

kaenm wrote:Are these problems with the new sound core known / under consideration, or is this kind of noise considered acceptable? Would it be possible to leave the old sound core as an option in future releases? It sounded beautiful and I never experienced these issues of jarring sound corruption.

I appreciate that the new sound core was added because it is "more accurate" BUT it is really hard to care about any small increase in accuracy when it comes at the expense of all the crackling/hiccuping. That totally nullifies any benefit of add'l accuracy, in my opinion.

Thanks again for your thoughts / suggestions.

Chances are, you don't know what you're looking for in terms of accuracy.

When things chance and it affects you, I'm sure it sucks. However, you can't just roll stuff back because you don't notice other games are broken with the older core.

I'm sure there will be attempts to make it work better for you, but reversion is a terrible suggestion.

Deathlike2 wrote: Chances are, you don't know what you're looking for in terms of accuracy.

What I'm looking for is sound that doesn't crackle, hiccup, and lurch in and out of sync. As far as what games had sound accuracy issues on 1.51, you're quite right, I've yet to come across any of them -- unless by accuracy we mean a very subtle deviation from the fully accurate sound of 1.52.

Deathlike2 wrote: When things chance and it affects you, I'm sure it sucks. However, you can't just roll stuff back because you don't notice other games are broken with the older core.

I'm sure there will be attempts to make it work better for you, but reversion is a terrible suggestion.

You talk about "rolling stuff back" and "reversion" -- I think you skimmed too quickly and are confused about what I said. I was merely wondering out loud if the old core would ever be left "as an option" in the future. The answer is no, which I 100% agree is the best way to go. Please don't mischaracterize my simple comment about leaving an option as a sign of me wanting to roll back or revert anything (words that imply doing away with the progress made on a new core).

In the meantime, I am thankful for people like zones trying to help those of us who've had our snes9x aural experience heavily impacted by the migration to this new core. I'm glad it's more accurate, for sure, and I applaud the developers who worked hard implementing the core itself and also transplanting it in place of the old one for this 1.52 release. It's just hard to enjoy any music, accurate or not, if it's sprinkled with crackles and hiccups. (If I had an mp3 full of that kind of noise I would delete it and try to find a listenable version.)

Cheers.

zones wrote:Try to set Input Rate to around 31000-32000.

Hi zones, thanks very much for your reply.

Good news! I moved the Input Rate down to about 31950, and have noticed a huge improvement. I can leave all the default settings (not even checking "allow lag") and just change the Input Rate and most of the problems go away. There is an occasional crackle but it's much more rare now. So -- thank you!

Now for another [hard] question:
Do you (or some developer with knowledge of how the system works) know how I could optimize what setting I leave this Input Rate at? What exactly is changing when I move this down below 32k, while the Output Rate stays at 32k?

Cheers.

kaenm wrote:You talk about "rolling stuff back" and "reversion" -- I think you skimmed too quickly and are confused about what I said. I was merely wondering out loud if the old core would ever be left "as an option" in the future. The answer is no, which I 100% agree is the best way to go. Please don't mischaracterize my simple comment about leaving an option as a sign of me wanting to roll back or revert anything (words that imply doing away with the progress made on a new core).

It's not exactly "possible", in the sense of how the integration is done. In addition, freeze state incompatibilities would exist, since you cannot use same freeze state between sound cores! So, it will cause more work and bloat... ultimately it would be difficult to maintain.

Sorry that I probably misread what you mean, but my point was that the core change was more necessary and there's no realistic "optional" method of keeping it intact other than using older versions of Snes9x.

Every [Input Rate] samples, [Output Rate] samples are generated. In your case for example, every 31950 "theoretical" samples 32000 real samples are generated.

Let's assume you have both set to 32000. Now if snes9x runs a bit slower than the real snes, for example because you are using vsync and it is a bit off, or if the framerate limiter can't exactly give you the right framerate, then you might only get 31980 samples in one second. But your sound system will still play 31200 samples, which will result in hearable crackles. Increasing the sound buffer will make them appear further apart, but also increase the delay.
Now if you have the input rate set to 31950, snes9x will create more samples through interpolation. Of course now you might have too many, but that is not as obvious to the human ear and can be remedied by enabling sound sync, which will cause the core emulation to wait until your sound system has consumed the samples.

OV2 wrote:Every [Input Rate] samples, [Output Rate] samples are generated. In your case for example, every 31950 "theoretical" samples 32000 real samples are generated.

Let's assume you have both set to 32000. Now if snes9x runs a bit slower than the real snes, for example because you are using vsync and it is a bit off, or if the framerate limiter can't exactly give you the right framerate, then you might only get 31980 samples in one second. But your sound system will still play 31200 samples, which will result in hearable crackles. Increasing the sound buffer will make them appear further apart, but also increase the delay.
Now if you have the input rate set to 31950, snes9x will create more samples through interpolation. Of course now you might have too many, but that is not as obvious to the human ear and can be remedied by enabling sound sync, which will cause the core emulation to wait until your sound system has consumed the samples.

Which is best for most Realtek and SoundMAX audio chipsets.

Deathlike2 wrote: In addition, freeze state incompatibilities would exist, since you cannot use same freeze state between sound cores! So, it will cause more work and bloat... ultimately it would be difficult to maintain.

Oh wow, I didn't even think of diff sound cores needing diff savestate formats! That's pretty cool. Well, cool as in interesting...definitely sounds like a major headache otherwise. Anyway, no worries, thanks for the comments.

OV2 wrote: Now if you have the input rate set to 31950, snes9x will create more samples through interpolation. Of course now you might have too many, but that is not as obvious to the human ear and can be remedied by enabling sound sync, which will cause the core emulation to wait until your sound system has consumed the samples.

Cool, thanks for that info. Since you mention it, I will try enabling sound sync to see if that changes anything. (I had tried it before in various combinations of settings, but not since reducing the Input Rate.)

Note that savestates will have the same file extension, however, they will not be compatible due to the new sound core.

i'm having a exctly same problem....just like MAME once had sound core rewrite..

this little fix completely removed all the poping and crackling noises..though i don't know if this fix can be applied in the same manner as MAME did...

from osd/windows/sound.c (MAMEUIFX - http://mame32fx.altervista.org/)

#ifdef SOUND_RESYNC
if (options_get_bool(mame_options(), WINOPTION_SOUND_RESYNC))
{
/* if we are active, update the sampling frequency */
if (machine->speed_percent > 0.0f)
IDirectSoundBuffer_SetFrequency(stream_buffer, machine->sample_rate * machine->speed_percent);
}
#endif /* SOUND_RESYNC */