emulation slows down considerably on Linux Mint within a minute of starting if sound output is enabled

[Girgitt]

Thank you for the hard work and incredible result.

I noticed some issue with emulation speed with default settings.

With crook5 loaded to MX-16 (by following wiki article) emulation slows down to about 3 chars/sec printing time to the built-in terminal.

how to reproduce:

1. follow wiki to configure crook5 image
2. turn key from off to on
3. toggle "start" up
4. toggle "clock" up
5. open terminal (rmp-> Open terminal)
6. wait until machine settles (allocation map lights up then changes to top two rows partially allocated)
7. issue ctrl+del in the terminal and login as boss
8. run lif command couple times

Toggling "start" temporarily restores full speed.

Issue is not present if sound output is disabled in settings.

[jakubfi]

For starters: run the emulator with "LIB" and "APP" logging enabled (em400 -l lib,app or enable logging and LIB+APP components in Emulator->Settings->Logging) until it slows down and then some, and attach the log file.

If you could also provide information on:

• audio hardware
• audio backend
• VM or baremetal?
• em400 and overall system CPU usage when the emulation runs

Problems you've encountered are a known limitation of how emulation tracks instruction execution time and stem from emulation vs audio clock desynch. Mostly mitigated, but still awaiting a "proper" fix. Toggling "START" allows those clocks to sync up again, thus resolving the issue.

[Girgitt]

Here are two logs uploaded to onedrive

1. zip file has log from the time issue occurred with all logging subsystems enabled
2. log file has only lib and app subsystems enabled (and does not tell much)

audio hardware:
$ sudo aplay -l**** List of PLAYBACK Hardware Devices ****
card 0: sofsoundwire [sof-soundwire], device 2: Speaker () []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 5: HDMI1 () []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 6: HDMI2 () []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofsoundwire [sof-soundwire], device 7: HDMI3 () []
Subdevices: 1/1
Subdevice #0: subdevice #0

$ sudo cat /proc/asound/cards
0 [sofsoundwire ]: sof-soundwire - sof-soundwire
DellInc.-XPS139350--0MMW13

audio backend:
$ pactl info | grep "Server Name"
Server Name: PulseAudio (on PipeWire 1.0.5)

baremetal

CPU usage in htop (100% == one core of Intel Ultra 7 258V)
4-10% in idle
25-35% when executing lif command

If this is not a known issue then do not waste time on it. I am running custom Dell kernel (6.17.0-1023-oem) on xps9350 due to Linux compatibility issues on this xps model which may contribute to the problem or make it harder to diagnose/reproduce.

With the sound disabled in settings I still get the switches/selector sounds and stable operation which is great.

[jakubfi]

Thank you! That verbose log was a good idea. The slimmed-down version did not carry enough evidence, problem was burried a bit deeper than I initially thought.

Short story long: As suspected - known issue and a workaround that usually works just fine, but somehow makes things much worse on your platform. It looks like at some point, for whatever reason, your audio device stops draining the buffer. I can't say where (pipewire? alsa? deeper in the kernel? hardware?) and I'm not sure if the stall is only brief or permanent. Either way - it upsets emulation timings and things break.

Proper fix for that is already planned. I'll leave the report open until the underlying issue is solved (which is really on the em400 side - misbehaving audio path is not an explanation for such behavior :-) ).

You could try playing with em400 sound settings just to see if that changes anything: Rate to 44100? Bump up the latency/buffers?

I'm curious: what is the "audible result" of that issue? What happens to the CPU audio when "LIF" starts slowing down?

[Girgitt]

ok so I think changing settings helped. With reduced sample rate I do not notice slowdowns anymore - for these settings to be exact:

sample rate: 22050
buffer: 2048
latency: 32ms

I tried about 5 different combinations and this is just the first "good" one. Certainly good enough for me :)

The "audible result" of the issue if the lack of the background "hiss noise".