cia interrupt issues with "fastes possible"

[MASHtm]

Describe the bug
With Amiberry 8.0.1 x86 (current git master locally built to RPM) ...
As soon as "fastest possible" CPU emulation is active classic CIA(B?) interrupt gets noticeable jitter/issues.
It is independent if CPU is 030 or 040 and if JIT is active or not.

To Reproduce
I used a module player which uses an execlib allocated CIAB interrupt with exact PAL timing (to mimic PAL VB interrupt) to play AMIGA mods and listened to the music. It is noticeable pretty fast that there are timing issues if one knows how the mod should sound. Samples seem to be played delayed sometimes/often.

I used my player from
https://aminet.net/package/mus/play/STP

It opens ciab.resource via OpenResource and calls AddICRVector. This works fine with all AMIGAs I know and even with FS-UAE 3 with 68040 JIT emulation which also feels like "fastest possible".

Expected behavior
Precise interrupt timing

Desktop (please complete the following information):

• OS: up2date Fedora 43 MATE
• both Intel Laptop and AMD Desktop show the same behavior.

Additional context
The AMIGA env is running my original A2000/Picasso-II setup with KS/WB 3.1 diskimages.

[midwan]

This might be an upstream bug (WinUAE), as the code is currently synced with that. It will have to be tested there to be sure as well.

[MASHtm]

I did some more tests and found one setting which influences this issue. It is the "Sound buffer size" setting. So maybe it isn't a interrupt emulation thing, but a general sound output issue? If I change it to 10 and resume amiberry freezes, including all my input, and I've to kill -9 it from console to get input on my graphical desktop back. Changing it to other sizes influences the sound issues, but I can't describe how in words yet.

[midwan]

Does it work better for you, if you switch to Push mode and reduce the buffer to 1 or even "Min" ?

[MASHtm]

No, with 1 or min and push I have a random distorted "click" noise every 1-2 seconds on both channels while the emulated AMIGA does not play any audio. While playing mods they are not changing and disturbing the played audio as well.

If I use the same CPU settings (040/fastes possible/JIT) but with a classic PAL WB3.1 screen from ADF and play mods with the same player everything sounds fine with "pull" and buffer size 6.

So maybe it's related to RTG/Picasso Emulation?

Disabling "mutlithreaded drawing" didn't change anything.
"Faster RTG" and changing Priority to "High" didn't change anything as well.

At least I assume that my initial report about CIA interrupts was wrong. Sorry for that.

[midwan]

Can you attach your .uae config used to replicate this? I'll need to see if I can recreate it here, to start debugging it.

[midwan]

@MASHtm
From a quick test here with my A4000 system clone, I think I can recreate it. I don't quite hear a "click", but more of a hiccup in the playback of the mod, every few seconds. So, not exactly what you described, but maybe related.

It only seems to happen if the player clones an RTG resolution. If I open it while using PAL, it plays back normally.
There isn't any option to choose what resolution it will use, is there? From the guide I saw it clones Workbench only.

I'll run some more tests to see if I can figure out where this is coming from. No other player I've tested so far does this, so I'm not sure what's wrong yet.

[midwan]

I've made a few changes to see if they help:

• Increased timer resolution to nanoseconds
• When the sound callback is used (Pull mode), always clear the buffer to silence first, to avoid playing garbage on underrun

Can you check if these help in your case?

BTW, testing with Eagleplayer, also using CIA for timing, doesn't have the same result.

[midwan]

FYI, while testing this on WinUAE for comparison, and having the Log output enabled, I noticed a bunch of messages like these:

29-264 [3007 001-063/060]: Audio 2 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=392
29-742 [3035 001-181/178]: Audio 1 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=112
29-742 [3035 001-181/178]: Audio 2 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=66
30-339 [3071 001-068/065]: Audio 0 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=90
30-339 [3071 001-068/065]: Audio 2 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=565
31-176 [3121 001-017/014]: Audio 2 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=29
32-012 [3170 001-226/223]: Audio 2 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=143
33-087 [3234 001-230/227]: Audio 1 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=97
33-087 [3234 001-230/227]: Audio 2 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=489
33-087 [3234 001-230/227]: Audio 3 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=85
33-565 [3263 001-087/084]: Audio 1 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=188
33-565 [3263 001-087/084]: Audio 3 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=146
33-804 [3277 001-147/144]: Audio 3 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=159
34-162 [3298 001-237/234]: Audio 2 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=143
34-162 [3298 001-237/234]: Audio 3 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=138
34-401 [3313 001-034/031]: Audio 3 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=60
34-520 [3320 001-064/061]: Audio 2 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=252
34-521 [3320 001-064/061]: Audio 3 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=142
34-760 [3334 001-127/124]: Audio 2 DMA wait hack ENABLED. OFF=401eb950, ON=401eb658, PER=158

