Opened 10 years ago

Closed 10 years ago

Last modified 5 years ago

#6510 closed defect (fixed)

SDL: Audio delay in daily builds

Reported by: misterhands Owned by: digitall
Priority: normal Component: Port: Win32
Version: Keywords:
Cc: Game:

Description

Win 32/64 daily builds All games

There is an important audio delay (the sound is about 500ms late) on my systems (desktop and my laptop too) in the Win 64/32 daily builds. This can be noticed in various games and engines. For example, the footstep sounds are lagging in FT, Bargon Attack, and WME games like Chivalry or Dirty Split.

I'm getting a related warning: WARNING: SDL mixer output buffer size: 11028 differs from desired: 4096! That's with the sample rate set to 44100 Hz.

With 22050 Hz, I get: WARNING: SDL mixer output buffer size: 5512 differs from desired: 2048!

The sample rate value and resulting buffer size does not alter the lag, from what I can tell.

For reference, there is an old bug about this issue: https://sourceforge.net/p/scummvm/bugs/5837/ and my original WME bug report: https://sourceforge.net/p/scummvm/bugs/6198/?page=0

The original interpreters do not have this delay problem, and ScummVM 1.6 works fine (no warning, no audio lag). So it looks like a bug in the daily builds, at least the Win 32/64 ones.

Ticket imported from: bugs/6510.

Change History (27)

comment:1 by digitall, 10 years ago

@misterhands: OK.. As was said on bug #5837, that warning indicates that SDL did not return the correct size of request audio buffer and thus odd things could occur.

To be clear, could you answer the following questions: 1. When you say "Daily builds", do you mean the buildbot daily builds or Kirben's additional Win32 daily builds? Can you test with the latest of both and indicate if the warning is present and what the observed behaviour is for both. 2. Could you try with a buggy Win32 daily build (which I am assuming is from the buildbot), try replacing the SDL.dll shipped with the one from the v1.6 release and see if this fixes the issue?

comment:2 by misterhands, 10 years ago

  1. I meant the buildbot ones. Just tested with a Kirben build and that one works fine.

  2. Yes that fixes the problem.

Stable v1.6 win32 and Kirben's build uses SDL v1.2.15.0 (file size 313 870 bytes) -> OK buildbot win32 uses SDL v1.2.15.0 (file size 1 069 567 bytes) -> WARNING + LAG buildbot win64 uses SDL v1.2.14.0 (file size 1 739 323 bytes) -> WARNING + LAG

I was not aware of these variations in SDL versions, nor of the different file sizes for v1.2.15.0... is this normal?

comment:3 by lordhoto, 10 years ago

Is the warning also gone (or changed) when you use a build/SDL.dll which does not inhibit the described issue?

comment:4 by misterhands, 10 years ago

The warning is gone in that case.

comment:5 by misterhands, 10 years ago

Hmm sorry; disregard that last reply, on 2nd thought I'm not sure I understand the question. Can you rephrase that lordhoto?

But basically the warning is always there with the lag. You get both or nothing, depending on the SDL file used.

comment:6 by lordhoto, 10 years ago

I was asking whether you still get a "SDL mixer output buffer size [...]" warning when running a build which doesn't have any audio delay for you.

comment:7 by misterhands, 10 years ago

Ok, like I said in that case there is no warning.

comment:8 by digitall, 10 years ago

misterhands: You mentioned about the "variations in SDL versions".

The problem is that the SDL project has deprecated support for SDL-1.2, and migration to SDL-2.0 API is not a viable option currently.

The last released SDL-1.2 version is 1.2.15 found here: http://www.libsdl.org/download-1.2.php specifically, this is the win32 standard precompiled SDL.dll: http://www.libsdl.org/release/SDL-1.2.15-win32.zip

This has a size of 303616 bytes and a md5sum of 3ea7829589775f17f3b2bd13c646d2f7

comment:9 by digitall, 10 years ago

Could you please try testing with this standard version and see if the warning is present?

The reason that both Kirben's built SDL.dll and our buildbot one differ is that they are rebuilt from v1.2.15 source code with a few minor patches to correct issues found since the v1.2.15 release. This is mainly a minor mistake which causes the SDL version listed on the DLL to be v1.2.14, rather than v1.2.15.

I setup the built SDL.dll for the buildbot after talking to Kirben, but I suspect something was missed here. Possibly bearing in mind the difference in the DLL size, the issue is that his DLL is built as release with no debug symbols and the buildbot one is built as a debug release with symbols, though this shouldn't cause the observed issue :/

With some help, should be able to investigate and correct the buildbot SDL.dll to a good version.

comment:10 by digitall, 10 years ago

