VOGONS

Common searches


indirect sound

Topic actions

Reply 60 of 228, by UCyborg

User metadata
Rank Member
Rank
Member

Oh, this thread? I've learned about Sens_oal.dll -> ct_oal.dll rename trick there. Funny thing about ct_oal.dll, the path to it is composed on the stack using a bunch of assembly MOV instructions, so searching for ct_oal.dll string in ALchemy's dsound.dll won't reveal its place. There's also a fallback to load OpenAL32.dll (aka. the OpenAL router DLL, which also has the preference to expose ct_oal.dll implementation as the main one) if that string wasn't available, but that condition never happens I think. Yes, I know any *oal.dll can be renamed to OpenAL32.dll to act as a single OpenAL implementation.

lowenz wrote:

Why use a separate piece of software like ALchemy if it already supports EAX? 😐 (a question for Creative devs and whoever knows the answer)

ALchemy converts DirectSound calls to OpenAL as stock DirectSound on Vista+ lacks certain features, so what you're trying to ask is why there are two separate OpenAL implementations to convert DirectSound calls to. 😉 I wonder this myself.

One interesting thing to note, there's probably a bunch of integrated sound cards out there that work with Windows XP, but because they're not Creative's, you don't get any special features from DirectSound on that OS neither.

@CoolGamer

ALchemy can work on its own, though if it can use ct_oal.dll, that resolves sound glitches in certain games. There must be some other issue. Your sound card also shouldn't have any negative impact. Are you positive that dsound.dll that ended up in game folders is patched? If it is, its modification date should be very recent.

@Davros

It seems to be meant as a bonus in conjunction with another Creative product.

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 61 of 228, by CoolGamer

User metadata
Rank Member
Rank
Member

UCyborg,

I found out what the issue was. My firewall was blocking the game exes. When I lifted the firewall restrictions, Alchemy started to work. When I add the game exes back to the firewall restrictions, Alchemy stops working again. I was very surprised to see that firewall was the issue.

Reply 63 of 228, by jonpol

User metadata
Rank Newbie
Rank
Newbie
UCyborg wrote:

I've noticed that in Drakan: Order of The Flame, sounds are funked up, like playing bad tape. Have to hear it yourself, when you start the game, hold Shift and make sure 3D sound buffers are enabled on Sound tab.

Unfortunately I don't have that game and from what I can tell it's not available to buy digitally. Have you checked the dsound.log file to see if any errors are reported?

UCyborg wrote:

When using Windows 10 with some games the dsound.dll DLL is ignored even when it is located in the correct place and works with the same game using earlier versions of Windows.

Check for references to dsound.dll in registry under HKEY_CLASSES_ROOT\CLSID and HKEY_CLASSES_ROOT\Wow6432Node\CLSID You should find a bunch of keys containing "%SystemRoot%\System32\dsound.dll". These used to be "dsound.dll", allowing dsound.dll to be picked from game folder if game uses COM to initialize DirectSound. One way to modify those entries is launching regedit as TrustedInstaller. Process Hacker with TrustedInstaller plugin can do it.

Thank you, this is very helpful!

Reply 64 of 228, by UCyborg

User metadata
Rank Member
Rank
Member
jonpol wrote:

Unfortunately I don't have that game and from what I can tell it's not available to buy digitally. Have you checked the dsound.log file to see if any errors are reported?

Right, it tells me to set maxFrequencyRatio to something really high like 17121.2. The number is different every time. Here's the demo version for you to play with. I've packed it with the latest IndirectSound and dgVoodoo2, the demo is the buggiest so it won't work without dgVoodoo. You can also try WineD3D instead of dgVoodoo. Should be good enough to determine the cause of sound problems.

jonpol wrote:

Thank you, this is very helpful!

Cool, MS actually started using absolute paths in that area in Windows 8. BTW, can IndirectSound work on Windows XP? I tried it on VMware virtual machine where it outputs:

The requested audio device {BD6DD71A-3DEB-11D1-B171-00C04FC20001} was not found!

I'm curious because without specific sound card, you get as much features via DirectSound on XP as on Vista+. At one point, I found a bit unstable driver for VMware's sound card (ES1371 chip) that exposes hardware accelerated 3D sound buffers and basic EAX (probably just 1.0). Random sound cards from VIA for example are still stuck with bare basics.

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 65 of 228, by jonpol

User metadata
Rank Newbie
Rank
Newbie
UCyborg wrote:

Right, it tells me to set maxFrequencyRatio to something really high like 17121.2. The number is different every time. Here's the demo version for you to play with. I've packed it with the latest IndirectSound and dgVoodoo2, the demo is the buggiest so it won't work without dgVoodoo. You can also try WineD3D instead of dgVoodoo. Should be good enough to determine the cause of sound problems.

Ok, great, I will try to figure out what's happening when I get some time.

UCyborg wrote:

Cool, MS actually started using absolute paths in that area in Windows 8.

Oh, yeah, I skipped form Windows 7 to 10 haha. Now that I see what's happening it makes total sense, but I don't think I ever would have thought of it... Was this change common knowledge when Windows 8 came out, and I just missed the memo? Anyway, it's really nice to know how to fix it (and I've confirmed that one of the games in question now does work with IndirectSound again for me in Windows 10), so thanks again! I will update the IndirectSound webpage with instructions when I have a moment.

UCyborg wrote:

BTW, can IndirectSound work on Windows XP? I tried it on VMware virtual machine where it outputs:

The requested audio device {BD6DD71A-3DEB-11D1-B171-00C04FC20001} was not found!

I'm curious because without specific sound card, you get as much features via DirectSound on XP as on Vista+. At one point, I found a bit unstable driver for VMware's sound card (ES1371 chip) that exposes hardware accelerated 3D sound buffers and basic EAX (probably just 1.0). Random sound cards from VIA for example are still stuck with bare basics.

It doesn't work on XP, but it's been so many years since I've looked into it that I've forgotten most of what I knew. I think it had something to do with the way I am loading libraries, but I didn't spend time fixing it since I figured anyone using XP could just use a real SoundBlaster. My guess is that it probably could work (again, going off memory here), but I've been debating changing some of the way IndirectSound works internally to use WASAPI instead of XAudio2 and maybe moving to a newer version of Visual Studio, after which XP would no longer be an option.

Reply 66 of 228, by UCyborg

User metadata
Rank Member
Rank
Member
jonpol wrote:

Oh, yeah, I skipped form Windows 7 to 10 haha. Now that I see what's happening it makes total sense, but I don't think I ever would have thought of it... Was this change common knowledge when Windows 8 came out, and I just missed the memo?

I don't know, I only noticed it when I copied my Max Payne installation along with ALchemy's dsound.dll over to another computer and the game was silent for some reason. I figured I never ran ALchemy application on that PC and when I did it, the sound magically returned. At that point I started searching registry for dsound.dll and realized Alchemy doesn't just copy over dsound.dll to particular game's folder, but also alters those registry entries.

jonpol wrote:

It doesn't work on XP, but it's been so many years since I've looked into it that I've forgotten most of what I knew. I think it had something to do with the way I am loading libraries, but I didn't spend time fixing it since I figured anyone using XP could just use a real SoundBlaster.

I see, interesting to know you can use XAudio2 in a way that breaks on XP. I occasionally mess with old Windows versions and thought that was strange since XAudio2 is officially supported on XP, at least the older version.

Back in September, GOG released The Suffering and The Suffering: Ties That Bind. These games use updated Riot Engine, like Drakan. They included older IndirectSound 0.12, which made game crash frequently (fault module dsound.dll). Version 0.13 is OK. With stock DirectSound, many sounds don't play or dropout. Despite the game having EAX checkbox in its sound options, logs don't indicate that it ever queries for EAX support. Still, subtle reverb effect is applied over its audio, which can be heard with ALchemy. It's present in PS2 and Xbox versions of the game as well, but not heard with IndirectSound. 3D positioning is OK. Anyway, whenever you find the time and will, I'm curious what you'll find.

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 67 of 228, by jonpol

User metadata
Rank Newbie
Rank
Newbie
UCyborg wrote:
jonpol wrote:

