Linux Audio Performance Scaling in Games

[edged]

Hey.

I completed a round of benchmarks a month or two ago, but never got around to posting it.

The idea behind it was to observe Linux audio performance and how it scales under different API. I decided upon utilizing ioquake3 because of several reasons:
1) It is an older game that is fill-rate limited, thus it will allow greater headroom for analyzing the impact of audio performance (the graphics card is less important).
2) It provides audio output through multiple APIs - SDL and OpenAL.
3) Furthermore, both SDL and OpenAL allow one to manually override (specify) the audio device to be used. This can be achieved in OpenAL's configuration file, and in the case of SDL through an environment variable.
4) Lastly, the quake3 engine is well known for being a reliable (reproducable) benchmark.

Test System
----------
Kubuntu 7.10
AMD 1.67Ghz Athlon XP
768 MB PC2100 Reg ECC (266Mhz DDR-SDRAM)
AMD 761 Northbridge (AGP)
ATI 9800 Pro 128MB AGP 4x
Creative SBLive! PCI


Graphics Drivers
--------------
Two drivers were tested along-side each other:
Xorg Mesa DRI and ATI's FGLRX (8.40.4)
These versions were the latest available to the distrobution at the time of testing. I later tested the ATI 8.42 driver, however it proved to be slower (yes slower), and the resolution of 1920x1440 did not function correctly (bugs, there were others).

Audio Drivers
------------
The distrobution (default included) versions were used of: ALSA, OpenAL and SDL.

Notes
-----
1920x1440 was unavailable to the opensource Mesa DRI driver on Kubuntu 7.10

Sound Disabled:
-------------


SDL ALSA Native:
--------------


OpenAL ALSA Native:
-----------------


OpenAL ALSA 5.1 Surround:
-----------------------



Analysis:
-------
Overall, the ATI FGLRX wipes the deck with the OSS Mesa DRI, but that is not the issue at hand,

Immediately, we can see in the transition from Sound Disabled to ALSA Native that ATI FGLRX takes a serious performance hit at lower resolutions (~30 fps). Mesa DRI also takes a performance hit (~15 fps), however Mesa DRI is already quite CPU-bound (limited to the power of your main processor) to begin with as it does more calculations on the CPU instead of on the 9800 Pro itself.

Going from SDL ALSA Native to OpenAL ALSA Native shows a slight hit in performance, although not nearly as bad as the previous transition. OpenAL is done in software on Linux, and this is the result of the positional calculations being done in CPU time.

At last, we can see in the OpenAL 5.1 Surround benchmark that the engine becomes entirely CPU-bound. This is unfortunate, for a couple of reasons:
1) The computer these tests were run on is not at all 'slow'. Requiring absurd amounts of CPU just for audio routing and positional processing is daft at best.
2) This was not always the case. Using the emu10k1 OSS drivers developed by Rui Sousa (still available on SourceForge), you can achieve very similar results (albeit 4-channel surround) with hardware surround decoding of both WAV and MP3.

Conclusion:
---------
With the myriad of options available to Linux users, there are ways to customize the gaming experience to become a very personal one. Hopefully in the future, performance of multichannel audio routing and positional adjustments using ALSA can be improved.


Please leave any comments or questions. I will try to answer them when I have the time. Thanks and I hope you enjoyed the banchmarks!

[Michael]

Good work, edged!

[Melcar]

