03401: circusc and clones: Slowdown in attract mode with DIP SW "Demo Sounds=ON"

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03401	Speed	Minor	Always	Aug 23, 2009, 07:29	Aug 23, 2009, 19:55

Tester	rte	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	No change required	OS	Windows XP (32-bit)
Status [?]	Closed			Driver	konami/circusc.cpp
Version	0.133u3	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	03401: circusc and clones: Slowdown in attract mode with DIP SW "Demo Sounds=ON"
Description	This bug occurs in attract mode (not during gameplay) and when the DIP SW "Demo Sounds" is set to "on". You may notice it with older computers only: On my Pentium 4 machine (1,7 GHz Willamette), I have temporary slowdowns in attract mode (FPS OSD reads ~30%). These slowdowns last several seconds. With my Core2Duo machine, there are no such slowdowns.
Steps To Reproduce	Start game. If DIP SW "Demo Sounds" is set to "off", change it to "on" and restart the game. Watch demonstration in attract mode.
Additional Information	As this bug is influenced by the "Demo Sounds" DIP SW, it may be related to sound hardware emulation.
Github Commit

Flags
Regression Version	0.129u6
Affected Sets / Systems	circusc and clones

Attached Files

No.04848 Fujix Administrator Aug 23, 2009, 09:36 edited on: Aug 23, 2009, 09:37	Core2Duo is enough fast to run the game at normal speed. This game uses Discrete Sound. These games usually need a lot of CPU power. On my PC with C2D, when I enable the demo sound, it is a lot slower (not as much as effecting the game play though): Demo Sound ON: D:\mame>mame -str 120 -nothrottle circusc Average speed: 542.80% (119 seconds) Demo Sound OFF: D:\mame>mame -str 120 -nothrottle circusc Average speed: 2124.39% (119 seconds)
No.04849 rte Tester Aug 23, 2009, 09:53 edited on: Aug 23, 2009, 10:06	I did some checks with older MAME versions. 0.129 is the latest version without slowdowns. I did not check the intermediate source updates. Version 0.130 and up have this bug. 0.125 to 0.128 had similar problems, but much slighter slowdowns. This matches the change to discrete sound emulation at 0.124u1. I wonder why 0.129 is performing perfectly then. If discrete sound emulation was the cause for the slowdowns since 0.130, shouldn't there be even more slowdowns while playing the game, since there is additional background music? The opposite is the case, during gameplay, there are no slowdowns.
No.04850 rte Tester Aug 23, 2009, 10:21	Here are some benchmarks from my Pentium 4 machine to compare: Version 0.129 with demo sounds on: Average speed 222.45% (119 seconds) Version 0.129 with demo sounds off: Average speed 425.68% (119 seconds) Version 0.130 with demo sounds on: Average speed 80.26% (119 seconds) Version 0.130 with demo sounds off: Average speed 383.76% (119 seconds)
No.04851 Tafoid Administrator Aug 23, 2009, 13:01	Something sound related if definitely triggering it. Regression to 0.129u6. I'm going to acknowledge this until it can be determined what the cause is. Once sound starts in the demo or if after a couple of seconds there is no further sound, the performance drops (about 40-50%) as noticed until a sound effect is made. Since there is music all the time in the game, it appears that there is no time for this 'bug' to manifest itself as there is almost always something being played. The only work on 0.129u6 was some device tagging in the driver - but I doubt that alone would cause the issue.
No.04852 couriersud Developer Aug 23, 2009, 14:54	This is not a bug. The konami filter emulation (DISCRETE_RCFILTER_SW) is expensive. If the filters are "off" it takes a faster execution path. If both filters (per channel) are "on" a longer execution path is needed. There had been changes to DISCRETE_RCFILTER_SW for 0.129u6. For some reasons they were not recorded in the whatsnew. Marked as BTANB.
No.04853 Fujix Administrator Aug 23, 2009, 17:20	Ah, BTANB is for original bugs. Nothing is wrong in this case, so this should be closed with the resolution of "No Change Required".
No.04855 Tafoid Administrator Aug 23, 2009, 19:55 edited on: Aug 23, 2009, 20:33	I'm posting this note based on a discussion with couriersud on this subject and questions from myself and others about how this can be happening: From a discussion with Couriersud on this matter, here is a further explaination: The speed depends on the state of the "konami" filters. This is a parallel RC discharge circuit where the RC elements can be "switched" on/off. If both are on, the performance drops, because we are doing 10 iterations to determine the next state. Now, whether they are on/off depends on the software. They are most likely on if there is music. Whether the sn76496 is doing something or not doesn't bother the discrete core. It gets the stream which is passed back from sn76496 to the streams core. Completely decoupled. Whether or not sound is played, the sound cores deliver the same amount of samples to the stream core. Whether or not sound is played the discrete core will process 48000 samples every second. If the software switches the filters on, it will slow down. Whether there is something audible or not. It is weird, but no sound in this case means more processing. No sound just means 48000 times a second a sample with amplitude 0. This is processed with both filters on ==> heavy cpu load. There may be room for optimization here, but it is not a bug. Scramble e.g. heavily depends on these filters. Some modification you can do: Change disc_flt.c line 1063 to read: #define DST_RCFILTER_SW_ITERATIONS (1) This should lessen the effect of the filters. Change line 1074 to if (0 && DST_RCFILTER_SW__ENABLE) This will completely disable the module and result no sound. The example only proves that the issue is related to the konami filters.