Test Results for 7 Sound Cards (Additional Sound Card Drivers do not seem to work)

[Torinde]

Hi I just tested 7 sound cards with SBEMU-X here are the results:
(Tested only with Quake)

• Sound Blaster Live 5.1 [SB0100] for reference:
  Works, no issues. Sound a bit on the low side; but same as SB-EMU

• CMI8738-PCI-6CH-LX, CMI-8738-PCI-6CH, CMI8738-PCI-SX
  Sound Card: CMI
  Real mode support: enabled
  Protected mode support: enabled
  OPL3 Emulation at port 388: enabled
  Crash
  Sometime followed after a few seconds by:
  JemmEx: Exception 0D or 06

• Sound Blaster 16 PCI
  Sound Card: ENS
  Real mode support: enabled
  Protected mode support: enabled
  OPL3 Emulation at port 388: enabled
  Crash

• ESS-Solo-1 [ES1938S]
  No Supported Sound Card Found

• AC97 [ULi Electronics Inc. M5455]
  No Supported Sound Card Found

Originally posted by @hjnijlunsing in sbemu-x#11

[crazii]

I updated a fix for CMI, please test if you can, thanks. @hjnijlunsing

[crazii]

Sound Blaster 16 PCI is also fixed.

I don't think SBEMU is needed for ESS Solo-1 since the card has good SB support.

[hjnijlunsing]

I tried the new version; findings:

• SBLive (Reference)

• Works with Doom (Also OPL) / Quake
• Lemmings (Crashed) - I believe this worked ealier, but not 100% sure

• SB 16:
  Sound Blaster 16 PCI
  Sound Card: Ensonic/SBPCI
  Real mode support: enabled
  Protected mode support: enabled
  OPL3 Emulation at port 388: enabled
  SB Pro Emulation at address 220, IRQ 7, DNA 1: enabled
  JemmEx: exception 06 occured at ( I have pictures on the details if needed)

• All 3 CMI Based cards:
  Sound Card: CMI 8338/8738
  Real mode support: enabled
  Protected mode support: enabled
  OPL3 Emulation at port 388: enabled
  SB Pro Emulation at address 220, IRQ 7, DNA 1: enabled
  JemmEx: exception 06 occured at ( I have pictures on the details if needed)

The errors are now happening always and the same (in the past; either crash without error; or error after few secs).

ESS Solo-1 Dos support is currently very much depending on Motherboard; thus with my ALI chipset it does not work as it does not support the TDMA/WDMA/PC-LINK. On my VIA chipset ESS Solo drivers do work.
Great thing with SBEMU is that it does not seem to be dependent on these motherboard features :)

[crazii]

OK, fair enough. There's driver for Solo-1, also Maestro/Allegro in ALSA, but it needs time to porting them.

I'll check the code to see what's wrong with the sbpci and CMI drivers.

[crazii]

I updated another fix, try the latest build, thanks.

[hjnijlunsing]

Same results as earlier (Tested SB16-PCI, 1 CMI Card and the reference SBLive).

Let me know in case you want me to enable debugging. I have spare pc's laying around which I can connect to the serial port if needed.

Also going forward it would be good to include the userbuild number in SBEMU as we are probably going to collect a lot of screen shots ;-)

Quick check; are you located in NL? If so I would be happy to send you a CMI card.
(Only reason I have them here is to play with SBEMU, apart from that I do not have a real use for them ;-) )

[crazii]

I appreciate your offer, but I have my retro rig with SBLINK+ymf724, and I might have a piece of CMI card or two, but I put them all up.
BTW I lives in Shanghai, China, a place doomed by some party and the GFW.

[crazii]

BTW can you perform a local build with your PC enabling the log in sc_es1731.c?
just uncomment the line //#define MPXPLAY_USE_DEBUGF 1 in line 18.

[hjnijlunsing]

Results:

[crazii]

Thanks to @jiyunomegami, now CMI driver works.
I also tried to fix ES1371 agian, you can confirm both changes.

[hjnijlunsing]

Just tested; my results are different.

Positive side: All crashes are resolved ;-)

Tests with Doom:

