r-type
commented
4 years ago c'est cool,merci! by chance, an idea of how to replace sigaction and signal handler (to port it on vita)?
Closed Chips-fr closed 4 years ago
r-type
commented
4 years ago c'est cool,merci! by chance, an idea of how to replace sigaction and signal handler (to port it on vita)?
Chips-fr
commented
4 years ago Sorry i have no idea about signal handler part (many part of uae4arm is still cryptic for me). Is this core really used ? On raspberry the graphic part is always shifted, hence i never see complete screen... I tried repojohnray one. It is based on a puae libretro core adaptation with a gui based on hatari vs an adaptation from vice/arnold libretro core for this one. But i haven't clearly identify which one is more relevant to look at.
r-type
commented
4 years ago the repojohnray is surely more ahaead than this one. this one is prehistoric and should be avoided :) BTW i never had issue with graphic like you discribe. i must have somewhere a version of this core with sdl/libchan libretro gui , but not sure if it was working fine or not , it's too old.
Chips-fr
commented
4 years ago On which platform you're testing ? Are you loading .uae file ?
I found that my issue was link to internal uae display setting not inline with libretro display. Ex of trace when display is shifted: retro:(320,240) gfx(640,256)
Now if i ensure both uae display size and libretro one are aligned it's working. I see this issue and i load .adf, so it use default setting inside uae. If you're using a .uae file with right setting inside it could explain why it's working on your side...
r-type
commented
4 years ago @Chips-fr @twinaphex
Ok i've succeflully built uae4arm (poc) for vita!
Now before working more on it i have to know wich of your version is the best,
i mean you have you rpi repo and the libretro own,
it seem that you update the two.
is RPI is more update (in JIT point of view?)
Chips-fr
commented
4 years ago Good news. If you're talking about https://github.com/libretro/uae4arm-libretro vs https://github.com/Chips-fr/uae4arm-libretro they are based on same uae4arm code. I just push first in mine then pull-request here. But i do only minor update regarding libretro port and nothing in the uae4arm core. So both are based on the 2016 uae4arm you started from.
r-type
commented
4 years ago no i'am talking about https://github.com/Chips-fr/uae4arm-libretro VS https://github.com/Chips-fr/uae4arm-rpi
if if the last one is more advanced maybe it's a good things to redone the libretro patch using the most advanced one ( and re-add your new additions into it)
Also this uae4arm-libretro'was a very quick and bad port , i took my arnold libretro patch and past it into your code :( It wiil be nice if we can clear all that mess and done a proper port, it could make others want to watch and improve it like it was done for uae-libretro. I think this core deserves to have better port than the one i did in 2016.
Chips-fr
commented
4 years ago Yes the uae4arm-rpi is slightly more updated but i stopped in 2018/2019 (i only merge some JIT improvements in 2019). TomB ( https://github.com/PandTomB/uae4arm/commits/Raspi ) has updated his uae4arm further like adding ARM64 JIT support and merging latest winuae code (but with some little slow down, hence i was reluctant to take them ...). I haven't look but a simple drop of JIT/68k files should align JIT part. Anyway if we take whole JIT & winuae alignment i was thinking if adding ARM JIT in libretro-uae would not be easier at the end ...
r-type
commented
4 years ago ok merci pour les précisions ! i've have started some cleanup , started from your repo, goal is to have clean start base to working on ( removed all non libretro backend, cleanup unused func/gui in libretro part ...) https://github.com/r-type/uae4arm-libretro-1
Chips-fr
commented
4 years ago Note that i don't know if i will do so much improvements, my goal was to understand better libretro API and solving issue is a good way... at some time i was thinking to have a common source for libretro and rpi version. Have you seen improvement in audio ? Did controller still works in my latest updates ? Between you repo is not compiling ATM... :)
r-type
commented
4 years ago i've just fix and merge ! yes i've tested your sound change , it's nice! your controller update is fine , except it will move mouse when virtual keyboard is on , a bit annoying but simple to fix.
r-type
commented
4 years ago If you have some spare time to test on RPI to konw if i didn't break anything ?
But at least it works on vita !
Chips-fr
commented
4 years ago Yes your modifications still works on Rpi. So hdd works ? I never tried... I just look impact to merge latest uae4arm-rpi it was resulting in "only" 13 merge conflict before your update... now it's above 20... things diverge quickly :( moreover in latest source we have not only signal_segv but signal_buserror and signal_term. And you had to patch signal_sergv on vita :( This would be good to send pull request with your modifications to the libretro-uae4arm since it add a new target so it's a good thing.
r-type
commented
4 years ago Tant mieux si ça marche encore! anyways i can't PR directly to libretro as it's a fork of your repo, then the logic is to PR your repo , then you will be able to PR libretro :)
r-type
commented
4 years ago Ok i ve opened a PR
Chips-fr
commented
4 years ago You push two new fix that i didn't test, then now i have a malloc error in rpi :( ... the "merge" bullet was working. And i don't know why but there are conflicts in your PR...
r-type
commented
4 years ago Ok then i close PR until fixed strange the malloc error , the + 2 fix only concern thread.
Chips-fr
commented
4 years ago A buffer overflow perhaps ?
hardreset, memory cleared corrupted size vs. prev_size
Thread 1 "retroarch" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
r-type
commented
4 years ago I will try to find an RPI to test, maby related to my thread change then. at worst i ll revert the last 2 fix
Chips-fr
commented
4 years ago I send a pull request of my improvements, at least there is no merge conflict. I have no idea what is the issue, i'm a little bit stuck. What was the purpose of the last 2 fix ? Note that the least we update uae4arm file the more easier it is to align code with latest uae4arm version...
r-type
commented
4 years ago Ok.
I really want to keep the refactor/clean code , so i 'll keep my work beside this repo for now. I'will check later if it can merge here. also I will look at merge the uae4arm-rpi change in.
For the note, last 2 fix was for fix vita build (pb with sdl thread and usleep) the code was inspired by thread in puae.
Chips-fr
commented
4 years ago For memory overflow, i like to use libasan. I add -fsanitize=address -fsanitize=bounds in Cflags & -fsanitize=address -fsanitize=bounds in linker.
Then need to preload libasan: LD_PRELOAD=/usr/lib/gcc/arm-linux-gnueabihf/8/libasan.so retroarch
When i launch uae4arm:
hardreset, memory cleared src/custom.cpp:3770:15: runtime error: index 8 out of bounds for type 'sprite [8]'
==3692==ERROR: AddressSanitizer: global-buffer-overflow on address 0x9f3eabd8 at pc 0x9ea37ce4 bp 0xae33df94 sp 0xae33df8c WRITE of size 4 at 0x9f3eabd8 thread T0
0 0x9ea37ce3 in do_sprites(int) [clone .part.19] (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x15bce3)
#1 0x9ea3857b in decide_line(int) (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x15c57b) #2 0x9ea56417 in hsync_handler() (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x17a417) #3 0x9ebaa6af in m68k_run_2() (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x2ce6af) #4 0x9eba3d17 in m68k_go(int) (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x2c7d17) #5 0x9eafc6f3 in do_start_program() (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x2206f3) #6 0x9eafca3f in real_main(int, char**) (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x220a3f) #7 0x9f160243 in skel_main(int, char**) (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x884243) #8 0x9f16bd0f in pre_main(char const*) (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x88fd0f) #9 0x9f16bf6f in retro_wrap_emulator() (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x88ff6f) #10 0x9f16d187 in retro_load_game (/home/pi/.config/retroarch/cores/uae4arm_libretro.so+0x891187)0x9f3eabd8 is located 24 bytes to the right of global variable 'spr' defined in 'src/custom.cpp:136:22' (0x9f3eaae0) of size 224 0x9f3eabd8 is located 8 bytes to the left of global variable 'sprpos' defined in 'src/custom.cpp:140:42' (0x9f3eabe0) of size 32
Looks like issue in line 3770 in custom.cpp: spr[num].dmacycle = 0;
by debugging clearly num increase from 0 to 8. should not go above 7.
If i take do_sprite function as in latest uae4arm problem is done (num go from 0 to 7)
I have same error return by libasan for the "merge" bullet despite it was working. Could it be an old memory leak that your update highlight due to a change in mapping ?
r-type
commented
4 years ago hum strange, i finally succes to find a rpi3 and compile RA on a raspbian! I will try to compil (with and without reverting my two last commit) and see how it goes ...
Chips-fr
commented
4 years ago I still have some more crash which i have difficulties to track down... I didn't have them previously. If it's really memory overflow issue it could lead to different behavior on another setup... i'm on latest raspbian with update done.
r-type
commented
4 years ago I revert the two last commit , to use old thread api but i have crash:
free(): invalid pointer
Thread 1 "retroarch" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type. (gdb) bt
fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:181p=0x75ead54c <Retro_Screen+174072>, have_lock=<optimized out>)
at malloc.c:4165So you should better stay on your branch until i found how to fix them. I ll try to redo cleanup steps statring from the libretro repo tomorow
r-type
commented
4 years ago I don't understand, even if i build the libretro core (without any of my modifiaction) it crash
Uae4arm v0.4 for Raspberry Pi by Chips 0: 640x400, 16-bit (50,60) 1: 640x480, 16-bit (50,60) 2: 800x480, 16-bit (50,60) 3: 800x600, 16-bit (50,60) 4: 1024x768, 16-bit (50,60) 5: 1152x864, 16-bit (50,60) 6: 1280x960, 16-bit (50,60) load config '/home/pi/libretro/1SYSDIR/uae4arm/conf/uaeconfig.uae':3 obsolete config entry 'sound_bits' Option `gfx_correct_aspect' requires a numeric argument. Don't care mouse mode set starting sound thread.. retro:(320,240) gfx(640,480) res 1 RTAREA located at 00F00000 uaegfx.card magic code: 00F00FA0-00F010DE ABI=00000000 KSPatcher: 'scsi.device' at 00FB592C disabled KSPatcher: 'carddisk.device' at 00FBEC90 disabled KSPatcher: 'card.resource' at 00FC2978 disabled munmap_chunk(): invalid pointer
Thread 1 "retroarch" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type. (gdb) bt
fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:181from /home/pi/libretro/uae4arm-libretro-master/uae4arm_libretro.so
Chips-fr
commented
4 years ago In feel like it's a memory overflow, which could come from original source. memory overflow generate crash when overwriting other variables, hence the crash depends on mapping. I never had such crash previously because the overflow should have overwrite non important data on my setup. Your setup is different hence you could face it more often than me (and no occurrence on your vita).
I found one in custom.cpp do_sprite function, you can change 3758 & 3559 lines:
if (maxspr > SPR0_HPOS + MAX_SPRITES * 4)
maxspr = SPR0_HPOS + MAX_SPRITES * 4;with
if (maxspr >= SPR0_HPOS + MAX_SPRITES * 4)
maxspr = SPR0_HPOS + MAX_SPRITES * 4 - 1;But even with this modification i still have some crash on my side... Now i have no clues :( Another solution would be to hide it (change a compiler option...). Alignment with latest uae4arm code could help since it could have been solved in latest uae4arm code (as the one i found in custom.ccp )
Chips-fr
commented
4 years ago On which git commit your are ? reset_drawing is executed very early and i remember at some time i had some crash in this function if the resolution/configuration was not good... especially when retro & uae core resolution where not aligned (see retro:(320,240) gfx(640,480) res 1 in your trace)
r-type
commented
4 years ago I am on 1b0a50947195365565999543bff8770e82298d91 (last from libretro) Yes config file is annoyning , it will be nice if core create a default config file at first start if it doesnt find any configuration. edit: Also it doesn't crash when build with DEBUG=1
Chips-fr
commented
4 years ago If i remember well having retro and gfx returning different value was not good. And height higher than 270 (you have 480) was not good too. Does it work on vita ? Can you post uae file ? If you use uae file you can try to change gfx value with low one same are retro (320 x 240) DEBUG=1 change compilation option, and if problem disappear it's typical of a memory overflow or bad pointer behavior...
r-type
commented
4 years ago config_description=UAE default configuration config_hardware=true config_host=true config_version=1.5.3 pandora.rom_path=/home/pi/libretro/1SYSDIR/uae4arm/kickstarts/ pandora.floppy_path=/home/pi/libretro/1SYSDIR/uae4arm/disks/ pandora.hardfile_path=/home/pi/libretro/1SYSDIR/uae4arm/hdf/ ; host-specific use_gui=no use_debugger=false kickstart_rom_file=/home/pi/libretro/1SYSDIR/uae4arm/kickstarts/kick31.rom kickstart_ext_rom_file= flash_file= cart_file= kickshifter=false floppy0=State_Of_The_Art.adf ;df0.adf floppy0type=0 floppy0sound=0 floppy1= ;df1.adf floppy1type=-1 floppy1sound=0 floppy2= ;df2.adf floppy2type=-1 floppy2sound=0 floppy3= ;df3.adf floppy3type=-1 floppy3sound=0 nr_floppies=1 floppy_speed=100 floppy_volume=33 parallel_on_demand=false serial_on_demand=false serial_hardware_ctsrts=true serial_direct=false scsi=true sound_output=exact sound_bits=16 sound_channels=stereo sound_stereo_separation=7 sound_stereo_mixing_delay=0 sound_frequency=44100 sound_interpol=none sound_filter=off sound_filter_type=enhanced sound_volume=0 sound_auto=yes cachesize=0 synchronize_clock=yes gfx_framerate=0 gfx_width=640 gfx_height=480 gfx_width_windowed=320 gfx_height_windowed=240 gfx_width_fullscreen=320 gfx_height_fullscreen=240 gfx_refreshrate=0 gfx_vsync=true gfx_lores=true gfx_correct_aspect=false gfx_center_horizontal=none gfx_center_vertical=none immediate_blits=false fast_copper=true ntsc=false show_leds=false chipset=aga collision_level=playfields fastmem_size=8 a3000mem_size=0 z3mem_size=0 z3mem_start=0x10000000 bogomem_size=0 gfxcard_size=16 chipmem_size=4 cpu_speed=max cpu_type=68020 cpu_compatible=false ;hardfile=rw,32,1,2,512,/home/pi/libretro/1SYSDIR/uae4arm/game31.hdf ;filesystem=rw,Games:/media/SD2/pandora/appdata/uae4all/Games/ input.joymouse_speed_analog=20 input.autofire=8
Chips-fr
commented
4 years ago Try to change gfx_height to 270 and it should works. If i remember well current uae4arm source used doesn't support height above ~280... but it's another bug that the crash i'm having since your vita dev :( It works on vita ? And the screen is correctly displayed ?
r-type
commented
4 years ago Yes it works fine on vita and screen is perfect like in the above screenshot , strange. if i change to 240 it works on my RPI, even my modified version with refactor/cleanup/fix :(
Chips-fr
commented
4 years ago Just to confirm the height issue, look at init_row_map:
for (i = gfxvidinfo.height; i < MAX_VIDHEIGHT + 1; i++)And MAX_VIDHEIGHT is 270 in current source code. PUAE has very different init_row_map function and higher MAX value.
Even if it's works on vita there is clearly a misbehavor here if gfxvidinfo.height is above 270...
Then if you have no issue with your latest code on your rpi then it's on my setup...but i didn't catch what it is... note that i have thoses crashes on my orange pi too (allwinner based) You could anyway push your modifications, then a merge of updated uar4arm could solve it...
r-type
commented
4 years ago I mean it works here until the 2 fix commit (concerning thread change)
and just to be clear, i"ve just checked my vita config and its different than my rpi one igfx_height=240 so it's why it does not crash !
config_description=UAE default configuration config_hardware=true config_host=true config_version=1.5.3 pandora.rom_path=ux0:/data/retroarch/system/uae4arm/kickstarts/ pandora.floppy_path=ux0:/data/retroarch/system/uae4arm/disks/ pandora.hardfile_path=ux0:/data/retroarch/system/uae4arm/hdf/ ; host-specific ;pandora.horizontal_offset=0 ;pandora.vertical_offset=0 ;pandora.cpu_speed=600 ;pandora.joy_conf=0 ;pandora.joy_port=0 ;pandora.stylus_offset=0 ;pandora.tap_delay=10 ;pandora.custom_controls=0 ;pandora.custom_dpad=0 ;pandora.custom_up=0 ;pandora.custom_down=0 ;pandora.custom_left=0 ;pandora.custom_right=0 ;pandora.custom_a=0 ;pandora.custom_b=0 ;pandora.custom_x=0 ;pandora.custom_y=0 ;pandora.custom_l=0 ;pandora.custom_r=0 ;pandora.button1=2 ;pandora.button2=1 ;pandora.autofire_button=3 ;pandora.jump=-1 ; common use_gui=no use_debugger=false kickstart_rom_file=/kickstarts/kick31.rom kickstart_ext_rom_file= floppy0= ;disks/BombJack.adf ;euae/PinballMagic.adf floppy0type=0 floppy1= floppy1type=0 floppy2= floppy2type=-1 floppy3= floppy3type=-1 nr_floppies=1 floppy_speed=100 floppy_volume=0 ;scsi=false sound_output=normal ;sound_bits=16 sound_channels=stereo sound_stereo_separation=7 sound_stereo_mixing_delay=0 sound_frequency=44100 sound_interpol=none sound_filter=off sound_filter_type=standard sound_auto=yes cachesize=0 ;8192 synchronize_clock=yes gfx_framerate=0 gfx_width=320 ;768 gfx_height=240 ;270 gfx_width_windowed=320 gfx_height_windowed=240 gfx_width_fullscreen=640 gfx_height_fullscreen=480 gfx_refreshrate=0 gfx_vsync=true gfx_lores=true gfx_correct_aspect=0 gfx_center_horizontal=none gfx_center_vertical=none immediate_blits=false ;gfx_lores=true ;gfx_resolution=lores ;gfx_correct_aspect=1 ;immediate_blits=false fast_copper=true ntsc=false show_leds=false chipset=aga collision_level=playfields ;a1000ram=false a3000mem_size=0 fastmem_size=8 z3mem_size=16 z3mem_start=0x1000000 bogomem_size=0 gfxcard_size=0 chipmem_size=4 cpu_speed=real cpu_type=68020 cpu_compatible=false ;cpu_24bit_addressing=true rtg_nocustom=true rtg_modes=0x500 hardfile=rw,32,1,2,512,ux0:/data/retroarch/system/uae4arm/hdf/games31.hdf ;hardfile2=rw,dh0:/home/pi/retro/hdf/blan512.hdf,32,1,2,512,0, ;hardfile=read-write,32,1,2,512,/home/pi/retro/euae/hdf/System31.hdf ;hardfile=rw,32,1,2,512,/home/pi/retro/hdf/blank512.hdf input.joymouse_speed_analog=2 input.autofire=8
Chips-fr
commented
4 years ago Ok. the crash i see appears after the two fix.
For the height, in order to avoid crash with a 480 height i increase raw_map size:
from
static uae_u8 *row_map[MAX_VIDHEIGHT + 1];to
static uae_u8 *row_map[480 + 1];This avoid the overflow (you can try it instead of lowering the height) but i got a shrink by half display on my Rpi... so i don't catch how it works on vita... that's why i removed options for resolution above 270 (it was a mystery for me since it always crashed in rpi)
r-type
commented
4 years ago Ok then i reverted the 2 last commits and redone a fix for vita that use the current thread implementation.
Chips-fr
commented
4 years ago For the few tests i just made it seems problem disappears in your latest version :) Any clues what was the problem ?
r-type
commented
4 years ago not really, but better stay with that thread implementation ;) currently i'am trying to fix conflit after merging ( using the libretro-repo as origin and your uea4arm-rpi as upstream)
Chips-fr
commented
4 years ago Good luck for the merge, source has changed so much. The whole input (keyboard, mouse, joystick...) is completly different...
r-type
commented
4 years ago lol yes , better redone all the port than try to update this one!
r-type
commented
4 years ago Ok so far ... i've done a quick port, no input just the the basis to have a video output :) but it seem to be slow on my rpi3 (only 30fps on state of art) and screen is not correct
BTW,can you give me an working uae config for this version i can use as reference ?
Uae4arm v0.5 for Raspberry Pi by Chips Based on uae version: 3.5.0 Unknown keycode to use, will use keysym starting sound thread.. retro:(320,240) gfx(320,240) res 0 starting sound thread..
UAE4ARM Logfile
Allocated 400 MB for entire memory
KS ver = 0022
Stored port 0/0 d=0: added 200 0
Stored port 0/0 d=0: added 200 0 Nubs as mouse MOUSE0
Port0: ID 'mouse' matched
Stored port 1/0 d=0: added 100 0
Stored port 1/0 d=0: added 100 0 dPad as joystick JOY0
Port1: ID 'joy1' matched
Port2: NONE
Port3: NONE
0: 640x400, 16-bit (50,60)
1: 640x480, 16-bit (50,60)
2: 800x480, 16-bit (50,60)
3: 1024x768, 16-bit (50,60)
4: 1152x864, 16-bit (50,60)
5: 1280x960, 16-bit (50,60)
target_cfgfile_load(): load file /home/pi/libretro/1SYSDIR/uae4arm/conf/uaeconfig.uae
load config '/home/pi/libretro/1SYSDIR/uae4arm/conf/uaeconfig.uae':3
unknown config entry: 'use_debugger=false'
unknown config entry: 'kickshifter=false'
unknown config entry: 'floppy0sound=0'
unknown config entry: 'floppy1sound=0'
unknown config entry: 'floppy2sound=0'
unknown config entry: 'floppy3sound=0'
unknown config entry: 'floppy_volume=33'
unknown config entry: 'parallel_on_demand=false'
unknown config entry: 'serial_on_demand=false'
unknown config entry: 'serial_hardware_ctsrts=true'
unknown config entry: 'serial_direct=false'
unknown config entry: 'scsi=true'
obsolete config entry 'sound_bits'
unknown config entry: 'sound_volume=0'
unknown config entry: 'sound_auto=yes'
unknown config entry: 'synchronize_clock=yes'
obsolete config entry 'gfx_correct_aspect'
unknown config entry: 'gfx_center_horizontal=none'
unknown config entry: 'gfx_center_vertical=none'
KS ver = 0028
Stored port 0/0 d=0: added 200 0
Stored port 0/0 d=0: added 200 0 Nubs as mouse MOUSE0
Port0: ID 'mouse' matched
Stored port 1/0 d=0: added 100 0
Stored port 1/0 d=0: added 100 0 dPad as joystick JOY0
Port1: ID 'joy1' matched
Port2: NONE
Port3: NONE
KS ver = 0028
Stored port 0/0 d=1: added 200 0 Nubs as mouse MOUSE0
Port0: COMBO 'Nubs as mouse' + 'MOUSE0' matched
Stored port 1/0 d=1: added 100 0 dPad as joystick JOY0
Port1: COMBO 'dPad as joystick' + 'JOY0' matched
Port2: NONE
Port3: NONE
Autoconfig board list:
Card 01: '
Chips-fr
commented
4 years ago You can try to select adf file directly without going through .uae . I always got good result this way (if you only need A500 config which is the default). You need to have a kick.rom in current directory, ideally a kick 1.3
Chips-fr
commented
4 years ago I you want i can pull to libretro repo. I just removed the two not working fixes and renamed some commit message. But doing this will break you repo so you'll need to realign... https://github.com/Chips-fr/uae4arm-libretro/commits/master
r-type
commented
4 years ago if you think it's ok and if it didn't break anything on your side , yes you can PR (i don't mind about it break my old repo). On the other hand, i've working a litte on uar4arm-rpi , i have a pseudo working libretro port on my rpi3 (but no input for now). i have to find some spare time to finish it
This modification solve the audio glitches and now sound is ok.