I probably could try to recompile it with some changes (need to update djgpp gcc to newer version) but without deeper knowledge of source of what this changes was intended to do it would be a bit of blind shooting. As some one else mentioned before it's different to can read the C code and really understand what it should do in wider context. Probably author of the commit could know within a minute a would see the issue it may caused...

Am I doing something wrong? SBLive with SBEMU and when I test audio in Descent setup the left channel and right channel plays on left and right but when it plays the centered audio it only plays on the right channel. fm synth also only outputs to the right channel so it seems offset to the right.

Lynxman wrote on 2025-01-23, 18:43:

Am I doing something wrong? SBLive with SBEMU and when I test audio in Descent setup the left channel and right channel plays on left and right but when it plays the centered audio it only plays on the right channel. fm synth also only outputs to the right channel so it seems offset to the right.

Try VSBHDA: https://github.com/Baron-von-Riedesel/VSBHDA

SbEmu 1.0beta5
Tested some DOS applications.

AXS Software Synthesizer v2.03, Not working. Reports:
"AXS Realtime Software Synthesizer v2.03+ Free Version (C) 1998-2000 Resolution

Loading configuration file 'AXS.INI'... OK
Loading preset bank 'AXS.BNK'... OK
Initialising MIDI device: SB MPU... ERROR

-> SB DSP reset failed ! (No SB16 found at specified baseport)
Initialising WAVE device: SoundBlaster... ERROR

-> SB DSP reset failed ! (No SB16 found at specified baseport)"

TiMidity м0.2g. Not working. Hangs up.

DOSMid v0.9.3. Works correctly.

SoftMPU. Not working. Reports:
┌────────────────────────────────────────┐
│SoftMPU 1.91 ■ Software MPU-401 Emulator│
│ │
│Copyright (C) 2013-2014 bjt, elianda │
│Copyright (C) 2002-2013 The DOSBox Team│
└────────────────────────────────────────┘
√ Sound Blaster (DSP 4.00) detected at port 220 IRQ 7
i SB-MIDI mode enabled
i MPU-401 interrupts disabled
! Error: Port trap failed. Please submit a bug report

krotan wrote on 2025-01-23, 18:57:

SbEmu 1.0beta5 Tested some DOS applications. AXS Software Synthesizer v2.03, Not working. Reports: "AXS Realtime Software Synthe […]
Show full quote

SbEmu 1.0beta5
Tested some DOS applications.
AXS Software Synthesizer v2.03, Not working. Reports:
"AXS Realtime Software Synthesizer v2.03+ Free Version (C) 1998-2000 Resolution
...

Then this is also a regression since earlier versions from 2023 worked perfectly with AXS Software Synthesizer v2.02 and v2.03.

@Edit:
I have just checked and latest version of SBEMU really does not work with AXS while on the same hardware SBEMU version from 2023.03.18 works perfectly.
Test video:
https://youtu.be/06F1SNhS0PQ

RayeR wrote on 2025-01-23, 13:37:

I probably could try to recompile it with some changes (need to update djgpp gcc to newer version) but without deeper knowledge of source of what this changes was intended to do it would be a bit of blind shooting. As some one else mentioned before it's different to can read the C code and really understand what it should do in wider context. Probably author of the commit could know within a minute a would see the issue it may caused...

Annotating the lines with the breaking changes you identified using git-blame, I found the Git commit ID in the main branch that contained this change:

1commit 880ddfa13ed6a8bbe43cac7f0ed1db4dc2044a9e
2Author: crazii <EMAIL ADDRESS REMOVED>
3Date:   Mon Feb 5 18:03:17 2024 +0800
4
5    improve resampling interpolation.

But I also see that he performed another interpolation-related tweak in the commit after that, this time changing just two lines:

1commit 082418e0a3235b9013364961d195a19a30c2d277
2Author: crazii <EMAIL ADDRESS REMOVED>
3Date:   Mon Feb 5 20:17:58 2024 +0800
4
5    bugfix on low frequency interpolation, i.e. skyroads.
6
7diff --git a/main.c b/main.c
8index 13a475a..bdec476 100644
9--- a/main.c
10+++ b/main.c
11@@ -1128,6 +1128,7 @@ static void MAIN_Interrupt()
12     BOOL digital = SBEMU_HasStarted();
13     int dma = (SBEMU_GetBits() <= 8 || MAIN_Options[OPT_TYPE].value < 6) ? SBEMU_GetDMA() : SBEMU_GetHDMA();
14     int32_t DMA_Count = VDMA_GetCounter(dma); //count in bytes
15+    if(!digital) MAIN_LastSBRate = 0;
16     if(digital)//&& DMA_Count != 0x10000) //-1(0xFFFF)+1=0
17     {
18         uint32_t DMA_Addr = VDMA_GetAddress(dma);
19@@ -1167,7 +1168,7 @@ static void MAIN_Interrupt()
20             int count = samples-pos;
21             BOOL resample = TRUE; //don't resample if sample rates are close
22             if(SB_Rate < aui.freq_card-50)
23-                count = max(1, count*SB_Rate/aui.freq_card);
24+                count = max(min(2,count), count*SB_Rate/aui.freq_card); //need at least 2 for interpolation
25             else if(SB_Rate > aui.freq_card+50)
26                 count = count*SB_Rate/aui.freq_card;
27             else

These appear to be the only two commits that mention "interolation" in the commit messages. I could try reverting them both. I have a Pull Request for testing SBEMU in a CI/CD pipeline, but I couldn't get it to output sound in a QEMU VM, even though I could have sworn that I had SBEMU working in a QEMU VM once. Perhaps these reverts will also make my CI/CD test branch work.

I'll test this soon. It's late over here, so I might pick this up the coming weekend.

Thanks RayeR and everyone else helping with testing and troubleshooting! 🙏🏽

Correction: both these commits appear to contain the changes that RayeR pointed out in his diff. So yeah, let me try reverting them both.

Okay, I created a branch in my SBEMU fork with those two commits reverted and then pushed a tag to trigger a build, but the build failed with the following compilation error:

1mpxplay/au_cards/au_base.c: In function 'mixer_speed_lq':
2mpxplay/au_cards/au_base.c:1092:16: error: 'total' undeclared (first use in this function)
3 1092 |   intmp2=ipi < total-ch ? intmp1+ch : intmp1;
4      |                ^~~~~
5mpxplay/au_cards/au_base.c:1092:16: note: each undeclared identifier is reported only once for each function it appears in
6make: *** [makefile:122: output/mpxplay/au_cards/au_base.o] Error 1

My guess is that the variable `total` was removed in some later commit after the line `intmp2=ipi < total-ch ? intmp1+ch : intmp1;` was replaced in the commits that RayeR's diff referred to. I need to go look for the commit that removed that variable and see if I can easily revert that one as well, at least partially. I'll look into this further some other time, perhaps in the coming weekend.

Any help with this is welcome! Thanks again. 🙏🏽

digger wrote on 2025-01-09, 09:22:

An open source unified Intel HDA driver for Windows 3.x would be very useful, for instance!

So I really don't get why people insist on making SBEMU compatible with Windows. That's really not what it's for.

There is a HDA driver for Windows 3.x. The source is available, but it is written in Pascal.

I just tried to recompile broken version SBEMU-UserBuild_2024.02.06_02-04 with reverted changes only in au_base.c and it seems its enough to fix playback speed but it may break somewhere else.
Then I tried to put some debug output in au_base.c in mixer_speed_lq()

int total = sourcesample/channels;
printf("samplerate=%d, srcsample=%d, newrate=%d, chans=%d, total=%d\n", samplerate, sourcesample, newrate, channels, total);

and launched doom. It hanged within a moment as printing from ISR is not good idea, sure...
But something can be seen. I wonder why the first call prints
"samplerare=11025" - the expectable number
and all later calls prints
"samplerare=11111" - the weird number
newrate and channels seems as expected, I use /k44100 option (but speed up effect happen regardless to it).

EDIT: it's expected, first call in main.c goes with parameter of emulated sample rate (SB_Rate) while further calls use some recalculated value...
// the actual sample rate is derived from current count of samples in direct output buffer
samples = mixer_speed_lq(MAIN_PCM, MAIN_PCM_SAMPLESIZE, MAIN_PCMResample, samples, 1, (samples * aui.freq_card) / aui.card_samples_per_int, aui.freq_card);

Perhaps this is the best thread to ask.

Does anyone know the "best" (compatibility/quality) ac97 chip that is also still available?

Falcosoft wrote on 2025-01-23, 19:07:

earlier versions from 2023 worked perfectly with AXS Software Synthesizer v2.02 and v2.03.

SbEmu 1.0beta5
Tested AXS Software Synthesizer v2.03 using SbEmu1.0b2 and SbEmu1.1a1. Not working. What version are working?

krotan wrote on 2025-01-24, 11:23:

Falcosoft wrote on 2025-01-23, 19:07:

earlier versions from 2023 worked perfectly with AXS Software Synthesizer v2.02 and v2.03.

SbEmu 1.0beta5
Tested AXS Software Synthesizer v2.03 using SbEmu1.0b2 and SbEmu1.1a1. Not working. What version are working?

As I have written (and as can be seen also in the test video) the version form 2023.03.18 is working perfectly with AXS.
So you should try 1.0 beta3 instead from 2023.04.20 first. If it does not work then I can attach my working one from 2023.03.18 as a download.

Falcosoft wrote on 2025-01-24, 11:25:

krotan wrote on 2025-01-24, 11:23:

Falcosoft wrote on 2025-01-23, 19:07:

earlier versions from 2023 worked perfectly with AXS Software Synthesizer v2.02 and v2.03.

SbEmu 1.0beta5
Tested AXS Software Synthesizer v2.03 using SbEmu1.0b2 and SbEmu1.1a1. Not working. What version are working?

As I have written (and as can be seen also in the test video) the version form 2023.03.18 is working perfectly with AXS.
So you should try 1.0 beta3 instead from 2023.04.20 first. If it does not work then I can attach my working one from 2023.03.18 as a download.

@Edit:
This is the version that works for me. Start it with START.BAT and then start AXS. Also make sure that your BLASTER environment variable is set to SB16. That is:
SET BLASTER=A220 I5 D1 H5 T6

Falcosoft wrote on 2025-01-24, 11:25:

So you should try 1.0 beta3 instead from 2023.04.20 first. If it does not work then I can attach my working one

Tested SbEmu1.0b3 with AXS. Not working. Please attach your version.

krotan wrote on 2025-01-24, 12:10:

Falcosoft wrote on 2025-01-24, 11:25:

So you should try 1.0 beta3 instead from 2023.04.20 first. If it does not work then I can attach my working one

Tested SbEmu1.0b3 with AXS. Not working. Please attach your version.

It has been already attached. Look at my previous post.
BTW, I have just tested 1.0 beta3 from 2023.04.20 and it's also working with AXS perfectly so your problem must be something else.

Try it without JEMM/QEMM memory managers loaded. This way real-mode support is disabled but since AXS is a protected mode program it should work anyway.

Confirmed: With JEMM/QEMM memory managers loaded AXS cannot detect SB16 with error: "No SB detected at baseport...".
So you should definitely disable EMS managers and thus real-mode support to use AXS.

@Edit:
This way it also works with latest version of SBEMU so there is no regression. Sorry for the noise.
But it does not work with latest version of VSBHDA even if real-mode support is disabled.

As a result of tests, a working configuration for AXS Software Synthesizer v2.03 was found:
- himem.sys enable
- emm driver disable
- hdpmi32i.exe enable
- SbEmu1.0beta5
(but SbEmu1.0brta3 is not working in my case and hangs)
Thank you very mach, Falcosoft

I also looked on VSBHDA sources and the structure is significantly different. I couldn't find any similar code to mixer_speed_lq() so it did it different way. Also found a minor problem with makefile.dos of current SBEMU version that it doesn't create required subdirectory structure in output dir, I had to mkdir it manually but maybe it's my problem of older Make or OS (WinXP).

Well I tried to revert changes in mixer_speed_lq() in current 1.0.0 beta 5 and it works for me too.
Please can somebody else try if this change didn't break playback speed on other soundcards?
Compiled binary here: http://rayer.g6.cz/download/download.htm#SBEMU_SBA_HOTFIX

RayeR wrote on 2025-01-24, 18:46:

Well I tried to revert changes in mixer_speed_lq() in current 1.0.0 beta 5 and it works for me too.
Please can somebody else try if this change didn't break playback speed on other soundcards?
Compiled binary here: http://rayer.g6.cz/download/download.htm#SBEMU_SBA_HOTFIX

It seems to be working properly with Realtek HD audio.