iOS Version of Reicast #768 (continued)

[AbandonedCart]

Continuation of https://github.com/reicast/reicast-emulator/issues/768

(Summary of most recent comments) @JoeMatt

I'm a little confused, is the disussion on posting a build from my fork? Was any of that merged into main? My fork is a nice thing to look at but I wouldn't consider it playable until I work out the audio timing issues. It's on my radar, but I have a lot of projects right now I'm working on.

I've actually been doing the next stage of work on a branch of Provenance, since I'm more familiar with my own code base and have a lot of assistance classes for audio / video timing etc,

https://github.com/Provenance-Emu/Provenance/tree/feature/Core-Reicast

I have another commit with the time stamped CARingBuffer, which might be the final solution, but I haven't pushed it yet since the input buffer's CATimeStamp is not yet synced to anything meaningful but the system clock, so it drifts in and out of the output buffer range. It's a nice test but you'll get audio for a few seconds, then none, then audio again, then none. The speed is more stable though and CPU isn't being stalled on each frame causing the massive overhead as it rushes to render the next frame after the audio buffer is drained like the original code on the non-dynarec pipeline.

@brand175

Instead of using google drive or dropbox. I zipped the file and dragged it onto github. I'll also put it on the reicast forum.

reicast-ios.zip

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/57982721-ios-version-of-reicast-768-continued?utm_campaign=plugin&utm_content=tracker%2F500311&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F500311&utm_medium=issues&utm_source=github).

[braindx]

I was looking at the speed syncing issues a while back too, maybe one of the Reicast devs more familiar with the inner workings can help me out here...

From what I recall, the interpreter has CPU_RATIO defined as 8 which affects how often interrupts get fired off into the other systems and how often various systems that are scheduled based on clock cycles get triggered. It seemed to me that it would be difficult or impossible to get games' audio and video to run at the correct speed without a CPU_RATIO of 1. Is that accurate or am I misunderstanding?

I also saw that there's the rec-cpp stuff which seems to me to be more like a threaded interpreter that caches traces so it wouldn't require executable code pages and would therefore work on non-jailbroken iOS devices. Am I understanding that right? I'm wondering if that would be the better path to pursue.

[DecMaster]

I was able to start Reicast for the first time on my iPhone 6s with the ipa of @brand175, thanks a lot ! If I can be helpful in testing some games or functionnalities in return, it will be with pleasure. Thanks to the dev team of Reicast by the way, I will never say it strongly enough.

I've first tested Sonic Adventure 2, and in contrary of @brand175 I was able to bypass the start menu normaly and reach the in-game section:

It might depends of the device or bios since I use the same .ipa

I've also tested Marvel vs Capcom 2 but here I can't pass this screen:

Maybe because the virtual memory is full or not recognized.

Here are some other issues I found: (it may be helpful)

• Sound & music & animation speed are some times too fast. Nevertheless it's mostly stable at approximatively 120fps for me, it's very hopeful for the future of the app !
• When lauching the game vertically the controls doesn't match correctly the screen when it return in the horizontal way.
• The play button on the bios doesn't play the game but crash or reach again the bios screen.
• As said before, Joystick doesn't work on touch screen but may work with a MFI controller after @brand175.
• Random D-pad directions are sometimes pressed automaticaly by the emulator.
• I didn't found any important graphic glitch
• There are two virtually memories card recognized by Sonic Adventure 2

NOTE: The .gdi and .cdi games files work both on the emulator.

Hope it will help you, and good luck for the next !

[brand175]

The music player in the bios works. Also @DecMaster don’t forget about the LT button being slightly lower than the RT button which would cause people with OCD to go crazy (not me 😊). Also did you first try the Sonic adventure 2 menu thing. This happens in most games I tried. If you keep retrying it works but unfortunately for me sonic adventure 2 still kicks me out even on my iPad Pro. Most of the times clicking the abxy buttons help before clicking the start button. I noticed that Soldier of Fortune on the iPhone 6 has about 35% less graphical glitches in the first cutscene than the iPad Pro. I’ve seen this kind of stuff on the Dolphin emulator on ios. It’s most likely an OpenGL problem than the emulator it self.

[brand175]

