Audio glitch about every 10-15 seconds

[GoogleCodeExporter]

What steps will reproduce the problem?

Pick any game that your very familiar with in regards to the music.

What is the expected output? What do you see instead?

There is a "stutter" or "glitch" in the audio every 10-15 seconds.

Maybe its a Sound/Sync or Hz issue? (I know I sound stupid, but I'm only a 
tester!)

What version are you using? On GameCube or Wii?

4.1.8 on Wii

Are you using the official build (from the downloads page or auto-update)?

Yes

Please provide any additional information below.

This issue is similiar to the FCEU audio glitch. Just happens less often. 
But still happens.

Original issue reported on code.google.com by nintygaming on 22 Apr 2010 at 11:29

[GoogleCodeExporter]

Did the same tests as I did earlier, but with 32000, same results unfortunately.

The magic number is definitely between 31890-31900 freq. 

Original comment by Nark...@aol.com on 29 Jun 2010 at 11:38

[GoogleCodeExporter]

@ thiagoalvesdealmeida 32000 is NOT the goal here. it depends on the refresh 
rate of the Wii vs the original SNES, and probably a few other factors. For 
example, if it's 59.91 hz, and the SNES NTSC non-interlaced refresh rate is 
(21477272.7272 / ((341 * 4 * 262) - 2)) ~= 60.099, then we're looking at (59.91 
/ 60.099) * 32000 = 31900hz.
Or if it were 59.94Hz then it's 31915. There are other ways to deal with 
syncing (as eke-eke describes), but this is the option is a decent way. We will 
NEVER achieve absolute perfection.

Original comment by dborth@gmail.com on 29 Jun 2010 at 11:47

[GoogleCodeExporter]

Tried with 31890. No crackling whatsoever in everything I tried. Zelda, Soul 
Blazer, Secret of Mana, Axelay, Mega Man X sounded and looked great.

Original comment by muceda9...@gmail.com on 30 Jun 2010 at 12:10

[GoogleCodeExporter]

OK. I understand. Sorry about that. The problem is really the frequency, not 
the latency.

Anyway, I think the 31890-31895 frequency range is the best option. 

It's good to finally see this problem fixed. Props to nintendonerd1889, he is 
the one who insisted on this subject. And dborth, who made this possible.

Original comment by thiagoalvesdealmeida@gmail.com on 30 Jun 2010 at 12:24

[GoogleCodeExporter]

I guess the idea sort of came to me, but if we can get this in the next 
version, the pretty much will make this the best Snes emulator on the wii.  I 
haven't had the chance to mess with the latency, though. 

Original comment by nintendonerd1889@gmail.com on 30 Jun 2010 at 12:29

[GoogleCodeExporter]

You need to check if 31890 works for you, since you said that couldnt hear any 
crack using 31955 (and a lot of crackling with 39000). If it really depends on 
the monitor, maybe your TV needs different values. If that's the case, an 
option to set the audio frequency through the menu would be a good feature in a 
future version.

Original comment by thiagoalvesdealmeida@gmail.com on 30 Jun 2010 at 1:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes, I'll check out 31890Hz to see if it sounds better (and I know it will, 
too). Maybe my ears aren't as sensitive as I thought....I Have a Sony Bravia 
46" LCD HDTV 
(NTSC), so, I'll need to experiment with more values. 

Original comment by nintendonerd1889@gmail.com on 30 Jun 2010 at 3:09

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Nice, I didn't knew the new audio core would let you change the emulated 
(input) sound frequency.

I think I measured the PAL60 Wii framerate to be approx. 59.82 Hz (not sure 
about Gamecube or NTSC Wii), using VSYNC callback to measure time intervals I 
obtained an average value of 16715 us between two VSYNC. This should be 
confirmed by additional tests though. 

If the formula you posted to get SNES original framerate is right AND Wii ouput 
samplerate is exactly 32KHz (seems to be the case from my tests) then it means 
a suitable value would be (1000000 / 16715 / 60.099) * 32000 = 31855hz.

Original comment by ekeeke31@gmail.com on 30 Jun 2010 at 6:53

[GoogleCodeExporter]

