Music runs slightly slow

[zenzero-2001]

Hello

I've compiled Cannonball version 0.3 for Linux Mint 14.04 64bit. I have noticed that the music runs a tiny bit too slow. I verified this by capturing the sound test output with ALSA and comparing the length of Magical Sound Shower with the wave output of the VGM version and with various CD releases.

Love what you have done with the game :-)

[djyt]

Verified as an issue.

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

[J1mbo]

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).

[gingerbeardman]

What about comparing to the original arcade hardware?

[J1mbo]

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

[TwoLeaves]

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.

[J1mbo]

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.

[J1mbo]

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

[J1mbo]

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.

[zenzero-2001]

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.

[J1mbo]

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.

[J1mbo]

@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.

[zenzero-2001]

@J1mbo Thanks for fixing this :-)

[J1mbo]

@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).

[djyt]

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