Strange performance problem... out of ideas


#1

I have a strange problem where my application streams audio (using DirectSound) and audio stutters like h-ll, I see in the debug log that the audio device keeps reopening all the time:

... opening dsound out device: Primary Sound Driver rate=44100 bits=16 buf=960 opening dsound out step 2 opening dsound out step 3 closing dsound out: Primary Sound Driver The thread 'Win32 Thread' (0xdd0) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x240) has exited with code 0 (0x0). opening dsound out device: Primary Sound Driver rate=44100 bits=16 buf=960 opening dsound out step 2 opening dsound out step 3 ...
If I then hide the application window (so its hidden by other windows), or disable GUI updates, audio works.

This would not by itself be annoying, but the thing is that I have another machine where the identical code base poses no problems whatsoever. No stuttering, nothing. Works like a charm.

And the machine where it works is actually a slower machine (!?)

I’m out of ideas, could really use some input here…

:cry:
/R


#2

That normally happens when the DSound input and output streams lose sync and it has to re-sync them. Some dsound drivers are crap in that way, others aren’t…

If you want to explore it a bit more, try looking in the resync() method in the DSound code. I’ve not got a machine here that has the problem.


#3

Indeed the resync() method is called repeatedly. To add to the conundrum, both machines have the same audio configuration: Logitech USB Headset (of same type) using the Windows USB Audio Device of same version (5.1.2535.0 Win XP SP2).

Machine with problem: Intel Pentium 4 3.2 GHz, 1GB RAM, Win XP Pro SP2

Machine without problem: Intel Pentium 4 3.06 GHz, 512MB RAM, Win XP Pro SP2

One odd thing though when looking now in the System props, is that the problematic machine reports 2.39 GHz (way-off from 3.2 GHz), whereas the other reports 3.07 GHz… :?

Indeed the problematic one has higher CPU usage (which would be explained by the low CPU frequency), which did strike me as odd given the better specs…

I’ll check if the BIOS has freaked out… :shock:
/R

[Edit: Upon checking the System props the correct CPU speed (3.19 GHz) is reported. So much for that thought… ]


#4

Solved. In the BIOS the High res timer (for multimedia) was disabled. Resetting the BIOS to default (in which HR timer is enabled) fixed the problem.

But… I forgot to mention one thing: I had an earlier incarnation of the application (using Juce V1.41) which didn’t exhibit the problem (even with the BIOS HR timer disabled setting). So for that sake, I tried using 1.41 instead of 1.42 in the new version of the appl, but that didn’t help either. Right now, I can’t make heads or tails of this…

But I’m happy for now… :slight_smile:
/R


#5