Audio stutter with latest commit 65ead111f56d95a8099b7d996bd1c623219037de

[christianhaitian]

This tracker is for pcsx-rearmed-libretro issues only.

If the issue also occurs in standalone PCSX-ReARMed, the upstream repo is probably a better place for it.

Description

On the RPI3 build, there's an audio stutter present now with this latest commit. You can best hear it when playing Castlevania - Symphony of the Night. When you first encounter Dracula in the beginning, you can clearly hear the stutter at the beginning of each characters speech. The last commit that I tried where the audio was fine was cf71346b180ca485e67a43fc199232c51be9459b.

Steps to reproduce

Using a armhf build of the core with this commit, play Castlevania and just run straight to dracula, takes less than a minute, richter speaks fine but then every line after that has an initial stutter.

When did the behavior start?

Some time after commit cf71346b180ca485e67a43fc199232c51be9459b.

Your device/OS/platform/architecture

Odroid Go Advance Ubuntu 19.10 RK3326 aarch64 and armhf

Logs (enable file logging and set log levels to DEBUG for core and frontend)

See attached. retroarch.log

[gameblabla]

This would need further regression testing. That said, i have some CD improvements that should fix some CD related issues, which i believe is what you are actually suffering from. There's also an issue with the CDDA code simply being borked, i will also address that in the Fantastic Pinball PR.

[gameblabla]

Possible suspects if it is indeed a regression is either The Cdrom timings changes https://github.com/libretro/pcsx_rearmed/commit/068a6133171b026956bbfd91e9bf4666def8823d OR The SPU fix for Diablo https://github.com/libretro/pcsx_rearmed/commit/9601ca6d16dcef59d123539f5e2af07e504ac329

But i don't really have your hardware so i'm afraid that you will need to go through each commit and test them one by one until you find the culprit. (as i did for the warning commit that turned out to break games)

[dhwz]

I think @gameblabla linked to the wrong commit: cdrom timing changes https://github.com/libretro/pcsx_rearmed/commit/068a6133171b026956bbfd91e9bf4666def8823d

[andreltrigo]

The culprit of this issue is commit 068a613. The previous commit (c54faa9) works without issues.

[gameblabla]

The culprit of this issue is commit 068a613. The previous commit (c54faa9) works without issues.

Thank you. This means i guess the delay is too high and causes audio drop. Reverting this is out of question as it fixes a couple of other games but perhaps we could lower the delay a bit.

If someone wants to test, i have released a branch here : https://github.com/libretro/pcsx_rearmed/commits/cdrom_audio_fix_attempt

And automated builds here : https://git.libretro.com/libretro/pcsx_rearmed/-/pipelines/58475

[gameblabla]

Ok so, lowest CTR's intro works properly before it goes to shit is 12. However even at 12, there is still the noticeable delay in Castlevania. At 1 (the way it was), i could actually still hear some static noise and stutter before the speeches but Dracula's voice is OK after that. I honestly don't think it's entirely related to that. That said, i also tried it in PCSX redux where they merged the patch and there's still the stutter before the speeches.

So before a speech sample plays, this happens

CD1 write: 1 (CdlNop)
CDR IRQ 1 cmd 01 stat 03: 22 
CD1 write: 1 (CdlNop)
CDR IRQ 1 cmd 01 stat 03: 22 
CD1 write: 9 (CdlPause)
CDR IRQ 1 cmd 09 stat 03: 02 
CDR IRQ 1 cmd 109 stat 02: 02 
CD1 write: e (CdlSetmode) Param[1] = { c8,}
CDR IRQ 1 cmd 0e stat 03: 02 
CD1 write: 1 (CdlNop)
CDR IRQ 1 cmd 01 stat 03: 02 
CD1 write: d (CdlSetfilter) Param[2] = { b, 6,}
CDR IRQ 1 cmd 0d stat 03: 02 
CD1 write: 1 (CdlNop)
CDR IRQ 1 cmd 01 stat 03: 02 
CD1 write: 2 (CdlSetloc) Param[3] = { 26, 1, 39,}
CDR IRQ 1 cmd 02 stat 03: 02 
CD1 write: 1 (CdlNop)
CDR IRQ 1 cmd 01 stat 03: 02 
CD1 write: 6 (CdlReadN)
CDR IRQ 1 cmd 06 stat 03: 22 
CD1 write: 1 (CdlNop)

A game that relies on this is CTR :

CD1 write: 9 (CdlPause)
CD1 write: e (CdlSetmode) Param[1] = { e8,}
CD1 write: d (CdlSetfilter) Param[2] = { 1, 8,}
CD1 write: 2 (CdlSetloc) Param[3] = { 30, 56, 47,}
CD1 write: 1b (CdlReadS)

I've thought of a hack that forces it to FALSE if it's ReadS but that would be obviously a hack and not accurate... We need more test games to check against the behaviour.

[gameblabla]

I have found a fix of sorts that fix Castlevania and doesn't regress the other games. However, it might need (heavy) testing to make sure nothing regressed from either my fix or before the CDROM timings changes. So yeah, quite a mess.

Download the artifacts for your platform here (or compile it yourself) and give it a try : https://git.libretro.com/libretro/pcsx_rearmed/-/pipelines/58676

My branch can be found here : https://github.com/libretro/pcsx_rearmed/tree/cdrom_audio_fix_attempt

[andreltrigo]

Most of the stuttering in SotN is gone with @gameblabla branch. There's still some crackling/stuttering at the beginning of the first few speeches, but it's barely noticeable.

Mega Man X4 still stutters at the beginning of the title screen and character selection tracks. Other games may be affected as well.

[gameblabla]

Well i guess this is still not a true fix... : / I'll add X4 to my list of problematic games.

[gameblabla]

Here's a new test build that should hopefully help with Megaman X4. Let me know if it fixes it or not (it does for me) : https://git.libretro.com/libretro/pcsx_rearmed/-/pipelines/59075

Here's another attempt but this time with some feedback from PCSX Redux's main dev. https://github.com/grumpycoders/pcsx-redux/issues/643#issuecomment-939613784

Here are my source code changes : https://github.com/libretro/pcsx_rearmed/commit/f2585a3793deaa1aabf01b8713188d79bd0b57ee

[andreltrigo]

There's still some slight stuttering that wasn't present in c54faa9, but it's much better than before.

[gameblabla]

So clearly this does not entirely fix it and i'm sick right now... i'm thinking of either :

• Putting an ugly hack
• Revert the CD timings changes
• Do nothing and wait for a proper fix from Redux (could take forever)

[gameblabla]

I compared my new fix vs the old behaviour for Megaman X4 and could not notice a difference. So for now, i went with my hack solution instead. However, we want to fix this properly in the long term.

According to nicolasnoble:

Yeah this code needs to be refined a bit. Basically there's already seek code in the cdrom logic code, and it needs to be compounded with it. We shouldn't cause a delay if the seek destination is already within a very close ballpark of the current location. In general, the seeking logic needs to be fully rewritten, with a logarithmic curve indicating the number of sectors covered in one tick.

This would require a lot more work so for now, i'm just doing a hack.

[notaz]

I've reworked the code removing most of the hacks discussed here, and the games mentioned in commends still work for me. It should be possible to lift more accurate seek timings from more accurate emulators without side effects now, but I'm not sure it will help any actual games.

@gameblabla you mentioned you have a list of problematic games, could you check if they still work?