GroovyArcade live-CD 2022 (collaborative effort)

[Substring]

GroovyArcade 2024.07 released

Nothing really new about it besides a bunch of updates that would anyway come with a uual update in GA.

Just a few more troubleshooting tools for the ISO (like fixing UEFI after the GA entry has been lost)

[mappy24]

I hope you can help me with this, I have a system that runs GroovyArcade 2020 perfectly with zero issues.  I'm trying to install the latest release and I can see Attract Mode OK, but when I select any game e.g. World Rally, it's like the frequency is wrong or something?  My monitor is a Hantarex Polo 20" and I've selected this in the video settings (I've tried Generic 15khz too, no change).

Here's what I see in game:
https://imgur.com/a/rynzxCl

Maybe a MAME video setting?

Any help appreciated!

[Substring]

Looks like a wrong monitor was selected. Try doing it again in gasetup

[donluca]

I've recently read that with 6.12 the linux kernel will have the realtime patches mainlined.

I was wondering if GA uses the realtime patches and if anyone has done any measurements against the "normal" kernel in terms of audio, video and input latency.

Always been curious about this.

[Substring]

The RT patch exists for years already, and was simply just not merged in the kernel. Quite some work has been made to have that RT patch merged for good inside the kernel. But maybe 2 years ago, Calamity made some tests with that patch: nothing better, nothing worse.

[intealls]

The RT patch exists for years already, and was simply just not merged in the kernel. Quite some work has been made to have that RT patch merged for good inside the kernel. But maybe 2 years ago, Calamity made some tests with that patch: nothing better, nothing worse.

I'm seeing benefit from the -rt patches when maximizing framedelay and minimizing audio latency as outlined in this post: https://forum.arcadecontrols.com/index.php/topic,160023.msg1770960.html#msg1770960 . The incoming/outgoing samples plot should be a continuous line without jumps, the -rt performs much better than the one without. This is still valid for me a couple of months down the line.

But you really have to measure it (and do that over a longer period of time, and examine video as well as audio). However, in practice I think the only way anyone would really notice would be the audio pitch shifts resulting from skipped frames. There might be drawbacks given all the hardware GA runs on, but for me whenever updating GA I build a new -rt kernel to go along with it and install that manually. But there is probably only a benefit if you really, really want to do something about those last couple of milliseconds of latency, and it could perform worse for some hardware.

I've also attached a new version of the rate filter (still only PortAudio) which should reduce audio pitch shifts with -syncaudio and high frame delay levels in case anyone wants to try it.

[edomatic]

Hi Intealls,

Could you elaborate on your findings with framedelay and where you noticed improvements using the RT kernel for GA.
You say you are in a couple of months, where do you notice the gains using RT?

[intealls]

Hi Intealls,

Could you elaborate on your findings with framedelay and where you noticed improvements using the RT kernel for GA.
You say you are in a couple of months, where do you notice the gains using RT?

Hi edomatic,

First of all, I'm pushing this system (an i5-46x0k@4.5 GHz) to its absolute limits. I've increased the frame_delay granularity to 100 instead of 10, so I get a 10x resolution increase in frame delay granularity.

I can observe two things:

* For whatever reason, it seems like audio update routine (callback) sometimes does not come at its required interval without -rt, it doesn't happen often, but it happens. So when the sound system should fetch samples, it doesn't. I'm not sure it's down to the particular hardware I'm using, but -rt seems to help here. I've attached the plots again (less cluttered) and this can be seen as a downward step in the plot.
* Frame delay will block until the last possible moment before emulating the frame and vblank, and as such the time after releasing frame delay is super sensitive if we don't want to miss vblank. -rt seems to perform better in this regard. Missed vblanks can be seen as upward steps.

BUT - I've spent a _lot_ of time tweaking this system, enabling the -rt patches might actually degrade performance for a given hardware configuration. But for my particular hardware and software configuration -rt helps.

[edomatic]

