It seems that the Xaudio and OpenAL output methods do not like having multiple soundcards in a system, the result of such a setup, is a massive frame hit, infact, its the same frame hit that happens with DirectSound, when sync to audio is disabled.
Â
with Xaudio, the fix is to disable any filters
Â
With OpenAL, setting to generic software, instead of generic hardware lessens the problem.
this is odd, its not related to 2 sound cards at all, it just seems that vba-m is using heavy amounts of cpu for xaudio and openal.
I tested that as requested Squall using Sword of Mana (the only game I am currently playing on VBA...and it should be good for some fast paced action and sound slowing down if it exists)(I ran it with HQ2x on).
Â
My results were as follows:
With sound sync disabled all of them ran my game into overdrive like 100-120% (usually around 115 or 116) (I have no frameskipping or throtteling enabled) with a random drop to 86%...probably caused by some background task spinking for a second.
With audio sync on they all ran at a cool 98-102%, but mostly 100...aside from OpenAL when set to hardware...it ran at around 80%. No problems however with Xaudio.
Â
When audio sync was disabled the CPU load was like 90+ on all of them.
When audio sync was enabled CPU load ranged from 70-100% but mostly stayed around the high 70s....aside from OpenAL on hardware...it seemed to be throttled down to 30-70% (mostly 60s..but it often randomly changed down to 37% or 47%...and the excess then showed up on my system idle process).
Update: I just found that I could boost the CPU load...and therefore running efficiency of OpenAL hardware by setting the buffer to the max...which gave me mostly 100%.
Â
As you know I have a Creative Sound Blaster Audigy Value sound card installed on my system...I am afraid I am not confident enough to mess around in my PC and see what my realtek onboard gives me.
Â
AMD Athlon64 3700+ (2.2Ghz rated as 3.7Ghz Pentium), ASUS A8NE-FM (OEM), 4x512MB DDR400 RAM,
ATI Radeon X850XT (256MB GDDR3 PCIe), Seagate Barracuda 320GB SATA2 HDD, Windows XP SP2 Home,
Leadtek Winfast TV2000 XP Expert, Creative Sound Blaster Audigy Value
quick c/p of my specs as seen in my sig on negmu
Yes, i have a SBLive installed in this system, and theres no problems
1s contain a Yamaha OPL3-SAx (Duron1100), and the last has a SBPCI, and CMI8738 with the latest drivers installed(AthlonXP2000),
Â
Only this system with the SBLive gets full performance with openal and xaudio. the other 2 get frame drops. i would assume its to do with buffering, on the yamaha and cmi boards it probably doesn't fill fast enough.
I'm kind of working on it, with XAudio2 at least.
Â
For now, the most important thing with OpenAL is to either increase the buffer size or to use the software driver. I've come around quite some cards where the native hardware driver was way to slow or even Generic Hardware did a bad job. But this is usually only related to the driver. For ex. my Xonar D2 had no native OAL driver in the first drivers, then it got one which was kind of bad with low buffers and now even that works better.
Yes, just an update, i managed to fix the performance on the Athlon2000
Â
it was caused by having 4xAA set globally (i hadn't modified the GBA profile on that machine to include the vba-m executable) so openal works alright on that machine now, in software mode. (hardware runs like ass, lol)
Â
However, Xaudio is still slow, seems systems that don't have a proper MPU chip don't get good Xaudio performance.
so wait, you are saying low buffer capabilities causes the low CPU use and framerate drops on OpenAL in hardware mode?
low, and software only buffers cause cpu usage to increase, and frames to drop.
yeah but this was kinda the opposite...cpu use was being limited to 70%....with my idle process then sitting at between 30-20% cpu use depending on which background task needed a bit of power...that was on default setting of 5...upping the buffer upped the CPU use and therefore performance of the emu...
thats because the buffer adjuster in openal, is extending the buffering cycle, short periods need less cpu time, but result in crackly sound.