Possible VT8235 PCM playback instability at 22050/44100 Hz in SBEMU beta5

[Yacko83]

Hello crazii,

while testing SBEMU beta3, beta4 and beta5 extensively on my VIA VT8235 system, I noticed a very interesting and consistent behavior regarding PCM playback stability and sample rates.

SBEMU beta3:

• has stable PCM playback when running at its maximum supported sample rate (44100 Hz),
• but many games/music tracks play at an incorrect/lower pitch.

SBEMU beta4 and beta5:

• fix the playback pitch problem completely,
• and music now matches real Sound Blaster recordings much more closely,
• however, both versions introduce PCM playback instability at lower sample rates.

On my hardware, using lower sample rates such as:

• /K22050
  or
• /K44100 (on beta4/beta5)

may produce:

• choppy/interrupted sound effects,
• missing tails/endings of PCM samples,
• and occasional clipping/cutoff artifacts.

However, after extensive testing, I discovered something very important:

On SBEMU beta3, the PCM instability disappears almost completely when using its highest supported sample rate:

• /K44100

Meanwhile, on SBEMU beta4 and beta5, the instability improves dramatically starting at:

• /K48000

I also confirmed that beta4 and beta5 support even higher sample rates (I tested values up to 192000 Hz successfully), although I personally do not need to use rates that high.

I also tested:
/FIXTC1

but this did not solve the issue on my VT8235 system.

At this point, it seems possible that VIA VT8235 playback stability somehow improves whenever the emulator operates at higher internal/output sample rates.

Because of this, I now suspect the issue may be related more to VIA timing/resampling/buffer behavior itself rather than a simple regression introduced in beta5.

Of course, I cannot confirm whether this behavior is specific only to my VT8235 system or possibly affects other VIA chipsets as well, but I thought the correlation was interesting enough to mention.

So from my testing, it currently seems that:

• beta3 has stable PCM playback but incorrect playback pitch,
• beta4/beta5 fix the pitch/timing issue,
• and all emulator versions appear to behave much better once higher sample rates are used.

Hopefully this information may still help narrow down the remaining VIA timing/PCM behavior differences.

Overall, beta5 already sounds extremely close to perfect on this hardware aside from this remaining sample rate behavior.

Thank you again for all the effort put into SBEMU and DOS audio preservation on these systems.

[crazii]

Thank you very much for your detailed tests, that wil help a lot.
I will try to further narrow down the code that cause the problem.

[Yacko83]

Hello @crazii,

thank you again for reading the report and for investigating this issue.

And thank you for all the work you are doing on SBEMU — projects like this are incredibly valuable for preserving DOS game audio and compatibility on later hardware.

While reviewing my previous message, I realized there are a few additional details that may be relevant.

One important thing I forgot to mention is that on my VIA VT8235 system:

• SBEMU beta3 identifies the chipset specifically as "VT8233",
• while beta4/beta5 identify it more generically as "VT82XX".

I do not know whether this matters or not, but perhaps chipset detection/initialization changed between versions.

Also, regarding sample rates:

• beta3 supports 22050 and 44100 Hz, but not 48000 Hz,
• while beta4/beta5 no longer accept 22050 Hz and start at 44100 Hz+, including 48000 Hz and higher.

In both cases, increasing the sample rate improves PCM stability noticeably, but I do not think the actual frequency itself is the real issue.

It feels more like a timing/buffer/resampling synchronization problem underneath.

For example:

• on beta3, moving from 22050 -> 44100 improves the issue significantly,
• while on beta4/beta5, moving from 44100 -> 48000 improves it again.

The easiest way to hear the problem is probably in Doom or Hexen:

• menu navigation sounds already expose it clearly,
• and Hexen MAP01 makes it extremely obvious because of the thunder ambience and many simultaneous PCM sounds.

There, the PCM playback becomes chopped/distorted with clipped sample endings and obvious desynchronization artifacts.

One reason I noticed the pitch issue so quickly is because I am a musician and tend to notice tuning/pitch differences by ear very easily. Beta4/beta5 definitely improved playback pitch accuracy considerably compared to beta3, so something in the newer timing/synchronization logic is clearly closer to real hardware behavior.

Also, if it helps, feel free to count on me for additional VIA testing in the future.

