#364 Changing Emulation Speed 1000+ crashes Fuse

[windale]

I change the emulation speed to a very high setting to check if the RZX i'm about to watch will work on Fuse without giving errors. If you set the speed to just over 1000 it crashes Fuse. If you turn the sound off first then you can increase to several thousand no problem. I think Fuse needs to automatically disable the sound when setting the emulation speed above a certain level.

[Philip Kendall]

Which platform / sound driver are you using?

[windale]

Windows 7 Ultimate x64.

[Sergio Baldoví]

Thanks for the report. I've seen random crashes when running Fuse full-speed, on both Windows and Linux. My first thought was that it was a driver error or a faulty locking mechanism. Never looked into that too much.

Fred, what do you think about disabling/silencing the sound?

[Fredrick Meunier]

We used to not be able to do sound except at 100% speed and turned off the sound at all other speeds, when we got the ability to keep the sound on I changed that.

Based on this bug, I'm inclined to turn the sound off when the speed is above say 500%?

[Lee Tonks]

I've noticed a slightly different problem - dropping the emulation speed to 30% or lower doesn't work properly - at 30% you get slow periods with sudden bursts of speed. By the time you get down to 10% Fuse is just running at full whack all the time. 31% speed and above seems to work as you would expect.

I'm wondering if this might be related to the long-standing problem I've had with pause mode (surmising that 'pause' actually reduces emulation speed to 0%, I realise that might be a bit of a stretch!)

Sometimes when I engage pause and wander off for a while pause mode will remain active but emulation will resume, running at full speed for a couple of seconds and then resuming 100% speed but without sound. Turning pause 'off' again resumes normal operation. I haven't reported this before because I can't reproduce it on demand, but I've had the same issue for many versions now.

Windows 10 64 bit, as usual. Thanks for your time, all!

[Lee Tonks]

Just double-checked and yes, with sound off you can successfully go below 30% speed without issue, so maybe all of this might genuinely be the same thing. :-)

[Fredrick Meunier]

Hi Sergio:
Any thoughts about Lee's experience here? I don't see these problems with Fuse on the Mac with the CoreAudio driver - what do you get on Linux with sound enabled and emulation of 30% or lower?

If you also get problems in these circumstances I'd be happy to limit the sound enabled range to say 50% to 500% speed, otherwise it may be platform-specific and likely a bug in the sound driver/timing routines?

[Sergio Baldoví]

I've had a look and I can reproduce this issue, it's related to the directsound sound driver.

Below 22% of speed, Fuse is running at full whack. If I use the --sound-force-8bit option the barrier lows to 11%. Frequency changes with the --sound-freq option also alter this barrier.

The directsound sound driver use a ring buffer (~40 Kb) with locking mechanism. I got these figures (default freq 32000 Hz):

at 2% speed: 31949 samples/frame, 63898 bytes/frame, unable to get a lock
at 21% speed: 3043 samples/frame, 6086 bytes/frame, 100% buffer used, usual buffer overflows
at 25% speed: 2556 samples/frame, 5112 bytes/frame, ~32 Kb from buffer are used, ocasional waits to avoid buffer overflows
at 50% speed: 1278 samples/frame, 2556 bytes/frame, ~16 Kb from buffer are used
at 100% speed: 639 samples/frame, 1278 bytes/frame, ~8 Kb from buffer are used
at 200% speed: 320 samples/frame, 640 bytes/frame, ~4 Kb from buffer are used
at 400% speed: 160 samples/frame, 320 bytes/frame, ~2 Kb from buffer are used, usual buffer underruns

First impressions:

• The ring buffer should be adjusted to the frame size. Lower speeds need more memory.
• Buffer overflows are not detected and are overwriting sound data.
• Buffer underruns are not detected and the driver wrongly assumes that an empty buffer is full.
• At very high speeds the locking mechanish could be a resource hog. sfifo with interrupt monitoring could be more efficient.

I think disabling the sound at some high limit could be interesting, but the directsound driver still needs to be fixed.

[Fredrick Meunier]

Thanks Sergio - I'd probably put in a cap of say 500% speed to keep sound generation going for all ports as a baseline.

Do you plan to fix the issues in the DirectSound driver or should we be limiting when the sound generation applies in Windows to a safe range until we have a better sound driver?

[Sergio Baldoví]

I'd probably put in a cap of say 500% speed to keep sound generation going for all ports as a baseline.

Looks good to me.

Do you plan to fix the issues in the DirectSound driver or should we be limiting when the sound generation applies in Windows to a safe range until we have a better sound driver?

I will rewrite the driver, but not before the next release. If we can apply a quick workaround, a safe range for Windows would be 50% - 300%.

[Fredrick Meunier]

OK, I've added a patch to limit the speed as discussed in [87e827], I'll work on the release tomorrow.

[Sergio Baldoví]

Thanks. Works like a charm.