Oh, yeah, I skipped form Windows 7 to 10 haha. Now that I see what's happening it makes total sense, but I don't think I ever would have thought of it... Was this change common knowledge when Windows 8 came out, and I just missed the memo?

I don't know, I only noticed it when I copied my Max Payne installation along with ALchemy's dsound.dll over to another computer and the game was silent for some reason. I figured I never ran ALchemy application on that PC and when I did it, the sound magically returned. At that point I started searching registry for dsound.dll and realized Alchemy doesn't just copy over dsound.dll to particular game's folder, but also alters those registry entries.

I've written up some instructions here. Thanks again for letting me know what was going on!

Reply 69 of 228, by jonpol

User metadata
Rank Newbie
Rank
Newbie
lowenz wrote:

Yes, this fixes the issues with Drakan that UCyborg discovered. Drakan enables Doppler shifting and also changes the world units from the default. I was making a rookie mistake of multiplying instead of dividing when adjusting the speed of sound by these non-default world units (which was never a problem when the default of 1 was used). Embarrassing, but I think all is well now 😊

Reply 70 of 228, by mirh

User metadata
Rank Member
Rank
Member

Last time I had checked, XAudio2 on XP was itself implemented over directsound.. So that'd be quite ironic, if not bad.

Anyway, the point of my post was asking what the actual best® way to do this would be.
John already told me about his idea of re-basing over WASAPI (which is also coincidentally what wine had originally chosen).
Makes sense if you consider that's also what Vista+ has been doing.
And I had also suggested to take into consideration this "just-do-on-your-own-everything-in-that-single-dll" 'image' dxwrapper gave to me.
...
But after countless of hours spent scraping discussions of wine devs I realized something.
For starters, that there is even another 'low level' pathway that you could use: MMDevAPI*.
Which is what they eventually switched to (for some particular reason that could be MIDI support or OSX sucking hard, I dunno) and is then responsible for talking with OS native apis and happily ever after.
Not sure of the differences between that and wasapi though.

But the real deal was noticing how behind a good portion of their last improvements.. there was OpenAL.
Mind me, not directly (albeit they based XAudio2 over it, 🤣) just a shallow copypasta of some line - but still.
Why that?
Because code reusing is good.
And code duplication is bad.
And effort duplication is even worse.
Not to mention more hands (and eyes) are better.

Now, f*ck EAX, XP, hardware acceleration (whatever it even means in 2017)**, and I will not even claim that any api is inherently better than any other one (including the hypothetical 'none' case with everything coded internally to software directsound)
It simply is an adversity that you had to spend half a decade retracing routes other people had already started exploring.

Guess who basically was already there 10 years ago?
This is ultimately my point.

I read you had problems in the past (not sure which kind of "updates" you were talking about tho) but I would be incredibly surprised if Chris wasn't 100% available to help you.
I mean, especially considering how few akin "insiders" usually steps by him (and/or helped adding 98% of the codebase)

Regards

*trivia: this is also the Windows backend openal-soft uses, alongside the directsound fallback
**they wouldn't hurt either of course

pcgamingwiki.com

Reply 71 of 228, by jonpol

User metadata
Rank Newbie
Rank
Newbie

Hi mirh,

mirh wrote:
Last time I had checked, XAudio2 on XP was itself implemented over directsound.. So that'd be quite ironic, if not bad. […]
Show full quote

Last time I had checked, XAudio2 on XP was itself implemented over directsound.. So that'd be quite ironic, if not bad.

Anyway, the point of my post was asking what the actual best® way to do this would be.
John already told me about his idea of re-basing over WASAPI (which is also coincidentally what wine had originally chosen).
Makes sense if you consider that's also what Vista+ has been doing.
And I had also suggested to take into consideration this "just-do-on-your-own-everything-in-that-single-dll" 'image' dxwrapper gave to me.
...
But after countless of hours spent scraping discussions of wine devs I realized something.
For starters, that there is even another 'low level' pathway that you could use: MMDevAPI*.
Which is what they eventually switched to (for some particular reason that could be MIDI support or OSX sucking hard, I dunno) and is then responsible for talking with OS native apis and happily ever after.
Not sure of the differences between that and wasapi though.