• Sound Blaster Live (reference) - Works OPL + Digital
• Sound Blaster 16 PCI - No sound (Music or Digital)
• CMI8738-PCI-SX - No sound (Music or Digital)
• CMI8738-PCI-6CH-LX - Music sounds fine, Digital is garbled & stuttering
• CMI-8738-PCI-6CH - Music sounds fine, Digital is garbled & stuttering
  (Let me know if an audio recording is helpful)

[crazii]

I think the CMI driver works, but the problem is the buffer is too long, the interrupt happens in too low frequency that the digital sounds will be delayed(SBEMU will fill new data on each interrupt). besides CMI/ES1371 cards have no "PERIODS", all other cards can divide the buffer into periods and issue an interrupt on each periods done, it's like double/multiple buffering that avoid sound buffer underrun.
I'll see to the ES1371 problems and try to improve the CMI buffering tomorrow.

[crazii]

I added experimental code for CMI, can you confirm the changes? thanks

[crazii]

What's the IRQ number used for your ES1371 card? is it below 7 (may be 5/7) or higher (9/10/11)?
It might be that the default setup uses 5/7 to get DOS compatibility, but it's not level triggered.

[crazii]

I forgot that VirtualBox has a SBPCI sound card, I can debug with it.
EDIT: not recognized, probably a ISA card. VMWare player has an SBPCI.

[jiyunomegami]

With the latest CMI driver, playing the Monkey Island intro, I get some buzzing (within the normal music), and then the system crashes after the intro ends and the game begins.

[jiyunomegami]

The sound is OK if you use card->dma_size -1 and card->period_size -1 in setrate:
snd_cmipci_write_16(card, CM_REG_CH0_FRAME2 , card->dma_size - 1);
snd_cmipci_write_16(card, CM_REG_CH0_FRAME2 + 2, card->period_size - 1);

[crazii]

Yes, that's an experimental piece of code - the CMI spec/datasheet says only "count" no mentioning -1, so I just wanna try it.
I just reverted it.

BTW it seems the ES1371 driver has no big problem, only the volume is too low, I adjusted the initial volume now it has sounds, code updated. or you may try the /VOL8 or VOL9 (no spaces, 9 is the maximum) to set volume.
But the digital sound seems delayed, noticeably in Duke3d menu "clicks", I don't know if it is a problem of VMWare player or real, so you may check the result.
The period of buffering is also added for ES1371.

We still got problem on CMI8738-PCI-SX, I'll check the code again.

[crazii]

Also going forward it would be good to include the userbuild number in SBEMU as we are probably going to collect a lot of screen shots ;-)

@volkertb could help with that.

[hjnijlunsing]

Very interesting results; two of my CMI cards are working as is the ES1371 now!

In fact... They are working better then my reference Sound Blaster Live which seems to have an audible back-tick with FX, not very disturbing, but the CMI and ES1371 do not have these issues.

Also tried the onboard VIA VT8233, this also seems to have some buffer issues. Thus kind of the same issues / sound issues as the CMI's were facing earlier. Is a similar fix a possibility? ;-)

(I can make sound recordings if required)

[crazii]

I believe I already did that for VT82xx, but there might be other problems.

EDIT: I've fix a bug on VT8237, which is the same chip of 8233, but I don't have a VT8233 PC, only a 8237 bought in order to fix that bug.

[crazii]

In fact... They are working better then my reference Sound Blaster Live which seems to have an audible back-tick with FX, not very disturbing, but the CMI and ES1371 do not have these issues.

The SBLive uses 4096 bytes buffer which may have the same problem, but I don't know if it is required by the spec or not, I cannot find the spec/datasheet for emu10k1, nor do I have a card to test, but you may change emu10k1.h:37
#define EMUPAGESIZE 4096 to 512 and try it out. and if it works, I think it'll be good news.

[hjnijlunsing]

Just tried changing it; unfortunately running SBEMU after the change just results in a lot of noise.

[crazii]

Then it's probably required by the spec, I remember a timer interrupt is used, you can tune the value of sc_sbliv.c:867
emu10k1_writefn0(card, TIMER, 0x240); //set timer rate to see what happens, it is not well documented, I believe it can be improved. maybe 0x3FF would be better?

[Torinde]