I have a real early-2000s VIA-based machine (one of those systems where ISA cards are no longer practical), so it has been very useful for testing SBEMU specifically.

If you do not currently have access to VIA hardware and ever need somebody to test preliminary builds or experimental changes, I would be happy to help and provide detailed feedback.

Thanks again for all your work on this project.

[crazii]

Thank you very much for your analysis.

Sorry that I was off for long and didn't remember any changes, but the commit history should be checked and tested. It might also be a performance issue that break the timing.
I will investigate it when I have another spare time, probably soon.

[Yacko83]

Hello @crazii,

no problem at all, and thank you again for taking the report seriously and looking into it.

I really think this may end up being an important improvement not only for the VT8235, but probably for VIA compatibility in general, so I’m sure many users will benefit from it even if they did not consciously notice the issue before.

And honestly, beta5 already sound remarkably close to real hardware overall aside from this remaining PCM behavior.

Good luck with the investigation, and thanks again for all the work on SBEMU.

And of course, if you ever need somebody to quickly test something on a real VT8235 machine, feel free to contact me anytime. I’d be happy to help.

[crazii]

Can you test this one?
I've made some changes related to the playback position.
sbemu.zip

If it does not work, can you provide a name of program or game that have most obvious of this problem? I may need to debug in on a real machine.

[Yacko83]

Hello @crazii,

thank you very much for taking the time to prepare another test build.

Unfortunately, after testing it extensively on my VT8235 machine, the PCM issue still remains almost exactly the same as in beta4/beta5. I could not notice any meaningful improvement yet.

The problem does not seem tied to one specific game or program. It is more like a general PCM playback/timing problem affecting most sound effects to different degrees.

The best way I can describe it is:

• chopped/interrupted PCM playback,
• overlapping or “echo-like” fragments,
• distorted/clipped sample endings,
• and general desynchronization of sound effects.

It really feels like some kind of timing/buffer/playback-position issue underneath.

Some games expose it very clearly though:

• Doom menu navigation sounds are an easy example,
• and Wolfenstein 3D door sounds also reveal it immediately.

The PCM effects sound broken/desynced rather than simply delayed.

What still makes me strongly suspect this is not a hardware fault on my system is the fact that beta3 behaves VERY differently:

• beta3 playback is much more stable on this same machine,
• the PCM corruption there is very minor and mostly negligible,
• but beta3 still had the incorrect music pitch/timing issue.

Meanwhile beta4/beta5/beta6 clearly fixed the pitch accuracy significantly, but at the cost of much worse PCM stability on this VIA chipset.

Interestingly, the same incorrect pitch behavior also existed in VSBHDA previously, and its developer later corrected it as well. So I suspect some important timing-related change happened between SBEMU beta3 and beta4 that fixed pitch synchronization but also introduced this new PCM instability on VIA systems.

Regarding configuration:

• I use your provided JEMMEX memory manager globally during DOS 6.22 boot,
• including testing with the newer JEMMEX version as well,
• while SBEMU itself is launched manually through batch files rather than loaded globally.

I do this mainly because I frequently compare multiple SBEMU/VSBHDA versions and it keeps testing cleaner and easier to isolate.

So overall, I still have fairly high confidence the issue is not simply caused by my DOS setup itself, because beta3 remains comparatively stable on the exact same machine/configuration.

Hopefully this additional information helps narrow it down further.

Also, yesterday while searching for newer drivers/documentation for this motherboard, I happened to find an official VIA VT8235 and VT1612 audio codec datasheet/reference documents.

I do not really understand the low-level details in it myself, but I thought I should mention it just in case it may be useful.

So if you think it could help, I can send/upload it for you.

[crazii]

Also, yesterday while searching for newer drivers/documentation for this motherboard, I happened to find an official VIA VT8235 and VT1612 audio codec datasheet/reference documents.

Thank you but I have that datasheet too, used for modifying the VIA sound driver code.

I took the HP T5530 (with a VT8237 audio chip that was tested with SBEMU) from my storage, and I will test wolf3d/doom this weekend.
I will also double check the difference between 8235&8237 and find the problem.
BTW, what's the CPU/machine you used with you VT8235?
I also have a T5710 , I will find which matches better for the test.
EDIT: I forgot that my T5710 has a VT82C686 which has its own HW SB emulation.

