Thandor: The Invasion - no sound with dsoal

[huh02]

Hi, I would like to ask if it is possible to fix this. With dsoal dsound.dll there is no sound or music on Win7 or Win11. This works with indirectsound or with dsound.dll from WinXP. Since I can't compile dsound.dll alone, I used bulid version from http://vaporeon.io/hosted/dsoal-builds/ but not even with the version from https://ci.appveyor.com/project/ChrisRobinson/dsoal/build/job/gpn3b2x1t88ioodr/artifacts it doesn't work. Here is the log with variable debug 3. 3dsoal_error.txt Thanks.

[ghotik]

As a further information about this, the Windows 11 system dsound.dll returns an error code at the Play method like shown in the following DxWnd log:

IDirectSoundBuffer::Play: lpbuf=0x1476e4a0 reserved=0 priority=0 flags=0x1(DSBPLAY_LOOPING)
IDirectSoundBuffer::Play: ERROR res=0x887d0009

Where 0x887d0009 corresponds to APOERR_INVALID_CONNECTION_FORMAT Though not for sure, it seems possible that dsoal could fail for the very same reason. Personally, I would be interested in understanding better what's going on behind the scenes to see if it could be possible to implement a fix in DxWnd.

[ThreeDeeJay]

I have no idea if there's a solution, but here's a few more options to test in case it can offer more clues:

• c++ rewrite branch: https://github.com/ThreeDeeJay/dsoal/releases/tag/latest-c%2B%2B-rewrite
• DSOAL XP: https://github.com/pachuco/dsoal-XP/tree/master/release
• Oldest builds from here in case there was a regression: http://vaporeon.io/hosted/dsoal-builds/

[huh02]

DSOAL XP: https://github.com/pachuco/dsoal-XP/tree/master/release

DsoalXP produces the same silence, here is the log. XPdsoal_error.txt

c++ rewrite branch: https://github.com/ThreeDeeJay/dsoal/releases/tag/latest-c%2B%2B-rewrite

But hey! This version works here in Win7. What is the difference? What's different in this version? I would like to find out. ThreeDeeJaydsoal_error.txt

[ThreeDeeJay]

Currently DSOAL is being rewritten into C++ in a different branch which is technically newer than the main branch but I think not all features have been reimplemented yet. But hey, if it works, it works :tm: Out of curiosity, could you also try this one? https://github.com/ThreeDeeJay/dsoal/releases/download/latest-master/DSOAL.zip Just wanna make sure whether it's really the non*-rewrite or the build from Appveyor that's causing issues.

[BEENNath58]

Just wanna make sure whether it's really the rewrite or the build from Appveyor that's causing issues.

Just to clarify, DSOAL is being used to fix the "silence" that is present with the native DSOUND. There is a probability that it was never fixed in DSOAL in first place

[huh02]

@ThreeDeeJay

Out of curiosity, could you also try this one? https://github.com/ThreeDeeJay/dsoal/releases/download/latest-master/DSOAL.zip

Now I tried it and I have no sound or music with this version (in Win7). Something must have made the difference between these versions. The previous version you sent works fine. 2ThreeDeeJaydsoal_error.txt

[kcat]

As a further information about this, the Windows 11 system dsound.dll returns an error code at the Play method like shown in the following DxWnd log:

IDirectSoundBuffer::Play: lpbuf=0x1476e4a0 reserved=0 priority=0 flags=0x1(DSBPLAY_LOOPING)
IDirectSoundBuffer::Play: ERROR res=0x887d0009

Where 0x887d0009 corresponds to APOERR_INVALID_CONNECTION_FORMAT Though not for sure, it seems possible that dsoal could fail for the very same reason. Personally, I would be interested in understanding better what's going on behind the scenes to see if it could be possible to implement a fix in DxWnd.

I doubt DSOAL would have the same error. APOERR_INVALID_CONNECTION_FORMAT would suggest there's a problem with negotiating the DSound output format with some APO on the system. DSOAL's Play method wouldn't get an error like that from anywhere.

I see the app is calling IDirectSoundBuffer::SetFormat for 16-bit stereo 22050hz on the primary buffer, which perhaps could be causing a problem somewhere when initializing the audio stream, and that error is getting returned back to the app as-is? Seems odd though. SetFormat is generally ignored (or only taken as a weak hint) these days, and that's not an unusual configuration for older apps to try to set, so I'd expect a more wide-spread problem if that's the issue.

DSOAL XP: https://github.com/pachuco/dsoal-XP/tree/master/release

DsoalXP produces the same silence, here is the log. XPdsoal_error.txt

c++ rewrite branch: https://github.com/ThreeDeeJay/dsoal/releases/tag/latest-c%2B%2B-rewrite

But hey! This version works here in Win7. What is the difference? What's different in this version? I would like to find out. ThreeDeeJaydsoal_error.txt

From the looks of the logs, it seems the app is creating a primary buffer with DSBCAPS_CTRLPAN and DSBCAPS_CTRLVOLUME. It then tries to pan the primary buffer to 0 (center). Older/pre-rewrite DSOAL would return an error if not in DSSCL_WRITEPRIMARY mode, since OpenAL has no way to pan a "primary buffer" such that it affects all sounds (even though it's 0 in this case, which wouldn't pan anything). That failure seems to cause the app to give up and stop using the device.