I second the idea of keeping the option to set the frequency in the next 
official release, if possible. We all play on different TVs and may cause some 
differences here and there, so everyone can tweak as needed.

I'll try later the 31855hz value and share my impressions.

Original comment by dierobo...@gmail.com on 30 Jun 2010 at 9:04

[GoogleCodeExporter]

There is a lot of crackling using 31855.

Original comment by thiagoalvesdealmeida@gmail.com on 30 Jun 2010 at 12:41

[GoogleCodeExporter]

I also get a lot of crackling with 31855, seems to do no better.

Does it make any sense testing with 31891, 31892...? I see we always try every 
5hz.

Original comment by dierobo...@gmail.com on 30 Jun 2010 at 3:02

[GoogleCodeExporter]

It wouldn't hurt to test more than just 5Hz increments, I think. 31890, 31889, 
31888.....31800 (that might be too low). Just an idea. 

Original comment by nintendonerd1889@gmail.com on 30 Jun 2010 at 3:26

[GoogleCodeExporter]

So it means there is nothing not correct in that formula.

Basically, knowing the number of frames executed per seconds (F = Wii output 
framerate), what you need is to modify the number of samples generated per 
frames (N) so that F * N = 32000;

N actually depends on 2 things:

(1) the ratio of the APU resampler (R = Settings.SoundInputRate / 
Settings.SoundPlaybackRate).

(2) the number of APU samples rendered per frame (S)

with N = S / R

Clearly, (1) is what you want to adjust (fixing the output to 32000 and 
modifying the input rate).

(2) is however less obvious to figure, this is directly related to the number 
of APU cycles executed per frame and less directly to the number of CPU cycles 
executed per frame. 

Original comment by ekeeke31@gmail.com on 30 Jun 2010 at 3:37

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yeah, so I tested the build (the frequency+latency options) and while I got to 
test some values, it gave me a code dump/stack code. The frequencies I tried 
were 31890 up to 31960Hz (in in 1 and 5Hz increments), and the best one sounded 
like 31953. I don't know if it'll help, but here's the code dump message: 

I'm not sure why this happened.

Stack: 

803297f8-->802f3080-->802f7b38-->802256fc

Code Dump:

803297F8  800B0000  90090000  800B0004  90090004
80329808  800B0008  90090008  800B000C  396B0010
80329818  9009000C  39290010  4200FFD8  38A5FFF0

I got this error code twice (occurred after pressing "home") 

Original comment by nintendonerd1889@gmail.com on 30 Jun 2010 at 8:01

[GoogleCodeExporter]

Scratch what i said, i figured the exact number of CPU cycles per frame, the 
average number of APU cycles per frame and the average number of samples per 
frame (one every 32 APU cycles) but the calculation give me a similar value.

The thing is that, contrary to genesis plus, snes9x does not produce the 
samples at the end of the frame but everytime the audio DMA need to be feeded, 
so my method does not work.

The solution seems to play with the input frequency setting AND the audio dma 
buffer length. Also i noted that  the function reading samples in snes9x 
(S9x_MixSamples) seems to return 0 samples if the number of samples required 
(the size of audio DMA buffer in our case) is less than the number of available 
samples. I think this should be modified to return at least the number ofa 
available samples.

Original comment by ekeeke31@gmail.com on 30 Jun 2010 at 8:37

[GoogleCodeExporter]

@ekeeke31, so what you're saying is that the solution to the sound buffer/dma 
issue closer than originally thought? 

Original comment by nintendonerd1889@gmail.com on 30 Jun 2010 at 10:13

[GoogleCodeExporter]

I haven't tested anything yet, it's only based on my analysis of the code 
because I had some time looking at it and was interested understanding how it 
worked.

At first glance, it seems to me the S9xMixSamples function used in Blargg's new 
APU core should be modified when hitting the case where spc::resampler->avail() 
< sample_count, which can happen if you didn't generated enough samples when 
this  function is called. Reading a suitable number of available samples (Wii 
audio DMA requires 32-byte multiple length) instead of 0 in that case seems 
more suitable.