[Yacko83]

Hello @crazii,

yes, exactly — Doom and Wolf3D are probably the fastest/easiest way to notice the problem.

In Doom, simply moving through the menus already exposes it clearly, while in Wolf3D the door sound effects make it very obvious as well.

Another very good test case is Hexen MAP01:
the thunder ambience and many simultaneous sound effects make the desynchronization extremely noticeable there. It almost feels like the playback buffer is overflowing/underrunning or losing synchronization somehow.

Even in simpler/lighter games (for example platform-style games like Jungle Book), the audio generally behaves better overall, but sound effects still tend to sound slightly saturated, clipped or distorted at times.

So it feels like there is some underlying/global playback issue affecting all sound effects playback to some degree, while games like Doom, Wolf3D and Hexen simply expose it much more aggressively.

I also tried simplifying the system configuration as much as possible (minimal devices connected, different USB keyboards, different RAM configurations, etc.) but the behavior remained consistent.

My current test machine is:

Motherboard: PCChips M825 v7.2A
Chipset: VIA KM266 + VT8235 southbridge
CPU: Athlon XP 1900+
RAM: 384 MB DDR333 (32 MB shared with integrated ProSavage graphics)
Storage: 30 GB IDE HDD
Audio: onboard VIA AC97 / VT1612 codec
OS: MS-DOS 6.22

Hopefully this helps reproduce it more easily on your side.

And thank you again for taking the time to investigate this — I have a feeling many VIA users will ultimately benefit from it as well 👌

[crazii]

I've tested with my HP T5530, the VT8237 have the same problem.
it is a timing issue, the sound interrupt rate is slow and falls behind doom's timer interrupt which reads and feeds dma. a low interrupt rate causes virtual DMA position not updated in time.
Changing sample rate will increase the interrupt rate, because the size of sound buffer is fixed. fixed number of samples with high samplerate uses shorter playback time, firing interrupts at higher rate.

It is a known problem of the fixed sound buffer size, I used to test it with 1024 bytes and doom has problem playing sound, so I changed it to 512 and it seemed "OK" to me, but actually not. I forgot those details but remember them in today's testing.

the 512 bytes is now changed to 384. changing to 256 causes slight noise I don't know why, probably there are still bugs in the floating-point free resample code I added to mpxplay.
EDIT: 256bytes also works.

There might still be noises , I seemed to hear noises on "Ahhh" scream on doom exit, but not heard on later runs.

the zip contains a fixed binary

sbemu.zip

[Yacko83]

Hello @crazii, 👋

first of all, thank you very much for taking the report seriously and investigating it so quickly.

The improvement with this new binary is honestly a huge change — almost day and night compared to before. The major PCM timing/desynchronization problem is now dramatically improved on my VT8235 system.

The annoying corruption in Doom menu sound effects is mostly gone now, and Hexen also behaves much better overall.

That said, I still noticed a few remaining issues that may help narrow down the last bits that still need adjustment.

For example, in Doom:

• if I move very quickly through the menu options, I can still occasionally hear small clicks/clips or slight overlapping artifacts between sound effects,
• much subtler than before, but still present.

Also, while testing Doom MAP02, I noticed some FM music inconsistencies:
at certain moments some instruments temporarily disappeared, and at another point the music briefly cut out before recovering normally.

So now it almost feels like the PCM side is much healthier, but after the latest timing/buffer adjustments I started noticing some new FM playback inconsistencies that I do not remember hearing on previous builds.

Another very useful test case seems to be Heretic.

During the intro/presentation music, the FM audio sounds noticeably distorted/glitched on SBEMU. Interestingly, this specific issue does not happen on VSBHDA on my system.

And in-game, Heretic sometimes shows:

• temporary FM dropouts,
• brief distortion/saturation,
• or moments where the music seems to partially “break” before recovering.

I think Heretic may be exposing some remaining VIA timing/calibration issue particularly well, because the behavior is very easy to notice there.

I also tested Jungle Book:
sound effects are MUCH better now, but during testing the game crashed once and forced me to reboot the machine. I do not remember seeing that behavior on previous betas, although I cannot say with absolute certainty yet.

Two additional VIA-related observations that may also be useful:

