Sound clipping in CPS2 when used with Low-pass filter

[voorunde]

After 1968b5f, which doubled the volume in CPS2 games, sound may become distorted due to clipping in some instances. The noticeability of clipping really depends on a particular game and what's currently happening, and it can be pretty faint with just a bit of added graininess, however the worst offender I've found to illustrate the problem is Dhalsim's stage in SFA2.
I've recorded several videos, but due to consideration of github maximum size embedding, video on itself is very low quality, however I made sure that audio is not. All recording was done in Retroarch, sound driver is xaudio, audio rate is 48000. Preferably use headphones for appraisal, and listen for low percussion and punch SFXs. Also a quick notice: the effect of clipping is not as pronounced when using ROM's sound test, and really manifests when there's both BGM and SFX playing at the same time, hence why I had to record gameplay.

Old build prior to the change:

old.mp4

Current build with -6dB preamp applied in Retroarch to roughly volume match:

new.-6db.mp4

Current build without preamping

new.mp4

[barbudreadmon]

Well, i'm a bit on the deaf side, so i'll need more information.
Is this happening only with low-pass filter ?
Is this happening with/without interpolation(s) enabled ?
What's that video in the middle ? Does it have the sound clipping problem ?

[barbudreadmon]

Ok, i tried to monitor clipping numerically, and it does happen quite a lot.
I ended up reducing multiplier from 2 to 1.25, but it doesn't prevent clipping on that dhalsim stage entirely (1.1 might do the trick).
Users used to complain a lot about this driver having its sound volume too low vs other drivers, so i'm not too sure what's the best course of action here.

[voorunde]

@barbudreadmon
Thank you for addressing it. While CPS2 can indeed be on the quieter side compared to other machines, Retroarch allows sound amplification via per-game or per-content folder overrides. That also can introduce clipping, but at least that would be on user's discretion, however if amplification happens on emulator side, there's little can be done to salvage the sound because it already arrives damaged. Low pass filter also amplifies the sound, so it creates a perfect storm.
There's also been a similar change to CPS1, but I haven't played its games enough to ascertain whether it's to any detriment like with CPS2.

[barbudreadmon]

Retroarch allows sound amplification via per-game or per-content folder overrides

Well, remember this is a standalone emulator before being a libretro core.

[voorunde]

Well, remember this is a standalone emulator before being a libretro core.

That's true. If I'm the only one's complaining about clipping after the change, whilst there were a lot of people complaining about sound being too low prior to the change, then I'm at a loss. I suppose not a lot of people are playing with Low-pass filter on, which really exposes the issue. So it's entirely your call how to balance between general usability and sound fidelity, I merely wanted to shed light on what's been bothering me since that change.

[voorunde]

I just had an idea, but I'm not a programmer so I'm unsure whether it's difficult/possible to implement. How about introducing a DIP switch for CPS2 games called "CPS2 volume boost" that makes it sound twice as loud, and is enabled by default? This way CPS2 would be as loud as it was before, but people like me who are experiencing issues can turn it off? Same can be done for CPS1.

[barbudreadmon]