Interesting stuff intealls!
Have you by any chance checked in with Calamity on his view on this?, i believe i read a comment from substring saying calamity experimented with this about 2 years ago ? but a lot can change in that timeframe off course,(patches,updates,improvements..).it looks like you are on to something.
I would love to test this rt kernel out to see what the impact is on the games in terms of framedelay/audio latency performance.
I myself am on a i7 4790k with substring’s latest GA build running in pretty much vanilla.i have not experimented with rt kernels, is it hard is to set that up or modify /add that functionality to the existing build i have?

[Substring]

In terms of input latency, Calamity said the RT patch brought nothing when he tested. But I shouldn't speak on his behalf

[intealls]

In terms of input latency, Calamity said the RT patch brought nothing when he tested. But I shouldn't speak on his behalf

No this would seem reasonable, I don't think the -rt patch would improve that all that much. Also, it would be brutally hard to measure this without some custom equipment. The runs I did were 15 minutes long I think and you can see there are a handful of framedrops. Checking next-frame response with a high frame rate camera (this is what I do anyway) for such a long time would probably drive anyone insane.

Interesting stuff intealls!
Have you by any chance checked in with Calamity on his view on this?, i believe i read a comment from substring saying calamity experimented with this about 2 years ago ? but a lot can change in that timeframe off course,(patches,updates,improvements..).it looks like you are on to something.
I would love to test this rt kernel out to see what the impact is on the games in terms of framedelay/audio latency performance.
I myself am on a i7 4790k with substring’s latest GA build running in pretty much vanilla.i have not experimented with rt kernels, is it hard is to set that up or modify /add that functionality to the existing build i have?

Hi endomatic, unfortunately it's kind of a painful process.

I've attached PKGBUILDs for linux-rt and GM with the rate filter patch. Building the packages is probably best done on something faster than the 46x0k, linux-rt package needs makepkg --skipinteg, or you'll need to add the sha512sums to the PKGBUILD.

Also, if you try this make sure to disable automatic installation of linux-rt on GA, otherwise you might lose 15 kHz on pacman -Syu.

Then:

Install linux-rt kernel and GM package.

Modify kernel command line (idle=poll is probably the most important one here, clocksource can probably vary between systems):

mitigations=off idle=poll tsc=reliable clocksource=tsc

Stuff run on startup (most from arch wiki, the performance governor is critical if not set through kernel, unclear advantage from all the other stuff):

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
echo 2048 > /sys/class/rtc/rtc0/max_user_freq
echo 2048 > /proc/sys/dev/hpet/max-user-freq
echo 0 > /proc/sys/vm/compaction_proactiveness
echo 1 > /proc/sys/vm/watermark_boost_factor
echo 1048576 > /proc/sys/vm/min_free_kbytes
echo 500 > /proc/sys/vm/watermark_scale_factor
echo 10 > /proc/sys/vm/swappiness
echo 5 > /sys/kernel/mm/lru_gen/enabled
echo 0 > /proc/sys/vm/zone_reclaim_mode
echo 1 > /proc/sys/vm/page_lock_unfairness
echo 0 > /proc/sys/kernel/sched_child_runs_first
echo 1 > /proc/sys/kernel/sched_autogroup_enabled
echo 3000 > /proc/sys/kernel/sched_cfs_bandwidth_slice_us
echo 500000 > /sys/kernel/debug/sched/migration_cost_ns

/etc/sysctl.d/90-max_user_watches.conf:
fs.inotify.max_user_watches = 600000

Allow arcade user to run mame with nice -n -20 (important):

https://wiki.archlinux.org/title/Limits.conf

nano /etc/security/limits.conf

...
#@student        -       maxlogins       4
*                -       nice            -20

# End of file
...

Reboot and then run mame:

nice -n -20 mame [options]

To measure use PortAudio with a low latency (-pa_latency 0.004 or 0.008 or similar) and do nice -n -20 mame game -pa_log -v | grep 123456.123456 > game.log and use buf.py (in rate_filter.patch) to visualize it (requires python and some supporting packages, can't be done easily on GA machine).

[Substring]

I'd be really open to anything that would bring extra perfs to GM, with or without the kernel patch.

Regarding port audio : too many people complained about it, so it's not default anymore. I find it way to complicated to set up, and it's pretty hardware dependant.

For nice and such : is it worh with a default kernel ?

[intealls]

I'd be really open to anything that would bring extra perfs to GM, with or without the kernel patch.

Nice, Calamity has OK'd the idea of the rate patch - it should get rid of most audio pitch shifts but only works for PortAudio. But I've got some boring stuff left on it so it'll take some more time, it needs testing on Windows, and might need some additional cleanup etc. I'm currently running GA on an SBC so a vastly different machine than the i5, and it seems to perform the same on this platform, and seems to be needed here as well. But since most people use Windows it needs some testing there. Maybe it should be added as an "experimental improved soundsync" option or something.

Regarding port audio : too many people complained about it, so it's not default anymore. I find it way to complicated to set up, and it's pretty hardware dependant.

For most cases I think it should be adequate to do -sound portaudio -pa_latency 0.0xx  -audio_latency 1 to get improved audio latency. It should then use the default audio device, but I'm not sure how that works in GA with ALSA etc, it's up to PortAudio itself. When manually selecting the sound device they can sometimes switch order (so if you have two, sometimes one shows up as hw:1,0 and other times as hw:0,0 which can be really irritating). But this could probably be fixed with udev, but also needs some tweaking.

But in the general case, PA will require more tweaking than SDL, it's the nature of the beast unfortunately.

For nice and such : is it worh with a default kernel ?

I think some of the tweaks are probably beneficial, most of them deal with pushing framedelay. If you're looking to add something to GA I'd say probably the most helpful one would be to set the performance governor and run GM with -nosleep. Of all the tweaks this is probably the one that helps the most. Keep in mind though that power will go up (and heat as well). So it's probably not a good idea to use it on a laptop. Also nice is good if there are many background processes, -20 is probably overkill though.

But generally, most of the improvements will come when trimming the latencies. Most of them are from https://wiki.archlinux.org/title/Professional_audio and https://wiki.archlinux.org/title/Gaming#Improving_performance .

[pixeltao]

I hope I'm not breaking any forum rules already (this is my first post here). I registered just to say that I've built a GroovyArcade using an old ATI graphics card from the 2010s during the holdidays and it's freaking awesome! Playing all of these arcade games on my D-series CRT is just perfect! I already got 2 MiSTers but having the option to play the huge MAME library (including CPS3 and Midway games) is really cool. I was hoping to support this via a patreon or something, but I've read on github that it's not a thing for GroovyArcade, so I wanted to at least share how happy I am this exists. Fantastic work!

Cheers

[Substring]

GroovyArcade is Free. I'm not asking any kind of retribution for it. I'd feel really ashamed of getting money from assembling stuff mostly done by others. So no, it's just free, eriod.

And I'm glad it worked like a charm for you

[Sledge]

This is working really well now

[camebackhaunted]

Can anybody recommend a gun that works well with groovyarcade please?

[Substring]

CRT guns work but ... The problem with CRT guns is that their calibration depends on the screen resolution. And considering we play arcade with as many resolutions as games, it's a pita

Can't tell about IR guns or any other technology

[camebackhaunted]

Complicated with the multiple resolutions isn't it.  I guess IR would be the best solution perhaps?

[imfirus]

Hi, to all
I love groovy arcade, i use it with my intel I7 old PC and runs buttery smooth.
Since yesterday, i installed a fresh new Groovy Arcade 2022.1, thats the one my motherboard recognice perfectly.
All was installed good as always, but when i tried to install the retroarch frontend, i never could open it, it only opens the groovymame frontend.
Could you help me, did someone got this new error with retroarch??
When i tried to reinstall retroarch, it give me a message like this: "pacman -syu" and something about questions and my keyboard. This never happened before.
Please, help and thanks for your hardwork

[Substring]

My guess is that your system couldn't update normally. Hard to tell just so. Using 202.01 iso is not a good idea either, updating will be a little complicated