Sega CD lag

[Former user]

Original issue 322 created by jamalcoar on 2013-01-28T00:34:31.000Z:

What steps will reproduce the problem?
1.Play a Sega CD game
2.
3.

What is the expected output? What do you see instead?
Smooth gameplay. Lag every 8 seconds or so

What version of the emulator are you using (official, SVN revision,...)?
Latest build

Please provide any additional information below (Emulator settings, Console
setting,...)
AdvancedAA shader

[Former user]

Comment # 1 originally posted by ekeeke31 on 2013-01-28T02:59:09.000Z:

Well, it does not happen for me so most likely the problem is on your side, not mine, but with so few information, how would you expect anyone to help you or figure anything, that's absurd.
Just make sure you are using IOS58 if you are using an USB drive to load CD images (you can tell what IOS version is used in your Wii by entering the exit sub-menu).

That's say, i am not even sure what you mean by AdvanceAA Shader. I can only speak for the Wii port i am maintaing, other ports (made with retroarch) might run slower depending on the platform, there is nothing i can do against that.

[Former user]

Comment # 2 originally posted by jamalcoar on 2013-01-28T03:01:26.000Z:

hello,

I am using the retroarch ps3 port. Squarepusher told me to post the issue on here

[Former user]

Comment # 3 originally posted by ekeeke31 on 2013-01-28T07:49:35.000Z:

ok, i will try to explain you.
lag in emulation can be caused by two things: either 1) emulation is too slow and eventually falls down the output framerate (frames are missed) or 2) it is a synchronization problem between audio and video outputs(emulation desyncs from one or another, which results in audio or video hichup)

Emulation synchronization with audio and video backend is the role of the frontend (retroarch in that regard), the core only gives access to functions that need to be called with proper sync to whatever timing base the target hardware is using. On that regard, Genesis Plus GX (my Wii port) provides perfect synchronization with audio AND video, and i can confirm it does not miss or repeat a single frame EVER (tested during an hour with Sonic 2 interlaced mode which requires the emulator to swap rendered fields in sync with Wii displayed fields).

Emulation speed is bound to target hardware as well, although i would expect PS3 to be on par with Wii and again, i can tell you there is no lag or speed issue with the Wii native port (and not even the Gamecube version I think, although i can not confirm it). I don't know what options you have access to with RetroArch PS3 but generally, disabling overscan and High-Quality FM can help improve emulation speed. On that regard, i know that Retroarch by default always resamples emulator audio output to desired output samplerate: the thing is that the emulator core already does the same, which can be quite inefficient. Setting config.hq_fm to 0 will select a faster (but less quality-wise) resampling algorithm.
Sega CD emulation is already quite well optimized and there isn't much room for improvment beside rewriting stuff in assembly and breaking portability, which i do not want to do.

A major bottleneck with Sega CD emulation though is I/O access (access to your harddrive or whatever is used to store CD image files). Since files (datatrack, audio tracks) are accessed permanently and randomly by the emulator(contrary to ROM files that can be stored for once in RAM), slow device access can indeed ruin emulation speed and cause noticeable lags. Again, nothing i can do about this, pretty much depends on every console hardware and the library it uses to access files, as well as the storage device itself.

I hope you appreciate me taking some time to give you a detailled answer about why those lags you are experiencing are not really my concern since they are most likely not caused by the emulator core itself.

[Former user]

Comment # 4 originally posted by jamalcoar on 2013-01-28T08:27:56.000Z:

Yes, your response is most appreciated. I apologize for the lack of detail earlier.

[Former user]

Comment # 5 originally posted by libretro on 2013-01-28T08:36:14.000Z:

Hi ekeeke,

I too have been noticing issues of this nature on RetroArch PS3 in the past few days with Sega CD - Sonic CD being a game where it's most evident. I should probably check RetroArch Wii as well to see if it affects that as well.

All I know is that this didn't happen a couple of revisions ago.

A couple of things I could try on the libretro end is -

* setting the samplerate from 44Khz to 48Khz and seeing if this produces better results.
* Avoiding resampling on the core side altogether - RetroArch already does this and there should be no discernable difference in sound quality (it would also be faster too - on Android where most CPUs have softfloat support only, resampling in the core would be especially painful compared to our optimized NEON resampling being done in RetroArch).

I think the 'lag' here is misattributed by the original poster and it's just disk I/O delays that is causing this - HDD file I/O are terrible on PS3/360. I could try one last thing - a HDD disk I/O cache was previously used on PS3 and 360 - I have since discarded that since I thought I didn't really need it for anything. Perhaps this is what caused it - this is just a speculation but I should test it out to see if it's the case.

This all being said and done, I do hope I will be able to restore performance back to the way it was before - because I am absolutely 100% confident this did not happen before at all.

[Former user]

Comment # 6 originally posted by libretro on 2013-01-28T08:37:25.000Z:

On another note, Genesis Plus GX is now on the Google Play store through RetroArch - and for free -just thought I should let you know - I already let Charles McDonald know and he was excited about it at least.

[Former user]

Comment # 7 originally posted by jamalcoar on 2013-01-28T09:35:33.000Z:

I can confirm it was a I/O issue. I transferred the .bin and .cue to the internal HDD of the ps3 from my Ext HDD and I no longer receive lag.

[Former user]

Comment # 8 originally posted by ekeeke31 on 2013-01-28T09:48:46.000Z:

great, buffered I/O could eventually improves reading speed (i think it is done by libfat on wii/gc, through a read-ahead cache) but if device access is too slow (like usb1 instead of usb2), it won't change much
regarding recent commits, honestly, i can not think of anything that would affect emulation speed or sync...