I cannot find the spec/datasheet for emu10k1

There are Live! drivers for Linux and other OSes (along with other materials at the linked issues) - in case that helps.

[crazii]

I cannot find the spec/datasheet for emu10k1

There are Live! drivers for Linux and other OSes (along with other materials at the linked issues) - in case that helps.

I remember checked multiple sources but they are all the same one, besides the special interrupt behavior for real time reaction might not be required/implemented by other code, that's a problem.

[volkertb]

Have you checked the SB Live! OSS driver sources yet? Those should really be different from the drivers in the mainline Linux kernel, since the OSS drivers are licensed differently, and have different people working on them.

Alternatively, the sound driver sources in the xBSDs should also be distinct from the Linux drivers, since the Linux driver sources are licensed under GPLv2 and also use the Linux-specific ALSA architecture/model, and the xBSD projects prefer to license their sources more liberally, and therefore can't just copy the Linux sources.

• FreeBSD emu10kx sources
• NetBSD emuxki sources
• OpenBSD emuxki sources, likely derived from the same sources as the NetBSD drivers
• OSS driver sources

[crazii]

I had a peek on OSS today, not to the emu10k1 source yet.

[volkertb]

Oh, and in addition to the above sources, you might also want to take a look at the open-source kX Project drivers, which are alternative Windows and macOS drivers for a number of sound cards, including the Sound Blaster Live!.

You can find their projects and sources at https://github.com/kxproject

I remember switching to kX audio drivers back in the day, when I was using Windows 2000 on a PC with a Sound Blaster Live!, because I was fed up with the buggy Creative drivers. I remember the kX drivers being rock-stable and flawless, unlike the official Creative drivers. 😅

Maybe those driver sources might provide some clues as well. 🙂

[hjnijlunsing]

The crash is back again (as can be observed from the character left-top)

[crazii]

Does it freezes? seems the upper left corner of screen have a character this time.
and I forgot the add "\n' to the log..
Also you can test it in games to see if things get any better, if it doesn't freeze.

[crazii]

OK, I removed the line that might cause the crash.
Also the white text is OK, it's just indicates that the log is output with interrupt disabled (i.e. in a interrupt handler or some code disables interrupt before outputting logs.)

[hjnijlunsing]

It froze, after the white text. (Everytime I get the character on left-top, the system freezes; this only happens on the SX, not on the 6ch). Debug output for both cards was the same.

[crazii]

Can you confirm it with the latest code, I removed one problematic line of code.
Does it still freeze?

Sorry I just fixed the typo of the log. updated.

[hjnijlunsing]

Still freezes

[hjnijlunsing]

Quick check. unsure if this means anything but when comparing the 'wrong' card with the 'right' card I can see differences
Right card:

• write mixer: 30, e0

Wrong card:

• write mixer: 30, c0

[crazii]

That's the default value of master volume, the difference is that one has one higher default volume, I think it doesn't matter.

BTW I removed the CDIN mixer for CMI, that's the last line after TSR.
Code, updated, hope it's OK this time.

[crazii]

There'll be more 33, 34 mixer reads&writes this time.

[hjnijlunsing]

Still freezes

[crazii]

The log shows no problem now.
I removed the logs and it should not freeze anymore. But I don't understand why it freezes. The log accesses the mixer register more than usual, so the mixers do have problems, even using SB16 mixer set - that's a new finding.

[crazii]

BTW you can uncomment the line 20 in sc_cmi.c: //#define MPXPLAY_USE_DEBUGF 1 to enable init message for CMI,
to check the chip version, it should be 37 for PCI-SX, but might not be 37, but 33 or 0.

[hjnijlunsing]

Tried the latest code; indeed the freeze disappeared.

