crazii wrote on 2023-02-27, 07:28:

...
I can try it but it needs debugging and I don't have the hardware to debug it, so it's not guaranteed to work.

Thanks, I can help debugging SB Live! 5.1 and Audigy 2 ZS.

Update:
1. added option /k to set sample rate. /k22050 or /k44100, default 22050
2.added experimental support for SB Live and Audigy (not tested, probably won't work, but with initialization log enabled)
3.experimental changes on HDPMI: a) if interrupt happens in PM, then after pm handlers service the IRQ, route interrupt to IVT first - don't know this is good, but fixed Miles Sound. b) "simulate real mode int" API calls IVT first. - don't know this is good either but both changes makes Miles Sound working. I'll turn off the switch if anything previously works but now goes wrong.
4. based on 3, now PM SB virtual interrupt are using INT xx, and with original context restored. this could make protected mode games more stable.

crazii wrote on 2023-02-28, 16:53:

...
2.added experimental support for SB Live and Audigy (not tested, probably won't work, but with initialization log enabled)

Hi,
With Audigy 2ZS the output of the new version is no different from the previous one. Namely:

No soundcard found!
Unknown soundcard (output module) name : NUL

Falcosoft wrote on 2023-02-28, 17:34:

Hi, With Audigy 2ZS the output of the new version is no different from the previous one. Namely: […]
Show full quote

crazii wrote on 2023-02-28, 16:53:

...
2.added experimental support for SB Live and Audigy (not tested, probably won't work, but with initialization log enabled)

Hi,
With Audigy 2ZS the output of the new version is no different from the previous one. Namely:

No soundcard found!
Unknown soundcard (output module) name : NUL

I added more log to show error information.

crazii wrote on 2023-02-28, 18:18:

Falcosoft wrote on 2023-02-28, 17:34:

Hi, With Audigy 2ZS the output of the new version is no different from the previous one. Namely: […]
Show full quote

crazii wrote on 2023-02-28, 16:53:

...
2.added experimental support for SB Live and Audigy (not tested, probably won't work, but with initialization log enabled)

Hi,
With Audigy 2ZS the output of the new version is no different from the previous one. Namely:

No soundcard found!
Unknown soundcard (output module) name : NUL

I added more log to show error information.

Hi,
Interesting, but the output is still the same. Do I have to use some kind of command line argument to get more verbose output?

Falcosoft wrote on 2023-02-28, 18:55:

crazii wrote on 2023-02-28, 18:18:

Falcosoft wrote on 2023-02-28, 17:34:

Hi,
With Audigy 2ZS the output of the new version is no different from the previous one. Namely:

I added more log to show error information.

Hi,
Interesting, but the output is still the same. Do I have to use some kind of command line argument to get more verbose output?

I checked the code again and found one important missing change, sorry. updated in the previous link.

crazii wrote on 2023-02-28, 16:53:

Update: 1. added option /k to set sample rate. /k22050 or /k44100, default 22050 2.added experimental support for SB Live and Au […]
Show full quote

Update:
1. added option /k to set sample rate. /k22050 or /k44100, default 22050
2.added experimental support for SB Live and Audigy (not tested, probably won't work, but with initialization log enabled)
3.experimental changes on HDPMI: a) if interrupt happens in PM, then after pm handlers service the IRQ, route interrupt to IVT first - don't know this is good, but fixed Miles Sound. b) "simulate real mode int" API calls IVT first. - don't know this is good either but both changes makes Miles Sound working. I'll turn off the switch if anything previously works but now goes wrong.
4. based on 3, now PM SB virtual interrupt are using INT xx, and with original context restored. this could make protected mode games more stable.

SBEMU.zip

Now that you started adding new output devices, can I suggest a couple of more to be added to the pipeline?
1) Covox. It's very widespread and compatible with both old and new systems. Only 8 bit sound is supported, yet, the sampling rate is unlimited.
2) Sound Blaster Direct mode, 8 bit, 8 or 11 khz maximum sampling rate. Can be used on systems with a SB DSP, but lacking DMA. Which is not unulual. For instance Omnibook 600ct has a ES1668 chip, but no DMA. I thik there existed PCI cards with SB DSP. And my favourite PCMCIA cards.
This one should be the easiest to implement, as no card detection procedures are necessary, the DSP sits on a usual port. As well as FM emulation, as it can be done in hardware.

Yes, I think it'll be good to add Covox support. however for the direct mode, its' complicated. with DMA, I only copy the ISA DMA buffer from DMA controller to PCI DMA buffer accessed by PCI bus master device, that simple enough. for direct mode, even if I'm able to put the sample directly into the PCI DMA buffer, I need to resample the buffer but there's no direct sample rate information, need a high frequency timer detect it.
For now I think the first priority still be making MDK working, which was one of my favorite games in my childhood. 😁 I still play it on Steam.

crazii wrote on 2023-03-01, 03:32:

I checked the code again and found one important missing change, sorry. updated in the previous link.

Hi,
I have re-tested the new version and this time it "worked" in the sense that it detected the sound card and I also heard a "pop" from my speakers (I think this is a good sign). But unfortunately testing with Duke Nukem 3D resulted in no music and no sound. The music test did not give any errors but simply resulted in silence. The digital audio test resulted in an error message that playback failed most likely because of not well configured DMA channel (or something similar in a red dialog).

Falcosoft wrote on 2023-03-01, 08:56:

Hi, I have re-tested the new version and this time it "worked" in the sense that it detected the sound card and I also heard a " […]
Show full quote

crazii wrote on 2023-03-01, 03:32:

I checked the code again and found one important missing change, sorry. updated in the previous link.

Hi,
I have re-tested the new version and this time it "worked" in the sense that it detected the sound card and I also heard a "pop" from my speakers (I think this is a good sign). But unfortunately testing with Duke Nukem 3D resulted in no music and no sound. The music test did not give any errors but simply resulted in silence. The digital audio test resulted in an error message that playback failed most likely because of not well configured DMA channel (or something similar in a red dialog).
20230301_093952.jpg

The most possible reason is that the interrupt is not enabled. I'll check what I can do.

crazii wrote on 2023-03-01, 07:06:

Yes, I think it'll be good to add Covox support. however for the direct mode, its' complicated. with DMA, I only copy the ISA DMA buffer from DMA controller to PCI DMA buffer accessed by PCI bus master device, that simple enough. for direct mode, even if I'm able to put the sample directly into the PCI DMA buffer, I need to resample the buffer but there's no direct sample rate information, need a high frequency timer detect it.
For now I think the first priority still be making MDK working, which was one of my favorite games in my childhood. 😁 I still play it on Steam.

I see. However if Covox is possible, then direct mode(DM) should not be an issue. As in both cases it's basically all about sending the data byte to the IO port at a given rate.
Yeah, same here, I love MDK since it came out 😁

Falcosoft wrote on 2023-03-01, 08:56:

Hi, I have re-tested the new version and this time it "worked" in the sense that it detected the sound card and I also heard a " […]
Show full quote

crazii wrote on 2023-03-01, 03:32:

I checked the code again and found one important missing change, sorry. updated in the previous link.

Hi,
I have re-tested the new version and this time it "worked" in the sense that it detected the sound card and I also heard a "pop" from my speakers (I think this is a good sign). But unfortunately testing with Duke Nukem 3D resulted in no music and no sound. The music test did not give any errors but simply resulted in silence. The digital audio test resulted in an error message that playback failed most likely because of not well configured DMA channel (or something similar in a red dialog).
20230301_093952.jpg

I wrote the wrong register to enable interrupts. now it MIGHT work, but I don't know the interrupt rate, might not work for doom's digital sound, maybe need configure a timer interrupt from the sound card.
let's see what happens first 😁 the TEST zip is updated.

Bondi wrote on 2023-03-01, 13:00:

crazii wrote on 2023-03-01, 07:06:

Yes, I think it'll be good to add Covox support. however for the direct mode, its' complicated. with DMA, I only copy the ISA DMA buffer from DMA controller to PCI DMA buffer accessed by PCI bus master device, that simple enough. for direct mode, even if I'm able to put the sample directly into the PCI DMA buffer, I need to resample the buffer but there's no direct sample rate information, need a high frequency timer detect it.
For now I think the first priority still be making MDK working, which was one of my favorite games in my childhood. 😁 I still play it on Steam.

I see. However if Covox is possible, then direct mode(DM) should not be an issue. As in both cases it's basically all about sending the data byte to the IO port at a given rate.
Yeah, same here, I love MDK since it came out 😁

Covox might be simpler, if I'm correct, just output whatever the samples to it at whatever rate, and it's done. But there's delay on CPU (the trapping code), the sounds may be distorted.
OK I was wrong, it will only be simple if it is direct SB mode for Covox. for DMA mode, the source sample rate info of the DMA buffer still needed to be used to send sample periodically.

I ran MDK with log again, the PM IRQ1 handler is hooked by DOS/4GW on initialization, MDK installs a DPMI RM vector for IRQ1, it seems setrmivec store the address to INTRMCBS.orgvec but never got a chance to call it. the only chance is to use "simulate real mode int" API.
But if it is the case, why std HDPMI with IOPL3 works?

EDIT: OK, the std HDPMI doesn't work now, I was using the one from the original site, created at the year 2009.

EDIT: if set rm interrupt vector is directly written to IVT, then MDK works. But I don't want mess up with HDPMI source code prematurely anymore. 🤣

crazii wrote on 2023-03-01, 13:23:

Falcosoft wrote on 2023-03-01, 08:56:

Hi, I have re-tested the new version and this time it "worked" in the sense that it detected the sound card and I also heard a " […]
Show full quote

crazii wrote on 2023-03-01, 03:32:

I checked the code again and found one important missing change, sorry. updated in the previous link.

Hi,
I have re-tested the new version and this time it "worked" in the sense that it detected the sound card and I also heard a "pop" from my speakers (I think this is a good sign). But unfortunately testing with Duke Nukem 3D resulted in no music and no sound. The music test did not give any errors but simply resulted in silence. The digital audio test resulted in an error message that playback failed most likely because of not well configured DMA channel (or something similar in a red dialog).
20230301_093952.jpg

I wrote the wrong register to enable interrupts. now it MIGHT work, but I don't know the interrupt rate, might not work for doom's digital sound, maybe need configure a timer interrupt from the sound card.
let's see what happens first 😁 the TEST zip is updated.

Unfortunately the end result is the same: soundcard detected, but neither music nor digital audio works in Duke 3D. The error dialog in case of digital audio testing still complains about DMA (not IRQ).

crazii wrote on 2023-02-27, 07:37:

The author of MPXPlay agreed that SBEMU uses its source code, as long as its header comments unchanged, and SBEMU opens source. 😁
https://sourceforge.net/p/mpxplay/discussion/ … ead/ac6560662b/

Good to know that the Mpxplay author doesn't object to their sound driver sources being used in SBEMU, but didn't you also integrate Sound Blaster emulation code from the DOSBox project? That code is likely licensed under the GPL, which doesn't allow it to be mixed with sources that have a more restrictive license. "You can't use this to make a clone of certain other software" is an additional restriction that the GPL doesn't have, and therefore make DOSBox sources and Mpxplay sources incompatible with one and other.

As long as the DOSBox developers don't mind this, I guess you could at least continue developing it further like this for the time being, but they legally have a right to object to this.

I would still recommend replacing the sound hardware driver sources from Mpxplay with alternative sources with a more permissive license.

The Open Sound System (OSS) driver sources from 4Front Technologies would fit the bill: they have been released under multiple open sources licenses, including 2-Clause BSD and GPL 2.0, and support a wide range of contemporary sound devices, including pretty much all the popular ones: Intel HDA, ICHx AC'97, Sound Blaster Live!, Audigy, and many others. The OSS drivers are multi-platform in the sense that they are intended for POSIX (UNIX-like) operating systems, but could perhaps be ported to DOS. Such a port would yield benefits not just for SBEMU, but for many other open source DOS sound projects as well.

I would guess that one major piece of "glue" that such a DOS port would require would be the PCI access stuff, so implementations of "pci.h" and such. That could perhaps be adapted from other open source DOS projects.

I'm sorry if I'm coming off as a bit pedantic when it comes to open source licenses and compliance and such, but open source projects have gotten in trouble over these things, and SBEMU is too cool to have it blocked or complicated by something like this.

I think I may have a candidate machine ready to test out since I don't have a PSU on hand to power my Nforce2. It's a an Intel Z77 with an X-Fi Titanium. Where can I get a current version to test this?

Falcosoft wrote on 2023-03-01, 15:47:

crazii wrote on 2023-03-01, 13:23:

Falcosoft wrote on 2023-03-01, 08:56:

Hi,
I have re-tested the new version and this time it "worked" in the sense that it detected the sound card and I also heard a "pop" from my speakers (I think this is a good sign). But unfortunately testing with Duke Nukem 3D resulted in no music and no sound. The music test did not give any errors but simply resulted in silence. The digital audio test resulted in an error message that playback failed most likely because of not well configured DMA channel (or something similar in a red dialog).
20230301_093952.jpg

I wrote the wrong register to enable interrupts. now it MIGHT work, but I don't know the interrupt rate, might not work for doom's digital sound, maybe need configure a timer interrupt from the sound card.
let's see what happens first 😁 the TEST zip is updated.

Unfortunately the end result is the same: soundcard detected, but neither music nor digital audio works in Duke 3D. The error dialog in case of digital audio testing still complains about DMA (not IRQ).

The interrupt is probably enabled now so IRQ is OK, but the IRQ rate is low and Duke3D doesn't detect DMA counter/pointer changes, since they're updated in the interrupt handler. I'll try the timer of Audigy2ZS or some undocumented ways.

digger wrote on 2023-03-01, 22:40:

"You can't use this to make a clone of certain other software" is an additional restriction that the GPL doesn't have, and therefore make DOSBox sources and Mpxplay sources incompatible with one and other.

OK, I didn't know DOSBox has such restriction, Does that makes DOSBox source code not reusable for any purpose? Even the clone of DOSBox, like DOSBox-X or DOSBox-SVN-Daum are not permitted?
Use another sound card driver can be done but it is expensive, meaning starting over and testing again for every games, I'm not ready to do this. I think use another OPL emulation code might be more easy.

ptr1ck wrote on 2023-03-01, 23:37:

I think I may have a candidate machine ready to test out since I don't have a PSU on hand to power my Nforce2. It's a an Intel Z77 with an X-Fi Titanium. Where can I get a current version to test this?

Here it is: Re: Possibility to write OPL3 sound driver for protected mode games