I managed to fix the Lt and Rt triggers for the MFi controller. They are currently bound to the right stick. Up and Down is Rt, Left and Right is Lt. I don't have enough experience in coding to bind the Rt and Lt on the controller itself. I'll see what I can do to fix it anyways. Also I can't compile the provenance version probably because of the older Xcode version that I have installed.

Reicast Rt Lt Experimental Fix.zip

[AbandonedCart]

https://github.com/AbandonedCart/reicast-emulator-lk/commit/1bcf1a062251f916266ea715b129cfbf7422a1d9

[brand175]

That would of taken me 3 weeks just to figure that out. I'm pretty sure that change was only for the touchscreen. I'll add that change to the MFi Controls section and update the ipa tomorrow.

[AbandonedCart]

It should be the same thing, but a different "trigger" (not the physical trigger)

[AbandonedCart]

@brand175 @mk8itra1n The old thread was 263 comments, so this thread was added to cut the excessive load time. A reference was left at the end of that thread, so everyone can find this one.

I renamed this thread, so there should be no confusion about the conversation being moved here.

[brand175]

@mk8itra1n Anything new about the iPhone X test yet. Would it be possible to make a short video since ios 11 has in built screen recording. I also tried to install the reicast on my iphone 4 but it said that the ios version is too low. I wonder if it would work on a iphone 5.

[mk8itra1n]

@brand175 I tested the build out on my X. It works on a game by game basis for me. Some games the Lt and Rt work and others like Sonic Adventure there is no response when i touch those controls or any controls for that matter. It may be just how the emulator renders certain games that is causing the control issues or timing issues with the CPU. I am jailbroken on iOS 11.1.2. I should be able to get a built in screen recording onto this thread. I believe this emulator should work on a iPhone 5 at the lowest since if memory serves me correctly it is able to run iOS 10.

[JoeMatt]

Doubt it would run on an iPhone 5 since it doesn't have GLES 3, weaker GPU generation in general even if GLES 2 is the target (it's not right now but could be).

But we know it runs, there's not much point in reporting anything and cluttering up this ticket until the clocking issues are resolved.

On that note, I pushed my WIP code for Provenance-Reicast with timestamped ring buffer.

https://github.com/Provenance-Emu/Provenance/tree/feature/Core-Reicast

The code that's in progress is this mess of method here, https://github.com/Provenance-Emu/Provenance/blob/b636f50a4d9e9225e2a23ef5fbee0a7d9d964738/PVReicast/PVReicastCore/PVReicastCore.mm#L821

That's where the callback is entered, which used to stall until the system drained the audio buffer, which would defacto sync the audio processor (and others?) to the system, but also caused the massive CPU overhead just spinning waiting for the buffers to be drained.

I experimented with read ahead, and threaded deadlocks, with limited success.

I have some things I need to know / learn,

1) If the audio CB doesn't wait when it's ahead in time, does it continue to repush PCM samples from the audio processor state? 2) If 1 is the case, is there a clock to sync the current time of the sample buffer start.

The point of the time stamped ring buffer is that if a buffer comes in that overlaps with existing audio waiting for the OS to pull it (audio buffers are a pull for those that don't know. The sound card requests the audio for a time, not the other way around of the system 'pushing' samples to the sound card as they come, that allows pre-preocessing audio in chunks ahead of time) , the ring buffer with time stamps should resolve, i think, overlapping input buffers if the audio coprocessor callback is repeating sections as it's ahead of the other processors and we're not stalling like the original way mentioned above.

• The other issue is coming up with a time stamp value that can be within a range for the output clock of the audio system (measered in samples acquired since 0) and the 'clock' state of the audio processor.

• Also need to check that the interlacing and bit depth/sample rate are correct, might explain the fast audio but normal video in some games

• Alternatively, if my assumptions are correct about repeated sample windows, maybe there's a way to jus not do that, like keep a window range and if the current state is still in the range of samples already sent, don't call the callback, (like how the callback isn't called if it's way ahead by that 1.2 value that I don't quite understand)

In the comments of that function i documented some things Im' going to play with, and also noted an interesting kind of hack that DirectSound does on Windows, which seems like was the original audio subsystem since the requriments on the design seem to parallel that way DirectSound works.

[brand175]

@mk8itra1n The Rt and Lt button only works on the MFi controller. I only set the Rt and Lt for the extended gamepad profile. Which has more buttons than the other MFi controllers. Also @LoungeKatt I couldn’t get the trigger fix to work. I’ve tried your way and then adding it to the mfi extended gamepad. Do I have to change the button to a axis along with the GCcontrollerAxisInput.

[AbandonedCart]

I believe you do. I'm still a little rusty with iOS. It's been a few months of strict Android lol.

[yurimerath]

Is Shenmue 2 working yet with descent sound and speed using touch screen controls? Iphone 6 would do It?

[skmp]

Let’s move general discussions and speculation to the forum to avoid overloading the tracker. http://dcemulation.org/phpBB/viewforum.php?f=86 please :)

On Wed, 9 May 2018 at 10:06, yurimerath notifications@github.com wrote:

Is Shenmue 2 working yet with descent sound and speed using touch screen controls? Iphone 6 would do It?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/reicast/reicast-emulator/issues/1145#issuecomment-387641732, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYAMp9-3JYcgB9gq0Y8_BB2oMH6fVF5ks5twpV_gaJpZM4TzmO- .

-- ~skmp

[brand175]

@yurimerath I haven’t tested it yet. Touchscreen controls are not fully implemented yet and would probably take some time. I think the Provenance version of reicast may have fully working controls but I can’t compile it due to the Xcode version I have plus other errors. I’m pretty sure that version also has better framerates than the other one. Also I know where to store the code for the touchscreen joystick. I just need to learn how to implement the code into reicast and bind it to the touchscreen. Just thinking about how to implement it is giving me a headache 🤕

[brand175]

@skmp I’ll just post the link to the forum that I created a few days ago on Reicast for iOS. Hopefully this comes to good use.

http://dcemulation.org/phpBB/viewtopic.php?f=86&t=104564&sid=35c81a33078e63a6f7f195708f50f7a0

[skmp]

Ahh there’s even already a thread. Nice!

On Wed, 9 May 2018 at 11:02, brand175 notifications@github.com wrote:

@skmp https://github.com/skmp I’ll just post the link to the forum that I created a few days ago on Reicast for iOS. Hopefully this comes to good use.

http://dcemulation.org/phpBB/viewtopic.php?f=86&t=104564&sid=35c81a33078e63a6f7f195708f50f7a0

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/reicast/reicast-emulator/issues/1145#issuecomment-387656067, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYAMmC36RPZUU4RLLiF42fmlA4bP_QDks5twqJ9gaJpZM4TzmO- .

-- ~skmp

[brand175]

I fixed the triggers for the MFi controller. I made a bunch of changes and I don't exactly know what I did. But what I do know is the GCcontrollerButtonInput stays the same as well as *button. I'll update the github code once I figure what I did to make it work. I didn't change much.

Reicast MFi Trigger fix.zip

[braindx]

@skmp From the GitHub history it seems like you wrote most if not all of the rec-cpp system. Would be able to weigh in on its current state and whether my understanding of it as stated above is correct? Additionally, if you have any insight as to the CPU_RATIO define and how that affects the synchronization/timing of various other subsystems it would be greatly appreciated. If you prefer to discuss this via forum or in another medium, just let me know. I'm happy to spin something up!

[yurimerath]

brand175 thanks and keep up the good work! Where can I get this provenance version with the recaist core and how do I configure It? (Where to put the bios files etc) I’m gonna test shenmue 2!

[AbandonedCart]

@yurimerath https://github.com/reicast/reicast-emulator/issues/1145#issuecomment-387542021

[yurimerath]

I want the IPA

[AbandonedCart]

@yurimerath The point was that there currently is no IPA, but you can build one yourself. If you would like help building it, then I recommend asking on the reicast forum. This thread is for trying to debug and improve the source.

[Lemmy8]

Hey guys, okay so i managed to build @JoeMatt ´s Provenance branch through XCode and send it to my iDevices. Those are iPad mini4 (10.2 Jailbroken), mini4 (11.2.1 non-Jailbroken) and iPhoneX (11.3 non-Jailbroken) Bios files are in the right place and 3 roms to test (SonicAdventure 2, SonicShuffle and VirtuaTennis2). On all 3 devices both Sonic games show black, then crash the app, Tennis gets stuck on a grey screen. Am wondering if my build is somewhat faulty... They all run more or less glitchy on @brand175 ´s standalone build. Am happy to test stuff out if you like me to

[AbandonedCart]

@Lemmy8 @JoeMatt did warn of that version being heavily under construction at the moment and will likely have resources set up to help debug it when it is ready. For now, we should probably try to focus on just the build that would be a likely candidate here to prevent confusion and give him some time to prepare for user feedback.

[AbandonedCart]

@brand175

/**
 Shoulder buttons are required to be analog inputs.
 */
@property (nonatomic, readonly) GCControllerButtonInput *leftShoulder;
/**
 Shoulder buttons are required to be analog inputs.
 */
@property (nonatomic, readonly) GCControllerButtonInput *rightShoulder;

/**
 Triggers are required to be analog inputs. Common uses would be acceleration and decelleration in a driving game for example.
 */
@property (nonatomic, readonly) GCControllerButtonInput *leftTrigger;
@property (nonatomic, readonly) GCControllerButtonInput *rightTrigger;

@end

I don't have a device to test it, but the code should be something like: https://github.com/reicast/reicast-emulator/commit/23d9bf61ac5a49180a40e86e4e0608e555123018

[Lemmy8]

@LoungeKatt sure, i had hopes that the Provenance implementation runs comparable to the standalone but fixes input issues. But yes, it's too early for testing. Please keep up the great work, this is coming along soo promising after all those silent months 😀

[brand175]

@LoungeKatt I just discovered that the Trigger fix that I did for the MFi controller from a few days ago isn't fully analog. And the very first one I did was (I think it may not be 100% analog. I tested a different game to test the triggers and I noticed that the newer one didn't work for that game but it did on the other). I'll test your code tomorrow and see if anything works. I'm hoping that I can contribute to reicast on ios even though my skill level is very low. I'm learning by modifying given code and creating new lines of code based on what code is available. I know some basic C++ stuff and that's about it.

[JoeMatt]

It seems there's a lot of community interest now but everyone is working on their own bug fixes. I have a busy schedule at the moment but I promise I'll fix my fork and make a proper pull request as soon as possible, hopefully this week, and incorporate some of the changes posted here. Then hopefully everyone can work together on a coherent branch.

Maybe the admins want to make a specific feature branch on GitHub too to work against since the PR wouldn't be ready for prime time on the main branches but I'll leave that up to them.

[brand175]

@LoungeKatt I tested your code and it doesn't work. I haven't tried it with the property. Neither MFi or touchscreen triggers work. I also couldn't reproduce the trigger fix. I believe that I just removed && value. I'm going to test that change in a few days and see if it makes your code work. Their must be a way into adding an axis system to it just like the joystick since it works fine when adding the trigger on the right joystick with a few modifications.

[JoeMatt]

Well if you're trying to get analog values

rt[0] &= ~(DC_AXIS_RT);

Still only sets a boolean value You'd need something like

rt[0] =Int(value * 255); // Normalize to 255

But you probably need to normalize value to something since it's a float 0 to 1.0. I think it's 0 to 255 according to the Windows code. Then set to 0 on the key up.

edit: This might do it,

[self.gController.extendedGamepad.rightShoulder setValueChangedHandler:^(GCControllerButtonInput *button, float value, BOOL pressed) {
    rt[0] = pressed ? (int)(255 * value) : 0;
}];

[self.gController.extendedGamepad.leftShoulder setValueChangedHandler:^(GCControllerButtonInput *button, float value, BOOL pressed) {
    lt[0] = pressed ? (int)(255 * value) : 0;
}];

[AbandonedCart]

@brand175 The code I posted wasn't going to work out of the box. I posted the "javadoc" about the triggers and only "connected" the controllers between the different endpoints. You don't want an axis system because that overcomplicates it. As @JoeMatt said above, you are looking to pass the degree of pressure in a linear fashion. It will be much the same as the Android code, but would need to have the endpoints translated into iOS. As you may have already noticed, that was the part I made sure to complete.

[brand175]

Code works fine @JoeMatt. Thank you.

Reicast Trigger Fix new.zip

[AbandonedCart]

Alright, to avoid reinventing the wheel with one-shot builds, there is now a branch that integrates all of @JoeMatt's "finished" changes (left out the final audio commits for the time being). Making test builds from it is fine, but we should make sure everyone can access it from the main project.

https://github.com/reicast/reicast-emulator/tree/jm/xcode-port

@JoeMatt I have you covered with retaining the "shared" guid without any loss of history on your commits. Let me know if there is anything you want done differently for your previous commits.

[JoeMatt]

Cool, that should help. We're about to wrap up the next release of Provenance 1.5 (not with Dreamcast obviously but we do have Mupen + GLIden64!). After that I can start taking a look at this again.

[brand175]

Heres an updated ipa (touchscreen triggers now work).

Reicast Touchscreen Trigger Fix.zip

[AbandonedCart]

There are still a couple changes required to make sure this doesn't prevent other platforms from building. I've got a few done, but I need to jump back into translating BDM for a bit.

Everything that was done is already added. I stopped at

[exec] jni/../jni/../../../core/rec-ARM/rec_arm.cpp:352:35: error: 'ngen_FailedToFindBlock_' was not declared in this scope
     [exec]  void (*ngen_FailedToFindBlock)()=&ngen_FailedToFindBlock_;  // in asm
     [exec]                                    ^
     [exec] make: *** [obj/local/armeabi-v7a/objs/dc/jni/__/__/__/core/rec-ARM/rec_arm.o] Error 1

[brand175]

@mk8itra1n @Lemmy8 @DecMaster @yurimerath I added touchscreen joystick functionality without the joystick itself. I didn't bother in trying to figure it out or even try. I'd rather have it as a d-pad which makes it more easy for me to put it together. Also Xcode is garbage. I place the joystick d-pad in the bottom left corner and no matter where it goes. It places it towards the up-left corner or not even on the screen at all even if I moved it somewhere else . So this is where it is. I hate it but it works so hooray!

Reicast (Experimental Touchscreen Joystick).zip

[AbandonedCart]

@brand175 What was giving you trouble with a "real" joystick?

After trying to see what you may have already tried, I came across a few issues: reicast is an open-source project, but it does have a license. You may want to check section 3, which goes over the requirement that you have a published copy of the source to distribute the program. You may also want to reconsider stating that you fixed the triggers for reicast on iOS, since it was @JoeMatt that provided the code. You said you were unable to reproduce your results.

[brand175]

@LoungeKatt I tried the joystick first but it wasn't working. I've never done or seen constraints in Xcode before. The joystick has one center x and one center y constraint while the dpad had 10. It literally took me 2 hours just to find the add constraint button. There's probably more to the joystick. Need to add UIEvent,UITouch or something. I added the button tags and stuff (img_vjoy) in the EmulatorView just like what I did to the dpad. I changed out the joystick to the dpad mainly due to my lack of skills. I could add 127 different constraints with tags to the joystick but that would take a very long time and would be a very stupid idea to attempt. Adding the constraints to the dpad is much easier for me and it was a functioning button that I could work on. I was hoping that maybe you could give me some ideas on what you would do to add functionality to the joystick.

[brand175]

@LoungeKatt I added the triggers to the right joystick on the MFI controller before @JoeMatt posted a solution. I also tried to use your add on for the touchscreen thing which didn't work at all. Before @JoeMatt ever posted the trigger fix, I came across a trigger fix (Left and Right Triggers on the controller) for the MFI controller but i set at 127 instead of 255 (correct value) and it was fully functional. @JoeMatt solution was way different than what I did. If you take a look at http://dcemulation.org/phpBB/viewtopic.php?f=86&t=104564&p=1054797#p1054797 I clearly stated that the new MFi controller trigger fix update was by @JoeMatt himself. When I said "I couldn't reproduce the trigger fix". I also didn't save the touchscreen joystick work that I did since I duped the wrong folder when I was making multiple changes and was saving them into separate folder. I have multiple folders of reicast on the computer which were named Copy. I could redo the work if you want. For the Touchscreen fix. All i did was( int value = 255) rt[0] = value and (int none = 0) rt[0] = none.

Edit: I just remembered that when I said "I couldn't reproduce the trigger fix". I meant that I couldn't reproduce the result that I got. Because I fixed the triggers but I forgot how I did it. I didn't save the changes but I compiled the app with the 127 value fix. But I remembered how I did it but didn't update the app since I already did.

[AbandonedCart]

@brand175 You are focusing on the wrong part of what I was trying to tell you. It really had nothing to do with who contributed what, but that did help to prove a valuable point.

Upload your source. Any claim you make is proven by it. Any trials are recorded and not lost among various local copies. Anyone attempting to help with an issue knows your progress.

[AbandonedCart]

https://github.com/pyzhangxiang/joystick-ios This is one example of someone's implementation of a virtual iOS joystick that circumvents the xib (as a means of control, at least). It seems like that would be the easiest solution, but would take some extra code to add the ability to configure size / location.

[JoeMatt]

I thought I'd chime in because I was tagged and I'm still loosely following, my update is,

• Provenance (my front end app) is still being wrapped up for next release (1.5)
• Provenance is currently working on a virtual Joystick that is better than what's out there, in prototype now with design team, will happily copy that over to Reicast native front end once we finish (yay FOSS)
• Hope to finish this week and publish Provenance 1.5 (no reicast yet)
• I'm out of town for most of June after that
• Next TODO for me is to work on Reicast though, will catch up in late June.

In general we're looking at adding Dreamcast and and PSP and probably stopping there as far as new cores since that pretty much maxes out what iOS is capable without jailbreak/jit that we don't have already (well I am working on a Atari Jaguar core port but that's less important and Sega Saturn is the other big missing system but iOS support is much more behind)

We do have to update some older cores but won't bore this project with those details.

Dreamcast has been huge request so I'm going to focus all I can once I can on this and PSP mid-summer, that's our 1.6 plans. Of course I plan to make all those changes upstream capable, then our 2.0 release is all UI features such as iCloud rom and save state syncing, better tvOS support and PS3/4 controller support without bluetooth jailbreaks (another prototype project I have that does work well with an ardunino hardware lightning USB to Bluetooth dongle I'll also FOSS) so hopefully we become a great iOS front end for Reicast so devs can focus on the core and not the overhead of an iOS frontend (though still available as a standalone if wanted)

I don't intend to sideline Reicast's tickets with more info on Provenance any more, I respect that this is reicast's GitHub, if anyone would like more info on our iOS/tvOS front end join our discord at, https://discord.gg/4TK7PU5

[brand175]

@LoungeKatt I’ll add on to the project from now on. But i’m pretty sure i’m at the end of my rope in terms of helping with the project. The xib file or something is screwy on the xcode on my mac computer. So I can’t place the on-screen controls exactly where I want them. Which really makes me mad. Most likely because I changed it to be compatible with Xcode 8.0 from Xcode 9.0.

[JoeMatt]

This is still something I'm working on.

I think I need more info on how the audio push's happen in reicast, on the non-dynarec model, with threads, and with or without the aica.LimitFPS and acia.NoBatch flags. What those do in the multi-threaded enviroment exactly?

I basically have 2 scenarios.

1. Game runs fullspeed.

But certain games seem to run a little sped up. Sonic seems too fast, at least the in game clock 1s == .5s in real life. Though Soul Caliber, the fight clock runs as expected.

The audio here sometimes runs fine for certain things, but sped up mickey mouse speed for others. I wonder if it has to do with audio that is played as WAV / samples, or audio that is rendered per frame. It seems like sample based audio is just sent to the rendering system as a dump and renders as fast as possible, but in the version of my audio callbacks where I don't stall the audio thread, this audio runs way too fast.

I'm experimented with using audio buffers in iOS with timestamps, but the difficulty is determing what the correct sample time should be when the callback is fired. Is there somthing that represents the system's internal kernel time?

I've tried to determine this a few different ways like, keeping an atomic counter on samples receiced, and samples pulled by iOS (the pulling should be around accurate to the rate the system wants audio to fill the hardware buffers and the sample rates we've set, so many times a per 1/60 a frame so this should be accurate enough to keep time.)

Another method is using a kernel time stamp on each write and read from reicast/iOS core audio and doing some maths to figure out how I should stamp the incoming samples based on how many samples are still sitting in the ring buffer since we tend to push audio into the the buffers faster than necessary in the mutli-thread - non locking models.

This basically failed but core audio is really trick so I coould just be stamping things at the wrong times (calced based on bytes per sample, channels, sample rate, interlacing etc)

2. Audio is perfect, but game is very slow and somewhat behind.

This is when I basically don't send off async and just stall the audio thread until the buffer is filled and then emptied on iOS's coreaudio callback thread.

The audio actually runs perfect here, but stalling the audio thread kills performance of the whole system.

What's odd, this is basically how all the other audio implimentations work, (OSS, ALSA etc), but maybe it's because 99% of users are using the JIT CPU paths and it's doing different things with the thread blockings?

(I had concerns with race conditions copying the buffer into the ring buffer to not stall the thread as quickly as possible, so i even internally in reicast added support for a rotating cycles of buffers to use on each render, basically a shitty ring buffer)

3.

I've tried various combos of 1 and 2, filling a ring buffer and using dispatch queues to sync stalls on the reciast push side of things if it gets too far ahead of the systems pull. This either had the faults of 1 or 2 or both in the 6 different variations i tried.

Conclusion

I think non JIT reicast is actually really performant, any slow downs seem to be related to the wait mechnism on the audio render thread not having a clue where it is in relation to the cpu and video emulatotions and relying on really slow stalls to keep in sync. (Just turn off audio and see even an iPhone 7 non-jb can run Soul Calibar at 60fps without frame skip on)

Also, I'm not sure if when the audio thread is running faster than the cpu/gpu threads, is it re-sending parts of samples that it already sent, basically going backwards? This might exaplain some of the echo type artificats I get on top of the mickey mouse speed playback on the non-stalling variations.

I'm curious if the RetroArch 'fork' of reicast works with audio on Non-jailbreak devices. I haven't had time to test since I don't really use retroarch on iOS ever. They have a very simple buffer copy similiar to the other system render types, so i'd assume it would be slow as shit like I get on my end on anything that isn't copy and return async. If it's not, I wonder if they made patches to the sync-ing of the a/v/cpu emulation. (Im' kind of assuming reicast models each of these in a kind of silo so they're not all thread blocking reading state data and generating their output, which I probably how the OpenGL side of things runs butter fast on slow cpus?)

Even though it's not really playable, the branch was getting so far behing I rebased and fused in my patches plus some from the other WIP iOS branches here and merged them into Provenance.

You can see my 8 or so different ways of doing the callback here, many many hours spent in vain :(

https://github.com/Provenance-Emu/Provenance/blob/develop/Cores/Reicast/PVReicastCore/Audio/PVReicast%2BAudio.mm

Hopefully someone with some better knowledge of wtf the whole audio threading model looks like in Reicast can work together with me to solve this, because other than me randomly coming up with ideas or spending a lot of time I don't have diffing into the guts of reicast more, this will kind of sit idle for a bit most likely.

[skmp]

@JoeMatt @brand175 are you guys still working on iOS support?

[brand175]

@skmp I don't have a Mac anymore :(

[JoeMatt]

I've been dabbling in it here and there. The issues in my post above remain unresolved.

Since most of my development is inside of Provenance as a front end I have some blockers there that once resolved will allow my focus to switch back over to Reicast and some other core ports.

1. Swift conversion of core wrappers
2. More generic libretro support to allow direct drop in of libretro build system.
3. Improved audio/input/gfx interfaces.

These basically go in order. I'm trying to refactor Provenance to be more agnostic as a front end and remove out a lot of our core specific hacks and build system. This would allow any work I do on iOS for Reicast to be more easily pushed back upstream.

Ideally the goal for me is to publish our GFX/audio/controller/filesystem/cheats/screeeshot etc iOS code as a Cocoa (OS X, tvOS, iOS) framework that works with libretro.h cores. Then Reicast and other projects could just import our framework and not have to reinvent the wheel with managing UIViewControllers, GCController, CoreAudio etc for their own single system frontends.

As I read through the various iOS "ports" I generally see the same slapped together code to just make it work, and often the same bugs and short cuts repeated, which is understandable since iOS is an afterthought for most emulators if at all, and at worst result in "ports" by developers who act like they made an emulator for console X when in fact all they did was make and release a basic front end and take all the twitter fame.

We also haven't supported jailbreaks in the past, but this might be something we'll allow toggling, at least in develop builds, as this might help me debug some of the issues with Reicast and other emulators that exhibit drastically different bugs in Dynarec modes due to the completely different pipelines, mostly in the newer gen consoles we're starting to support (Dreamcast, N64, PSP etc).

If there's anything quick I could do to help out let me know. Other than that, best I can say is that it's on my radar, but I've been super swamped with some career changes that required a lot more overtime that I would have liked the last 6 months. Looking to switch to a dev shop with a regular work schedule again very soon and start working on FOSS projects again.