For context, this thread was from Tino's Ishiiruka thread; where this comment starts by saying that Linear's results should be ignored due to certain settings. I did not alter this post other than this message.
__________
I see a person using vbeam speedhack and framelimiter to audio by default and assume they know nothing about how the emulator. Your testing results should be ignored for anything that matters.
No offense to you are what you want, but "testing needed" usually requires that the settings on the users side be stable during testing.
(09-11-2014, 07:27 PM)JMC47 Wrote: [ -> ]I see a person using vbeam speedhack and framelimiter to audio by default and assume they know nothing about how the emulator. Your testing results should be ignored for anything that matters.
No offense to you are what you want, but "testing needed" usually requires that the settings on the users side be stable during testing.
I'm an engineer, not a noob who doesn't know what is real console hardware, what is video pipeline and audio timing ! Do you have any idea how real developers make their games and how they are handling unstable FPS drops or general gameplay speed ? Audio unit is not just for audio in many cases - it also serves as a timing mechanism for a lot of purposes ! No offense to you, but I don't need your opinion about my testing, and check this method for yourself in order to see how this way works ! ( VBeam + Audio framelimit + No idle skipping )
I not saying that real GC or Wii always works this way, but a lot of games adjusting their speed by SPU. Also - ask Skidau about VBeam, he will open your eyes.
If you think that I don't know anything about hardware - check my modchips for previous generation consoles like PS2, they are still works well enough !
Oh boy..... *gets popcorn*
JMC47 is one of the more knowledgeable posters on this forum. If he says something, know he means business.
Go read the paragraph labeled An Odd Trend:
https://dolphin-emu.org/blog/2014/07/31/...july-2014/
You may be an engineer, but the devs have been tearing apart the GC/Wii hardware for years. They know what they're doing when it comes to audio and how it works, and how Dolphin implements it.
And as for the GC/Wii, read this thread for more info:
https://forums.dolphin-emu.org/Thread-pl...ized-audio excerpts below
(09-06-2014, 06:52 PM)Shonumi Wrote: [ -> ]triad Wrote:That is definitely not my experience. G6SE7D and RO7E7D I'm most familiar with and generally lucky to get 60% (with almost 50% higher CPU speed than you're claiming), and I've seen as bad as 30%-ish (especialy in the dream sequences in RO7E7D). I want to say RO8E7D is comparable. That sound dump is from RO7E7D when it's getting around 55%. This is with both 3.5 (from rpmfusion, so theoretically not a build issue on my end, except GWLE6L which doesn't run on 3.5) and 4.x (pretty much any master since July); I've yet to see any noteworthy speedup in 4.x compared to 3.5. Pre-rendered video in all of the above especially are well under 100% (55%-70% in RO7E7D, 30% or even 10% in RO8E7D).
You probably really don't have sufficient hardware. Some games are more demanding than others, what's "sufficient hardware" will change for a range of games. It might be that the Spyro games are very demanding in Dolphin (I don't own any, I can't test them myself). Your settings sound good. Test this: set your IR to 1x, disable all AA, and see if you get any slowdowns. If you do, then you have verified that you have a CPU bottleneck.
Some further advice, try other games aside from the Spyro games. Try some light-weight ones and see if you have issues running them (Brawl, Melee, Wind Waker, most any WiiWare will do it).
triad Wrote:It almost sounds like you're saying the 3.5 behavior was more correct?
Actually no. These games are coded in such a way that the CPU still has enough cycles to send audio data to the DSP at a constant rate, while on the other hand they may not always issue GPU commands in a timely fashion (hence an FPS drop on the console). In the case of real Wii hardware, the CPU is still has the necessary cycles for audio handling routines. With Dolphin, the audio sounds horrible if the emulated CPU is not running at 100%, so essentially slowdowns of Dolphin's emulated CPU represent what would happen on a Wii if the CPU were suddenly "too busy" to even process audio in time. If a real Wii's CPU is too busy (imagine a bottleneck occurring and stealing cycles), it might not be able to send audio data to the DSP at a constant rate, thus it would sound horrible similar to Dolphin. However, to my knowledge, many developers fought to avoid bottlenecking the CPU, so outside of homebrew tests, not much software for the Wii (or GC) displays this behavior. Sacrificing FPS was generally the lesser evil as opposed to sub-par audio.
So to summarize:
Actual Wii -> CPU too busy -> DSP does not receive enough data -> Audio quality may suffer
4.0 -> Emulated CPU too busy -> Emulated DSP does not receive enough data -> Audio quality may suffer
3.5 -> Emulated CPU too busy -> Emulated DSP grabs the data anyway (data is not always correct) -> Various audio issues occur, but the overall quality may be seem higher
4.0 and above are closer to how the Wii actually works. The DSP, real or emulated, needs constant and timely data or instructions on how to process audio. Any interruption of that distorts the audio.
(09-06-2014, 10:12 PM)delroth Wrote: [ -> ]If you are "worried about the future of dolphin", then please feel free to fork and get everyone else who shares your concerns to join you. You are yet another backseat programmer that has no idea how emulation works and still tries to tell us how to do our job.
Asynchronous audio is broken audio. The GameCube DSP code that generates audio samples is based on input data that is generated by the emulated CPU every 5ms, and this input data only contains information for exactly 5ms of audio (seriously - for example, it has 5 fields that should be applied each every 32 samples, aka. 1ms). It also reads audio data that was postprocessed by the emulated CPU... again, 5ms at a time. If you want to read more than 5ms, you end up reading uninitialized memory, because the game only knows how to generate 5ms of audio data. Then, every 5ms, the DSP sends an interrupt to the CPU to signal that it has produced audio samples (games rely on this for timing and other stuff, so you can't cheat and send it less often). Anything that generates more than 5ms of audio at a time is wrong and has no business being in Dolphin.
(09-07-2014, 05:25 AM)degasus Wrote: [ -> ]By the way, do you know that half of the ingame crashes we had in 3.5 were because of async audio? I don't care much about small music stops, but I do care about tons of game crashing because the game doesn't expect to provide lots of audio frames without any cpu time.
As I said - I don't need an opinion from people who didn't create any game for console. I told it once here and I will tell it again = long time ago I've talked with one guy from the development team of MGS:TS (konami GC title) and he GODDAMN PROVED that they used an DSP for speed control, like stable and effective reference clock.
I respect ALL developers of Dolphin project and other emulators, you are all great and intelligent people ! And I'm not asking to change something in master branch, not asking to fix something, not screaming here what is right and what is wrong. All I want here is just to help Tino with my testing reports ! He is trying to experiment with different approach and his own ideas about backends. Alternate ideas always helps to see more ways to fix something.
So what I see = all my tested games works better with this alternate speed control way = Framelimit by Audio + VBeam (thanks Skidau!) + EFB-RAM without cache. I never had any crashes due to Audio speed control, I NEVER use Idle skipping, EFB-Texture, Skip-EFB-access from CPU or any other hacks in Video Interface, and with this way - timestreching doesn't needed because audio always works fine !
If someone here thinks that I'm wrong or telling something offtopic - I can stop bothering people here without any problems.
P.S. - my old modchips works without any problems of desync ONLY because it's cycle counter based on DSP ! Other ways always hangs due to sync errors.
(09-12-2014, 03:17 AM)Linear Wrote: [ -> ]As I said - I don't need an opinion from people who didn't create any game for console. I told it once here and I will tell it again = long time ago I've talked with one guy from the development team of MGS:TS (konami GC title) and he GODDAMN PROVED that they used an DSP for speed control, like stable and effective reference clock.
I respect ALL developers of Dolphin project and other emulators, you are all great and intelligent people ! And I'm not asking to change something in master branch, not asking to fix something, not screaming here what is right and what is wrong. All I want here is just to help Tino with my testing reports ! He is trying to experiment with different approach and his own ideas about backends. Alternate ideas always helps to see more ways to fix something.
So what I see = all my tested games works better with this alternate speed control way = Framelimit by Audio + VBeam (thanks Skidau!) + EFB-RAM without cache. I never had any crashes due to Audio speed control, I NEVER use Idle skipping, EFB-Texture, Skip-EFB-access from CPU or any other hacks in Video Interface, and with this way - timestreching doesn't needed because audio always works fine !
If someone here thinks that I'm wrong or telling something offtopic - I can stop bothering people here without any problems.
P.S. - my old modchips works without any problems of desync ONLY because it's cycle counter based on DSP ! Other ways always hangs due to sync errors.
So you're not getting any of the issues mentioned here:
https://code.google.com/p/dolphin-emu/is...il?id=7514
?
Especially the replay/ghost issures are to be taken seriously. Can you record a replay on f-zero or mario kart with vbeam disabled on lastest master(<-important to get a correct replay file), and then play it back correctly with vbeam enabled? From what i understand, the dolphin devs are kinda allergic to inaccuracies of the emulation, and spend countless hours to fix even the slightest sight of them(thank you so much fiora!). And i'm with them on this, even though i'd really much like more speed in dolphin.
I don't doubt that you know your stuff about consoles and audio. But maybe Dolphin is doing things not the way you expect it to? Maybe because stuff is named wrong, maybe there are bugs, maybe the real hardware is acting weird, who knows? But i have to ask: What is your reasoning behind disabling Idle skipping? Is this faster or more accurate? Does this solve some problem? From what i understand, it skips over idle loops in the cpu emulation. Is that a bad thing?
(09-12-2014, 04:08 AM)mimimi Wrote: [ -> ] (09-12-2014, 03:17 AM)Linear Wrote: [ -> ]As I said - I don't need an opinion from people who didn't create any game for console. I told it once here and I will tell it again = long time ago I've talked with one guy from the development team of MGS:TS (konami GC title) and he GODDAMN PROVED that they used an DSP for speed control, like stable and effective reference clock.
I respect ALL developers of Dolphin project and other emulators, you are all great and intelligent people ! And I'm not asking to change something in master branch, not asking to fix something, not screaming here what is right and what is wrong. All I want here is just to help Tino with my testing reports ! He is trying to experiment with different approach and his own ideas about backends. Alternate ideas always helps to see more ways to fix something.
So what I see = all my tested games works better with this alternate speed control way = Framelimit by Audio + VBeam (thanks Skidau!) + EFB-RAM without cache. I never had any crashes due to Audio speed control, I NEVER use Idle skipping, EFB-Texture, Skip-EFB-access from CPU or any other hacks in Video Interface, and with this way - timestreching doesn't needed because audio always works fine !
If someone here thinks that I'm wrong or telling something offtopic - I can stop bothering people here without any problems.
P.S. - my old modchips works without any problems of desync ONLY because it's cycle counter based on DSP ! Other ways always hangs due to sync errors.
So you're not getting any of the issues mentioned here:
https://code.google.com/p/dolphin-emu/is...il?id=7514
?
Especially the replay/ghost issures are to be taken seriously. Can you record a replay on f-zero or mario kart with vbeam disabled on lastest master(<-important to get a correct replay file), and then play it back correctly with vbeam enabled? From what i understand, the dolphin devs are kinda allergic to inaccuracies of the emulation, and spend countless hours to fix even the slightest sight of them(thank you so much fiora!). And i'm with them on this, even though i'd really much like more speed in dolphin.
I don't doubt that you know your stuff about consoles and audio. But maybe Dolphin is doing things not the way you expect it to? Maybe because stuff is named wrong, maybe there are bugs, maybe the real hardware is acting weird, who knows? But i have to ask: What is your reasoning behind disabling Idle skipping? Is this faster or more accurate? Does this solve some problem? From what i understand, it skips over idle loops in the cpu emulation. Is that a bad thing?
Hi !
1) I don't have those issues because I testing here latest builds from Tino, and this builds work correctly and still have Framelimit by Audio mode. I saw some similar issues before and it was due to timing bugs when Dolphin first time building cache for game and those stutters breaks general sync. If cache already built and you try to start your game again with properly configured VBeam and VI - you will not have those issues. Just to be sure - you can delete old cache and config data in your "My Documents folder"
2) It is incorrect to record something with standard builds and then launch those records with different settings and builds.
3) About Idle skipping - I already reported its buggynezz in this thread, you can read about it. Idle skipping intended to skip some useless cycles and by that - give speed boost... In theory... But practice shows that it skips some useful cycles. It slows down all my testing games and my homebrew testing soft. Sometimes it also causes animation desync (rare and ugly cases) and FMV stutters. So I never use Idle skipping after I discovered this problem... And it is a hack anyway, not a compatible approach... Without it - games runs faster and smooth.
You can test it by yourself and you'll see. My config was posted somewhere here too...
Please don't take this off topic. This is Tino's thread for his branch, I was making a comment about your settings compromising the emulator. If you wish to complain about this further, make a new thread.
Failure to follow directions will result in future posts off topic in this thread being deleted.
(09-12-2014, 03:17 AM)Linear Wrote: [ -> ]As I said - I don't need an opinion from people who didn't create any game for console. I told it once here and I will tell it again = long time ago I've talked with one guy from the development team of MGS:TS (konami GC title) and he GODDAMN PROVED that they used an DSP for speed control, like stable and effective reference clock.
No, they don't use the DSP for speed control, since the DSP timing in the AX UCode is completely based on interrupts sent by the PowerPC. They might be using the AI timing (many games do that), but even then audio framelimit has no influence on the timing, it only influences when and where Dolphin decides to sleep to limit framerate.
I wouldn't like to be the friend you're misquoting to "prove" your objectively wrong views. Consoles are different, your experience with modchips (which, btw, I'm very doubtful of now that I've heard you talking) doesn't translate to GC or Wii.