Uncommenting the define results in:
CC output/mpxplay/au_cards/sc_cmi.o
In file included from mpxplay/au_cards/au_cards.h:4,
from mpxplay/au_cards/sc_cmi.c:23:
mpxplay/au_cards/sc_cmi.c: In function 'cmi8x38_chip_init':
mpxplay/au_cards/sc_cmi.c:537:70: error: expected ')' before 'cm'
537 | mpxplay_debugf(CMI_DEBUG_OUTPUT, "chip version: %d, multi_chan: %d" cm->chip_version, cm->can_multi_ch);
| ^~
mpxplay/au_cards/au_base.h:607:81: note: in definition of macro 'mpxplay_debugf'
607 | #define mpxplay_debugf(fp, format, ...) mpxplay_debug_f(fp, FILE, LINE, format, ## VA_ARGS)
| ^~~~~~
mpxplay/au_cards/au_base.h:607:56: note: to match this '('
607 | #define mpxplay_debugf(fp, format, ...) mpxplay_debug_f(fp, FILE, LINE, format, ## VA_ARGS)
| ^
mpxplay/au_cards/sc_cmi.c:537:2: note: in expansion of macro 'mpxplay_debugf'
537 | mpxplay_debugf(CMI_DEBUG_OUTPUT, "chip version: %d, multi_chan: %d" cm->chip_version, cm->can_multi_ch);
| ^~~~~~~~~~~~~~
make: *** [makefile:77: output/mpxplay/au_cards/sc_cmi.o] Error 1

[crazii]

Fixed. I think you can try if it works (although I highly doubt it works), also, the chip version from log may help.

[hjnijlunsing]

Chip correctly identified as 37, but no sound

[crazii]

OK, I think the problem is the mixer, it freezes when log read more times from it. but the underlying reason still needs to be found.
It's already 12:00 AM and I'll head to bed.
I really thank you for your patience. :)

Slow progress but at least we get some more information.

[hjnijlunsing]

No problem, to me the hobby is getting it to work. Not so much the end result ;-)
Tomorrow I'll have less time to test; but Tuesday should be fine.

[crazii]

OK, guess we have the same hobby. :)

[hjnijlunsing]

Meanwhile I tested the official dos drivers; they crash with all my 3 cards.
However when disabling digital and only doing OPL, my 2 cards (6ch) works and the SX cards is completely silent.

Looking at the internet, it seems the SX card actually is known for this behavior: https://www.youtube.com/watch?v=dkanu26cKtk&t=1624s (Not sure if you can watch this, but this guy is using the stock drivers for SX and is facing exactly the same issue).

Thus the bright side is at least that SBEMU is already outperforming the CMI stock driver.

[crazii]

You may need check there's no JEMMEX installed, and choose HIMEM.SYS to gain max compatibility for the DOS drivers.

Also, the official dos driver may use legacy SB feature for the card, but SBEMU doesn't. So the question will be, whether the Windows/Linux drivers work for those card (even without any dos compatibility in windows)? if they work, then SBEMU should work too. The point is SBEMU works as a pure PCI sound card driver internally.

[crazii]

I found 2 CMI cards in my stock, one is CMI8738/PCI-6ch-MX, and the other is CMI8738/PCI-SX
I remember that on vongons there's talks about the chip number (some of them don't have FM chip but wavetable), I don't know if it's exactly the same as yours. If it is, then I can debug with it.

BTW I never tested those CMI cards, I just putem up after bought them, about several years ago, so they might not work.

[hjnijlunsing]

I have the infamous 037D chipset, which indeed does not have an FM Chip.
Tomorrow (today I am not at home); I will check in another computer if it works with Windows, I'll plug it in an ESX server with PCI passthrough and see what the results are ;-)

I also did not test my cards before SBEMU; I got the pack of 4 cards cheap for around 20 euro's total.

[hjnijlunsing]

Ok, I am giving up on the PCI-SX card; I tried the following:

• Created an ESXi virtual machine with PCI passthrough using the 6CH-LX running Linux Mint --> Sound Working

• Swapped it for the PCI-SX --> Entire ESX server crashed trying to produce sound when booting

• Reran the experiment; with same results

• Used the 6CH-LX in an Windows 98 machine (on different hardware) using Phil's Drivers --> After some Windows 98 crashes; random boots it started working with sound

• Swapped it for the PCI-SX --> Windows 98 fails to boot

• Reran the experiment; with same results

Either it's a horrible, horrible card. Or it is defective.
I am curious though if you can get your 037C chipset to work.

I'm sorry if this (possible) defective caused any unnecessary changes/code on your part;

