There must be log output, otherwise changing the sblaster.cpp would not
be capable of disabling sb functionality.

UUUPs ....

This is the output:

read mixer 4 write mixer 4 : 37 read mixer 4 read mixer 2e write mixer 2e : ee read mixer 2e write mixer 22 : cc write mixer 4 : […]
Show full quote

read mixer 4
write mixer 4 : 37
read mixer 4
read mixer 2e
write mixer 2e : ee
read mixer 2e
write mixer 22 : cc
write mixer 4 : cc
write mixer 26 : cc
write mixer 28 : cc
write mixer 2e : cc
write mixer a : 0

this is the non-working case ?

Yes. Windows stays silent.

Maybe just for completeness you could try posting the log output with
the old sblaster.cpp (or is it the same?)

Using the old sblaster.cpp, the output is like this:

read mixer 4 write mixer 4 : 37 read mixer 4 write mixer 4 : ff read mixer 2e write mixer 2e : ee read mixer 2e write mixer 22 : […]
Show full quote

read mixer 4
write mixer 4 : 37
read mixer 4
write mixer 4 : ff
read mixer 2e
write mixer 2e : ee
read mixer 2e
write mixer 22 : cc
write mixer 4 : cc
write mixer 26 : cc
write mixer 28 : cc
write mixer 2e : cc
write mixer a : 0
write mixer e : 0
write mixer e : 0
write mixer e : 0
write mixer e : 0

In both cases (old and new sblaster.cpp) I simply started and quitted windows.
With the old sblaster.cpp I could hear both the start and the exit sound. With the new one, nothing ... .

Thanks for the log.

1read mixer 4
2write mixer 4 : 37
3read mixer 4

This won't return 37 but 26 with sbpro or sbpro2 (because of two "reserved" bits which are set to 0 on read), although it's strange that it still doesn't work with sb16 setting where it should return same value (maybe it stops somewhere else). I will check with the driver that I found.

This won't return 37 but 26

Maybe the register should get a different initialisation value? As they read
something from reg4 and (supposedly) write that (modified) back.

Found this bug (missing brackets):

1-(((_WHICH_[0] & 0x1e) << 3) | ((_WHICH_[1] & 0x1e) >> 1) & (sb.type==SBT_16 ? 0xff:0xee))
2+((((_WHICH_[0] & 0x1e) << 3) | ((_WHICH_[1] & 0x1e) >> 1)) & (sb.type==SBT_16 ? 0xff:0xee))

Could be a cause for this regression (driver will read 0xfe, not 0xee from 0x2e reg).

Regarding default values, we set volumes for 0x4,0x22,0x26 to 31 (to get higher volume in games), while default should be 20 (or 0xaa in sbpro reg). Default for 0x2e is 0 which is correct in dosbox.

Version of sbpro2 driver I have here is a bit different from kruwi's. It doesn't work with older mixer code either, nor with above fix, and it reads only the line-in register:

<cut> issue with my driver doesn't seem to be mixer related, aborts after reading dsp version several times.

sbtype=sb16 in combination with the sb16 drivers is actually working.

How about Pro2 driver? Is it better with above bracket correction or still refuses to initialize?

kruwi: please check out current sources and re-test the problem with
the sbpro driver. If it doesn't work add the log messages again and
see if the output changed.

Quite funny. With the current sources and the setting sbtype=sb16, the sbpro2 drivers are working. They are not working, however, if I try sbtype=sbpro2.

Now checking log files ...

sbtype=sb16, using the sbpro2 drivers (working):

1read mixer 4
2write mixer 4 : 37
3read mixer 4
4write mixer 4 : ff
5read mixer 2e
6write mixer 2e : ee
7read mixer 2e
8write mixer 22 : cc
9write mixer 4 : cc
10write mixer 26 : cc
11write mixer 28 : cc
12write mixer 2e : cc
13write mixer a : 0
14write mixer e : 0
15write mixer e : 0
16write mixer e : 0
17write mixer e : 0

sbtype=sbpro2, using the sbpro2 drivers, not working:

1read mixer 4
2write mixer 4 : 37
3read mixer 4
4read mixer 2e
5write mixer 2e : ee
6read mixer 2e
7write mixer 22 : cc
8write mixer 4 : cc
9write mixer 26 : cc
10write mixer 28 : cc
11write mixer 2e : cc
12write mixer a : 0

It's the 37->26 issue.

Only difference between sbpro2 and sb16 is last precision bit for each stereo volume, it seems that driver assumes 4-bit precision while sbpro/pro2 *should* have 3-bit precision - probably it does, but driver still expects last bit to be preserved ( Creative breaking their own nice-coding guidelines from SB SDK).

Shoud work if we remove sb.type==SBT_16 checks from macros SETPROVOL and MAKEPROVOL and assume as if they were true.