search

crazii / SBEMU

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

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

Open Torinde opened 7 months ago

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

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

crazii commented 6 months ago

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

I tried the new version; findings:

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

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

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

hjnijlunsing commented 6 months ago

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. sbemu

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

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

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

Results: sbemu

crazii commented 6 months ago

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

hjnijlunsing commented 6 months ago

Just tested; my results are different.

Positive side: All crashes are resolved ;-)

Tests with Doom:

crazii commented 6 months ago

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

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

crazii commented 6 months ago

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

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

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

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

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

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

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

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

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

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

crazii commented 6 months ago

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

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

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

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.

crazii commented 6 months ago

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

volkertb commented 6 months ago

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. :sweat_smile:

Maybe those driver sources might provide some clues as well. :slightly_smiling_face:

hjnijlunsing commented 6 months ago

Setting it to 0x3FF definitely made it worse.

Also I am getting warning (unrelated) currently when compiling:

CC output/mpxplay/au_cards/sc_inthd.o mpxplay/au_cards/sc_inthd.c: In function 'snd_ihd_mixer_init': mpxplay/au_cards/sc_inthd.c:937:3: warning: implicit declaration of function 'delay' [-Wimplicit-function-declaration] 937 | delay(10); | ^~~~~

hjnijlunsing commented 6 months ago

Ok, seems the issue is solved; I changed it to the TIMER_RATE as defined in the .h file:

define TIMER_RATE 0x0a00001a

Now SBLive seems to be working the same as SB16PCI and the CMI cards ;-)

hjnijlunsing commented 6 months ago

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.

Unfortunately still the same issue (fx corruption) occurs on the 8233

crazii commented 6 months ago

Ok, seems the issue is solved; I changed it to the TIMER_RATE as defined in the .h file: #define TIMER_RATE 0x0a00001a Now SBLive seems to be working the same as SB16PCI and the CMI cards ;-)

Glad to hear that, I will update the code 😃

crazii commented 6 months ago

Setting it to 0x3FF definitely made it worse.

Also I am getting warning (unrelated) currently when compiling:

CC output/mpxplay/au_cards/sc_inthd.o mpxplay/au_cards/sc_inthd.c: In function 'snd_ihd_mixer_init': mpxplay/au_cards/sc_inthd.c:937:3: warning: implicit declaration of function 'delay' [-Wimplicit-function-declaration] 937 | delay(10); | ^~~~~

It'll be fixed

vicokoby commented 6 months ago

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.

hjnijlunsing commented 6 months ago

Just tested Hocus Pocus on my CMI-8738-PCI-6CH, which worked (Don't have an 8338)

Check questions:

vicokoby commented 6 months ago

@hjnijlunsing 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.

hjnijlunsing commented 6 months ago

Another check:

vicokoby commented 6 months ago
hjnijlunsing commented 6 months ago

Tested https://github.com/crazii/SBEMU/releases/tag/UserBuild_2024.01.20_16-26 for the CMI8738-PCI-SX; same issue. No crash, but also no sound. Same issue as last week.

crazii commented 6 months ago

Some code from Linux source was added. It's inefficient to test & try code like this... But I really don't want to bring out my desktop rig when I have too many laptops already.

crazii commented 6 months ago

Fixed DMA buffer alignment for CMI.

hjnijlunsing commented 6 months ago

I noticed a new build was not created; thus compiled locally. --> Same behavior

I'll think I'll be automating the tests some more next week; in order to avoid swapping USB disks with my dev laptop ;-). The idea is:

I think setting up a https to http proxy on my network I can automatically get the latest build and source github using Brutman's HTGET

crazii commented 6 months ago

That's a good idea, I can also add more debug info into the CMI driver. First there need to be a log in interrupt function to check whether the playback is actually running.

crazii commented 6 months ago

I added a specific log to the getbufpos() function, if the playback is running in background, you should see "buffpos" message all over screen - for DEBUG=1 builds.

hjnijlunsing commented 6 months ago

With both CMI cards debugging starts instantly after SBEMU.EXE without starting any games.

I was actually looking to hook up another computer for the debug messages (current test pc has a serial port) so I could debug capture when I was starting games. But for now it seems not necessary yet.

crazii commented 6 months ago

Yes, you have serial port connected you can use /DBG1 to output debug to serial port 1.

crazii commented 6 months ago

With both CMI cards debugging starts instantly after SBEMU.EXE without starting any games.

Yes, is the message about buffpos printing on the screen? if yes, then the playback & interrupt is OK, there might be some configure on the devices that was missing, i.e. mixer/volumes.

hjnijlunsing commented 6 months ago

Yes the bufpos message is continuously scrolling

crazii commented 6 months ago

OK, that's a good sign at least. :)