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

[yoyofr]

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]

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 [email protected] 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]

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 [email protected] 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 [email protected] 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]

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 [email protected] 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 [email protected] 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 [email protected] 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]

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

Le 28 juil. 2013 à 01:18, Chris Moeller [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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.