The thing is that the default cps2 volume is maxed (it can be seen in cps2's service menu), and i consider the 2.0 multiplier with the loud and slightly saturated sound to be the correct behavior with a maxed cps2 volume.
You are supposedly able to use cps2's "volume down" button to reduce it if needed, but there is a trick : retroarch has disastrous limitations when it comes to button mapping, so some buttons present in standalone FBNeo just can't be made available in the libretro port.

Well, i'd like to remember which game was used as a reference when i did this change 2 years ago, it definitely wasn't sfa2, because sfa2's volume is "fair" even if i entirely remove the multiplier.

[voorunde]

Indeed, the ability to control the volume from 0 to 39 on a per game basis would be the ideal solution. Looking at available inputs of a 6-button CPS2 game (SFA3 in this case), I noticed there's still space to map vol -/+ to L3/R3, even considering there's already "extra" 3x punch and 3x kick inputs, or maybe I'm not understanding this correctly.

[barbudreadmon]

Mapping volume up/down should be optional and unmapped by default, to avoid having users pressing them by mistake, it has been a running gag in standalone where those buttons used to be mapped by default. L3 would be especially bad.

I could theoretically map them to keyboard's volume up/down, they are available through the libretro api, you'd need to have a keyboard with those buttons though (i don't)

[voorunde]

I think it'd be best they would be unmapped by default, but a user can map them to buttons like L3/R3 on a retropad via control options, then configure the sound, then unmap them again as to not accidentally press them. If there's no extra slots on retropad, then at least an option to map them to a key on a keyboard would be better than nothing.

[barbudreadmon]

In case it wasn't clear from the previous convo and the issue i linked, additionally to the lack of slots, retroarch doesn't allow cores to "declare a button and let the user decide if he'll map it somewhere or not".

[voorunde]

I see, that is unfortunate. I didn't know this because I recall some games on FBN not mapping all available inputs automatically. If that's the case and, unless Libretro API is modified to allow extra retropad inputs, assigning volume control inputs in CPS1/2 is impossible, then I suppose there's little that can be done.
Thank you addressing my concern by reducing volume boost from 100% to 25%. I'll keep the issue open in hope that sometime a volume control solution materializes, but if you consider it's solved, then feel free to close it.

[barbudreadmon]

@dinkc64 this is a first draft, but i was thinking of implementing something similar to the "cpu cheat" framework to register sound chips :

#define SOUNDCHIP_MAX 2

struct soundchip_config {
	char soundchip_name[32];
	void (*change)(double);  // change volume
	double (*get_default)(); // get default volume
	double (*get_current)(); // get current volume
};

struct soundchip {
	soundchip_config *soundconfig;
	INT32 nChip;
};

struct soundchip soundchips[SOUNDCHIP_MAX];

static void dummy_change(double) {}
static double dummy_get_default() { return 0; }
static double dummy_get_current() { return 0; }

static soundchip_config dummy_config  = {
	"dummy",
	dummy_change,
	dummy_get_default,
	dummy_get_current,
};

void SoundChipRegister(INT32 nChip, soundchip_config *config)
{
	cheat_core *s_ptr = &soundchips[soundchip_init_pointer];

	s_ptr->soundconfig = config;
	s_ptr->nChip = nChip;

	soundchip_init_pointer++;
}

static void SoundChipRegisterInit()
{
	for (INT32 i = 0; i < SOUNDCHIP_MAX; i++) {
		soundchip *s_ptr = &soundchips[i];
		s_ptr->soundconfig = &dummy_config;
		s_ptr->nChip = i;
	}
	soundchip_init_pointer = 0;
}

We could then call SoundChipRegister when initializing a sound chip, and later have some frontend dialog to query/modify volumes for all registered sound chips.
Does it sound like a good idea ? Any ideas/corrections welcome !

[dinkc64]

This is a great idea!
I would also like to suggest a last option:
a post-mixing master gain. This will allow for changing the
volume of all the sound chips, leaving the relative volumes intact.

so:
something like: (of course, it will be capitazlied how you want it, this is just pseudocode
to get the point across)

soundchipsetvol(chip#, x.xx); to set chip's volume for both channels/routes
soundchipsetvol(chip#, route, x.xx); to set chip's volume for route specified
soundchipsetmastergain(x.xx); // sets master gain

Final amp stage:
for example:
(it goes through all the chips and renders them like usual)

void soundchipRender(pbso, len) // <-renders all chips
{
for (int i=0; i< soundchips_count; i++) {
chip[x].render(pbso, len);
}
if (master_gain != 1.00) BurnSoundTweakVolume(pbso, len, master_gain);
}

EDIT: the <> code feature on this editor don't work any longer, weird?

as you can see, mastergain will set the final volume, leaving the all the chips'
relative volumes the same.

BurnSoundTweakVolume() will also let you know if we're clipping (but only
after applying the master gain)
see src/burn/burn_sound.cpp

best regards,

• dink

[dinkc64]

I thought about this some more. Maybe we should apply the master gain(volume) somewhere else down the line so that we don't have to ever call a new function like soundchipsrender(), as I've mentioned above.

I also wrote a bunch of nice little sound effects;
delay, reverb, chorus, stereo widening

some day I'd like to add them somewhere/somehow :)
One of them is already in the NES driver, it can be enabled via dip "Stereoizer"

best regards,

• dink