Sega CD lag

[GoogleCodeExporter]

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

Original issue reported on code.google.com by jamalc...@gmail.com on 28 Jan 2013 at 12:34

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 28 Jan 2013 at 2:59

• Changed state: Invalid

[GoogleCodeExporter]

hello,

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

Original comment by jamalc...@gmail.com on 28 Jan 2013 at 3:01

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 28 Jan 2013 at 7:49

[GoogleCodeExporter]

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

Original comment by jamalc...@gmail.com on 28 Jan 2013 at 8:27

[GoogleCodeExporter]

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.

Original comment by libre...@gmail.com on 28 Jan 2013 at 8:36

[GoogleCodeExporter]

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.

Original comment by libre...@gmail.com on 28 Jan 2013 at 8:37

[GoogleCodeExporter]

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.

Original comment by jamalc...@gmail.com on 28 Jan 2013 at 9:35

[GoogleCodeExporter]

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

Original comment by ekeeke31@gmail.com on 28 Jan 2013 at 9:48

[GoogleCodeExporter]

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.

Original comment by libre...@gmail.com on 28 Jan 2013 at 3:50

[GoogleCodeExporter]

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...

Original comment by ekeeke31@gmail.com on 28 Jan 2013 at 4:49

[GoogleCodeExporter]

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).

Original comment by libre...@gmail.com on 30 Jan 2013 at 11:18

[GoogleCodeExporter]

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 ?

Original comment by ekeeke31@gmail.com on 31 Jan 2013 at 7:20

[GoogleCodeExporter]

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.

Original comment by libre...@gmail.com on 31 Jan 2013 at 7:44

[GoogleCodeExporter]

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?'.

Original comment by libre...@gmail.com on 31 Jan 2013 at 7:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by libre...@gmail.com on 31 Jan 2013 at 8:47

[GoogleCodeExporter]

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?

Original comment by libre...@gmail.com on 1 Feb 2013 at 2:32

[GoogleCodeExporter]

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 ?

Original comment by ekeeke31@gmail.com on 1 Feb 2013 at 7:37

[GoogleCodeExporter]

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.

Original comment by libre...@gmail.com on 1 Feb 2013 at 8:30

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 1 Feb 2013 at 11:43