Update:
Tried; on the bare metal with Linux Mint; system doesn't crash. But no sound either.
dmesg entry:
[278.xxxxxx]: NMI: PCI System error (SERR) for reason a1 on CPU 0
[278.xxxxxx] Dazed and confused, but trying to continue

Update 2:
Also tried Windows XP with both WDM and Non-WDM drivers.
No crash, card detected, but also no sound

--> It's going to the garbage

[crazii]

It's OK. I wanted it work as you do.

I've made the PCI SX of mine working, no big changes but it suddenly worked even when I reverted the changes. I'm confused and then hard reset the PC by power off and on, and it stopped working again, with some noises.

I dump the registers and found they read back -1 occasionally and the interrupt status is wrong without the summery bit - it might have hw defection or just broken old. it still produces noise after I fixed them.

Then I just rolled a bit of the audio plug...and the noise is gone and sound is working.😂
Half a day is wasted on this stupid problem.

I'll update the code later, Incase it works for you too, also plz make sure the audio cable is plugged into “front speaker” jack and is connected well.

[crazii]

I pushed code now you can test it.
If it doesn't work for your card, I'm afraid we'll have to leave it for now :).

[hjnijlunsing]

Tested it, but no sound. I guess the card is toast.
I did check one thing though: I ran the CMI Mixer prior to running SBEMU and the output was 2-speaker with Master Volume 15
After running SBEMU the output of CMI Mixer was set to 4 speaker mode with master volume 12.
But manually switching it back did not make any difference.

Moving on ;-)

[crazii]

Yes the driver always use 4 speaker as Linux driver does, there is a flag N4SPK or something is set that copy front speaker data to rear. But I never tested the rear output.

[crazii]

BTW I just tested with this "YMH 724B-V" https://www.vogons.org/viewtopic.php?p=1025196#p1025196 , which also has the chip version 37 (CMI faked as an YMF XG),
and it worked as well.

So I have 3 CMI cards actually, except that the last one is a fake YMF (I thought it was YMF when I bought it) and I don't like it very much. :)

[crazii]

I remember that there's talks about 8338 not working, also /T5 with divide by zero problem, but I cannot find it LOL, can you help me find it? I added some fix that might cause /0 error, but maybe not all of them.

[hjnijlunsing]

Yes; it was in this same thread @vicokoby mentioned he had issues with Hocus Pucus

I tested sbemu UserBuild_2024.01.14_13-29 with my M748MR Rev:1.3 motherboard, which has an integrated HT8338A/PCI chip (CMI8338), the sound card is correctly recognized, both real and protected mode, and OPL3 emulation are enabled, so I ran Hocus Pocus, the game has sound but unfortunately it starts very slowly and ends up crashing completely, I also want to add that this does not happen with my SB0100. (@vicokoby)

Then I tested:

Just tested Hocus Pocus on my CMI-8738-PCI-6CH, which worked (Don't have an 8338)
Check questions:
Which version of Hocus Pocus are you running? (1.0 or 1.1) - I used shareware 1.1 from:
https://legacy.3drealms.com/hocus/index.html
Which type of Sound Blaster did you specify? With T5 I got a division by zero with T3 it worked

Reply: (From @vicokoby)

I'm using Hocus Pocus 1.1 Registered Version, specifying T4.
Later I tried T3 and it is true that it works better but it continues to work very slowly although it does not crash.
With T5 divide by zero just like you.

Some more debugging questions:

Another check:
Did you try only OPL or only Digital?
Does Doom work?
Is the sound also slow? (Thus wrong sample rate); or only the game itself?
If so is only the music slow, or also fx or both?
Did you try other sample rates in SBEMU? (/K)

Reply: (@vicokoby )

I only tried with OPL enabled
Doom works using a sample rate of 22050, with 44100 it does not work
The sound is quite fluid in Doom
Hocus Pocus runs faster with music disabled and only FX enabled
Using the 22050 sample rate, Hocus Pocus's performance is much better than the 44100 I was using before, although the game still feels slightly slow

I'll check if the division by zero is fixed by the latest build (Personally I can't reproduce the performance issue, but perhaps the above results will help with that)

Update:
Tested the latest build; specifying T5 results in DIVIDE ERROR. T3 works.