Emotion - Does it work under QEMU?

@smarkusg

Im used only gtk for qemu. Is there benefit to use sdl instead?

@Mlehto
Changes to the mplayer (sdl) settings must be made under AmigaOS4.
I use QEMU on a Mac Mini M1. My audio and video outputs are native to Apple's “cocoa”

@Mlehto
Quote:
The default TB cache size is 1/8th of host memory or 1GB otherwise so in your case the default is also likely 2GB and the tb-size option does nothing for you.
Quote:
Having more than 64MB video memory is not possible with sm501 because the register encoding the memory size does not allow more (and drivers probably would not use more either). The default is already the maximum the sm501 can support so the option could only decrease it and only some specific power of 2 values are valid.
Quote:
The Linux scheduler should take care of that without nice, what may help a little is pinning the QEMU process to specific CPU cores which some vfio guides suggest but it probably does not make much difference as you noted above.
Quote:
Depends on where you get your binary from or how your distro compiled it. Some distros may already use optimised settings others may be more conservative.
Quote:
How did you measure that? Disabling mttcg might avoid some locking that is not needed for single vCPU but this should not have noticable overhead. If it has maybe this should be investigated or have QEMU automatically disable it for machines with single CPU.
Quote:
Currently it has a limit that makes it slower than expected and as smarkusg noted it may be worse with RX cards so probably HD cards work the best now. The limit is not fully understood, even on real machines there seems to be some issue but on QEMU it's even worse. I have a theory on the QEMU side but did not have time to investigate. Maybe I try to bring that up on the QEMU list and see if somebody there has an idea on how to improve it. But at least vfio passthrough allows using 3D and should be faster than software rendering.

@smarkusg

Yes, I've modified the settings for mplayer to use sdl for both audio and video. It has improved, but not completely fixed the stuttering and out of sync mouse to voice sounds.

@n3m3
You haven't shared enough info on what machine you run QEMU on. All you said so far that you're using QEMU 9.2.1 via Kyvos but no idea on what host OS, what CPU, what sound backend, what soundcard under which AmigaOS version. It's hard to tell what could be your issue or how could it be improved without more info. It could be that your machine is not fast enough, could be the QEMU version is too old or not compiled with optimal settings but we don't know what machine, what host OS you use and where did you get QEMU from for it so we can't tell if anything could be improved. With the info available so far the only thing I can say to answer your question is to try latest QEMU on the fastest machine you have.

@balaton

- Debian 13 Trixie
- GMKTec G5 Mini (Computer)
- QEMU from debian repository

Kyvos

- CPU = default
- Memory = 2048
- Display = sm501
- Renderer = gtk

@n3m3
Quote:
This has an Intel Alder Lake N97 CPU which only has 2GHz E-cores that can only turbo boost to 3.6GHz for limited time. It's not very fast so this may be pushing its limit. For QEMU single core performance is needed so a faster i5 or i7 should run better which have 3GHz base clock and turbo boost around 4GHz.
Quote:
The patch that sets try-poll=off default for alsa backend was from this March so only present in QEMU 10.1. This is known to cause sound issues in earlier version which need the command line option mentioned above but if you're not using alsa then that's not causing it. I don't know how Kyvos configures audio. If you can set it you could try alsa with try-poll=off or jack that have lower latency than pulseaudio or pipewire and maybe try -device ES1370 instead of via-ac97 but I don't know if any of this helps or how to configure it with Kyvos and what default sound server Debian uses and how to change that.

In general, it would be nice to specify the thresholds at which emulation works.
It would be useful for everyone to know what to expect when running qemu-ppc.
Some simple test that can run qemu-ppc even on Linux, not just on AOS4 itself.

I remembered something that @balaton created some time ago.
link - > http://zero.eik.bme.hu/~balaton/qemu/amiga/pegasos2-lame-test.zip
LAME test posts to run on QEMU PPC.
The time results would be a reference to the speed of qemu-ppc.
If it is lower than the set threshold, the emulation may run slower; if it is above the set threshold, the emulation should run at a satisfactory speed.

@walkero
This may also be useful for Kyvos. It could be added “check system speed under Qemu-ppc”.
The sources (linux kernel/LAME) are GPL, so nothing would violate any license.

@balaton

Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 497
Tile Size: 65472
User Name: niter3
Host Name: amiga
Server Name: PulseAudio (on PipeWire 1.2.7)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_00_1f.3.hdmi-stereo
Default Source: alsa_input.usb-CSCTEK_USB_Audio_and_HID_A34004801402-00.mono-fallback
Cookie: 4d90:bce8

Just updated to Ubuntu 25.10 which incluces QEMU version 10.

Still no dice. Is it safe to say it's because of the host computer just being to slow?


QEMU emulator version 10.1.0 (Debian 1:10.1.0+ds-5ubuntu2)
Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers