Crackling audio sound problem (RetroArch PC)

RetroArch General
#1

If I use the combination retroarch.exe 0.9.9 (wip1/wip2/wip3), SDL video driver, SDL/DirectSound audio driver and following libretros: genesis_plus_gx_libretro_x86, mednafen_pce_fast_libretro_x86, mednafen_psx_libretro_x86 and meteor_libretro_x86 I have a heavy crackling audio sound. Any changes on the audio or other settings doesn´t help. With retroarch.exe 0.9.8 the sound is fine with these libretros!

Note: All other libretros and and its sound is ok with retroarch.exe 0.9.9

System: DELL Latitude C840 Notebook Mobile Pentium 4-M Stepping:C1 1794.5 MHz Graphic: NVIDIA GeForce4 440 Go (64MB) Audio: Crystal CS4205 Driver (Cirrus Logic, Inc.) DirectX 9.0c (4.09.00.0904) Windows XP SP3 32-bit

#2

Tried XAudio? Anyways, git bisect to find the relevant commit.

#3

Yes, I tried XAudio too.

Any changes on the audio or other settings doesn´t help.

Note: XAudio produce crackling audio sounds it doesn’t matter whether I use 0.9.8 or 0.9.9

#4

Here are 2 recorded sound samples to get a impression.

0.9.8_mednafen_pce_fast_libretro.mp3

Libretro: mednafen_pce_fast_libretro_x86 Game: Neutopia.pce RetroArch: v0.9.8

0.9.9_mednafen_pce_fast_libretro.mp3

Libretro: mednafen_pce_fast_libretro_x86 Game: Neutopia.pce RetroArch: v0.9.9

#5

I did more testing with my crackling sound issues with the mednafen-psx core and found switching from dsound to xaudio didn’t really make a difference on average. I did find that changing the audio latency to 200 lessened the crackling, but it would still happen too much. I guess changing the latency isn’t the same as increasing the sound buffer in medanfen proper.

That’s the only core I have that issue with on my 3.3ghz i5 2500k machine, probably because that’s one of the most resource intensive cores available.

#6

video_refresh_rate could be misconfigured. If it’s way off target, it could cause audio crackling. Does it happen when vsync is disabled?

#7

I hadn’t tried turning off vsync entirely. That does eliminate the crackling, even at Zanac Neo’s first boss where it was the worst before. I did try getting a precise refresh rate using your “Getting optimal vsync performance” guide on the wiki and that didn’t seem to help though.

#8

If VSync behavior on your machine is unreliable, you can try turning video_threaded = true. It shouldn’t affect your audio in that case.

#9

Turning video_threaded on fixes the audio at the cost of stuttering video, at least with hard sync on. Turning hard sync off makes it run fine at the cost of the input lag. Oh, tradeoffs :U

#10

That’s the beauty of doing the “impossible” of syncing to video and audio at the same time. :\ Dynamic Rate Control gets you there most of the time, but there’ll always be some messed up setups.

If you play with vsync + no threaded, you’ll see dynamic rate control stats on exit. The audio buffer fill stat should hover around 50%. If you get a very low value (with a high percentage of the time being close to underrun), you can try lowering video_refresh_rate a bit. Many twiddle factors. If the audio card DSP clock is way off target, this could happen, but that’s kinda rare :v

#11

I’m thinking hard sync plus that core is just too much for my system. I tried Einhander with threaded off, vsync and hard sync on and get an average audio buffer saturation of 5.25% and amount of time spent close to underrun 96.03%. Without hard sync they are at 42.60% and 37.50% respectively and I rarely get a crackle (turning on threaded fixes the few crackles I get with normal vsync). The average hz it gives me varies with hard sync on but is consistent with normal vsync.

Lowering the refresh rate value with hard sync on does increase the buffer and decrease underrun a little, but the best I can seem to get is around a 5% change.

#12

Ye, hard sync is demanding. That’s how it gets lower latency. With hard sync, you have a frame timing like:

Emulate Game -> Dispatch GL calls -> Swap -> Wait till GPU has finished, so both emulation and rendering has to happen sequentially within 16ms (very demanding especially if you’re using shaders).

Non-hard sync doesn’t block, so emulation can take close to 16ms. Just dispatching GL calls doesn’t take much.

#13

@Maister

Did you found the relevant changes between 0.9.8 and 0.9.9 which can be the reason for my crackling audio sound problem?

Thanks in advance.

#14

@Maister

Did you found the relevant changes between 0.9.8 and 0.9.9 which can be the reason for my crackling audio sound problem?

Thanks in advance.[/quote] No, I can’t. You have to git bisect and build yourself to binary search through ~1500 commits and see where it starts to change behavior. Should take roughly 20 compilations to find the commit.

#15

@Maister

Did you found the relevant changes between 0.9.8 and 0.9.9 which can be the reason for my crackling audio sound problem?

Thanks in advance.[/quote] No, I can’t. You have to git bisect and build yourself to binary search through ~1500 commits and see where it starts to change behavior. Should take roughly 20 compilations to find the commit.[/quote]

I´m too busy with my projects, in this case RetroArch has a low priority for me. At moment I´ll stay with the version 0.9.8. Version 0.9.9 is useless for me.

#16

I’m curious if there are any less intensive sync methods that could be implemented that would still reduce lag. Maybe a triple buffered vsync? Hard sync is great since it lowers input lag to a level below proper mednafen, but I’d be happy if I could get at the same level without killing performance. RetroArch has so many more shaders available and does the 4:3 aspect ratio better, which is why I want to switch my PSX emulation over to it.

I should mention I tried turning off shaders just to see if that would be enough to make hard sync run better with PSX, but it didn’t make a difference.

#17

You can’t force triple buffering in GL, it’s all up to the driver (it’s probably already doing it, and probably more, since you’re getting so much lag). It’s possible to fence on the previous frame to allow 1 extra frame of lag, but it just adds so much complexity :\

#18

Hmm, well if you can figure out a way to implement that without muddying up the code too much it might be a nice feature for Windows users with Nvidia cards. You’ve been quite diligent with the replies and the addition of hard sync already so I appreciate all the effort as is :slight_smile:

#19

Ye, wasn’t as bad as I expected, pretty clean. Added video_hard_sync_frames (0 is current behavior, 1 lets GPU run 1 frame ahead, etc).

#20

Nice! I might give a look at that compiling guide to try this before the next release.

Edit: I was able to compile a 64bit build tonight. With hard_sync_frames set to 1 it works perfectly :smiley: