search

kode54 / Game_Music_Emu

Game Music Emu - Multi-purpose console music emulator and player library
80 stars 16 forks source link

vgm/issue with recursive calls to int Vgm_Core::run_dac_control #2

Open yoyofr opened 10 years ago

yoyofr commented 10 years ago

Hi,

I've done some testing on a particular vgm file which was causing issue and it seems related to huge nb of calls to run_dac_control. I've just added a counter to get out of the function when reaching more than x recursive calls and it is now working rather well.

The file used is: https://dl.dropbox.com/u/1287967/djtBMX_avg2-tamaotheme-fixed.vgz

my slighly updated version of the code (128 is just a random value) /* Recursive fun starts here! */ int Vgm_Core::run_dac_control( int time ) { static int rec_cpt=0; if (rec_cpt>128) return 1;

rec_cpt++;
for ( unsigned i = 0; i < DacCtrlUsed; i++ )
{
    int time_start = DacCtrlTime[DacCtrlMap[i]];
    if ( time > time_start )
    {
        DacCtrlTime[DacCtrlMap[i]] = time;
        daccontrol_update( dac_control [i], time_start, time - time_start );
    }
}

rec_cpt--;

return 1;

}

kode54 commented 10 years ago

DAC Control should not recurse. It would be helpful if I could have this troublesome file, so I could trace where and how the DAC Control is reentering itself.

On Jul 27, 2013, at 3:27 PM, yoyofr notifications@github.com wrote:

Hi,

I've done some testing on a particular vgm file which was causing issue and it seems related to huge nb of calls to run_dac_control. I've just added a counter to get out of the function when reaching more than x recursive calls and it is now working rather well.

The file used is: https://dl.dropbox.com/u/1287967/djtBMX_avg2-tamaotheme-fixed.vgz

my slighly updated version of the code (128 is just a random value) /* Recursive fun starts here! */ int Vgm_Core::run_dac_control( int time ) { static int rec_cpt=0; if (rec_cpt>128) return 1;

rec_cpt++; for ( unsigned i = 0; i < DacCtrlUsed; i++ ) { int time_start = DacCtrlTime[DacCtrlMap[i]]; if ( time > time_start ) { DacCtrlTime[DacCtrlMap[i]] = time; daccontrol_update( dac_control [i], time_start, time - time_start ); } }

rec_cpt--;

return 1; }

— Reply to this email directly or view it on GitHub.

yoyofr commented 10 years ago

Ok. You should be able to get the file at the link I gave you. This was pointed out by one user of my iOS based player (modizer)

Here is the forum entry if you're interested: http://modizer.988727.n3.nabble.com/Issue-with-homebrew-Genesis-VGMs-samples-not-playing-td4023962.html

thanks for the ultra fast reply :-)

ym

Le 28 juil. 2013 à 00:44, Chris Moeller notifications@github.com a écrit :

DAC Control should not recurse. It would be helpful if I could have this troublesome file, so I could trace where and how the DAC Control is reentering itself.

On Jul 27, 2013, at 3:27 PM, yoyofr notifications@github.com wrote:

Hi,

I've done some testing on a particular vgm file which was causing issue and it seems related to huge nb of calls to run_dac_control. I've just added a counter to get out of the function when reaching more than x recursive calls and it is now working rather well.

The file used is: https://dl.dropbox.com/u/1287967/djtBMX_avg2-tamaotheme-fixed.vgz

my slighly updated version of the code (128 is just a random value) /* Recursive fun starts here! */ int Vgm_Core::run_dac_control( int time ) { static int rec_cpt=0; if (rec_cpt>128) return 1;

rec_cpt++; for ( unsigned i = 0; i < DacCtrlUsed; i++ ) { int time_start = DacCtrlTime[DacCtrlMap[i]]; if ( time > time_start ) { DacCtrlTime[DacCtrlMap[i]] = time; daccontrol_update( dac_control [i], time_start, time - time_start ); } }

rec_cpt--;

return 1; }

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

kode54 commented 10 years ago

Pardon my stupidity:

https://github.com/kode54/Game_Music_Emu/commit/966cf2d866cec3226265798c4631e21ca9c57d83