XAudio2 is not implemented over DirectSound. They are both implemented using WASAPI.

WASAPI and MMDevAPI are kind of sibling APIs: They are both low level, and they are both used together.

mirh wrote:
But the real deal was noticing how behind a good portion of their last improvements.. there was OpenAL. Mind me, not directly (a […]
Show full quote

But the real deal was noticing how behind a good portion of their last improvements.. there was OpenAL.
Mind me, not directly (albeit they based XAudio2 over it, 🤣) just a shallow copypasta of some line - but still.
Why that?
Because code reusing is good.
And code duplication is bad.
And effort duplication is even worse.
Not to mention more hands (and eyes) are better.

Now, f*ck EAX, XP, hardware acceleration (whatever it even means in 2017)**, and I will not even claim that any api is inherently better than any other one (including the hypothetical 'none' case with everything coded internally to software directsound)
It simply is an adversity that you had to spend half a decade retracing routes other people had already started exploring.

Guess who basically was already there 10 years ago?
This is ultimately my point.

I read you had problems in the past (not sure which kind of "updates" you were talking about tho) but I would be incredibly surprised if Chris wasn't 100% available to help you.
I mean, especially considering how few akin "insiders" usually steps by him (and/or helped adding 98% of the codebase)

I'm not sure if you want a response or if you are just expressing frustration, 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 😊

Reply 73 of 228, by mirh

User metadata
Rank Member
Rank
Member
jonpol wrote:

XAudio2 is not implemented over DirectSound. They are both implemented using WASAPI.

I was saying in wine. Seemed curious.

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

pcgamingwiki.com

Reply 74 of 228, by jonpol

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 75 of 228, by UCyborg

User metadata
Rank Member
Rank
Member

Is there a reason why the end user should care which API is used under the hood? The point of OpenAL is just being an abstraction layer for developers so one doesn't have to write different code for different operating systems, but instead have OpenAL implementation call into the OS specific APIs. Seems to me some people do not understand that OpenAL by itself is not the magic that makes games sound good. Creative's own simple explanations make it seem so to get you to buy their stuff.

As has been pointed out long time ago, the first problem is some games not being happy with software 3D sound buffers for positional audio on Vista+ and the second is dependency on the library of special effects, which happen to be proprietary and ALchemy just enables accessing them in a different way. Surely being able to use an alternative (open) library would be a nice option and OpenAL Soft happens to have it.

I'm trying to say that such a library is not an inherent part of OpenAL, the only thing that's guaranteed to be 'open' is convention on how an application talks to the sound library to play audio and how extensions are implemented, extensions which one OpenAL implementation may have, but not another.

Just recently, someone asked about Unreal Tournament 2004. The question was deleted, but he quoted something from here:

Some OpenAL-based games seem have a DirectSound dependency (UT2004, Postal 2) that makes it seem like the game's OpenAL software isn't properly communicating with your audio drivers. UT2004 and Postal 2 seem to respond to DS3D restoration software; I get EAX effects in UT2004 and surround sound restored in Postal 2. Doesn't make much sense to me since an OpenAL game shouldn't need DirectSound, I just try various things and go with what works

Well, by plain OpenAL installation (running oalinst.exe), you're guaranteed to get the router DLL (OpenAL32.dll) and wrap_oal.dll. Guess what wrap_oal.dll is? It takes game's OpenAL calls and forwards them to DirectSound. UT2004 comes with DefOpenAL32.dll, which is used when System Driver option is checked; DefOpenAL32.dll is just an old wrap_oal.dll. So it makes perfect sense that with such configuration ALchemy makes a difference since it pretends to be DirectSound with all features.

One can also set the original DOOM 3 to use wrap_oal.dll in which case ALchemy gives EAX. There's also DirectSound codepath which only features surround sound when you set speaker configuration to 5.1 in Windows, any other setting (including 7.1) makes it fall-back to stereo. Source engine based games can also use DirectSound on Vista+ to produce multi-channel audio without requiring any workarounds.

Something nice about Creative's software OpenAL implementation, it gives a surround effect using the plain stereo headphones without any special configuration. OpenAL Soft has this feature too, you have to enable HRTF explicitly and there are some HRTF files to put in place, to give one the option to use different HRTF profiles I think.

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 76 of 228, by Chris2

User metadata
Rank Newbie
Rank
Newbie
UCyborg wrote:

Is there a reason why the end user should care which API is used under the hood?

Because it could influence the available featureset and quality. With OpenAL Soft, for instance, it can detect a device being configured as headphones and automatically enable HRTF for full 3D sound positioning without the application or user having to do anything. There's also global configuration options, so a user can tell OpenAL Soft to use a high quality 24- to 48-point anti-aliased resampler, 2-channel UHJ output (a stereo compatible mix that can be fed to a surround sound receiver), a specific HRTF profile, etc. Anything that utilizes OpenAL Soft then implicitly inherits these settings, and just about anything that uses OpenAL can use OpenAL Soft.

OpenAL is also still actively updated, both with newer features and improved compatibility with modern systems. So an app that was made 15 years ago that used OpenAL can take advantage of what the newest OpenAL releases offer. Whereas an app that utilized DirectSound3D... well, we see what they're like now. So for sure, there are reasons why a user should care what API is used under the hood.

The point of OpenAL is just being an abstraction layer for developers so one doesn't have to write different code for different operating systems, but instead have OpenAL implementation call into the OS specific APIs.

An abstraction layer implies that the heavy lifting is given to the underlying system. Like SDL, which provides access to preexisting OS components using a common system-agnostic API, but it's still the OS doing most of the work. That's not quite how OpenAL works. The core features of OpenAL are not dependent on the underlying OS's 3D sound capabilities. That is, OpenAL isn't made to simply forwards calls to DirectSound or XAudio2 on Windows, where those things do all the real work. It is of course possible for an implementation to utilize a preexisting OS component to do the work, but that's not the point of the API.

In regards to OpenAL Soft, its output goes to the lowest level of the Windows audio stack, MMDeviceAPI/WASAPI, just like XAudio2. Indeed, they could be more considered siblings, both sitting at the same level on the system. There's no extra level of abstraction there.

Well, by plain OpenAL installation (running oalinst.exe), you're guaranteed to get the router DLL (OpenAL32.dll) and wrap_oal.dll. Guess what wrap_oal.dll is? It takes game's OpenAL calls and forwards them to DirectSound.

Yes and no. wrap_oal.dll is actually two different drivers in one. On the one hand, it provides a Generic Hardware driver. With this, it believes DirectSound3D is hardware accelerated with necessary features and will forward calls to it as a way to get hardware acceleration (for when a proper OpenAL hardware driver isn't available). On the other hand, it also provides a Generic Software driver. With this, it does all the processing/mixing in software and simply uses DirectSound to play the resulting stream. These were of course made when DirectSound was the lowest layer available on the Windows audio stack, and there was a decent chance for acceleration, so using DirectSound for output was as low level as anyone could realistically get at the time.

UT2004 comes with DefOpenAL32.dll, which is used when System Driver option is checked; DefOpenAL32.dll is just an old wrap_oal.dll. So it makes perfect sense that with such configuration ALchemy makes a difference since it pretends to be DirectSound with all features.

DefOpenAL32.dll is provided as a fallback, which is used if another OpenAL driver isn't installed and selected. ALchemy can work that way (DefOpenAL32.dll -> ALchemy/dsound.dll -> ct_oal.dll), though if the game uses OpenAL it should also be able to utilize the hardware ct_oal.dll driver.

OpenAL Soft has this feature too, you have to enable HRTF explicitly and there are some HRTF files to put in place, to give one the option to use different HRTF profiles I think.

The latest release of OpenAL Soft (1.18.2) has the HRTF files built-in for 44.1khz and 48khz output, so no extra files are needed for it. If Windows reports the device's formfactor as Headphones or Headset, it'll also automatically enable HRTF. If for some reason it doesn't, then (like mentioned above) you can globally configure OpenAL Soft to use it anyway.

Reply 78 of 228, by lowenz

User metadata
Rank Oldbie
Rank
Oldbie
Chris2 wrote:

DefOpenAL32.dll is provided as a fallback, which is used if another OpenAL driver isn't installed and selected. ALchemy can work that way (DefOpenAL32.dll -> ALchemy/dsound.dll -> ct_oal.dll), though if the game uses OpenAL it should also be able to utilize the hardware ct_oal.dll driver.

And if ct_oal.dll has some problems (having a Creative soundcard you got it installed) you must trick the game in using OpenAL Soft renaming soft_oal.dll to "ct_oal.dll" and NOT "wrap_oal.dll" :p
It's hardwired in OpenAL32.dll router......damn Creative.

Reply 79 of 228, by UCyborg

User metadata
Rank Member
Rank
Member

All good points, Chris2, you're right, OpenAL can do a lot. I kinda ignored the fact that a lot can be done before the final result is send to the sound card. But it does depend on the particular implementation (eg. OpenAL Soft), correct? OpenAL does have the history back from the days of the Loki Software, the guys who specialized in porting Windows games to Linux. Been a while since I updated my OpenAL Soft, back then you had to put some files in place for HRTF. Out-of-the box optimal positional sound on headphones is a great thing to have.

Couldn't also be said that the state of DirectSound today is like that because of the unfortunate historical reasons? The redesign of the whole audio architecture and how everything was relying on special hardware back then? Only time will tell what the new Microsoft will cook up in the future, but generally, backwards compatibility is supposed to be serious thing on Windows, although there are reasons for it not being optimal in the sound and graphics department.

I wonder though, why did they decide to remove DirectPlay from default Windows install? For some reason, some games are using its presence to check if DirectX 8 or newer is available (Mafia, The Suffering series, GTA III, GTA: VC, ...) even if the game binary is linked to d3d8.dll and would fail to load otherwise. Is there a historical reason for this as well? And there's removal of Direct3D Retained Mode runtime (d3drm.dll) since Vista.

I was told Raymond Chen has a lot of blog posts about how developers tend to mess up when using Windows APIs, but I'm guessing those are mostly related to non-gaming applications.

DOOM 3 indeed outputs that it found "Generic Hardware" when you combine it with ALchemy on a modern system with wrap_oal.dll. Yes, I understand DefOpenAL32.dll is provided so the things work when no OpenAL is installed on the system and this particular flavor of it guarantees that it will always at least provide basic audio playback.

Either way, we still have a problem of converting old games' DirectSound calls. FWIW, IndirectSound happens to work on my small library of games and does what it promises without having to mess with its settings. I doubt anyone misses Buffers, Duration and DisableNativeAL settings from ALchemy. If one day, IndirectSound can work universally without that frequency setting and implements EAX, then it's a victory!

So far, we haven't seen full-blown DirectSound -> OpenAL Soft wrapper. I remember the wrapper from dsoal.zip, but it's also incomplete.

lowenz wrote:

And if ct_oal.dll has some problems (having a Creative soundcard you got it installed) you must trick the game in using OpenAL Soft renaming soft_oal.dll to "ct_oal.dll" and NOT "wrap_oal.dll" :p
It's hardwired in OpenAL32.dll router......damn Creative.

Yes, the router loves to put ct_oal.dll in the primary spot, and if you don't have Creative card, but happen to have software pack like Sound Blaster X-Fi MB 3, you have to rename Sens_oal.dll to ct_oal.dll to get ALchemy to use it. And for other games, you have to put DisableNativeAL=false in dsound.ini so it behaves as if ct_oal.dll does not exist. Because some game will be buggy with either real ct_oal.dll/ct_oal.dll renamed from Sens_oal.dll but not with whatever is in ALchemy's dsound.dll and vice-versa.

When it comes to OpenAL games, ideally, they would all let you choose which device (OpenAL driver) to use, but that's too much work! 😁 The router DLL also has reference to adi_oal.dll. Anyone knows what this one is?

Last edited by UCyborg on 2018-01-18, 00:58. Edited 2 times in total.
Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.