I found out the cause of my problem, I was missing P330 in the BLASTER variable, sorry for the false alarm.
Thanks again for the update.

Nemo1985 wrote on 2025-02-01, 16:04:

Confirmed, I reduced the clock from 3.06 to 2.30 (fsb from 133 to 100) and it works. What doesn't work it the converted sf2 to s […]
Show full quote

Cacodemon345 wrote on 2025-02-01, 15:54:

Nemo1985 wrote on 2025-02-01, 15:26:

Disable the soundfont did the trick. For further testing I don't know how to disable the mpu-401 emulation, do I need to use a specific switch?

You need not test any further. This looks like a speed issue.

Confirmed, I reduced the clock from 3.06 to 2.30 (fsb from 133 to 100) and it works. What doesn't work it the converted sf2 to sf3. If I load the sf2 everything works fine, if I load the sf3 there are audio issue (I'm going to load a video).
SF2: https://youtu.be/eXm2CMTZuGw
SF3: https://youtu.be/LofcIMGDLDw
I used sf2convert-1.2.2-win so I don't know if it's a program issue or the sf3 implementation. I also tried another sf3 converted file but the result is the same the only output is a swish noise.
Edit: I used Polyphone 2.5.1 to convert the sf2 file to sf3, the sound is still broken but the pattern is different, like less broken the music is distorted but more familiar.

Pretty sad to see this finding out why support for SF3 (OGG Vorbis variant) had been taken off. I've been curious how much would one single SF2 of gigs of wavetable get reduced once converted into SF3. It's for simply one reason that I came to see the requirement of 128MB XMS memory, which I'm not sure if it is enough for such an enormous SF2.

Limitations on the SF3 format still exist, though, like there's no way to just replace OGG compressed samples into any SF3 and save it as another SF3 (in Polyphone at least). And I'm not sure whether the CPU is yet capable enough to process so many OGG samples at a time. I simply just isn't sure, however, if my Core 2 Duo laptop with 4GB RAM and ALC262 is capable of processing such enormous SF2, which I'll be trying sometime.

p.s. SF3 banks from sf2convert 1.2.2 cannot even get opened within Polyphone, unlike the SF3s from Polyphone itself, which I was confused as I just tried last night. Also, these SF3s, both from sf2convert and Polyphone, seem to have the resulted-in OGG samples so much larger than those from some cmd OGG encoder I've been using, under the same quality preset.

Upstream VSBHDA with v1.7 has backported the soundfont support from VSBHDASF. As such, I think VSBHDASF has mostly served its purpose.

Maybe VSBHDASF will see a 2.0 release if I'm able to add support for more open-source software synths beyond TinySoundFont, but I don't think there will be any further releases.

Cacodemon345 wrote on 2025-08-11, 09:11:

Upstream VSBHDA with v1.7 has backported the soundfont support from VSBHDASF. As such, I think VSBHDASF has mostly served its purpose.

Maybe VSBHDASF will see a 2.0 release if I'm able to add support for more open-source software synths beyond TinySoundFont, but I don't think there will be any further releases.

Thanks for your contribution, Cacodemon345! It's a shame you couldn't get Munt to work for MT-32 compatibility. But as you explained, bridging VSBHDA's C code with Munt's C++ code proved problematic.

What I think would also be a really cool feature is if SoftMPU's functionality could be integrated into VSBHDA or VSBHDASF, allowing people to hook up a MIDI device to a serial port, using something like Dreamblaster's MPU-232 adapter, and having support for MPU-401 compatible MIDI devices in both real mode and protected mode DOS games, even on newer PCs. This way, it would allow actual MT-32 modules or something like an MT32-Pi to work in such as setup as well as whatever physical MIDI devices people would like to play with.

Yes, I know, that would better be discussed in a dedicated thread. 🙂

digger wrote on 2025-08-12, 17:20:

Thanks for your contribution, Cacodemon345! It's a shame you couldn't get Munt to work for MT-32 compatibility. But as you expla […]
Show full quote

Cacodemon345 wrote on 2025-08-11, 09:11:

Upstream VSBHDA with v1.7 has backported the soundfont support from VSBHDASF. As such, I think VSBHDASF has mostly served its purpose.

Maybe VSBHDASF will see a 2.0 release if I'm able to add support for more open-source software synths beyond TinySoundFont, but I don't think there will be any further releases.

Thanks for your contribution, Cacodemon345! It's a shame you couldn't get Munt to work for MT-32 compatibility. But as you explained, bridging VSBHDA's C code with Munt's C++ code proved problematic.

What I think would also be a really cool feature is if SoftMPU's functionality could be integrated into VSBHDA or VSBHDASF, allowing people to hook up a MIDI device to a serial port, using something like Dreamblaster's MPU-232 adapter, and having support for MPU-401 compatible MIDI devices in both real mode and protected mode DOS games, even on newer PCs. This way, it would allow actual MT-32 modules or something like an MT32-Pi to work in such as setup as well as whatever physical MIDI devices people would like to play with.

Yes, I know, that would better be discussed in a dedicated thread. 🙂

I tried it on 5 different machines. SBEmu/VSBHDASF is the best as it is, they work perfectly.