kode54/Game_Music_Emu

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

Opened this issue · 4 comments

yoyofr commented

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

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

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

Pardon my stupidity:

966cf2d

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

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:

966cf2d

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.