@ squarepusher: that's very cool, i just looked at your recent work on github and it seems you have been working non-stop for the last month... impressive, time for some rest maybe ;-)
i tried to get it working on my smartphone (htc desire, quite old) but it´s not compatible, most likely because i'm using an outdated android os (currently stuck to that though unless i hack it)
nice work anyway, it´s great to finally have a solution that respect the original "spirit" of emulation scene

[Former user]

Comment # 9 originally posted by libretro on 2013-01-28T15:50:30.000Z:

Android 2.3 support is going to be done soon.

Regarding Genesis Plus GX on ARM in general - perhaps you could look into adding Cyclone for ARM (notaz maintains a version here that works for Picodrive at least - http://notaz.gp2x.de/cyclone.php) - it should decrease system requirements by a lot.

[Former user]

Comment # 10 originally posted by ekeeke31 on 2013-01-28T16:49:42.000Z:

Yes, I know about Cyclone and DRZ80 but I have actually no ARM compiling/testing setup and not much time to spend on this sadly. This could be a nice exercise for anyone wanting to step in genesis plus gx sourcecode though.

On a side note, I also have PowerPC assembly 68k and Z80 cores (Asgard68k & AsgardZ80) written by Aaron Gilles but never took the time to look at them. They might be useful someday when tackling with 32x emulation on Wii/PS3/X360...

[Former user]

Comment # 11 originally posted by libretro on 2013-01-30T23:18:43.000Z:

Hi there ekeeke,

just wanted to let you know that RetroArch Android works now on Android 2.3 and up.You should be able to use it on your HTC Desire now if you have at least 2.3. I can't go any lower than that for the reason that native activities were not yet available before API Level 9 (2.3).

[Former user]

Comment # 12 originally posted by ekeeke31 on 2013-01-31T07:20:12.000Z:

I just checked and it seems my smartphone is stuck on 2.2 (froyo), HTC didn't ever bother releasing 2.3 conpatible for it, from what I gathered on internet. So i guess i am out of luck until I bought a more modern one.

Out of curiosity, what are native activities ?

[Former user]

Comment # 13 originally posted by libretro on 2013-01-31T07:44:11.000Z:

Damn, I was hoping this would enable you to use it.

Anyway, a 'native activity' is a glue code layer so that native code can interface with upper-level Java code and services. A 'native activity' also maintains its own state and lifecycle in native code as opposed to having to implement that in Java.

Behind the scenes though, it is still a mixture of Java and native code - but this allows you to just not bother with a single line of Java code if you don't want to.

[Former user]

Comment # 14 originally posted by libretro on 2013-01-31T19:06:10.000Z:

BTW, sorry about those people badgering you about resolutions in RetroArch Wii - it's driving me nuts as well. Just know I have nothing to do with them bothering you with that. They're doing it with Tantric as well and creating a lot of ill feelings towards me because they're continually going about it like 'RetroArch does this, RetroArch does that - why don't you do it?'.

[Former user]

Comment # 16 originally posted by libretro on 2013-01-31T20:47:37.000Z:

Native activities cannot be used for API levels lower than API Level 9 (Android 2.3 - Gingerbread) - so I'm afraid this is as low as I can go.

What Broglia is doing is really the inverse of what I'm doing - he's spending most of his runtime state inside Java land, while I'm spending most of my runtime state inside native code. I wouldn't have it any other way because of the slowness of Java's garbage collector, the Dalvik JVM having to increase its heap size every time you allocate something in Java, and lots of other reasons that makes me even more convinced that doing as much native as possible is the only way to go.

[Former user]

Comment # 17 originally posted by libretro on 2013-02-01T02:32:34.000Z:

BTW - I'm experiencing an issue right now with a Sega CD game on Genesis Plus GX (libretro port) - probably not the right thread for it but hopefully you don't mind me posting it here -

I'm trying to load the Mega CD game 'Lunar - Eternal Blue' with a CUE sheet that looks like this -

http://pastie.org/6002365

When I start up the '.cue' file, it shows me the Japanese Mega CD screen. After pressing Start, it shows the audio CD screen. I then press Start again with the cursor highlighting the 'CD-ROM' button. It shows a 'Sega copyright screen'. After that, nothing will show up and the game won't progress - screen stays black.

I'm curious what the issue here is. I've had another guy test a bunch of Japanese Mega CD games for me and so far everything works except for Lunar Eternal Blue. Is there something wrong with my libretro code in libretro.c?

[Former user]

Comment # 18 originally posted by ekeeke31 on 2013-02-01T07:37:30.000Z:

I don't know, i will have to test it in my standalone genesis plus gx to see if it still works. Does the US version works ?
Also, does the CD player shows the 4 tracks ? Can it play audio tracks ?

[Former user]

Comment # 19 originally posted by libretro on 2013-02-01T08:30:32.000Z:

Yes, according to almostalive the US version works whereas the Japanese version doesn't. Even the redump image of the game doesn't seem to work.

The CD player shows all 4 tracks and you can play the redbook audio tracks just fine. It just doesn't start up when you select CD-ROM - it just shows a black screen after the 'Sega Enterprises' copyright screen.

[Former user]

Comment # 20 originally posted by ekeeke31 on 2013-02-01T23:43:55.000Z:

I can confirm the Japanese version of Lunar Eternal Blue hangs on a black screen after the Sega licensing screen in my current version, not sure if this happened in earlier versions as well as I always only tested the US version (which works fine), thinking it would have used similar booting code.

I will need to have a look at it, feel free to open an issue for this one.