search

libretro / px68k-libretro

Portable SHARP X68000 Emulator for Libretro
http://hissorii.blog45.fc2.com
GNU General Public License v2.0
47 stars 42 forks source link

Super Street fighter 2 or Hang On FM/PCM music degration #181

Closed Kelvfimer closed 3 months ago

Kelvfimer commented 3 months ago

Hello

Using internal music there are FM/PCM degration that can be very noticable at Hang On and after playing 10 minutes with Super treet Fighter 2 (Feilong or Cammy stages when changing to speed song before dying occurs always or when exotic animals screams at feilongs song)

it occurs in all commits but it's true latest commit https://github.com/libretro/px68k-libretro/pull/180 with Street Fighter occurs more frequently.

I'm wondering @negativeExponent as you have knowledge concerning music boards per your commits, if you can pls take it a look.

thx KR

negativeExponent commented 3 months ago

I was thinking of another bug. Ignore the last comment

Kelvfimer commented 3 months ago

No worries. It could be great if you can fix it. If you need repro files let me know.

negativeExponent commented 3 months ago

in core options > advance, set everythin to Off, leave frame skip at full frames. the core was originally was on a specific frame phasing and all those other options were added later to remedy some timing issue especially sound. if your running higher than 10Mhz cpu clock, turn it back down.

Kelvfimer commented 3 months ago

Hello @negativeExponent it is as you said and the sound is even losing more using latest PR commit https://github.com/libretro/px68k-libretro/pull/180/commits/f6379a75cb1a49937f2a7a7ec12a2a0b13d40bef :( I'm using 10MHZ, RAM 12 MB, eveything off and full frame. How can debug it to provide you logs? thx

negativeExponent commented 3 months ago

see if anything changes in latest commit.

if it still sounds the same, make a recording and upload it. also, post a copy of retroarch.cfg and config/PX68K/PX68K.opt

also try this one when above still has problems: px68k_libretro-x86_64.zip

Kelvfimer commented 3 months ago

thx for the binary @negativeExponent but I'm using Linux on an odroid n2+. not Windows with PC.

Nevertheless, I've just tested on Windows downloading the latest core and on RA 19.1 and it is working fine...

So I need to troubleshoot a bit and I will provide a video :)

thx for your support and time.

Kelvfimer commented 3 months ago

Hello @negativeExponent

Here it is the video, you also have the settings in the video.

The video was done with MIDI OFF

https://www.youtube.com/watch?si=ixMfByOTRf9m3Frz&v=mNKygv9Jjco&feature=youtu.be

Retroarch Log of this video retroarch2024_08_0214_45_30.log

The video was done with MIDI ON https://www.youtube.com/watch?si=Vdk20WCQrwEyesJ8&v=uEFjV-LMmTM&feature=youtu.be

RetroArch Log of this video retroarch2024_08_0215_02_37.log

Latest config file Config files.zip

Platform

The platform is Odroid n2+ Linux 4.9 EMUELEC 4.8 TEST. On Windows seems to work fine per my tests

I'm using commit https://github.com/libretro/px68k-libretro/pull/180/commits/49d5df3fd60a8b64f6a3ed49b64bc992596c6319

I'm using 10MHZ, RAM 12 MB, eveything off and full frame. I tested with MIDI Off and ON. I'm not using MIDI I'm using internal music.

If you need the rom file let me know however I don't think is a rom specific issue as it is happening with hangon, crossfire ex, SSF2 etc for mos of the games :(

thx

negativeExponent commented 3 months ago

What do you mean MiDI OFf? From core options?

You cannot run this core with MiDi off. As I've stated in the erased comment I've said on day one, the core do not have bus error handling which is suppose to switch to FM mode when Midi SW is off

negativeExponent commented 3 months ago

[DEBUG] [Environ]: GET_VARIABLE: px68k_midi_output = "disabled"

This can never be off as stated in the description. This bugs the core in it's current configuration.

I'm surprise you are able to run it on SF2. This is suppose to freeze on the dos loading screen with bus error in log.

Kelvfimer commented 3 months ago

@negativeExponent ok but even with px68k_midi_output = "enabled" it has those music glitches :) . Maybe it gets corrupted due to off and then on.

negativeExponent commented 3 months ago

Just leave MIDI core option to Off, even without a midi attached. Just use the in-game options to switch music mode to Mimi or internal(FM)


MIDI Output (Restart) [px68k_midi_output] (disabled|enabled)

Enables the software MIDI. If disabled, it will use internal OPM for music, otherwise it will try use use midi software synthesizers configured. Due to missing bus-error handling in the CPU cores, its not recommended to disable this option.
Kelvfimer commented 3 months ago

But now I have it disable and the issue still there :(

Kelvfimer commented 3 months ago

I was testing changing the audio driver and it doesn't matter if I use alsa alsathread or SDL2 it fails in the same way :( I change audio latency and the same.... I don't know what to do...

negativeExponent commented 3 months ago

Sorry meant to say leave MiDI option On. I should remove that option sine the code that's suppose to handle that has been removed.

I've never had issue like you have even with SF2 played. It your able to compile the core yourself. Try it with the musashicpu core. It will be slow but may work.

Compile with make clean && make MUSASHI=1

UPDATE: odroid is arm? not sure i can compile. i have created a new test branch. this brance restores the option to change sample rates (11Khz, 22Khz, 44Khz). see if changing sample rates does helps. compile with standard C68K cpu core:

make clean && make

back then there were issues with the current C68K cpu with sound especially with SF2 or any capcom games. there could still be lingering issues in the cpu core. so try to make with musashi cpu core instead with:

make clean && make MUSASHI=1

this core is more cycle-accurate and may be slow.

if everything is still the same with both cpu cores with different sample rates (you do need to restart core after changing samplerate). try compiling the px68k from my repo. that repo is using the original CPU core which was modified to work with 64-bit platforms.

here are the repos: testing-branch: https://github.com/negativeExponent/px68k-libretro/tree/restore_sound_samplerate_option

my personal repo: https://github.com/negativeExponent/px68k-libretro.git

additional testing notes:

Kelvfimer commented 3 months ago

thx @negativeExponent nothing worked I'm wondering if it's an issue on my flashed sd card...

BTW to compile with Musashi I had to remove

ifeq ($(C68K),1) FLAGS += -DHAVE_C68K -DC68K_CONST_JUMP_TABLE SOURCES_C += \ $(CORE_DIR)/m68000/c68k/c68k.c \ $(CORE_DIR)/m68000/c68k/c68kexec.c

It doesn't matter what I did it was using DHAVEC68k.

I will reflash the sd card, I hope tomorrow and check if maybe is an issue anywhere in my Operating System. thx for your help and support.

negativeExponent commented 3 months ago

sad to hear that. issue probably is device specific or something is affecting core timings or whatever.

with regards to mushasi, it appears C68K is hardcoded to 1. you may need to run make C68K=0 to make it use musashi

Kelvfimer commented 3 months ago

Thx for all you help @negativeExponent . After reflashing a new sd card and having everything from the scrath in my OS the issue is gone even using the same disks (afaik the disk are preserving the data).

I'm wondering that my previous SD had any issue with the OS. So the issue seemed to be external.