Sample_count is the size of the audio DMA and is fixed to 1024 samples. 
Coincidently, it's the same value used for the APU internal buffer (passed as 
first parameter when calling S9xInitSound), maybe increasing this value could 
help (to prevent the opposite situation where DMA is not reading samples fast 
enough and the APU can not render any more samples)

There is also Settings.SoundSync which seems to be used for better sound 
synchronization but I didn't really figured how it exactly works. It is 
disabled by default in the current SVN.

Last, the code below is used in the function S9xSyncSpeed which is called at 
the end of each frame:,

    while (!S9xSyncSound())
        usleep(10);

I am not sure this is required since synchronization is already done using 
timer or vsync. On that note, S9xSyncSound() always return TRUE when 
Settings.SoundSync is disabled, which means this does nothing in the current 
revision but should be taken in consideration when activating 
Settings.SoundSync.

Those are really only various ideas dropped from looking at the code, there is 
no concrete solution yet but I think understanding first how samples are 
generated, read and ouput is mandatory.

Original comment by ekeeke31@gmail.com on 1 Jul 2010 at 6:51

[GoogleCodeExporter]

Brilliant! I've messed around with it and tested quite a few settings with 
headphones and I agree that 31890 is the best frequency. I'm quite happy with 
it, minimal crackling (which I cannot really hear through the TV speakers which 
suits me fine) and NO stuttering. I'm happy with how 31890 sounds. :-)

Original comment by tmo...@gmail.com on 1 Jul 2010 at 5:55

[GoogleCodeExporter]

I really wish the latency/frequency build wouldn't give me so many dump codes; 
I suppose it's not unexpected, being a beta release and all. But you're right, 
it sure as heck sounds better! XD

Original comment by nintendonerd1889@gmail.com on 1 Jul 2010 at 7:18

[GoogleCodeExporter]

i agree that this should be in the next release so anyone can just make it the 
way they want it

Original comment by Gamewiza...@gmail.com on 1 Jul 2010 at 7:29

[GoogleCodeExporter]

I did some more testing and for me the best sounding is 31894. I couldn't hear 
any problems at all with headphones. Tested using 4:3 original mode, no filters.

Original comment by muceda9...@gmail.com on 1 Jul 2010 at 9:17

[GoogleCodeExporter]

Is anyone else besides Nindendonerd getting code dumps? I still haven't got one 
code dump, and I have been using these latest sound-tweaking builds quite 
excessively.

 I also agree on a custom Hz setting in the next official build would be nice. I think 31900 sounds spot-on, and have seen alot of praise for 31890. I've tried both and honesty, they both sound the same to me. =/

Can anyone tell me if they actually hear the difference between 31890 and 
31900? (or even 31894 stated above). I would really appreciate it. 

They all sound equally great to me, and I can't choose one over the other.

Original comment by Nark...@aol.com on 1 Jul 2010 at 11:16

[GoogleCodeExporter]

I must be the only one getting the code dumps, but whatever. I can't tell the 
difference between 31900 and 31890Hz;  If we did add customizable frequency 
settings in the next version, would that cause more crashes or are these caused 
by pressing the Home button too many times (to change the Hz)? 

Original comment by nintendonerd1889@gmail.com on 2 Jul 2010 at 12:26

[GoogleCodeExporter]

I extensively tried 31894hz setting for almost 2 hours using headphones, lots 
of different games. Not even a single skip. Original video setting, no filters, 
4:3, playing (U) roms. Sound is flawless.

Geez, what a joy. Playing this emulator with an original SNES controller is 
just like being in heaven :D

Original comment by dierobo...@gmail.com on 2 Jul 2010 at 12:28

[GoogleCodeExporter]

@nintendonerd 

See, that's the thing! I have actually tried to make it crash intentionally, by 
doing things like, load roms in rapid succession, press the home button over 
and over, change options then press home alot, change the Hz all over the place 
then play awhile, press home alot again. Do all this and exit, still no dump. I 
just can't break it!

 It performs like a finely tuned piece of software. What exactly do you usually do that causes said code dumps? Are you just playing a game,.. and then FREEEZE, CODE DUMP! or is it just pushing home while playing, that causes the code dump? Or a black screen on exiting? I'm very curious what is causing yours. 

Original comment by Nark...@aol.com on 2 Jul 2010 at 12:52

