unic0rn wrote:

sure it's based on the same old wine code, but there's no openal support in that github tree, so it's useless. the whole point of that wrapper is to translate eax2 into openal effects. also, that wrapper was written by openal-soft author.

if you can't spot the difference, well. good luck with building it.

I cant spot the difference at looking in the code for 5s... if you can good luck for your. I currently successfully compiled fine old one in MSYS2 with small changes in code.
PS: EAX emulation is not my main concern, I need a stable dsound implementation for some broken games like Soul Reaver.

EDIT: Full proof-of-concept build, old src you posted, compiled using MSYS2, includes changed source code and -full- OpenAL Soft release - current master, VS2015 U3 build, includes QT4 configuration app! http://www48.zippyshare.com/v/7WDIzYIe/file.html
EDIT: Upps, i forgot to include default HRTF tables, link updated.

Nucleoprotein wrote:

I cant spot the difference at looking in the code for 5s... if you can good luck for your. I currently successfully compiled fin […]
Show full quote

unic0rn wrote:

sure it's based on the same old wine code, but there's no openal support in that github tree, so it's useless. the whole point of that wrapper is to translate eax2 into openal effects. also, that wrapper was written by openal-soft author.

if you can't spot the difference, well. good luck with building it.

I cant spot the difference at looking in the code for 5s... if you can good luck for your. I currently successfully compiled fine old one in MSYS2 with small changes in code.
PS: EAX emulation is not my main concern, I need a stable dsound implementation for some broken games like Soul Reaver.

EDIT: Full proof-of-concept build, old src you posted, compiled using MSYS2, includes changed source code and -full- OpenAL Soft release - current master, VS2015 U3 build, includes QT4 configuration app! http://www48.zippyshare.com/v/7WDIzYIe/file.html
EDIT: Upps, i forgot to include default HRTF tables, link updated.

proof of what, that you can compile things? there are full releases of stable openal-soft versions available on github. if anyone wants latest unstable - they've most likely built it themselves already. the point of my build was to provide drop-in replacement for those wanting a version pretending to be creative's openal - which is, unfortunately, something that some games require to work out of the box. as for the wrapper - assuming everything is fine with yours - there's no difference. basically, what you're doing looks pointless.

unic0rn wrote:

proof of what, that you can compile things? there are full releases of stable openal-soft versions available on github. if anyone wants latest unstable - they've most likely built it themselves already. the point of my build was to provide drop-in replacement for those wanting a version pretending to be creative's openal - which is, unfortunately, something that some games require to work out of the box. as for the wrapper - assuming everything is fine with yours - there's no difference. basically, what you're doing looks pointless.

Their released are build using (old?) MinGW which performance for me is sub-optimal on Windows (always been, latest version are little better, I'm waiting for better clang support on Windows), and I always build my own openal-soft (and many other projects, mostly emulator stuff) for about 3 or 4 yeras now. It's a proof-of-concept it can be build without "tricky" cygwin-mingw environment, I think it can be compiled in VS2015 too, code do not look compiler depended.
PS: On github is only source code on openal-soft, builds are on openal-soft site.

Nucleoprotein wrote:

unic0rn wrote:

proof of what, that you can compile things? there are full releases of stable openal-soft versions available on github. if anyone wants latest unstable - they've most likely built it themselves already. the point of my build was to provide drop-in replacement for those wanting a version pretending to be creative's openal - which is, unfortunately, something that some games require to work out of the box. as for the wrapper - assuming everything is fine with yours - there's no difference. basically, what you're doing looks pointless.

Their released are build using (old?) MinGW which performance for me is sub-optimal on Windows (always been, latest version are little better, I'm waiting for better clang support on Windows), and I always build my own openal-soft (and many other projects, mostly emulator stuff) for about 3 or 4 yeras now. It's a proof-of-concept it can be build without "tricky" cygwin-mingw environment, I think it can be compiled in VS2015 too, code do not look compiler depended.
PS: On github is only source code on openal-soft, builds are on openal-soft site.

correct about the builds on openal-soft website.

as for performance, mingw is gcc. mingw under msys2, mingw under cygwin - same thing, nothing "tricky" about it, the difference is that under cygwin the compiler itself is a cygwin binary, so it can use cygwin environment during build process, but the final binary is cygwin-independent and with same mingw version, there will be no difference. i had to modify the sources to build them, so did you, that only proves my point. as for VS2015, the person that asked me to reupload the binary, tried it and it failed. it's an old codebase and it's bound to fail under anything recent. clang - i've had first hand experience with its developers, don't count on them really supporting anything but osx. not a chance in hell.

also, openal-soft is optimized in assembly. that means that regardless of the compiler you'll use to build it, the performance will be mostly the same, if not identical. you may get some marginal differences between 10 years old gcc and latest clang, but even that is kinda doubtful.

as i've said, you're wasting time.

unic0rn wrote:

correct about the builds on openal-soft website. […]
Show full quote

correct about the builds on openal-soft website.

as for performance, mingw is gcc. mingw under msys2, mingw under cygwin - same thing, nothing "tricky" about it, the difference is that under cygwin the compiler itself is a cygwin binary, so it can use cygwin environment during build process, but the final binary is cygwin-independent and with same mingw version, there will be no difference. i had to modify the sources to build them, so did you, that only proves my point. as for VS2015, the person that asked me to reupload the binary, tried it and it failed. it's an old codebase and it's bound to fail under anything recent. clang - i've had first hand experience with its developers, don't count on them really supporting anything but osx. not a chance in hell.

also, openal-soft is optimized in assembly. that means that regardless of the compiler you'll use to build it, the performance will be mostly the same, if not identical. you may get some marginal differences between 10 years old gcc and latest clang, but even that is kinda doubtful.

as i've said, you're wasting time.

Well I have successfully build it under VS2015 today (if somebody wants it: http://www108.zippyshare.com/v/1yi1qkDj/file.html), binary is 151KB (stripped, static CRT) and in in most cases smaller code == faster code, but I think this is because of different CRT, GCC runtime on Win32 is bloated. About assembly in openal-soft, there is none, only SSE -compiler- intrinsic, dunno if generated code is exactly same.
About Clang, I think Clang is supported in Android as -default- compiler in latest NDK, is also included in MSYS2, but C++ exception handling in Win32/Win64 is quite new and buggy. Clang is also included in VS2015 (from Update 1 i think - https://blogs.msdn.microsoft.com/vcblog/2015/ … -2015-update-1/) as mobile/UWP target compiler. Also many static analyzers like PVS Studio uses clang.

This is my last post about this also, because this discussion only bloats this forum, maybe i wasted time, maybe not, maybe somebody wants my builds, maybe not, I don't care, like it, hate it or leave it.

Nucleoprotein wrote:

Well I have successfully build it under VS2015 today (if somebody wants it: http://www108.zippyshare.com/v/1yi1qkDj/file.html), […]
Show full quote

unic0rn wrote:

correct about the builds on openal-soft website. […]
Show full quote

correct about the builds on openal-soft website.

as for performance, mingw is gcc. mingw under msys2, mingw under cygwin - same thing, nothing "tricky" about it, the difference is that under cygwin the compiler itself is a cygwin binary, so it can use cygwin environment during build process, but the final binary is cygwin-independent and with same mingw version, there will be no difference. i had to modify the sources to build them, so did you, that only proves my point. as for VS2015, the person that asked me to reupload the binary, tried it and it failed. it's an old codebase and it's bound to fail under anything recent. clang - i've had first hand experience with its developers, don't count on them really supporting anything but osx. not a chance in hell.

also, openal-soft is optimized in assembly. that means that regardless of the compiler you'll use to build it, the performance will be mostly the same, if not identical. you may get some marginal differences between 10 years old gcc and latest clang, but even that is kinda doubtful.

as i've said, you're wasting time.

Well I have successfully build it under VS2015 today (if somebody wants it: http://www108.zippyshare.com/v/1yi1qkDj/file.html), binary is 151KB (stripped, static CRT) and in in most cases smaller code == faster code, but I think this is because of different CRT, GCC runtime on Win32 is bloated. About assembly in openal-soft, there is none, only SSE -compiler- intrinsic, dunno if generated code is exactly same.
About Clang, I think Clang is supported in Android as -default- compiler in latest NDK, is also included in MSYS2, but C++ exception handling in Win32/Win64 is quite new and buggy. Clang is also included in VS2015 (from Update 1 i think - https://blogs.msdn.microsoft.com/vcblog/2015/ … -2015-update-1/) as mobile/UWP target compiler. Also many static analyzers like PVS Studio uses clang.

This is my last post about this also, because this discussion only bloats this forum, maybe i wasted time, maybe not, maybe somebody wants my builds, maybe not, I don't care, like it, hate it or leave it.

one of the points of using SSE intrinsics is control over generated code. so yeah, you can count that as assembly. and smaller code doesn't have to be faster - there's no telling how much of that executable are functions that are called once or twice. that, and the fact that things like loop unrolling tend to help, at least as long as you're within cpu cache.

Hi,
I am doing some experiments with HW acceleration with my Creative X-FI Titanium HD.
I need 64bit version of Sens_oal.dll (I only have 32 bit 2.2.20.3080).
Can anyone send me that file?

Mr.Lolendo wrote:

Hi, I am doing some experiments with HW acceleration with my Creative X-FI Titanium HD. I need 64bit version of Sens_oal.dll (I […]
Show full quote

Hi,
I am doing some experiments with HW acceleration with my Creative X-FI Titanium HD.
I need 64bit version of Sens_oal.dll (I only have 32 bit 2.2.20.3080).
Can anyone send me that file?

Should be bundled in your card drivers in HOAL package.

THX.
I didn't find it at drivers of my Titanium HD. Also ct_oal.dll was missing.
But I found it at drivers of my another X-Fi Extreme Audio.
I am using Daniel_K's custom drivers.

Before The Following update to the Dying Light I was able to run the game with OpenAL if I copy Senc_oal.dll (32bit) to game directory. It completly bypassed Windows volume control so I have proof that OpenAL is running.
What is very weird is that the game is 64 bit. Well now I will try with 64bit Senc_oal.dll.

Mr.Lolendo wrote:

THX. I didn't find it at drivers of my Titanium HD. Also ct_oal.dll was missing. But I found it at drivers of my another X-Fi Ex […]
Show full quote

THX.
I didn't find it at drivers of my Titanium HD. Also ct_oal.dll was missing.
But I found it at drivers of my another X-Fi Extreme Audio.
I am using Daniel_K's custom drivers.

Before The Following update to the Dying Light I was able to run the game with OpenAL if I copy Senc_oal.dll (32bit) to game directory. It completly bypassed Windows volume control so I have proof that OpenAL is running.
What is very weird is that the game is 64 bit. Well now I will try with 64bit Senc_oal.dll.

I think ct_oal.dll is Creative HW OpenAL only and newer cards do not have support for this. I think Sens_oal is based on old Sensaura 3DPA - it's fully software.

My Sound Blaster X-Fi Titanium HD is Top-end Creative x-fi soundcard with full support HW acceleration of OpenAL. New replacement Sound Blaster ZxR do not support HW acceleration of OpenAL.
So Sens_oal.dll is only soft-base hmm interesting. What is wrap_oal.dll?

With HW OpenAL I am using Winamp with plugin for OpenAL. It working very good but there is no different for example AIMP with ASIO.

It is disappointing how quality of sound stagnates or worse. Today everything has that SW base FMOD. BattleField 4 and SW BattleFront sounds great but EAX 5.0 is totally somewhere else.
Especially since the DX11.1 is the ability to render 3D sound on graphics cards. In the and for VR headsets everything must change.

The problem is not instrinically "software".
It's just Creative pulled too much the rope during audio landscape "adolescence" and unnatural choices gonna extinct.

More on wrap_oal here.

Mr.Lolendo wrote:

My Sound Blaster X-Fi Titanium HD is Top-end Creative x-fi soundcard with full support HW acceleration of OpenAL. New replacemen […]
Show full quote

My Sound Blaster X-Fi Titanium HD is Top-end Creative x-fi soundcard with full support HW acceleration of OpenAL. New replacement Sound Blaster ZxR do not support HW acceleration of OpenAL.
So Sens_oal.dll is only soft-base hmm interesting. What is wrap_oal.dll?

With HW OpenAL I am using Winamp with plugin for OpenAL. It working very good but there is no different for example AIMP with ASIO.

It is disappointing how quality of sound stagnates or worse. Today everything has that SW base FMOD. BattleField 4 and SW BattleFront sounds great but EAX 5.0 is totally somewhere else.
Especially since the DX11.1 is the ability to render 3D sound on graphics cards. In the and for VR headsets everything must change.

The wrap_oal.dll is standard OpenAL to DirectSound/WINMM wrapper. About DX11.1 is the ability to render 3D sound, i think you talking about AMD TrueAudio and it is not rendering but processing.

EDIT: Currently OpenAL Soft is much better wrapper.

No I talking about NVIDIA VRWorks Audio
https://www.youtube.com/watch?v=A3Y2BSHxKHU

Mr.Lolendo wrote:

No I talking about NVIDIA VRWorks Audio
https://www.youtube.com/watch?v=A3Y2BSHxKHU

Hym, I do not think is something better than TrueAudio, https://en.wikipedia.org/wiki/AMD_TrueAudio which use DSP enmbedded in AMD GPUs.
VRWorks is NVIDIA shit so it will work only on their latest hardware, but it seems to be full software solution (I do not see in Pascal specs any DSP).

PS: Yes, i really hate NVIDIA, their proprietary software/middleware works only on their hardware or is specially written to have lower performance on other GPUs (GameWorks), AMD software/middleware works everywhere and is opensource - http://gpuopen.com/games-cgi/

I do not like both AMD and Nvidia. But Nvidia making thing that works and are widely used. Nvidia is like Creative. Just selling conglomerate... How many games have TressFX, Mantle and TrueAudio...?!
GameWorks is pack of complete effect for lazy and incapable developers. But they even fucked up implementation of GameWorks to theirs games. Than blame Nvidia for that. Of course all layman eat the crap.
Nvidia and AMD are tired of those losers developers that they can not properly optimized theirs game. Why must Nvidia and AMD do others jobs? Every new AAA games is at launch broken crap.
GameWorks is here for Nvidia make their job optimize of drivers easier.

If are games technically optimized and TOP then there is no point for other third party effects. Far Cry 1, Prey, Crysis 1, SW: Battlefront (2015)...

Whole gaming industry was fucked up by consoles. Of course consoles itself are innocent. The environment around I blame. How much time it takes when most widely used engine UE3 learn simple MS/SS antialiasing?! PC port was and are shitty and disfigured from consol. "Composite shadows"??? What is that shit doing at PC. PC can have fully dynamic volumetric shadows. Etc.

Alan Wake was the most important game in the industry. It should be best looking game at PC and show true power of DX10. But no. Microsoft just need to have console and exclusive content. Yep because X360 does not support DX10. So they fucked up DX10, game it self and whole Windows as gaming platform.

I remember when HL2 came out. At X360 game looks much better than PC version because in those days consoles was TOP-end hardware.

So i dont care about brand. I want active/pleasant support my bought product, quality recording in games with almost no impact at performance and heavily customizable of setting at the drivers. (Nvidia Profile Inspector)
Well only Nvidia this can offer to me.

Nucleoprotein wrote:

Mr.Lolendo wrote:

No I talking about NVIDIA VRWorks Audio
https://www.youtube.com/watch?v=A3Y2BSHxKHU

Hym, I do not think is something better than TrueAudio, https://en.wikipedia.org/wiki/AMD_TrueAudio which use DSP enmbedded in AMD GPUs.
VRWorks is NVIDIA shit so it will work only on their latest hardware, but it seems to be full software solution (I do not see in Pascal specs any DSP).

TrueAudio is just DSP effects - similar to what Creative cards were offering with EAX.
VRWorks Audio is ray-traced audio - similar to what Aureal were doing with A3D.

Nucleoprotein wrote:

PS: Yes, i really hate NVIDIA, their proprietary software/middleware works only on their hardware or is specially written to have lower performance on other GPUs (GameWorks), AMD software/middleware works everywhere and is opensource - http://gpuopen.com/games-cgi/

AMD GPUs have poor tessellation performance, thus any effect which uses a lot of tessellation runs poorly. You can't blame GameWorks for that.
GameWorks effects are totally optional anyway. No game forces them on.

I suppose it's NVIDIA's fault that DX11 titles run poorly on AMD as well, since NVIDIA supports driver command lists, while AMD does not.
Or NVIDIA's fault that GCN cards don't support things like conservative rasterization in DX12.
Or NVIDIA's fault that AMD's OpenGL drivers are terrible.

NVIDIA's OpenGL performance is not far off Vulkan in DOOM, while AMD saw significant improvements when moving away from OpenGL to Vulkan.
Prior to the Vulkan patch, people were claiming that id Software were biased against AMD since mid-range NVIDIA GPUs were outperforming high-end AMD GPUs. Nope - that's just how bad their OpenGL drivers are.
And now we have AMD owners complaining that the new 3DMark DX12 benchmark is "rigged" because they don't use vendor-specific code.

Deep Thought wrote:

TrueAudio is just DSP effects - similar to what Creative cards were offering with EAX. VRWorks Audio is ray-traced audio - simil […]
Show full quote

Nucleoprotein wrote:

Mr.Lolendo wrote:

No I talking about NVIDIA VRWorks Audio
https://www.youtube.com/watch?v=A3Y2BSHxKHU

Hym, I do not think is something better than TrueAudio, https://en.wikipedia.org/wiki/AMD_TrueAudio which use DSP enmbedded in AMD GPUs.
VRWorks is NVIDIA shit so it will work only on their latest hardware, but it seems to be full software solution (I do not see in Pascal specs any DSP).

TrueAudio is just DSP effects - similar to what Creative cards were offering with EAX.
VRWorks Audio is ray-traced audio - similar to what Aureal were doing with A3D.

Nucleoprotein wrote:

PS: Yes, i really hate NVIDIA, their proprietary software/middleware works only on their hardware or is specially written to have lower performance on other GPUs (GameWorks), AMD software/middleware works everywhere and is opensource - http://gpuopen.com/games-cgi/

AMD GPUs have poor tessellation performance, thus any effect which uses a lot of tessellation runs poorly. You can't blame GameWorks for that.
GameWorks effects are totally optional anyway. No game forces them on.

I suppose it's NVIDIA's fault that DX11 titles run poorly on AMD as well, since NVIDIA supports driver command lists, while AMD does not.
Or NVIDIA's fault that GCN cards don't support things like conservative rasterization in DX12.
Or NVIDIA's fault that AMD's OpenGL drivers are terrible.

NVIDIA's OpenGL performance is not far off Vulkan in DOOM, while AMD saw significant improvements when moving away from OpenGL to Vulkan.
Prior to the Vulkan patch, people were claiming that id Software were biased against AMD since mid-range NVIDIA GPUs were outperforming high-end AMD GPUs. Nope - that's just how bad their OpenGL drivers are.
And now we have AMD owners complaining that the new 3DMark DX12 benchmark is "rigged" because they don't use vendor-specific code.

I'm not AMD fanboy, I'm open source fanboy - ie. everything proprietary is bad, everything open sourced is good - that's it. If NVIDIA open source their tech I will not hate it... NVIDIA is company that buys other companies only for their tech and then make is proprietary like SLI and many other, is a cancer like Creative and Oracle.

PS: And very smart guy tells that too... https://www.youtube.com/watch?v=_36yNWw_07g

Don't forget Microsoft, which (to be slightly more on topic) basically killed Creative's EAX. And Creative, well they basically facilitated Aureal's self-destruction. Ah... such a proprietary world we're living in!

Nucleoprotein wrote:

I'm not AMD fanboy, I'm open source fanboy - ie. everything proprietary is bad, everything open sourced is good - that's it. If NVIDIA open source their tech I will not hate it... NVIDIA is company that buys other companies only for their tech and then make is proprietary like SLI and many other, is a cancer like Creative and Oracle.

NVIDIA SLI has nothing in common with 3DFX SLI. It is "scalable link interface" vs "scan-line interleave".

Nucleoprotein wrote:

PS: And very smart guy tells that too... https://www.youtube.com/watch?v=_36yNWw_07g

Yet anyone that cares about gaming on Linux uses NVIDIA. It's another area where AMD are falling significantly behind.
The only reason that AMD are pushing for open-sourcing everything is because of the position they're in. If they were in the dominant position and had the resources to fully develop and support technologies themselves, they absolutely would not be doing this now.
It's the same reason they're pushing so hard for low-level APIs - it pushes a lot of the work onto the developers rather than having to focus on producing high quality drivers.

I agree with the notion that open source is preferable to closed-source, but sticking to that means making significant ease-of-use, quality-of-life, and performance sacrifices.

archsan wrote:

Don't forget Microsoft, which (to be slightly more on topic) basically killed Creative's EAX. And Creative, well they basically facilitated Aureal's self-destruction. Ah... such a proprietary world we're living in!

Yeah, just look at what happened to PC game audio after Microsoft killed off EAX a decade ago: absolutely nothing.
The loss of EAX was considerable and it's only now that we're starting to see good audio returning to games.

I'll happily take a widely supported proprietary solution over nothing at all.