Tweet
Originally posted by darkphoenix22
View Post
-
I would imagine he'll end up reading this thread and will respond when he does. -
Well this thread is about it and I didn't create it so I don't know what to tell you about that. You might be lost since you're discussing something that you don't think will arrive.Originally posted by pingufunkybeat View Post
Did I say that? No I didn't. The discussion of OSS4 vs ALSA and the problems of PA was a discussion started long before I came a long I added my point of view and that was that.Originally posted by pingufunkybeat View PostComment
-
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.Comment
-
Impartial 3rd party take on Linux audio:From: http://www.hemispheregames.com/2010/...ortem-part-23/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.
Good article, lots of good criticisms, sadly it will be ignored or dismissed rather than fixing the underlying issues.Comment
-
The other parts of that article are also well worth the read.
I should purchase Osmos these days, but I'm not even playing the Humble Bundle stuff I purchased not so long ago.....Comment
-
Matches 100% my own experience. This article is really good.Originally posted by yogi_berra View PostComment
-
The old song. Instead of solving problems with better design moan about them and push the blame on others.Originally posted by yogi_berra View PostComment
-
Having everything in a magical one-size-fits-all solution is not good design. Hell it's not Unix.Comment
-
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.Comment
-
Again, it doesn't separate out functions like the per-app volume controls, the software mixing, and the device switching.
Each of these functions would be better handled as separate entities, rather than in one whole.Comment
Comment