crazii / SBEMU

legacy sound blaster emulation for DOS
GNU General Public License v2.0
597 stars 32 forks source link

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

Open Torinde opened 8 months ago

Torinde commented 8 months ago

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

Originally posted by @hjnijlunsing in https://github.com/sbemu-x/sbemu-x/issues/11

crazii commented 7 months ago

You can comment out the line 834 at sc_cmi.c: _LOG("buffpos:%u\n", bufpos); and it should behave as before (not working, no crahses). I push the changes later.

crazii commented 7 months ago

Just another update, I added logs to the mixer reads/writes, and removed the SBPro mixer used by CMI as SB16 mixer, as previous test shows that access to SBPro mixer may cause problems. And it won't print much messages this time. only the write mixer: read mixer: are newly added to check if the addresses/values are set properly.

hjnijlunsing commented 7 months ago

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

image

crazii commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

Still freezes image

hjnijlunsing commented 7 months ago

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

Wrong card:

crazii commented 7 months ago

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 commented 7 months ago

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

hjnijlunsing commented 7 months ago

Still freezes

image

crazii commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

hjnijlunsing commented 7 months ago

Chip correctly identified as 37, but no sound

image

crazii commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

OK, guess we have the same hobby. :)

hjnijlunsing commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

DSC_0459 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 commented 7 months ago

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 commented 7 months ago

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

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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.