[GoogleCodeExporter]

Well this sucks. Am I supposed to delete the settings.xml file before I use 
this or what? Right now I'm using the predefined 31955Hz build...I know it 
doesn't sound as good as the customizable ones, but I've used it for over two 
hours, and not once did I see a crash. Now with the customizable builds, I seem 
to be cursed; it seems to happen randomly, whether I push the home button or 
not, thus forcing me to manually hard reboot the wii. I'm using the normal 4;3 
aspect ratio (since it looks better than the 16;9 forced correction, IMHO) with 
a normal filter (I don't like the way SNES games look unfiltered; it looks too 
much like upscaled VC games). I just wish someone else could confirm this 
issue, or at least tell me WHY it's happening in order to prove I'm not 
hallucinating. 

Original comment by nintendonerd1889@gmail.com on 2 Jul 2010 at 1:29

[GoogleCodeExporter]

@nintendonerd, you're not alone. I just happened to come across the same issue 
when I hooked my wii back up to my hdtv (running 16:9 filtered). Just as I was 
playing I hit the home button and got a code dump. I restarted the wii, started 
a game, hit the home button and got another code dump. This never happened to 
me when I was running the same build (customizable with latency) on my CRT (4:3 
original mode), so maybe the filter has something to do with it.

Original comment by muceda9...@gmail.com on 3 Jul 2010 at 12:50

[GoogleCodeExporter]

Why would the filter cause these crashes? I've used 4.2.0 and 4.1.9 (then 
again, ever since Snes9xGx was "born") with filters before and never had a 
single code dump; other problems caused those (such as pressing "home" too many 
times or a corrupt ROM file). I'm sure these will go away once the code is 
cleaned up a bit and released as 4.2.1. 

Original comment by nintendonerd1889@gmail.com on 3 Jul 2010 at 1:07

[GoogleCodeExporter]

I think Muceda is right about the filter causing this.

I use a CRT television with no filters, on 4:3, and have no issues with code 
dumps/freezes.  

Original comment by Nark...@aol.com on 3 Jul 2010 at 1:26

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Why have an HDTV if you can't even use it for videogames? How can it be the 
filter? 

Original comment by nintendonerd1889@gmail.com on 3 Jul 2010 at 2:24

[GoogleCodeExporter]

Another thing I noticed was when switching to filtered mode, I began to hear 
crackling again. I switched to unfiltered mode, and the crackling was still 
there. Switched back to original mode, and the crackling was gone. This was all 
done with the input freq. set at 31984.

So I tested the filtered and unfiltered modes with nintendonerd's suggestion of 
31953 and the sound was perfect. When I tried it with original mode the sound 
skipped about every 10 seconds. So maybe the frequency setting is different for 
both supported resolutions. original's 256x224 sounds best with 31894, while 
filtered/unfiltered's 640x480 (at least I believe so) works best with 31953. 
16:9 correction seemed to have no impact to the sound. Can someone please 
confirm this?

Original comment by muceda9...@gmail.com on 3 Jul 2010 at 2:34

[GoogleCodeExporter]

@nintendonerd, it's the build. I switched back to the older customizable build 
(no latency, just freq) and got no code dumps on all modes.

Original comment by muceda9...@gmail.com on 3 Jul 2010 at 2:36

[GoogleCodeExporter]

Hopefully the new version will rid this issue once and for all XD

Original comment by nintendonerd1889@gmail.com on 3 Jul 2010 at 3:12

[GoogleCodeExporter]

I've been getting no code dumps what so ever from using both the frequency 
release and freq/latency build. In fact they are the most stable builds I've 
used for what ever reason.

To answer the question someone asked earlier:

I cannot tell a difference through my TV speakers from 31890 to 31900 but with 
a pair of Sennheiser headphones on I noticed there is a lot less crackling with 
31890. From what I can tell 31890 appears to be the sweet spot and personally 
speaking if it were up to me, I would incorporate that frequency as a default 
setting in the next official build.

Original comment by tmo...@gmail.com on 3 Jul 2010 at 4:59

[GoogleCodeExporter]

