Music runs slightly slow about cannonball HOT 14 CLOSED

@zenzero-2001 I have posted a fixed version in my fork: https://github.com/J1mbo/cannonball

The main change is to run the sound and game in seperate threads, as on the the original hardware which decouples the timing. In the sound / music test menu there is a 'Playback Speed' option, which defaults to 125 and gives an exact speed match to the OutRun 20 years CD rips on YouTube. This gives a sound 'tick' period of exactly 8ms which seems plausible.

from cannonball.

Compared to a YouTube video, it does indeed run the same amount slow.

from cannonball.

Hi all. J1mbo, do you mean by the above comment that the Cannonball engine runs the music at the same speed as the original arcade machine (i.e. both "slow" compared to the CD)? If so I'm not sure that's correct, or perhaps there are multiple versions of the arcade machine. When I look at videos of the original machine on YouTube the music seems to run at 126bpm as opposed to this engine which runs at about 120bpm. That is on the "Passing Breeze" track, a good example of which (on original hardware) is here: https://youtu.be/8kM467EHDxE?t=622.

from cannonball.

Sorry for the lack of clarity. Yes I agree, the arcade cab is the same as the CD based on what I can find on YouTube.

from cannonball.

Verified as an issue.

I have not, as yet, been able to track down what is causing this.

from cannonball.

I think the CDs must have been re-mastered. The speed can be matched by increasing the sample rate to about 45KHz, but the pitch is then quite a lot out (maybe a semi-tone).

from cannonball.

What about comparing to the original arcade hardware?

from cannonball.

Based on the numbers, my guess is that something is counting to 64 instead of 60.

from cannonball.

The game timers (without fixed applied) appear to be true to the arcade. I haven't been able to alter the music playback speed at all, this one remains a mystery.

from cannonball.

Maybe it is something to do with the segapcm driver? The comment in the code says it is altered from the MAME version to output at a fixed rate of 44.1kHz, maybe there is an issue here? Also, I notice that the clock parameter for the SegaPCM constructor appears to be unused.

It is just an idea, I'm probably barking up the wrong tree.

from cannonball.

The bug was first noted in 2008 in MAME and noone has been able to fix it yet according to this: https://mametesters.org/view.php?id=7211

But I'm not convinced the error is in the Yamaha emulation. I'm wondering if the program sync between the 68k and Z80 might be to blame, I don't really understand enough about what does what on the system board. I was finally able to being the music (broadly) up to speed by adding an audio tick every 20 frames like so:

void OSoundInt::tick()
{
    if (config.fps == 30)
    {
        play_queued_sound(); // Process audio commands from main program code
        osound.tick();
        play_queued_sound();
        osound.tick();
        play_queued_sound();
        osound.tick();
        play_queued_sound();
        osound.tick();
        current_sound_frame += 4;
    }
    else if (config.fps == 60)
    {
        play_queued_sound(); // Process audio commands from main program code
        osound.tick();
        osound.tick();
        current_sound_frame += 2;
    }
    if (current_sound_frame == 20) {
        play_queued_sound(); // JJP - increase music by ~5%
        osound.tick();       // JJP
        current_sound_frame = 0;
   }
}

It might be better to put osound.tick() in a seperate thread then more granular control of the speed could be achieved.

from cannonball.

@J1mbo Thanks for fixing this :-)

from cannonball.

@zenzero-2001 no problem, I have further updated my fork today which I believe 'correctly' fixes this issue as I think it gets the cannonball emulator a bit closer to the way I think the arcade system board works. There are numerous other changes and performance improvements too, most significantly decoupling the game video and SDL2 video rendering (building without SDL2 is almost certainly broken).

from cannonball.

This is now fixed in the latest source chcek-in. And I really wish I'd read this thread first. :)

from cannonball.