![]() ![]() Old solution because it worked without really understanding "why" is not a System_frame/audio_update/video_update sequence), simply "going back" to an I repeat that the problem is with the way you are syncing the emulatedįrames to your host system (i.e time interval between calls to The same amount of samples as psg chip, which was not correct). Won't do it because it is less convenient and less accurate in regard toįm/psg sync (fm chip was sometime running a few additional cycles to return Sure you could simply go back to the old code if it worked for you but i With regards to matching the 'exact framerate' of the GPU or matching the original machine speed - all I know is that this kind of tight syncing is only really required for the Wii because of the really low-level audio API - this shouldn't be a requirement for any other system where we have a more or less lenient audio server.Īlso, whereas before the 360 port had totally FUBAR sound (but at least it ran and went ingame) - this time RetroArch tells me 'timings deviate too much' and then fails hard on an assert - which prevents it from starting up. I tried setting the second param to 0 - this gets rid of most of the audio pops that occur every 30-40 seconds - but instead, there is an 'audio pause' that replaces it. This produces a lot of audio pops right now. The default audio_init invocation in the libretro port is this - (this used to work fine for Genesis Plus GX 1.6.0). Reply to this email directly or view it on GitHub:Īny way I can get the old behavior back by any chance? Reproduce this issue, just ask and I could help.īTW- this issue seems to affect every platform- from PC to PS3 and so on. If you need help with compiling the libretro port and testing it on PC to Instance), so perhaps something got affected that hasn't made itself known I see that the audio code has changed here and there (blip buffer for.I can't see how my port code could be to blame - the audio settingsĬhanged the same in the GX port and they correspond with the libretro port Is affected by this same glitch - including Sega CD games. The Hedgehog (W (REV01) or some other Sonic game - but really, every game I can reproduce this with a game like Sonic It seems that starting with this version, there is now an annoying audio Request it, but one single thing is still bugging me. The libretr port is more or less done - I was about ready to git pull With your video hardware and pass its exact framerate to audio_init,Īudio_update will still return the appropriate number of samples on each Output samplerare (n = samplerate/framerate). Will return the appropriate number of samples on each frame based on your When doing this, it's easy (andĪdvised) to sync with your audio hardware since the audio_update function ![]() Ntsc machine, mclock_pal/313/3420 for pal). System_frame_xx functions (framerate is mclock_ntsc/262/3420 when emulating Master clock frequency) so your backend must use the same frequency to call Now run at the original machine speed (i.e based on original pal or ntsc Really need to be synced precisely with an external time reference) will Some changes between 1.6.0 and 1.7.0 : if you pass zero to framerate,Įmulation (and in particular audio chips since those are the only ones that What arguments are you passing to audio_init function ? There have been Samples returned on each frame by audio_update. Impact on external sync and is only more accurate regarding the number of Recent changes to psg chipĮmulation and sync with fm chip is internal to emulator should not have any Synced properly with your audio hardware. Related to audio options, so my first guess is that frame emulation is not Well, audio hichups are definitively an audio sync issue and should not be
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |