Amiberry / Pimiga 3

[giantclam]

How are you obtaining FPS values?

[giantclam]

There's 2 strains of the JIT code in amiberry ~ 32 & 64 bit .... I very much have to meld the pimiga stuffs into a 32bit raspOS setup, and retest this some.

You need to detail exactly what audio you're talking about..ie; amiga demo or game being used at the time. I don't think it's display, but FTR I'm using a Philips 273V5LHAB

I ask about the FPS values because such monitoring introduces other quirks ...the only instrumentation I'm using currently are ears & eyes...(and having been around Amigas since they began =)

[giantclam]

Originally Posted by vatovey

Hey Giantclam,

Oh my goodness, I can't thank you enough for spending so much time trying to get to the bottom of this.

Tested at 1080p with JIT off - same issue, FPS averaging 30-35, very choppy audio.

Tested at 1440x900 with JIT off - FPS pretty much locked in at 50, perfect audio.

Tested at 640x480, 640x512, 720x400, 720x576, 800x600, 1024x600, 1024x768, 1280x720, 1280x1024, 1440x900 - audio working perfectly, FPS locked at 50FPS for these resolutions.

Tested at 1920x1080 - audio choppy, FPS 32-42fps

Tested at 2560x1440 - audio choppy, FPS 32-42fps

Removed Pulse audio as suggested, didn't resolve audio choppyness at 1080p

Is this a monitor issue possibly.

Can you do 1680x1050 ?....just curious

[vatovey]

Using the Amiberry built in FPS viewer.

Am simply trying to play mods Workbench via Eagleplayer etc...

Games and Demo's seem to work ok, assuming because they are relatively low-resolution compared to Workbench.

I have recorded a video for you to see the differences between 1920x1080 and 1440x900

I can view 1680x1050 on the Linux side of things, but not in the Amiga.

Apologies for the wonky angle of the recording, hopefully it will give you an idea of what I'm experiencing.

https://www.dropbox.com/scl/fi/8j3pz...fkr8tuhyd&dl=0

[giantclam]

Originally Posted by vatovey

Using the Amiberry built in FPS viewer.

Am simply trying to play mods Workbench via Eagleplayer etc...

Games and Demo's seem to work ok, assuming because they are relatively low-resolution compared to Workbench.

I have recorded a video for you to see the differences between 1920x1080 and 1440x900

I can view 1680x1050 on the Linux side of things, but not in the Amiga.

Apologies for the wonky angle of the recording, hopefully it will give you an idea of what I'm experiencing.

Thanks for that ~ it puts you in the running for the 'worst vid I've had to review in 2023' award <grin> ...but it serves purpose enough to demonstrate the usage scenario


About that ... 'usage scenario' ...what you're doing there is something I never entertain. This is me saying, that if I want to listen to a mod file, then all I'm interested in is the accuracy, clarity and quality of the sound replay ... end of story. To that end, I have no need to start an Amiga emulator, to load up Workbench, to play the modfile there with one or another native Amiga modplayer ~ I just play the file directly in debian... [ Show youtube player ]

The only reason I run Workbench in an emulator, is if I need to ~ that would include running Amiga native apps (I like Algomusic =), running .exe demos.... anything that absolutely requires a running AmigaOS & Workbench...and when that is the case, it's a very spartan Workbench install, with only what's required...


...with amiberry, everything gets launched directly...ie; I'm not going to start Workbench, to play a game that I can directly launch (floppy images, CD iso/bin/cue, whdload archives)...it's just 'senseless' to me...especially if it's a lower powered device (handheld)... I mean, geez... not even the amiberry GUI gets launched around here...


This is not me dismissing an obvious audio problem ~ that I'm none too sure about at the now, could be anything from SDL2 audio/mixer to something in the core uae engine, but I know on x86-64 I can simulate the same effect of sorts, by launching classicWB (1280x1024) with amiberry, and launching another 1 or 2 amiberry instances (768x576 each)...one running a music disk and the other running a game ...the audio will devolve into something almost identical to what you're getting....


....I know that's an unrealistic usage case, and close to the Zappa line of "... and they danced with depraved abandonment around a six foot high pile of transistor radios, each one turned to a different station...", but I'm not CPU/ram limited, and have the headroom to answer inane questions like.."what happens if I <insert stupid idea>?"