Just to confirm, I've also been using a CRT SDTV hooked up through RGB SCART 
(c'mon guys, it's the ONLY way to play SNES in pure 240p goodness :P) which may 
explain why it's been stable for me also. :-)

Original comment by tmo...@gmail.com on 3 Jul 2010 at 5:02

[GoogleCodeExporter]

We don't USE SCART over here, just component/NTSC combination, and I don't want 
to use CRTs because the flickering gives me a headache (the 50/60Hz frequency). 
But like I said earlier, I must be cursed. Maybe dborth knows why this is 
happening.

Original comment by nintendonerd1889@gmail.com on 3 Jul 2010 at 5:22

[GoogleCodeExporter]

There is no flicker in 240p though :) it's a progressive signal not interlaced. 
Though if you are from the US (I'm from UK) then I understand why you don't use 
it. But yeah I do hate flicker myself. This is just one of the reasons why I 
think this is the best SNES emulator out there, even better than ZSnexbox on 
Xbox as it could only output at 480i/576i on SDTV's. Plus Snes9X GX sounds 
amazing now.

On the old build I was using I was getting code dumps quite frequently, now 
it's really stable but for some odd reason seems to only effect component users?

Original comment by tmo...@gmail.com on 3 Jul 2010 at 6:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I play with a CRT too, original video settings, and never got a single crash 
with all the later small releases dborth gave us here. It's probably the 
filters+new audio frequency which causes the problems. I initially used an HDTV 
to play but switched back to an old TV... it was just embarrassing to play with 
such huge pixels :)

I stay with 31894. By the way, it also depends on the roms you play. NTSC games 
(60hz) play perfectly in sync with that frequency, but PAL games (50hz) will 
start crackling and skipping sound, as they have different refresh rate, so 
keep that in mind when doing some tests. You'll probably need a different audio 
frequency to match the PAL games rate and achieve perfect sound.

Original comment by dierobo...@gmail.com on 3 Jul 2010 at 9:09

[GoogleCodeExporter]

Yeah I know what you're saying, though for me NTSC ROMS take priority. The only 
way to test PAL ROMS in 50hz on these builds is to enter the Wii menu and force 
50hz then boot up the emulator. It's a real tough one as I went down as low as 
31300 and while there was no noticeable stuttering below the default setting, 
there was noticeable crackling which I couldn't seem to get rid off no matter 
what I tried..

Original comment by tmo...@gmail.com on 3 Jul 2010 at 11:34

[GoogleCodeExporter]

@ dieroboter

Can I just ask you why are you using 31984 and not 31890? Have you spotted 
something wrong with 31890 over 31984? I admit they sound very similar indeed 
but I thought I heard the occasional crackle at 31894, but that could have been 
my imagination.

Original comment by tmo...@gmail.com on 3 Jul 2010 at 11:48

[GoogleCodeExporter]

I'll do some more PAL testing later, but turns out that the ROM I was testing 
was International Superstar Soccer and the menu music has quite a crackly sound 
to it anyway so that could have affected my judgement.

Original comment by tmo...@gmail.com on 3 Jul 2010 at 11:50

[GoogleCodeExporter]

@tmor81: I got some slight problems with 31890 (though not happening every 
15sec like earlier this issue) that 31894 apparently helps to get rid of. I've 
been playing with headphones and I couldn't notice any cracks or skips. I don't 
have an explanation or a reason why it works better; just kept trying and found 
it was the best :)

Anyway, I would like to hear more from ekeeke31's coding comments, he seems to 
be the only one who happens to know how is the sound engine working and where 
to modify. Maybe there's a proper way to fix this... or more "polished". The 
programming process surpasses me, hehe.

Original comment by dierobo...@gmail.com on 3 Jul 2010 at 12:18

[GoogleCodeExporter]

Just wanted to mention that some games have some crackle even on a original 
SNES console. For example, the first stage in Castlevania IV, past the castle 
gates, there is normal crackling in that game. So be sure of what your hearing 
guys. 

Original comment by nintygaming on 4 Jul 2010 at 12:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Oh, and just a random side note, is it just me, or did issue 498 come back from 
the dead in the 31955 build? 

Original comment by nintendonerd1889@gmail.com on 13 Jul 2010 at 12:36