Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Audio lag/delay - consistent
#1
I have a consistent audio lag that I haven't been able to get rid of no matter how I fiddle with settings.

It doesn't change - it's always about a second. My games run at full speed (60 fps), and audio sounds fine, it's just delayed. (Easy way to check is changing menu pages in Dragon Quest 8 or Final Fantasy 12.)

Anyone have any suggestions?

Using PCSX2 1.1.0.5622 SVN build, though I have the same issue with 1.0.0.

AMD Phenom II X4 940 clocked to 3.5 GHz
AMD Radeon 7850 mild factory overclock
Razer Barracuda sound card
8 gigs DDR2 RAM
Most recent non-beta drivers for everything

Most settings are default. Changes:
Speedhacks enabled
. MTVU speedhack on (necessary to get decent speed in DQ8 - disabling doesn't help)

GS window: Aspect ratio set to 16:9

GSdx plugin SSE2
. DirectX 11 Hardware (changing to DX9 or software doesn't help)
. Internal resolution set to 3x Native (changing it doesn't matter)
. HW hacks enabled: (disabling them doesn't change it)
. MSAA 8x
. WildArms Offset

SPU-2x settings:
. Interpolation: Hermite (doesn't seem to make a difference)
. Module: 2 - DirectSound
. Latency: 102ms (I fiddled with this, but it didn't seem to matter?)
. Synchronizing Mode: TimeStretch

LilyPad svn pad plugin.

cdvdGigaherz (though I'm running from an ISO anyway)

USB, FW, and DEv9 are null plugins.
Reply

Sponsored links

#2
The most common cause of audio desync is EE cyclerate altoung VU cycle stealing can do it also in some game (the common symptom of excess VU cycle stealing is the game looking sluggish/laggy).

That's game dependent, the mentioned games works relatively well with speedhacks, probably you have EE maxed what shouldn't.

Xenosaga, for example is sensible and may desync even with just a little EE cyclerate, FF Dirge of Cerberus goes wonky with any VU clycle stealing...

So, try changing the speedhacks combination keeping in mind the lesser possible is always better.

PS: Avoid "Enable Fast CDVD" in general fashion also. It may useful in few and very specific cases only.
Imagination is where we are truly real
Reply
#3
EE cyclerate is the default 1. Changing it doesn't change the sound delay.

VU Cycle Stealing is at 0. Changing it doesn't change the sound delay, though it does make the games stutter.

My lag doesn't seem to be game dependent - all the games I've tried do it, and all to the same degree.

(I thought maybe it was a sound driver issue, but it doesn't happen in any other programs, and unfortunately there aren't any newer drivers for my sound card. It's a nice card, but Razer abandons their products way too fast.)

I tried disabling my sound card and using the audio support on my video card, but it didn't make a difference.

I'm completely baffled.
Reply
#4
I see you are using direct sound which lost Windows native support since Vista (If I recall correctly), have you tried the recommended XAudio?

Try the "Latency" also knowing smaller values means smaller (and quicker) buffers that can accelerate the sound at expense of possible choppiness if too small or greater latency if too big (what may the problem in there).

Those games should not present that problem with conservative hacks (or none) if the FPS is not too low.
Imagination is where we are truly real
Reply
#5
yeh use xAudio2 in spu2x and drag the latency slider as low as it will go (50ms?) it will still be verrrrrrry slightly out, but it should be fine unless you are playing music rhythm games.
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#6
I tried XAudio2, DirectSound, WaveOut, and Portaudio. Portaudio produced no sound, but I had the lag issue with all of them. Dragging the latency from 102ms down to 50ms made a -tiny- difference, but not much.

If I had to guess, I'd say I've got about 750ms lag in audio. It's just enough to be really irritating.
Reply
#7
Indeed, such latency is unacceptable or at least irritating. But I'd say it is a general issue in your rig instead a problem with the emulator in this case. Due to nature of emulation you can't compare with native PC code (or games or media players).

One possible attempt would be removing the video card audio support at all as any other possible audio driver not directly related to the audio card (discrete or integrated). I do it myself, preventing Nvidia ever installing the audio driver because I know it is cause of issues even with PC games in many cases and even when it is not being used directly.

PS: If using the sound integrated to TV via HDMI this could pose one level more of complexity and be source for issues.
Imagination is where we are truly real
Reply
#8
i've got idea put latency minimal 1ms but dev againts it. So better buy better cpu dude, it's kind useless cos right now dev priority is compatibility.
Reply
#9
(05-04-2013, 05:22 PM)billyash Wrote: i've got idea put latency minimal 1ms but dev againts it. So better buy better cpu dude, it's kind useless cos right now dev priority is compatibility.

what the duck.
Reply
#10
(05-04-2013, 05:22 PM)billyash Wrote: i've got idea put latency minimal 1ms but dev againts it. So better buy better cpu dude, it's kind useless cos right now dev priority is compatibility.

The answer is still the same, 1ms latency is hard to accomplish even in professional sound devices with ASIO drivers and running native code... let's not even think such thing in emulation... 50ms is already "dangerous" and the emulation may not be able to keep it smooth at this value (despite 50ms is clearly perceivable and not for the best, is admited) Smile

So is not that the devs are trying to avoid the issue, that's just too unreal...

Code:
PS: One must remember that showing images, playing sound and accepting gamepad inputs aren't the only things the computer does in playing the game, it needs to do a lot of calculations also, actually need to do lots of calculation even to show the image, play the sound and manage the inputs... all the while the OS is taking it's time also. 50ms is kind of giving time for the emulator doing the translation, caring for the video and other things before getting to the sound again (hence the buffer is expected to be large enough to keep 50ms of sound data that the sound card can use while the processor is doing something else).

Reducing the latency to 10ms means the emulator must care for the sound more frequently and probably the processor will not be able of doing so, then the buffer will get empty before the processor can resume the sound and then the sound becomes chopped, probably desynced and maybe nastier things may happen, like increased appearances of grues in the dark ready to eat incautious players :)
Imagination is where we are truly real
Reply




Users browsing this thread: 1 Guest(s)