It's supposed to be called from normal chip writes, but it's not supposed to recurse upon itself like that, since it makes no sense to catch all the other chips up with each individual timestamp update. Better to batch each chip up to the timestamp passed by the outer call. This should fix your stack overflow issues.

On Jul 27, 2013, at 3:51 PM, yoyofr notifications@github.com wrote:

Ok. You should be able to get the file at the link I gave you. This was pointed out by one user of my iOS based player (modizer)

Here is the forum entry if you're interested: http://modizer.988727.n3.nabble.com/Issue-with-homebrew-Genesis-VGMs-samples-not-playing-td4023962.html

thanks for the ultra fast reply :-)

ym

Le 28 juil. 2013 à 00:44, Chris Moeller notifications@github.com a écrit :

DAC Control should not recurse. It would be helpful if I could have this troublesome file, so I could trace where and how the DAC Control is reentering itself.

On Jul 27, 2013, at 3:27 PM, yoyofr notifications@github.com wrote:

Hi,

I've done some testing on a particular vgm file which was causing issue and it seems related to huge nb of calls to run_dac_control. I've just added a counter to get out of the function when reaching more than x recursive calls and it is now working rather well.

The file used is: https://dl.dropbox.com/u/1287967/djtBMX_avg2-tamaotheme-fixed.vgz

my slighly updated version of the code (128 is just a random value) /* Recursive fun starts here! */ int Vgm_Core::run_dac_control( int time ) { static int rec_cpt=0; if (rec_cpt>128) return 1;

rec_cpt++; for ( unsigned i = 0; i < DacCtrlUsed; i++ ) { int time_start = DacCtrlTime[DacCtrlMap[i]]; if ( time > time_start ) { DacCtrlTime[DacCtrlMap[i]] = time; daccontrol_update( dac_control [i], time_start, time - time_start ); } }

rec_cpt--;

return 1; }

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

yoyofr commented 10 years ago

thanks! Now I can go to sleep (1:24am in paris) ;-)

Le 28 juil. 2013 à 01:18, Chris Moeller notifications@github.com a écrit :

Pardon my stupidity:

https://github.com/kode54/Game_Music_Emu/commit/966cf2d866cec3226265798c4631e21ca9c57d83

It's supposed to be called from normal chip writes, but it's not supposed to recurse upon itself like that, since it makes no sense to catch all the other chips up with each individual timestamp update. Better to batch each chip up to the timestamp passed by the outer call. This should fix your stack overflow issues.

On Jul 27, 2013, at 3:51 PM, yoyofr notifications@github.com wrote:

Ok. You should be able to get the file at the link I gave you. This was pointed out by one user of my iOS based player (modizer)

Here is the forum entry if you're interested: http://modizer.988727.n3.nabble.com/Issue-with-homebrew-Genesis-VGMs-samples-not-playing-td4023962.html

thanks for the ultra fast reply :-)

ym

Le 28 juil. 2013 à 00:44, Chris Moeller notifications@github.com a écrit :

DAC Control should not recurse. It would be helpful if I could have this troublesome file, so I could trace where and how the DAC Control is reentering itself.

On Jul 27, 2013, at 3:27 PM, yoyofr notifications@github.com wrote:

Hi,

I've done some testing on a particular vgm file which was causing issue and it seems related to huge nb of calls to run_dac_control. I've just added a counter to get out of the function when reaching more than x recursive calls and it is now working rather well.

The file used is: https://dl.dropbox.com/u/1287967/djtBMX_avg2-tamaotheme-fixed.vgz

my slighly updated version of the code (128 is just a random value) /* Recursive fun starts here! */ int Vgm_Core::run_dac_control( int time ) { static int rec_cpt=0; if (rec_cpt>128) return 1;

rec_cpt++; for ( unsigned i = 0; i < DacCtrlUsed; i++ ) { int time_start = DacCtrlTime[DacCtrlMap[i]]; if ( time > time_start ) { DacCtrlTime[DacCtrlMap[i]] = time; daccontrol_update( dac_control [i], time_start, time - time_start ); } }

rec_cpt--;

return 1; }

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.