• In Hocus Pocus, FM quality itself sounds good, but the playback speed/timing behaves erratically under SBEMU. The music speeds up and slows down inconsistently. VSBHDA also plays it slightly slower than real hardware on my machine, but there the timing stays much steadier overall.

• Wacky Wheels still crashes immediately on startup under SBEMU on my VIA system (this was already happening before this binary). Interestingly, it works correctly under VSBHDA.

I thought it was worth mentioning these cases because perhaps they are all related to the same underlying timing/synchronization behavior, and maybe adjusting one remaining part of the VIA handling could improve several of them at once.

But overall, this new binary is already a very major improvement compared to the previous behavior on VT8235.

[crazii]

• if I move very quickly through the menu options, I can still occasionally hear small clicks/clips or slight overlapping artifacts between sound effects,

Don't worry about this one, I committed the change with buffer size not 384 but 256, as I tested it is OK.

For any performance/freeze/hang problems, I recommend tests with the new VDPMI that I was focus on.
because my fork of HDPMI was a clumsy fork and not up to date, there is no guarantee that SBEMU can work the same as VSBHDA. and I am not quite good at assembly, so now a new DPMI server is made to support both 16 bit (tyrian and jazz etc.) and 32 bit clients at the same time , with additional v86 monitor (an EMM in its early dev stage).

You can test this zip and check if those problem still exist:

https://www.vogons.org/viewtopic.php?p=1424330#p1424330

VDPMI is loaded in CONFIG.SYS and you can check the example in the zip.

For current main dev branch, only sound problem will be fixed, because I my focus will be on the new sbemu+vdpmi build.

[Yacko83]

Hi @crazii 🙂

First of all, thank you again for all the recent work on the new SBEMU + VDPMI direction.
After extensive testing, I honestly think this is a very promising path and already a major improvement in several important areas.

Some things are now working significantly better than before:

• Hocus Pocus finally plays at the correct music speed and stays stable during gameplay.
  This is the first time I have heard it behave properly on this VT8235 machine.

• Wacky Wheels no longer hard-locks the entire machine like before.
  With /EMS, the game starts but audio breaks into a continuous corrupted noise.
  With /EMSX, the game runs without music and sound FX but remains playable and stable.

• Trolls (Magic Trolls) is also much improved.
  Previously music and sound FX disappeared after the intro/title screen, but now both continue working correctly during the title screen and gameplay.

• Hexen is also noticeably better now, especially the thunder/ambient PCM effects.

• Jungle Book no longer crashes and is generally much more stable.
  However, the snake choking/swallow sound effect after hitting it with bananas now seems to be missing most of the time.

So overall, the new memory/DPMI approach definitely seems to be moving in the correct direction.

However, I still found several remaining issues that may help narrow down the last timing/sound problems:

• Doom:
  PCM artifacts are much smaller now, but if moving very rapidly through the menu, I can still hear small residual clicks/overlapping artifacts.

  Also, on MAP02, FM music sometimes temporarily loses instruments or briefly cuts out before recovering.

• Heretic:
  still exposes the problem very clearly.

  If you stay on the first level and let the music continue playing for a while, there is a specific moment where the FM audio heavily distorts/almost crashes before recovering again.

  It happens consistently at the same point in the music.

• Duke Nukem 3D:
  audio became significantly worse with the new VDPMI branch.
  Heavy distortion/corruption appears regardless of EMS/EMSX mode.

• Vinyl Goddess From Mars:
  game starts correctly but hard-locks when navigating menu options.

• Lost Vikings intro:
  music occasionally disappears briefly and then returns.

• Prehistorik 2:
  gameplay music and sound FX quality itself sounds fairly accurate, but timing/performance still feels unstable overall.

One additional thing I consistently notice across many games is that PCM / sound FX effects still feel unusually “harsh” or overly aggressive compared to real hardware.

Not exactly clipping in the traditional sense, but more like:

• overly sharp/granular transients,
• very strong attack,
• slightly distorted/saturated texture on effects like shots, screams, pickups, etc.

It almost feels like the PCM mixer/output level or playback handling may still be somewhat too aggressive under VIA, similar to the behavior already present in the regular SBEMU builds.

One more detail:
after booting into any SBEMU/VDPMI configuration, Ctrl+Alt+Del no longer works correctly on my system.
Instead of rebooting normally, the machine shows halt/system state messages and requires a manual reset.

