DragonSlayer wrote on 2023-04-13, 18:44:

Concerning my earlier post about DOSBox-X muting itself when minimized or running in the background, DOSBox Staging has recently fixed this problem with their fork. I can now listen to MIDIs playing in the background when running Windows 98 on DOSBox Staging without it muting or stuttering! Now if only the DOSBox-X team could implement their recent fix, that would be awesome! 😀

The only reason I can think of for muting itself when not the active application would be something to do with DirectSound, which I recall will do that automatically unless the application asks it not to. At least that's how DirectSound worked way back in the Windows 95/98/ME/XP days. Was the fix not to use DirectSound? (will check after posting this)

Even more awesome would be posting such a request on the dosbox-x github issues page.....

Browsing through Staging's git repository, I see some code cleanup and unit test commits but nothing about muting of audio in the background.
I regularly visit their Discord server, I went ahead and asked them about the muting fix.

DosFreak wrote on 2023-04-13, 18:50:

Even more awesome would be posting such a request on the dosbox-x github issues page.....

I signed up on there long ago just to post bugs about the ps1 audio card long ago and Github randomly flagged my account when doing that.
Please disable ps1 audio card support since it's not working for a lot of time.

@DosFreak: The reason I mentioned it here is because I originally asked the question here and I thought it might be of use to help anyone else that was experiencing the same problem as I was. I'm just trying to be helpful.

@TheGreatCodeholio: When I was looking for a solution to this problem, I read a post from a guy on another message board that dated to about 3 weeks ago saying that the muting problem was fixed with DOSBox Staging, but I don't know when the fix was actually implemented. I just know that it must have been rather recently for the guy to have just mentioned it 3 weeks ago. I'm sorry that I didn't save a link to it because that might be of help to you now. I'll see if I can find the link again.

I found the link. The relevant part is that Johnnovak asked to close the ticket on this issue 3 weeks ago because they implemented the "configurable pause/mute when inactive settings" that fixed the issue.

https://github.com/dosbox-staging/dosbox-staging/issues/109

I am testing the recent patch for an increased baud rate on a serial port. Since it may affect the modem emulation:

1static Bitu INT14_Handler(void) {
2..
3    switch (reg_ah) {
4    case 0x00:  {
5...
6        Bitu baudrate = 9600;
7        uint16_t baudresult;
8        Bitu rawbaud=(Bitu)reg_al>>5;
9        
10        if (rawbaud==0){ baudrate=110;}
11...
12        else if (rawbaud==7){ baudrate=9600;}
13
14        baudresult = (uint16_t)(115200 / baudrate);
15
16        IO_WriteB(port+3, 0x80);    // enable divider access
17        IO_WriteB(port, (uint8_t)baudresult&0xff);
18        IO_WriteB(port+1, (uint8_t)(baudresult>>8));

hail-to-the-ryzen wrote on 2023-04-14, 06:05:

I am testing the recent patch for an increased baud rate on a serial port. Since it may affect the modem emulation: […]
Show full quote

I am testing the recent patch for an increased baud rate on a serial port. Since it may affect the modem emulation:

Copy code to clipboard

1static Bitu INT14_Handler(void) {
2..
3    switch (reg_ah) {
4    case 0x00:  {
5...
6        Bitu baudrate = 9600;
7        uint16_t baudresult;
8        Bitu rawbaud=(Bitu)reg_al>>5;
9        
10        if (rawbaud==0){ baudrate=110;}
11...
12        else if (rawbaud==7){ baudrate=9600;}
13
14        baudresult = (uint16_t)(115200 / baudrate);
15
16        IO_WriteB(port+3, 0x80);    // enable divider access
17        IO_WriteB(port, (uint8_t)baudresult&0xff);
18        IO_WriteB(port+1, (uint8_t)(baudresult>>8));

It's implemented as a multiplier. If you really want > 115200 baud serial then you're probably not too concerned with whether BIOS functions set the correct baud rate.

I suppose it's similar to would happen if you overclocked the UART on your computer. You'd get a faster baud rate but everything that expects the normal rate would be affected.

https://github.com/joncampbell123/dosbox-x/issues/4115

A multithreaded version of the software rendering path in the 3dfx Voodoo 1 emulation patch is compatible with DOSBox-X:
Re: VIDEO - 3dfx voodoo emulation (SDL1)

It has different code for the PCI emulation, but it is not difficult to adapt. It requires moving lines of code while not modifying the low level PCI emulation. It works while use_threads is true. However, as jmarsh advised, the fpu states are not necessarily preserved where multithreading is active (affecting Windows 95 guest OS, for example).

The above 3dfx emulation with the dynamic_x86 +dh_fpu shows these fpu related problems by at least graphical artifacts. However, the normal core in the same build appears to run normally. The solution to the artifacts is in the original 2011 3dfx Voodoo patch which encloses several code blocks, such as triangle generation, with *_SaveDHFPUState and *_X86_RestoreDHFPUState. These functions are defined in the 2011 patch.

The lod calculations in the 3dfx mame code are not sufficient for generating accurate mipmapping. A workaround is to disable it as described here:
https://github.com/joncampbell123/dosbox-x/co … d954fa470754bd2

Attached is code to implement a gamma level modifier in the 3dfx Voodoo emulation (non-opengl software path only), as in DOSBox-X. It likely requires manual application of the patch since it was formed in a modified build. It also has a feature that implements a gamma level for non-3dfx cases where the input color depth is 8 bpp and the output is 32 bpp. This is a typical case today. There is documentation in the patch on details about the functions in the code. The purpose of this patch is to increase the brightness level in games that use the 3dfx emulation. It is also not meant to emulate the gamma level in the real 3dfx Voodoo card, but instead a method for convenience for changing the gamma level apart from a setting provided by a video card or monitor.

hello

i found a small bug or strange behavior with latest dosbox-x (20230401005056)

when i play mod sound files with libopenmpt (i use dosbox-x with default settings, fullscreen, aspect ratio and cycles = max)
the music does not play smoothly but has slowdowns at irregular intervals
i have to set a fixed cycle like 100.000 or 200.000 depending how many channels the mod files have.
and playback is fine

i know setting cycles too high for host machine will
generate sound problems
but cycles = max should work fine

with older dosbox-x versions i have no problems using cycles = max with libopenmpt

edit: when i set cycles=max and enable "show fps and rt speed in title bar"
and use libopenmpt the cycles fluctuate from 50.000 to 250.000 all the time
most of the time they stay above 200.000 and everything is ok
but when they go below 80.000 the music slowsdown
seems cycles=max is dropping the cycles to far down

when i use dosbox-x 20221226190454
and set cycles=max
the cycles with libopenmpt fluctuate only from 140.000 to 145.000
and remain more or less constant

with dosbox-x 20230401005056
cycles=max and impulse tracker 2.15
cycles shown are about 37.000 - 40.000
playback is fine

with dosbox-x 20230401005056
cycles=max and open cubic player 2.6
cycles shown are about 495.000 - 505.000 (seems very high...)
but playback is fine

seems only libopenmpt has problems with cycle=max and latest dosbox-x

edit2:
I've found another problem that is independent of the above one 😀
the sb oplrate and gus rate is set to 44100 but the mixer is set to 48000 per default.
when oplrate is != mixer rate you get sound cracks for e.g. in privateer 2
everytime when game switches from video to in game and back.
i would therefore suggest setting the mixer to 44100 by default.

hail-to-the-ryzen wrote on 2023-04-23, 14:31:

Attached is code to implement a gamma level modifier in the 3dfx Voodoo emulation (non-opengl software path only), as in DOSBox-X. It likely requires manual application of the patch since it was formed in a modified build. It also has a feature that implements a gamma level for non-3dfx cases where the input color depth is 8 bpp and the output is 32 bpp. This is a typical case today. There is documentation in the patch on details about the functions in the code. The purpose of this patch is to increase the brightness level in games that use the 3dfx emulation. It is also not meant to emulate the gamma level in the real 3dfx Voodoo card, but instead a method for convenience for changing the gamma level apart from a setting provided by a video card or monitor.

Please submit this to the issue tracker or as a pull request to the DOSBox-X project.

K.A.R.R. wrote on 2023-04-30, 11:37:

hello […]
Show full quote

hello

i found a small bug or strange behavior with latest dosbox-x (20230401005056)

when i play mod sound files with libopenmpt (i use dosbox-x with default settings, fullscreen, aspect ratio and cycles = max)
the music does not play smoothly but has slowdowns at irregular intervals
i have to set a fixed cycle like 100.000 or 200.000 depending how many channels the mod files have.
and playback is fine

i know setting cycles too high for host machine will
generate sound problems
but cycles = max should work fine

with older dosbox-x versions i have no problems using cycles = max with libopenmpt

edit: when i set cycles=max and enable "show fps and rt speed in title bar"
and use libopenmpt the cycles fluctuate from 50.000 to 250.000 all the time
most of the time they stay above 200.000 and everything is ok
but when they go below 80.000 the music slowsdown
seems cycles=max is dropping the cycles to far down

when i use dosbox-x 20221226190454
and set cycles=max
the cycles with libopenmpt fluctuate only from 140.000 to 145.000
and remain more or less constant

with dosbox-x 20230401005056
cycles=max and impulse tracker 2.15
cycles shown are about 37.000 - 40.000
playback is fine

with dosbox-x 20230401005056
cycles=max and open cubic player 2.6
cycles shown are about 495.000 - 505.000 (seems very high...)
but playback is fine

seems only libopenmpt has problems with cycle=max and latest dosbox-x

edit2:
I've found another problem that is independent of the above one 😀
the sb oplrate and gus rate is set to 44100 but the mixer is set to 48000 per default.
when oplrate is != mixer rate you get sound cracks for e.g. in privateer 2
everytime when game switches from video to in game and back.
i would therefore suggest setting the mixer to 44100 by default.

I recently (after the May 1st release) made some fixes to the CMOS emulation, if that is the cause.

I set the mixer default to 48000 because most AC'97 and HD audio chipsets since the early 2000s run at that rate (if not 96000Hz for any reason including what is connected to your HDMI port) and often the rate is fixed and your OS is resampling application audio to the hardware sample rate anyway. Sound cards that max out at 44.1KHz and/or change according to application sample rate have not been the standard since the late 1990s to early 2000s.

thanks for the answer 😀

just tested latest dosbox-x version
20230501152329
it has the same behavior with libopenmpt and cycles=max like 20230401005056

its not a big issue
with fixed cycles playback is ok

K.A.R.R. wrote on 2023-05-10, 17:00:

thanks for the answer :-) […]
Show full quote

thanks for the answer 😀

just tested latest dosbox-x version
20230501152329
it has the same behavior with libopenmpt and cycles=max like 20230401005056

its not a big issue
with fixed cycles playback is ok

Just after release I made some additional fixes to CMOS emulation. Can you compile from the latest commit to master and try again?

just tested dosbox-x-mingw-win64-20230509035144

its working again with cycles=max
cycles are more or less constant at around 250.000
and playback is smoothly

compared to old 20221226190454
cycles are higher around 230.000 - 260.000 compared to 140.000 - 145.000

thx for the fast fix 😀

hi
may be you can take a look at a small problem with gus and midi playback

with standard patches (from latest driver 4.11) midi playback
for e.g. with playmidi.exe
is fine.
but when i use ppl 1.61 (pro patches lite 1.61)
some instruments are incorrectly looped.

dosbox, x, staging and pcem all have this problem
(x, staging and pcem have even more looping problems than normal dosbox with ppl1.61)

BUT with a real gus and the pro patches lite there is no looping error
means the patches are not the problem.

seems there is a bug in midi playback when using the ppl 1.61 patches with dosbox.
would be great if this could be fixed

here some test midis and a recording of the problem
https://www.mediafire.com/file/kfrhzm8720anw2 … ditest.zip/file

DragonSlayer wrote on 2023-04-14, 02:16:

I found the link. The relevant part is that Johnnovak asked to close the ticket on this issue 3 weeks ago because they implemented the "configurable pause/mute when inactive settings" that fixed the issue.

https://github.com/dosbox-staging/dosbox-staging/issues/109

"JohnNovak" here... I think audio/MIDI playing in the background without stuttering was fine for a long long time in Staging . For the record, FluidSynth and the MT-32 run emu in their own threads and have been carefully performance optimised for minimal dropouts/stutter, etc. even on a lowly Raspberry Pi. I only fixed the "pause on inactive" behaviour recently, and made MIDI pausing/resuming a lot better overall (e.g. long notes don't go "missing" after a pause/resume, but they will be retriggered, just like in good MIDI sequencers).

K.A.R.R. wrote on 2023-05-18, 17:54:

hi may be you can take a look at a small problem with gus and midi playback […]
Show full quote

hi
may be you can take a look at a small problem with gus and midi playback

with standard patches (from latest driver 4.11) midi playback
for e.g. with playmidi.exe
is fine.
but when i use ppl 1.61 (pro patches lite 1.61)
some instruments are incorrectly looped.

dosbox, x, staging and pcem all have this problem
(x, staging and pcem have even more looping problems than normal dosbox with ppl1.61)

BUT with a real gus and the pro patches lite there is no looping error
means the patches are not the problem.

seems there is a bug in midi playback when using the ppl 1.61 patches with dosbox.
would be great if this could be fixed

here some test midis and a recording of the problem
https://www.mediafire.com/file/kfrhzm8720anw2 … ditest.zip/file

Hi K.A.R.R.

I would love to fix this. I suspected this was an emulation problem...

Can you please raise a ticket in our issue tracker on GitHub for this with all relevant info? I don't have a GUS anymore, so every bit of info helps.

DOSBox Staging issue tracker
https://github.com/dosbox-staging/dosbox-staging/issues

Thanks!

@Rincewind42: Thank you very much for taking the time to respond to this very annoying issue. Do you care to speculate as to why DOSBox-X has a stuttering problem when playing MIDI in the background and can you think of any way it could possibly be remedied to bring it in line with what has been accomplished with DOSBox Staging?

It's a real shame that DOSBox Staging still doesn't officially support Windows 98 when it is currently the only version of DOSBox that can play MIDI in Windows 98, without stuttering problems, when minimized. It's sad that the average newbie would have a very difficult time in getting Windows 98 set up to run inside of DOSBox Staging, as it stands currently, when it is so very close to supporting Windows 98 properly.