mirh wrote:
jonpol wrote:but I think what you are saying is that I should use OpenAL? If you're curious I'm willing to give more reasons why I didn't (and why I don't regret that decision), but I can't guarantee that you will find any of those reasons convincing 😊
Yeah more or less
Ok, well, I already discussed some reasons on the first page of this thread here and here, and so I maybe won't go into too much depth repeating those. Some of my other reasons and biases wander into similar territory of the lively and off-topic exchange that was moved from this thread into its own separate thread, and it doesn't make too much sense to have a repeat of that situation either; I guess I'll share some of my thoughts and opinions (and answer followup questions if anyone is interested), but otherwise I'm going to try and resist any further defending or attempts at convincing or changing anyone else's opinions.
One of the main reasons for me to use XAudio2 over OpenAL is that I would rather work with XAudio2 than OpenAL. I realize that it can be hard as a user of a product to care about what the creator of a product wants, and maybe it seems selfish of me to prioritize working with an enjoyable API. If I were being paid to create something my boss might be sympathetic to my preferences, but in the end s/he would really only care about what would get something working reasonably well in a reasonable amount of time. In the case of IndirectSound, however, I'm my own boss: It's something that I work on in my free time, I spend money on the website, I spend money buying games that I never intend to play to try and fix bugs that users report, and part of the motivation for me is being able to write software the way that I would like without having to make the kinds of compromises that one does in an actual programming job. That's not to say that I don't care about users or what they want... I really do! It just means that if I have a preference for one API over another then that is reason enough (from my perspective) for me to choose that API.
By the same token, I can understand why you are frustrated that I may be duplicating work that others have done. I would be too if I were you! But, for me, I guess it's just not quite as negative because my priorities may be a bit different. If I think that there's a better way to do something and that motivates me then I don't mind doing it.
Ok, on to more technical reasons. In order to try and discuss this I have to reveal a bit about myself, and I hope it doesn't come across as sounding smug or superior or anything like that. One of the things I've noticed is that it's not unusual for programmers who have been in the games industry (and especially engine programmers) to have a number of beliefs and opinions that go against conventional wisdom. For better or for worse, I tend to think like a low-level engine programmer about a lot of things, and it's funny how often standard programming advice goes directly against what I consider to be "best practice" based on my own experience.
On the internet there tends to be an overwhelming disdain for anything "proprietary" (and an almost reverential respect for anything with "open" in the name or that is "standard"). I used to feel this way about everything, and I still do about many things, but there are some cases where I have changed my opinion.
In general if there is a native API for a given platform then it will be as efficient or more efficient to use that native API than it is to use some standard or open API. Said the other way around, if there is a standard or open API then, in general, the best case scenario for a given function is that it is as efficient as a native function, but it can be expected that the open/standard function will often be less efficient. There are two reasons for this: 1) The open/standard API will be implemented using the native API and 2) The open/standard API will be designed to work with different platforms, and so the "correct" way to do something in an open/standard way might not be the best way to do it for a specific platform.
When I am working on something game engine-y I will almost always implement things using the native API (with my own platform-independent interface when working cross platform) rather than using an open/standard function.
(Sidenote: I occasionally teach a class, and one of the things that I make my students do is to implement a renderer in both OpenGL and Direct3D. When I am working on the assignments and my reference implementation I always do Direct3D first, and then begrudgingly follow with OpenGL. I don't think that Direct3D is particularly well-designed, but the things that it lets you do map reasonably well to what I actually want to do compared to OpenGL, where I feel like the API doesn't accurately reflect what is actually going on. The students almost invariably start with OpenGL first, though, of course 😊)
The way that OpenAL works does not represent how audio in Windows works. WASAPI would be best in this sense, but XAudio2's API does a better job of mapping to what it is that I actually want to do. I have framed the argument in terms of "efficiency" above, but that may not be the best way to describe what I'm trying to say. Let me give an example about the "updates" that I mentioned in a previous post. Unfortunately, since I don't remember details this example is necessarily going to be hand-wavy, and I won't be able to back up anything I say unless I get motivated enough to dive back into OpenAL 😀, but here goes: When configuring ALchemy there are settings for "Buffers" and "Duration". When I was looking into using OpenAL to emulate DirectSound and trying to figure out how it would work I realized that I would basically need the same thing (I would need some number of internal buffers and decide how long to make them, and that decision would have different consequences for different games depending on how they were programmed). With XAudio2, though, I didn't need that: I could use the API to do what I wanted rather than having to find workarounds. I don't know if anyone even notices (no one has ever said anything to me about the fact that IndirectSound doesn't have analogous settings), but I personally am really happy that users don't have to worry about it.
As I have added more and more subtle improvements to IndirectSound to try and emulate DirectSound and my SoundBlaster X-Fi in Windows XP even more faithfully I have had to change more and more low level things (in fact, with the next release of IndirectSound I will have replaced almost all of the 3D algorithms that XAudio2 provides with my own custom implementations), and in many of those cases I don't think that OpenAL would have allowed me to make the same changes.
This doesn't mean that XAudio2 is perfect, of course. In recent versions of IndirectSound I have had to add a new user-configurable setting dealing with the maximum frequency ratio that a voice can have, and this, just like ALchemy's Buffers and Duration, is something that deals with an internal implementation detail and is something that users shouldn't have to worry about. I hated having to put that in, and feel lame when users ask when it will be "fixed" and I have to admit that it's by design. Additionally, one of the major roadblocks I have run into with emulating EAX is because of some performance issues I have encountered with XAudio2. Both of these cases, however, have not made me think "I wish I had used OpenAL". Instead, they have made me think "I should probably switch to WASAPI so that I can have as much low-level control as possible."
Ok, I guess the final thing to discuss is the actual merits of proprietary vs. open. Although I think that XAudio2's API is actually really well-designed fundamentally, from what I can tell it is was basically abandoned by Microsoft pretty early in its life. Even though I know there have been some minor changes made with recent versions of Windows, the version that I use as part of DirectX hasn't been updated since June 2010. It's possible (likely?) that Microsoft will make a change in a future version of Windows that will break old XAudio2, in which case IndirectSound will also stop working until/unless it is updated to the Next New Thing. A convincing argument could be made that, had I used OpenAL instead, IndirectSound would keep working as long as someone kept updating OpenAL.
I think this point is a good one, and I'm not going to try and argue against it. With that being said, I guess that I don't necessarily believe that OpenAL is "the future" either. From what I can tell it's not really used by most modern games, Creative has made it proprietary, and so its future existence kind of depends on people trying to keep a legacy API working with modern Windows changes.
WOW LONG POST! 😲
Again, it's fine if you don't find anything that I've said convincing, but hopefully it has at least given you a bit more insight into why I chose XAudio2 instead of OpenAL, even if you don't agree.