Still, overall this is already a huge step forward compared to the older builds, especially regarding timing consistency and game compatibility on VIA.

Thanks again for continuing to investigate this 👍

[crazii]

Thank you for your detailed feedback again,

I will take a quick look into these problem.

One more detail:
after booting into any SBEMU/VDPMI configuration, Ctrl+Alt+Del no longer works correctly on my system.
Instead of rebooting normally, the machine shows halt/system state messages and requires a manual reset.

Can you post the messages, is it VDPMI related?

FYI there are still some architectural adjustments in the furture, a new vxd build of sbemu is planned to support win9x, so even those problems are fixed now, they may reappear later. the plan is do a deliberate fix for them later, after the adjustments. please be patient, but don't worry I will check those problem soon and fix them if it is easy.

One additional thing I consistently notice across many games is that PCM / sound FX effects still feel unusually “harsh” or overly aggressive compared to real hardware.

Not exactly clipping in the traditional sense, but more like:

• overly sharp/granular transients,
• very strong attack,
• slightly distorted/saturated texture on effects like shots, screams, pickups, etc.

It almost feels like the PCM mixer/output level or playback handling may still be somewhat too aggressive under VIA, similar to the behavior already present in the regular SBEMU builds.

That I'm not familiar with, actually I don't know much about those sound knowledge, I just learned while coding, and quickly forgot them all. LOL. There are 2 that I can recall, that might be related to the issue, after recent reading of my previous code:

• The 'mixer_speed_lq' function I added to mpxplay is very simple, it is a resample (usually upsampling) function using 16 bit integer linear interpolation with a fixed point factor. the poorest quality but fastest. and the implementation may have problem. google told me that advanced filters are needed, e.g. 11025 to 48000 or higher needs more complicated methods. but I doubt the real time performance of that. there are also some resample library but they probably using float points and may not suit the real time needs. I can try to set the input sample rate to DAC using the games settings (/K=dynamic sample rate set by game to SB) and let the DAC to perform that conversion, but it is never tested, and some chips may not support it or arbitrary rate, and still needs manual resample. the VIA chips support that.
• The OPL emulation generated PCM is amplified (amplitude x 2). I did that because someone said the music volume is small compared to sound FX.

[crazii]

Btw the OPL emulation came from DOSBox, it's fast but not 100% precise, there is a nukedOPL emu lib that is more precise, but I don't think it's suitable to put in a hardware interrupt handling which requires fast process.

[Yacko83]

Hi @crazii 🙂

Thank you again for the very detailed explanation.
It was actually very interesting to read and helped me understand much better what is happening internally.

Regarding the Ctrl+Alt+Del issue: yes, I am almost certain it is related to the new VDPMI environment/build.

I never experienced this behavior with the previous regular SBEMU builds. It only started appearing after moving to the new VDPMI-based branch.

Unfortunately the system halts before I can fully read the message properly, but usually I can briefly see messages like:

• System Halt
• or System Halt followed by random numbers/characters.

The text itself often appears partially corrupted or incomplete before the machine becomes unresponsive, so I unfortunately cannot capture the exact full message yet.

It almost feels like the reboot interrupt/state transition itself is getting corrupted or interrupted somehow during the Ctrl+Alt+Del sequence.

Also, thank you for continuing to push this project forward.
Honestly, the future plans sound extremely promising.

The planned Win9x VxD support sounds incredible already — that would honestly be something very special for retro PC audio compatibility/history 🙂

And the idea of letting the VIA DAC itself handle the sample-rate conversion also sounds fantastic.
That honestly feels like the closest possible approach to real hardware behavior.

If you ever need additional testers for any of those experiments/projects, feel free to count on me.

The machine I mentioned earlier currently has both:

• native DOS 6.22
• and Windows 98 SE

So I would be very happy to help test:

• future VDPMI/SBEMU builds,
• Win9x driver/VxD experiments,
• or the DAC-driven sample-rate conversion idea.

And no worries — I am patient 👍
I mainly report these things simply because I enjoy helping improve the emulator and documenting VIA behavior as accurately as possible.

By the way, for future reports/testing results, what would you prefer?
Should I continue reporting here, on Vogons, or somewhere else instead?