Tertz wrote:

Yes, this removes some wrong percussions's pitch in OPL emulation.
And adds another problem, - the resampling made by the emulator or by a card adds noisy distortion, as there is no native 49716 Hz mode and quality of resampling is mediocre on many cards/onboard chips.

I think it should be the job of the emulator to solve this.
If the OPL emulation HAS to run at 49716 Hz for some reason, then there should be resampling built into the emulator to resample it to more common rates, such as 44.1 KHz.
libsamplerate may be a good choice for that.

I use the settings oplrate=49716 and mixer rate=48000. This effectively downsamples the output a bit, but in my case it is the lesser evil because the DSP on the Audigy 2 ZS soundcard I have is locked at 48K and resamples all input to that rate using a poor algorithm. There is some loss of quality from the mixer downsampling, but I would hardly characterize it as "noisy distortion".

There may to be "HQ resampling" option. Similarly as there are 2 algorithms for FM emulation - faster or better.

ripsaw8080 wrote:

I would hardly characterize it as "noisy distortion".

Noisy in the sense of type, not a degree. Bad resampling sounds as noiser, more dirty FM instruments. The difference may be heard if having rate=48000 to set oplrate=48000 - this gives cleaner sound, and then oplrate=49716 which gives noiser one.

I hear the difference in headphones with ordinary amplifier. To switch between these settings is easier in ykhwong's port through its menu. Keen 4 is also comfortable for direct comparision of FM, as with entering to the game's menu by ESC the music stops and returning to the game restarts the tune. Also in ykhwong's port you may compare hardware OPL and emulated, for example in Keen's map screen plays wrongly a percussion (triangle).

It should probably be added that - I believe - the last revision of the Nuked OPL emulator (as prepared for Chocolate Doom) internally works only at the rate of 49716Hz, so it uses SRC/libsamplerate for support of other output rates (see e.g., call to src_new): https://github.com/nukeykt/chocolate-doom-bet … ster/opl/opl3.c

Of course, such a solution may theoretically work with other resamplers. I'm not sure it's necessarily the "right" way, though; Some may claim it's rather the mixer's responsibility to do the re-sampling. But, it's at least a technical possibility.

Of course, some resamplers, possibly with certain options/settings (e.g., libsoxr with HQ resampling) may introduce audible latencies, so care should be taken!

we'd need more than resampling though. A low-pass filter was a feature on many early computer speakers (as well as boomboxes with equalizers that could be routed to 😀, and some sound cards.)

NY00123 wrote:

Of course, such a solution may theoretically work with other resamplers. I'm not sure it's necessarily the "right" way, though; Some may claim it's rather the mixer's responsibility to do the re-sampling. But, it's at least a technical possibility.

That assumes that you use a mixer in the first place.
Depending on the sound API you use, you may or may not be able to freely choose your sampling rate. The more low-level APIs will only expose a few fixed sample rates that the hardware supports, as the sound buffers will be sent to the hardware directly, without any additional processing.

Scali wrote:

That assumes that you use a mixer in the first place.
Depending on the sound API you use, you may or may not be able to freely choose your sampling rate. The more low-level APIs will only expose a few fixed sample rates that the hardware supports, as the sound buffers will be sent to the hardware directly, without any additional processing.

Well, I was thinking about DOSBox' mixer and the output sampling rate. Indeed, this is an internal mixer specific to DOSBox itself, and not an OS/driver level mixer. In the case of DOSBox, the sampling rate given by the "rate" setting is requested in the call to SDL_OpenAudio, but if a different rate is obtained then the latter one is used for the mixer.