Ouch. Kinda defeats the purpose of having a dedicated sound card, thought last I heard the SBLive! line was rather CPU hungry (but that's in Windows).

[edged]

Thanks, Michael

Ouch. Kinda defeats the purpose of having a dedicated sound card, thought last I heard the SBLive! line was rather CPU hungry (but that's in Windows).

The SBLive is one of the few audio cards that officially supports HWMIX in ALSA. Basically that means it can open and mix different audio streams simultaneously in hardware, and that is officially supported by ALSA.

I think most of the concerns about the SBLive were due to it not being "bit-correct" in it's audio reproduction, but what you are referring to is what I believe some people tend to call the "Creative Labs Windows Driver Phenomenon"

[Thetargos]

The Live! was "CPU intensive" with EAX, i.e, the card didn't actually do much EAX accel (it DOES have the DSP for it, but AFAIK the Live! drivers don't fully expose the chip or some such)

Edit

By the way, there was supposed to be a special version of OpenAL that actually supported hardware OpenAL acceleration on EMU10K1 hardware (Live!, Audigy, Audigy2 [ZS]; NO Audigy Value, Audigy LS, Live 24-bit). This "special" OpenAL was designed to be used with UT2004, I still have the source tree, but I have lost the URL for the download site.

From the README file:

The error:

ALSA lib pcm_hw.c:324: (snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS failed: Cannot allocate memory

can be safely ignored in most cases. It is just the application trying to
allocate more sources than there are free hardware resources to accomodate.

This library can provide at most 21 sources. It may be more in the future.
Less sources will the avaiable if another application is doing audio playback.

If you are using UT2004 you can supress this message most of the time by
modifying your ~/.ut2004/System/UT2004.ini as follows:

[ALAudio.ALAudioSubsystem]
Channels=20



If on a Soundblaster Live, in your ~/.openal-speakers you have volumes set
for any more than the first two speakers you should manually zero the
following mixer controls:

Wave Surround Playback Volume
Wave Center Playback Volume
Wave LFE Playback Volume

You may not need to do this on an Audigy or Audigy2 but I've not been able to
test that.

[edged]

By the way, there was supposed to be a special version of OpenAL that actually supported hardware OpenAL acceleration on EMU10K1 hardware (Live!, Audigy, Audigy2 [ZS]; NO Audigy Value, Audigy LS, Live 24-bit). This "special" OpenAL was designed to be used with UT2004, I still have the source tree, but I have lost the URL for the download site.

That's correct. That would be Christopher John Purnell's version of OpenAL which is based on Creative's drivers for the emu10k1 for Windows, and it requires ALSA.

As you can see from the readme file, it only supports 20 channels. While his version does support pushing the streams through in hardware, it won't support any of the "whiz-bang" effects such as reverb or flange etc. in games such as UT2004 (neither does the software implementation) - i.e. running through a tube and hearing your gun echo or other player's screams echo and other environmental effects will be missing, just FYI.

I believe Purnell explains it in more detail on his website, or atleast in the documentation, why exactly there is a limitation to 20 channels. To be blunt it is due to the actual design limitations of ALSA itself (the way it couples channels and interprets 'stereo groupings', as well as ALSA even reserving channels).

The channel ceiling in the implementation is a rather serious limitation, which either not enough people care about (or should I say the right people care about) or just too lazy to fix. It is one of those cases where you won't actually see it in certain situations such as most 'regular' desktop applications, however unfortunately it does exist.

For example, Quake 3 Arena in "single player" mode (not networked) uses at most approximately 90 channels simultaneously - that would be using OpenAL with the ioquake3 port. Keep in mind that this does not even account for the most popular way of playing the game (which is online), where far more players can play each other simultaneously; nor does this take into account the mission pack: "Quake 3 Team Arena". In the mission pack a single chaingun firing can easily eclipse the in-hardware emu10k1 implementation by Purnell.

Also so anyone reading this realizes this, that when a game or application tries to use more channels than what the implementation supports those channels (sounds) are not heard at all.

BTW there was actually another version of OpenAL based on Purnell's version, but supporting any ALSA supported sound card that was capable of HWMIX. It didn't work for me on the SBLive!, and I no longer have the link to it. It seems to have vanished, but FWIW it was developed and tested only on one audio chip IIRC.

As you can see it's a rather lengthy discussion that I didn't want to go into in the benchmark article - it's really out of the scope of the document. It would be possible to have an article in itself discussing such things

[Thetargos]

Indeed... I was aware of the limitations of the OpenAL implementation by Purnell, and the design of the ALSA drivers. However I do believe that there had been since the he published this, modifications to ALSA's emu10k1 driver and other important ALSA intrinsic workings. I couldn't say if these changes address this, though. Theoretically (as reported by ALSA) the emu10k1/2-based cards support up to 32 hardware streams in the main DSP while supporting up to 8 in the secondary. At any rate, as you said this is not for the benchmark article to discuss this in. You, however seem to have more first-hand information (or experience) than I do, and most certainly a good in-depth ALSA article would be an excellent article and an interesting read.