Sound very choppy in Windows Vista

[maartena]

I can also confirm it works!! Sound is playing perfectly.

My aero interface is still taking about 25% CPU when playing openttd, but since I now have a dual core thats only a problem on slower machines I suppose. Not an issue here

Only thing is, that I can't play multiplayer with this version, because its different then the regular RC4. But single player works fine, and I can only hope this gets in the RC5 release.

On a side note, yes my server is down. Harddrive crash. Reinstalling now on a 120 Gb I stilll had.

[edwardvdv]

After playing the whole weekend, I can confirm what I suspected Friday: it works perfectly.

Thanks for the quick fix Now let's hope the patch'll be integrated in the final release.

(I updated the Flyspray entry @ http://bugs.openttd.org/task/489)

[maartena]

I played a few single player games with it (got bored, no proper competition), and the sound works fine!

And on another side note, harddrive issue fixed, server back up.

[Quark]

My aero interface is still taking about 25% CPU when playing openttd, but since I now have a dual core thats only a problem on slower machines I suppose. Not an issue here

Maybe try SDL video driver?

[RvL]

Great work! Will there be DirectSound support in the coming 0.5 version?

[Quinnyowns]

Thank's greatly buddy

So far I've found the new Windows Vista experience beyond terrible This lightens my day a little

[Darkvater]

<< Just got back.

Interesting to read the DirectSound driver is working correctly. I have only been able to test the driver in a virtual windowsXP installation and it did consume more CPU power (for me) than the old waveout driver.

I will have a bit closer look at the driver to check for possible improvements and fixes. Cannot promise anything for 0.5.0 final.

[Darkvater]

Had some more work on the DirectSound driver, but still far from happy with it. As I have implemented it at the moment:
Set up n (in this case (secondary) buffers and events. When a sound is played it is put into the buffer (pretty big buffers) and a notify event is set for the end of the sound (DirectSound has no concept of sound-ending, etc. just buffersize). When the event is fired I "free" the buffer for more sounds.
The events are checked every 300ms to see if they have finished.

Now the problem is that I don't like this approach. The buffers are way too big (each sound, as they aren't streamed) must fit and I'm continually checking events to see if a buffer was freed.

I don't like throwing out the buffers after the sound has played (memory fragmentation), but can't keep all sounds in memory either (80/90 samples?).

We could go the current way that OpenTTD itself mixes the sounds and streams them to the buffer. I've also tried this but didn't really work out (either very choppy sound and high CPU usage due to high buffer-streaming (small buffer-size) or lagging sounds (due to bigger buffer-size (1-2 second(s)).

If anyone has ideas or written DirectSound for games I'd like to hear.

[dannys9]

Just found an easy fix! Start the game as follows:

openttd -s win32:bufsize=2048

This doubles the sound buffer size compared to the hard coded one. Works perfectly for me.

[Darkvater]

Just found an easy fix! Start the game as follows:

openttd -s win32:bufsize=2048

This doubles the sound buffer size compared to the hard coded one. Works perfectly for me.

It's hardly hardcoded if you can change it through the command line . But nice find, might even be useful for vista people if this is confirmed.

A bigger bufsize does mean more lagged sounds, so don't increase this size too much.

[dannys9]

It's hardly hardcoded if you can change it through the command line .

Well, it truly is, as a fallback in win32_s.cpp, line 61:

Code: Select all

_bufsize = GetDriverParamInt(parm, "bufsize", 1024);
                                              ----

The problem is, that passing options on the command line only seems to work with nightlies and svn versions. With 0.5.0-RC5 you can pass the parameters, but there will be no sound (at least, here). Maybe a wanted behaviour of debug and release versions?

I would increase the hardcoded fallback and submit a patch, but I can't get my MinGW to run properly

[henrik]

I've done sound streaming with DSound before, without consuming any massive amounts of CPU or anything.

Here's my (very old) code:

http://www.dtek.chalmers.se/~tronic/dsound.rar

The coding style is a little bit messy but it has worked very well for me in the past, and exhibits no problems on Vista.

For a smooth CPU usage profile, DSound_Update() should be called once every frame or so.

[maartena]

Just found an easy fix! Start the game as follows:

openttd -s win32:bufsize=2048

This doubles the sound buffer size compared to the hard coded one. Works perfectly for me.

Wow.

This works

I haven't started playing yet, but I have started OpenTTD on Vista/Aero, and I hear no sound distortion.

I'm gonna play me a game now on RC5

[maartena]

Just found an easy fix! Start the game as follows:

openttd -s win32:bufsize=2048

This doubles the sound buffer size compared to the hard coded one. Works perfectly for me.

It's hardly hardcoded if you can change it through the command line . But nice find, might even be useful for vista people if this is confirmed.

A bigger bufsize does mean more lagged sounds, so don't increase this size too much.

It does indeed slightly lag the sound. But still a nice find

[Darkvater]

I've done sound streaming with DSound before, without consuming any massive amounts of CPU or anything.

Here's my (very old) code:

http://www.dtek.chalmers.se/~tronic/dsound.rar

For a smooth CPU usage profile, DSound_Update() should be called once every frame or so.

Thanks henrik. I've finished the dsound-driver though so will compare it with yours

About the hardcoded-guy: it is *NOT* hardcoded. It is a default if no value is passed. Every settings needs to have a default, that is not hardcoding. The setting won't work in 0.5-RC5 because the driver only has space for 16 chars, and '-s win32:bufsize=2048' is longer, so it'll be trunc'd . (Will be) fixed for final release.

@henrik: I had a look at the code and it only uses a single buffer without support for multiple channels so we would have to use the OpenTTD mixer. I was curious about drivers using multiple buffers and sounds (streaming or static). Anyways I'll clean up my driver and post it here to see how you guys like it (if someone has programming experience). I am not even sure the code actually works as there is for example no primary buffer created, which is really a must.

I guess the high-priority is kinda off now that increasing the bufsize helps.

[maartena]

The setting won't work in 0.5-RC5 because the driver only has space for 16 chars, and '-s win32:bufsize=2048' is longer, so it'll be trunc'd . (Will be) fixed for final release.

You are wrong. When I use that setting in 0.5-RC5, I have working sound in Vista, without it I do not.

So it does work

[RvL]

I can confirm that the workaround works, though it sometimes gets choppy when there is a lot of sound (e.g. big stations)

[CMircea]

So it does in XP for me, when there are a lot of sounds p laying at the same time.

[Darkvater]

Current directsound driver diff, comments are welcome if someone has them

[flake]

I use 0.5-RC5 under vista 64bit and "-s win32:bufsize=2048" works just fine, all the stuttering is gone.