For completeness, the v1.6.0 build and Kirben's daily builds use a SDL.dll of 313870 bytes with a md5sum of 12048f8179a29db5d87eebf45333df14.

comment:11 by digitall, 10 years ago

The buildbot is currently an SDL.dll of 1069567 bytes with a md5sum of f272bc48d82c071503810d882cc38eee for win32 builds and an SDL.dll of 1739323 bytes with a md5sum of cc900637d38b903767576ba226ef04e8 for win64 builds.

This is not the same as the precompiled win64 SDL.dll from the libSDL project page i.e. http://www.libsdl.org/release/SDL-1.2.15-win32-x64.zip which is 306688 bytes in size and has an md5sum of cf31ca8ebb1b595c0307621a1204d5a5

comment:12 by misterhands, 10 years ago

Just tried a buildbot win32 build with the SDL.DLL from here: http://www.libsdl.org/release/SDL-1.2.15-win32.zip (size 303616 bytes and md5sum 3ea7829589775f17f3b2bd13c646d2f7)

And

a buildbot win64 build with SDL.DLL from here: http://www.libsdl.org/release/SDL-1.2.15-win32-x64.zip (size 306688 bytes and md5sum cf31ca8ebb1b595c0307621a1204d5a5)

In both cases, there is no warning / lag.

comment:13 by lordhoto, 10 years ago

I setup the built SDL.dll for the buildbot after talking to Kirben, but I suspect something was missed here. Possibly bearing in mind the difference in the DLL size, the issue is that his DLL is built as release with no debug symbols and the buildbot one is built as a debug release with symbols, though this shouldn't cause the observed issue :/

Is buildbot's SDL.dll build against DirectX, i.e. does it have a dsound audio output? (This makes me wonder: Can someone try the working SDL.dll with waveout, i.e. SDL_AUDIODRIVER=waveout, and see whether it starts to fail for that?)

comment:14 by digitall, 10 years ago

Have committed some debug code for the SDL audio driver in use as commit a4ad32c5d9d4a09765c8441b7296a0aefe66d327.

misterhands: Try running the next nightly build or a self compiled build from the latest master, using the command "scummvm -d 1" from a command window.

This will then print the SDL video and audio drivers being used. For me on Linux x86_64, these are x11 and alsa.

As lordhoto has indicated, you can also switch/force an audio driver using SDL_AUDIODRIVER=waveout or SDL_AUDIODRIVER=dsound, so see if this makes the difference with both "good" and "bad" SDL.dll

comment:15 by Kirben, 10 years ago

I can only produce that warning on my builds, if I switch the SDL audio driver to waveout.

It really looks like the SDL version on builtbot was built without the required DirectX libraries, which can be downloaded at http://www.libsdl.org/extras/win32/common/directx-devel.tar.gz

comment:16 by digitall, 10 years ago

@kirben: Ah! Thanks, will recompile the SDL.dll on the buildbot box to support dsound as well as waveout then.

Does this indicate a latent issue with "waveout"? Should we issue a warning if the audio driver is returned as "waveout"...

comment:17 by digitall, 10 years ago

Owner: set to digitall

comment:18 by Kirben, 10 years ago

The waveout driver is known to have more latency, although I'm not sure if it is worse under Windows Vista onwards, due to audio changes.

I don't think it is worth adding a warning, as the waveout driver is usually only tried, if the dsound driver is causing problems.

comment:19 by misterhands, 10 years ago

Same thing here, waveout seems to be the culprit. No warning / lag when using dsound. The SDL.DLL files in the buildbot win32/64 builds apparently force waveout, as dsound isn't working there.

comment:20 by digitall, 10 years ago

misterhands: Right. Have rebuilt the win32 SDL.dll for buildbot with DirectX. Please try the next nightly.

comment:21 by digitall, 10 years ago

win64 SDL.dll also updated on buildbot with DirectX.

comment:22 by digitall, 10 years ago

As we have had sporadic reports similar to this issue over time, I have added a warning if "waveout" is being used as commit: c5e7aa8e93cbc1bea8442ac88a4e6db9873763e2

The code for this was fairly simple and self contained and should head off future user bugs in this area when a user's DirectX setup is the problem.

Changing this bug to pending-fixed, waiting on misterhands to confirm that the latest nightly fixes the issue for him.

comment:23 by digitall, 10 years ago

Resolution: fixed
Status: newpending

comment:24 by misterhands, 10 years ago

Yes, I've tested the win32 and 64 nightlies and it's now fixed. Thanks a lot! :)

comment:25 by digitall, 10 years ago

Thanks. Closing as fixed.

comment:26 by digitall, 10 years ago

Status: pendingclosed

comment:27 by digitall, 5 years ago

Component: --Unset--Port: Win32
Note: See TracTickets for help on using tickets.