Newer/c++-rewrite DSOAL will succeed with trying to pan the primary buffer, storing the set value but otherwise ignoring the call, which makes the app happy and lets it continue as intended (though if it ever does set a non-0 pan on the primary buffer, that won't do what it's intended to and the sound won't change).

[huh02]

@kcat, @ThreeDeeJay Thanks for the support and explanation!

[BEENNath58]

I did have an opposite effect and solution. On my Windows 11 machine, the menu effects play. However with @ThreeDeeJay 's build that worked for @huh02 I get no sound.

IndirectSound, with at least 10 sound buffers return the menu effects and music. With 63 buffers (preferably 64 by Audigy2 standards), all the sounds (including the talking man) work.

Is this feature of HardwareBufferCount available on DSOAL?

[BEENNath58]

@ThreeDeeJay I tried to use your version, and log the operations, but the file is just blank. Other DSOAL versions don't have this issue

[kcat]

Is this feature of HardwareBufferCount available on DSOAL?

Not directly. By default, DSOAL requests 1024 sound sources from OpenAL, and reserves 128 as "hardware" buffers (I've run into an app that fails to play any audio if it's higher), leaving the rest as "software" (some apps pre-allocate a lot of software buffers, even though it doesn't play many at once). If OpenAL can only allocate 256 sources or less, DSOAL will instead reserve only 64 as "hardware" buffers. So you can create an alsoft.ini config file in the executable's folder with the lines:

[general]
sources = 256

to limit the number of sources OpenAL Soft will allocate, reducing the DSound hardware buffers to 64. This will also reduce the number of software buffers that can be allocated, which may or may not be a problem for a given app.

Currently DSOAL doesn't have any direct configuration options itself, as I've not made a configuration parser for it yet. It will only be affected by OpenAL Soft's capabilities, which can be configured via alsoft.ini.

[BEENNath58]

As unfortunate as it is, the game is still quiet with this configuration in alsoft.ini. If it helps, I am uploading my logs: dsoal_error.txt alsoft_error.txt

[kcat]

As unfortunate as it is, the game is still quiet with this configuration in alsoft.ini. If it helps, I am uploading my logs: dsoal_error.txt alsoft_error.txt

You need to use the build from the c++-rewrite branch. The older version returns an error from SetPan on the primary buffer that causes the app to stop doing audio stuff, which is fixed in the newer/rewrite version.

[BEENNath58]

You need to use the build from the c++-rewrite branch.

As I said earlier, it creates an empty log file. It doesn't even bother creating the OpenAL log, even when explicitly put in as an env var.

The non-c++ rewrite creates a dsoal log saying openal was loaded, and that's the only line. OpenAL log isn't yet generated.

The last version that works is 0.9.5 from ThreeDeeJay

[BEENNath58]

@ghotik was kind enough to create a exclusive build to handle the SetPan capability. Coupled with 0.95, the last build that would "log" on my machine, it was "outputting" sounds!

@kcat @ThreeDeeJay

1. The HardwareBufferCount feature is necessary, but the no of sources required seems less. If I put a total of 128 (not sure how many HW buffs that is, 32?), the audio would still play. However keeping a low number would mute the sound. Is there a way to bypass in DSOAL, the HW buffer count and let Windows DSound do it itself (just as to see if SW buffers work, it seemed to be working on Windows 98).
2. The dsoal newer versions not logging makes me think Windows sees it as some unsigned code? If it's the case, is there something I can do to bypass that?

[kcat]

As I said earlier, it creates an empty log file. It doesn't even bother creating the OpenAL log, even when explicitly put in as an env var.

That would suggest it's not using OpenAL Soft, then. Either dsoal-aldrv.dll was missing, or wasn't OpenAL Soft. Or something else is going wrong that it's not even getting to the point of using OpenAL. With the rewrite branch, it may be helpful to set DSOAL_LOGLEVEL to 4 instead of 3, to show more of the calls being made (this can create really large log files for otherwise mostly functioning apps, logging potentially dozens or hundreds of lines per audio update depending on how much it's doing).

If I put a total of 128 (not sure how many HW buffs that is, 32?), the audio would still play. However keeping a low number would mute the sound.

128 sources would still reserve 64 hardware buffers, only shrinking the number of software buffers it could create. Any less than 128 sources will fail with opening the device, as the number of available sources would make the available buffers very low, and inevitably cause problems for many apps. I don't really know how many hardware voices apps could expect from contemporary devices, but I can't imagine many apps would be happy with less than 64. Maybe 32, but would apps really accept (let alone require) less than that?

The dsoal newer versions not logging makes me think Windows sees it as some unsigned code? If it's the case, is there something I can do to bypass that?

I doubt it has to do with being unsigned code. Neither the new or old versions are signed, so the behavior should be the same. Some apps do apparently have an issue with the way they load DSound that it won't recognize the dsound.dll in its own folder as an override for the system DLL, which can be fixed by setting some registry keys. However, if that was the issue, it'd affect the new and old versions alike as well, with the effect being it using the normal system dsound.dll as if DSOAL wasn't there.

[BEENNath58]

With the rewrite branch, it may be helpful to set DSOAL_LOGLEVEL to 4 instead of 3, to show more of the calls being made (this can create really large log files for otherwise mostly functioning apps, logging potentially dozens or hundreds of lines per audio update depending on how much it's doing).

Yes I already tried putting 2, 3, 4 there. The result is always a 0KB file