In contrast, in Amiberry I see these instead:

30-281 [1271 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=81
31-081 [1311 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=170
31-880 [1351 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=259
32-681 [1391 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=216
33-480 [1431 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=134
34-479 [1480 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=209
35-883 [1550 : Audio 3 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=176
39-076 [1709 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=245
42-274 [1869 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=126
43-073 [1909 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=214
43-874 [1949 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=652
45-472 [2028 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=412
45-872 [2048 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=98
46-683 [2088 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=135
47-271 [2118 : Audio 3 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=138
47-471 [2128 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=594
47-671 [2138 : Audio 3 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=268
47-870 [2148 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=53
51-868 [2347 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=350
53-467 [2427 : Audio 2 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=0
56-025 [2554 : Audio 0 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=23
56-025 [2554 : Audio 3 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=23
56-985 [2602 : Audio 1 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=89
56-985 [2602 : Audio 2 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=145
57-624 [2634 : Audio 1 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=206
57-625 [2634 : Audio 2 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=48
59-544 [2730 : Audio 1 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=329
59-544 [2730 : Audio 2 DMA wait hack DISABLED. OFF=407109d2, ON=407105f4, PER=171

The audio emulation code has a comment about these log entries:

// check if CPU executed at least 60 instructions (if JIT is off), there are stupid code that
// disable audio DMA, then set new sample, then re-enable without actually wanting to start
// new sample immediately.

So now at least I have something to dig further into.

[midwan]

Should be fixed with the latest commit now, please report otherwise!

[MASHtm]

First of all thanks for your efforts!

To be honest... it's worse now. I get a constant clicking every 2-3 seconds on both channels and the sound is interrupted even with eagleplayer. JIT on/off makes no difference. push/pull no difference. buffersize influences the rate of clicks. Lower size means shorter click interval.

The clicking starts after the first audio was played and stays until F12. After resuming if buffersize is changed it only starts again after the first sound is played as well. Without config change it resumes clicking immediately.

My config:
MASH-2000.uae.txt

Picasso-II Screenmode is 1024x768 8bit
Debugoutput shows:

INFO: RTG conversion: Depth=4 HostRGBF=8 P96RGBF=6 Mode=1/1
INFO: SNDRATE 263.0*227.5*59.280407=3546895.000000
INFO: NTSC mode V=59.2804Hz H=15590.7471Hz (227x262+1) IDX=-1 (<?>) D=0 RTG=1/1
INFO: RTGFREQ: 262*59.2804 = 15531.4668 / 59.3 = 262

I usually use my player with (undocumented beta) ToolType "DEFPUB=on" and "DEFPUBPOS=x/y". It opens in a window on the DefPubScreen then, instead of cloning the Workbench Screen. The aminet .lha contains a .info with it as default.
If it can't open the window on DefPub for some reason (color space/alloc, ...) it falls back to opening a screen.

About that comment in the source... it's true that my player uses a in same aspects improved but mostly common modplayer routine, as most of us did back then. I never touched the DMA stuff so far. Looking at eagleplayer I can trigger that warnings as well if I switch the timing mode to "DBF wait" with default 400. In automatic mode, rasterline mode or DBF with 4000 the warnings disappear. They obviously improved that part in recent years.

Another common player, Delitracker II, triggers the same warnings ... so the comment is true that the common and quite old modplayer routines were not done to be perfect for current "as fast as possible" CPUs back then. Not sure if I want to blame them and call them stupid for real. I take the comment as a rant. But at least I know there is room for improvement.

Since the comment also states "(if JIT is off)" I'm not sure this hack is directly related to this issue because it happens independent of the JIT state.