Now that I know your actual usage case, I can have another look...but as mentioned before, I'll do that on a vanilla 32bit debian bookworm install, and compile amiberry against that specific layout, and meld in the pimiga stuffs...suck it and see. I want to see the 32bit JIT code working anyhow, to see if it's just as borked/broken as 64bit JIT.

[vatovey]

Indeed, I would gratefully receive any 'worst video' award lol , I did try doing native screen-recording on the Pi using Vokoscreen, but it slowed everything down to unusable - even at lower screen-resolutions.

The reason I use Workbench is quite simply because I like to play about in it, and have some music running in the background, along with launching games/demo's from igame.

I really can't see my setup being 'that' much different to anyone else's, which is why I'm surprised I've not seen a considerable more amount of Amiberry users experiencing similar to audio issues that I am.

I should note that I don't believe this is a Pimiga issue, as I experienced the same issue when using Amibian - I suspect it's a UAE / Amiberry issue. Also, I experience the same issue on various Pi 4's - that said, I think all my Pi 4's are probably early gen Pi 4's, as they were all purchased reasonably soon after the Pi 4 launch.

Anyways, if there is anything I can help with - please let me know.

[giantclam]

There's no significant difference between models ~ https://core-electronics.com.au/guid...-Raspberry-Pi/

I've yet to find ~any~ reviews (or YT vids) showing Pimiga working at 1920x1080 ..none..

I'll have another poke at it later ~ the 32bit latest raspOS is all Xwayland so that throws a spanner in the works, but even so, at 1920x1080 ..if you start AmigaAmp (no music playback, just launch it)...it can't even pull off a smooth text scroll in it's tiny little window, and if you want to really pay attention the jitters in the text scroller coincide with the audio interruptions ...this is a lost cause =)

You can help ... find me a review/video showing Pimiga running 'properly' @ 1920x1080 8)

[giantclam]

Originally Posted by vatovey

I really can't see my setup being 'that' much different to anyone else's, which is why I'm surprised I've not seen a considerable more amount of Amiberry users experiencing similar to audio issues that I am.

Oh, don't worry ~ I feel like the only person on Debian x86-64 desktop using amiberry, for exactly the same reason ; no-one else complaining. Which is especially odd when I consider I found a couple of bugs that were absolute show-stoppers... not to mention the binary packages not always working on every deb instance they should, that fact amiberry has a hate relationship going with nvidia drivers, and last I checked the current amiberry tree has some real problems on deb 10.xx ... not a whisper from the masses =)

[giantclam]

M'kay.... I did get it to work, but I'm none too sure at this point where the problem is (was =)

Installed/setup this image --> https://downloads.raspberrypi.com/ra...64-full.img.xz

At setup create the new user account 'pi' with whatever passwd you want. (just saves mucking about with owner/perms)

Tarball the user 'pi' homedir and copy that to the rpi4.

Add dependencies & clone the amiberry source as per https://github.com/BlitterStudio/amiberry on the rpi4

make PLATFORM=rpi4-64-sdl2

Untar the archive into /home/pi/pimiga/ (you only need the disks directory)...tar will bitch about some timestamps being in the future, ignore)

Start amiberry and load the Pimiga32.uae file (stick that into the amiberry/conf directory)

Make sure CPU configuration is 68040 with JIT enabled

Press start in amiberry gui .... seems to work fine

[vatovey]

I assumed most people were running their Pimiga's at 1080p tbh - maybe I'm wrong in that assumption.

Hmmmm, is this indicating something up with the current Pimiga build - like you said, whether its a host os issue, or an Amiberry issue is unknown.

Does Chris the creator of Pimiga frequent these forums ?, I guess he would know if 1080p audio is stable... or not.

[giantclam]

Originally Posted by vatovey

I assumed most people were running their Pimiga's at 1080p tbh - maybe I'm wrong in that assumption.

Hmmmm, is this indicating something up with the current Pimiga build - like you said, whether its a host os issue, or an Amiberry issue is unknown.

Does Chris the creator of Pimiga frequent these forums ?, I guess he would know if 1080p audio is stable... or not.

Define "Pimiga build" ~ it's just a debian raspOS with amiberry + Amiga files. The Amiga files I just treat like I would ClassicWB (or any other WB setup) ...there's nothing 'special' here so to speak...(although I question the ethics distributing an Amiga Workbench setup without needing AmigaOS disks...if you know ClassicWB, you know what I'm talking about). The boot straight into emulation shizzle is just user configuration files...in the debian setup ~ don't look for 'magic' here, there is none...


....like...consider ; I just installed the raspOS in bog standard trim, no configuration changes to the base system what-so-ever (caveat the pironman stuffs), compiled amiberry from source, put the pimiga directories in place, and it worked fine (at 1920x1080). The Pimiga documentation seems a long way from where the raspOS I installed is today...


..I can tell you audio was fine at 1080p ...perhaps a tiny bit better over 3.5mm audio out compared to HDMI audio....but like I say, I didn't have to touch anything ~ the raspOS defaulted to 3.5mm out ...there is no CEA/DMT modes anymore for video, no hdmi_groups etc ...and the only real difference is that with the pironman setup I'm booting from USB which is connected to the M.2 SSD...I don't think that's participle however, but I should check it to be sure.


Not sure if Chris comes here ~ I could spin off an image, but I doubt he'd be happy about someone doing that (going by what I read on his site). I'm merely reporting it does work 'as expected' following the installation route I example above =) Oh, and FTR, 32bit JIT crashed and burned like a carbon fiber submersible (libc.6 hurling chunks, so don't go there...lol...)

[stainy]

1080 has been stable for me for ages! audio too. Come to the discord and we`ll help

[giantclam]

Originally Posted by vatovey

Is this a monitor issue possibly.

It's a variable, but I don't think so ~ you can examine /var/log/Xorg.0.log and see what resolutions EDID of the monitor is reporting .....I say I don't think so, because I was able to recreate the issue here on the 273V5 and the 'fix' as it were had nothing to do with the monitor =)

[vatovey]

Have managed to resolve the issue with the help of Stainy - very very much appreciated sir.

Edit /home/pi/amiberry/conf/amiberry.conf

change from use_sdl2_render_thread=no to use_sdl2_render_thread=yes

This change is required if a user compiles a version of Amiberry themselves, I did compile the latest version of Amiberry (v5.6.1).

Restart Pimiga, set resolution to 1920x1080, exit Pimiga - set Linux screen resolution to 1920x1080. Start Pimiga once again and audio should then work fine at 1080p.

Thanks giantclam for the all the help / suggestions to - again, very very much appreciated boss.

[giantclam]

Thanks for getting back to this thread (imho discord is a pita =), and that you found a solution.

Just to elucidate, when compiling from git/source, the default amiberry.conf file has that setting default to no/false .... if you look at the amiberry wiki ...



... you may be able to fathom why 'use_sdl2_render_thread=no' is the default position =)

That aside, the cause of this would've been your upgrade path when moving from amiberry v5.5b to v5.6.1 ,,,, if you wanted to avoid this, as the pi user ..mkdir tmp ; cd tmp ; do a git clone of amiberry into this directory, cd amiberry, compile, and then copy/overwrite the files in ~/pi/amiberry with the newly compiled binary and data directory, and you then don't overwrite any conf/*.* files. That'll be a handy hint for the next amiberry release =)

[giantclam]

I asked midwan about this scenario...(quote);

Several targets have that option as default in the Makefile (look for -DUSE_RENDER_THREAD). When that is defined, the use_sdl2_render_thread option is enabled, however this does not override what you may already have in the amiberry.conf file.

So in other words, the default option applies if there is no amiberry.conf file yet, in which case it's regenerated with the default values. If there is a file already, the values in there are respected.

The file included in the repo has that value disabled for maximum compatibility, so if you overwrite your local file with the one from the repo, you would end up disabling that option. I'm guessing that's what happened in the case you mention above.

Due to the fact rpi4 has problems with KMS/console, the -DUSE_RENDER_THREAD is not set, and for compatibility here, use_sdl2_render_thread=no is the default for amiberry.conf

[Solskogen]

To be a bit more technical about it. It's not rpi4 that has problems with KMS/console, but the SDL support. The same thing applies to x86_64.

[giantclam]

True that ~ fortunately here, the Pimiga emulation starts after a Xsession is spawn, so I didn't think to draw too fine a point =)