If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
The only time Pulse has given me problems is when running certain games on Wine.. Unreal Tournament 3 immediately comes to mind.. Running OpenSuse 11.2 and Creative audio hardware works very well overall.
The audio situation is another major obstacle to game development on Linux. It’s 2010; audio is a solved problem. And yet on Linux, it’s shocking that you cannot count on something as simple as non-streaming playback, never mind any kind of processing (which most games are wont to do!) There are a variety of standards (ALSA, OSS, PulseAudio, Phonon, …) — which one to choose? Each standard has different problems on different machines. For a given standard, some drivers are buggy and poorly configured by default, while others do horrible thinks like block on open when another process opened the device. This is all another way of saying that there are no audio standards. What is a developer to do?
“But doesn’t OpenAL hide all the mess behind a single stable API? Ideally you’d write the audio code once in OpenAL and then walk away.” This isn’t how it happens in practice, because the fact of the matter is that the mess is still there. Simply wrapping another software layer around the underlying problem doesn’t make it go away. Using OpenAL for audio doesn’t all-of-a-sudden mean I can count on anything runtime-behavior-wise. I write my code in OpenAL (rather than having to write directly in ALSA, PulseAudio, etc), but at runtime I still need to make choices — for example, by saying which underlying audio layer I want to use — and different people’s machine/lib/driver combos will do different things. Simply using the local machine’s default audio device doesn’t guarantee anything about what’s going to work and what doesn’t, and a game needs guarantees in order to work correctly. The audio situation is quite horrible I’m afraid.
It's not a one-size-fits-all solution. It's actually very Unix like in that the code dealing with card switching is placed at the exact right location. This kind of code is wrong in drivers (code-duplication smells, each driver has to implement it) as well as in applications (code-duplication smells, each app has to implement it). The non-Unix solution would be to scatter this code all over the place instead of tasking a single unit with handling this transparently in both directions.
Have you even an idea about software design? Looks like not.