[openal] "Performance" Question
metalcaedes at gmail.com
Wed May 21 20:52:08 EDT 2014
Am 22.05.2014 02:47, schrieb Chris Robinson:
> On 05/18/2014 10:51 PM, developer at oldunreal.com wrote:
>> I am using OpenALSoft for quite a while already in Linux for my project
>> and decided to move on from Creatives OpenAL Version to OpenALSoft in
>> Windows too. I avoided it so far because it seemed to run flawlessly and
>> it was able to initialize the (Creative) Hardware directly. Now that I
>> switched people are afraid of losing hardware acceleration. I know
>> OpenALSoft initializes DSound and WinMM but I have honestly no idea
>> about how much these are can benefit from any hardware acceleration
>> provided by a soundcard.
>> Are there any charts, further information, comparisons or whatever to
>> compare that? Is there even a difference in the end? I was not able to
>> find a measurable quantity so far, but to appease the people I'd love to
>> know more about that topic if possible.
> I don't have any comparisons, but as a quick test I did, the current git
> head of OpenAL Soft is able to process 512/1024 sample updates from a
> couple dozen sources, and one reverb effect, in about 0.5 ~ 1ms (64-bit
> Linux, AMD Athlon64 X2 4200+ which is a fairly old dual-core CPU). This
> is with each of those sources having their properties updated 30+ times
> a second, using cubic resampling (the default is linear, which is
> faster). It'd be a bit worse with HRTF enabled, but more than good
> enough for general use.
> The biggest benefit you'll have with a hardware OpenAL driver is audio
> quality. Hardware can employ better techniques for resampling, filters,
> and effects since it won't bog down the CPU at all. It would also
> potentially have the benefit of more types of filters and effects,
> although OpenAL Soft is slowly but surely adding more of them (high-pass
> and band-pass filters were implemented very recently).
I guess that using lots of EFX effects could have a noticable
performance impact compared to hardware acceleration - but in the end
one just needs to test whether it's an unacceptable slowdown in the
specific application or not.
Shouldn't OpenAL-softs and Createives openal.dll be compatible anyway,
so people could just use whatever they want, even if you develop against
OpenAL soft (assuming you don't rely on extensions unsupported by Creative)?
More information about the openal