Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #51  
Old 5th November 2014, 04:11 AM
deathdroid deathdroid is offline
Alpha Tester
Project Supporter
Member
 
Join Date: Apr 2009
Posts: 43
Default

Quote:
Originally Posted by Frank74 View Post
I think that with the new 2.0+ release, Zilmar was wanting to get the Fixed Audio Timing implemented correctly. So when it came to PAL detection, decided to leave it out or not call it.

All for the benefit of netplay, to sync everything together.

Unfortunately, this line seems to never be referenced.

Code:
void CGameSettings::SpeedChanged (int SpeedLimit )
{
	int FullSpeed = g_System->m_SystemType == SYSTEM_PAL ? 50 : 60;
	m_bSyncingToAudio = SpeedLimit == FullSpeed ? m_bSyncToAudio : false;
}
If Fixed Audio Timing is ON in a PAL game, the VI's hover around 51, 52 VI/S, the same as playing a (U) game which will hover around 62/63 VI/S. So, that's where my assumption of Fixed Audio Timing needing to be on comes from.

I can see it was thought about at least. With a workaround using the ScreenHertz=50 option to set in the rdb.
Ohhhhhh i see where your coming at there.
In his original code, yes that would of broken PAL and caused it to automatically assume that its not syncing to audio. Should function properly though if SetHertz has been called with the correct value dependent on the system.
(I think i understood your post correctly)


BTW Fixed Audio Timing does work, and yes it is primarily for netplay to ensure that everything across different clients is called at the same time.
And as far as I know it functions exactly as it should but has no automatic mechanisms so you have to play around with the AiCountPerBytes from what I remember right.
Reply With Quote
  #52  
Old 5th November 2014, 05:32 PM
Tasoulis Tasoulis is offline
Senior Member
 
Join Date: May 2011
Posts: 167
Default

Fixed audio timing screws up frame rate in all games by adding extta stuttering and unstable vi/s. So if you play solo its a useless option. If jabo audio plugin needs it i suggest to use a different sound plugin. One that doesnt need it ofc.
Reply With Quote
  #53  
Old 5th November 2014, 06:15 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by Tasoulis View Post
Fixed audio timing screws up frame rate in all games by adding extta stuttering and unstable vi/s. So if you play solo its a useless option. If jabo audio plugin needs it i suggest to use a different sound plugin. One that doesnt need it ofc.
Iirc, it only messes up the VI/s when both FAT and audio sync is enabled. However, I remember the audio seeming worse, with FAT enabled.
Reply With Quote
  #54  
Old 10th November 2014, 09:53 AM
deathdroid deathdroid is offline
Alpha Tester
Project Supporter
Member
 
Join Date: Apr 2009
Posts: 43
Default

Hmm, actually seeing if I can workout what Zilmar was thinking with his counter per byte calculation method that he never ended up finishing. IF anyone has any thoughts on this shoot me a message. Also might upload a new build of Project64 soonish, managed to fix a couple of problems and re-introduce plugin hotswapping. Plus a user has been working on improving the accuracy of the RSP code.

EDIT: Trying to improve the fixed audio timing is probably going to take time, can't quite work out why it produces so much stutters.

Last edited by deathdroid; 10th November 2014 at 02:46 PM.
Reply With Quote
  #55  
Old 10th November 2014, 05:22 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by deathdroid View Post
Hmm, actually seeing if I can workout what Zilmar was thinking with his counter per byte calculation method that he never ended up finishing.
I wish I knew more about audio, but I think Mupen64 and Apollo did audio properly. I've tested both with AQZ's netplay input plugin and both didn't desync, while 1964 and PJ64(without FAT enabled) did. I'm going to be studying emulator code from various sources, as I'm trying to fix emulator issues that have bugged me for months ;/ .

So I suggest skimming through the source code of both those emulators.

Quote:
Originally Posted by deathdroid View Post
Also might upload a new build of Project64 soonish, managed to fix a couple of problems and re-introduce plugin hotswapping.
Nice! I never figured out how to do that. I'll have to check that out as well.
Reply With Quote
  #56  
Old 10th November 2014, 10:12 PM
Frank74's Avatar
Frank74 Frank74 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Aug 2013
Location: UK
Posts: 828
Default

Quote:
Originally Posted by deathdroid View Post
Hmm, actually seeing if I can workout what Zilmar was thinking with his counter per byte calculation method that he never ended up finishing. IF anyone has any thoughts on this shoot me a message. Also might upload a new build of Project64 soonish, managed to fix a couple of problems and re-introduce plugin hotswapping. Plus a user has been working on improving the accuracy of the RSP code.

EDIT: Trying to improve the fixed audio timing is probably going to take time, can't quite work out why it produces so much stutters.
Nice, also see if you can figure out why some RDB settings are not talking to the gfx plugins. For example, Clear Frame =0|1|2 and Emulate Clear, are not working at all. But Culling does work. And I can't find a reference to any of these options in the new 2.1.0.1 source.
Reply With Quote
  #57  
Old 10th November 2014, 10:18 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by Frank74 View Post
Nice, also see if you can figure out why some RDB settings are not talking to the gfx plugins. For example, Clear Frame =0|1|2 and Emulate Clear, are not working at all. But Culling does work. And I can't find a reference to any of these options in the new 2.1.0.1 source.
Some of those sound like the options in Jabo's video plugin. I haven't seen them in PJ64's Glide.
Reply With Quote
  #58  
Old 11th November 2014, 09:06 AM
deathdroid deathdroid is offline
Alpha Tester
Project Supporter
Member
 
Join Date: Apr 2009
Posts: 43
Default

Quote:
Originally Posted by RPGMaster View Post
I wish I knew more about audio, but I think Mupen64 and Apollo did audio properly. I've tested both with AQZ's netplay input plugin and both didn't desync, while 1964 and PJ64(without FAT enabled) did. I'm going to be studying emulator code from various sources, as I'm trying to fix emulator issues that have bugged me for months ;/ .

So I suggest skimming through the source code of both those emulators.

Nice! I never figured out how to do that. I'll have to check that out as well.
Hmmm yeah I'll have to take a look at how Mupen handles all of its timing, as Project64 traditionally relies completely on the audio plugin for all of that stuff.

Quote:
Originally Posted by Frank74 View Post
Nice, also see if you can figure out why some RDB settings are not talking to the gfx plugins. For example, Clear Frame =0|1|2 and Emulate Clear, are not working at all. But Culling does work. And I can't find a reference to any of these options in the new 2.1.0.1 source.
This would be a problem with Jabo's plugin talking to Project64. Project64 doesn't personally handle any of those individual options, fairly sure its all just passed to the emulator and the emulator passes back info. Have to chase up Jabo to fix up missing RDB config problems.
Reply With Quote
  #59  
Old 11th November 2014, 05:41 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by deathdroid View Post
Hmmm yeah I'll have to take a look at how Mupen handles all of its timing, as Project64 traditionally relies completely on the audio plugin for all of that stuff.
I tried looking at Apollo yesterday, but it's too different .

The thing about mupen was, I was able to find the code responsible for synching audio to video, but cannot find the code responsible for having consistent audio (this is what's important for netplay).

Anyway, I've never been able to compile Mupen64 lol. Let me know if you get that working .
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 06:21 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.