Surrounder+ bug (with 10k1 models)

Russ · Mar 5, 2007, 02:25 PM

Who is currently maintaining the Surrounder+ code?

The reason I ask, is because it suffers from the "writing to zero" problem (with 10k1 models anyway, which explains some issues noted in the forum regarding signals bleeding into other channels (related to the vRearW setting, IIRC)).

i.e. (code with Surrounder set to 4.1 (everything else is default values) with a Live! 5.1)

Code:

     macsn      lb,  in_L,  in_lfe,  0x40000000;
     macsn      rb,  in_R,  in_lfe,  0x40000000;
     acc3      LFE,  0x0,  0x0,  0x0;
     macs      0x0,  vWl,  wfzl,  wfb;
     macmv      wfzl,  vWl,  vWl,  wfy;
     macs      vWl,  accum,  in_L,  wfa;
     macs      0x0,  vWr,  wfzr,  wfb;
     macmv      wfzr,  vWr,  vWr,  wfy;
     macs      vWr,  accum,  in_R,  wfa;
     macs      0x0,  0x0,  lb,  SK1;
     macsn      dwL,  accum,  rb,  SK2;
     macs      lb,  lb,  in_n,  CK;
     macs      fL,  in_nw,  lb,  0x7fffffff;
     macs      sL,  in_sw,  drL,  0x7fffffff;
     macs      0x0,  0x0,  rb,  SK1;
     macsn      dwR,  accum,  lb,  SK2;
     macs      rb,  rb,  in_n,  CK;
     macs      fR,  in_ne,  rb,  0x7fffffff;
     macs      sR,  in_se,  drR,  0x7fffffff;
     macs      Center,  0x0,  0x0,  0x0;
     macs      0x0,  0x0,  0x0,  0x0;
     macs      0x0,  0x0,  0x0,  0x0;
     macs      0x0,  0x0,  0x0,  0x0;

The instructions highlighted in red are a problem with 10k1 models.

BTW: "Writing to zero" does not seem to be a problem when used with the MACMV instruction, nor with instructions such as "macs 0, 0, 0, 0".

-Russ

Max M. · Mar 6, 2007, 06:02 AM

>Who is currently maintaining the Surrounder+ code?

Eugene. But he won't be able to fix that. So i see no chance for me to not send corrected sources to him.

mmm... wil that work if i replace
" macs 0, 0, lb, SK1"
with
"macs anytempregister, 0, lb, SK1"
?

Russ · Mar 6, 2007, 08:52 AM

Thanks Max, I thought it was E., but wanted to be sure (as I had thought that you created originally), before posting something in the Bug Thread, etc.

Yes, that will fix it.

Russ · Mar 6, 2007, 10:20 AM

BTW: It is hard to test with Surrounder+, as with its dynamic code, it does not like being edited at run-time. But, I tested the various (suspect) parts of the code in seperate plugins (and as much as I could by editing Surrounder's microcode), and that should fix the 'writing to zero' problem in Surrounder+, but can you verify (since you understand the code the best) the following symptom to be sure it is caused by this?

If set to 4.1 mode, and vRearW > 0, 'in_n' bleeds into 'sR'. (Screenshot)

There may be other symptoms, but that is the main one (most visible one) that I noticed (and of course similair code is used under different settings, so it should be fixed for all settings).

With the 'writing to 0' problem, the result of the (red) instruction is added to the 2nd instruction following it (which is the instruction where 'in_n' is used (under the 4.1 setting)), so that would seem to be the cause of the above symptom (but again, if you could verify this, it would be good).

Maddogg6 · Mar 6, 2007, 11:07 AM

Quote:

If set to 4.1 mode, and vRearW > 0, 'in_n' bleeds into 'sR'.

I see this on my A2 card btw... so not just 10K1 cards

Russ · Mar 6, 2007, 11:21 AM

Quote:

Originally Posted by Maddogg6

I see this on my A2 card btw... so not just 10K1 cards

OK, so maybe there is another issue (which is why I wanted verification from Max), but can you try the following code (on your A2), so I can verify that it is not related to the 'writing to zero' problem:

Code:

static r1=0x0, r2=0x0, r3=0x0;
static r4=0x0, r5=0x0

macs      r1,  0x0,  0x0,  0x0;
macs      r2,  0x0,  0x0,  0x0;
macs      0x0,  0x20000000,  0x0,  0x0;
macs      r3,  accum,  0x20000000,  0x20000000;
macs      r4,  0x0,  0x0,  0x0;
macs      r5,  0x0,  0x0,  0x0;

Then use the 'mp' console command and post the register dump from the above code.

i.e.

Quote:

[8000]: 'r1' p=0; translated: 12a; current=0
[8001]: 'r2' p=0; translated: 12b; current=0
[8002]: 'r3' p=0; translated: 12c; current=28000000
[8003]: 'r4' p=0; translated: 12d; current=20000000
[8004]: 'r5' p=0; translated: 12e; current=0

Maddogg6 · Mar 6, 2007, 11:45 AM

Sure - no problem...

Code:

engine "kX";
created "03/06/2007";
guid "b28873c4-0b2c-422a-88f5-2ef29375c4da";
; Registers
[8000]: 'r1' p=0; translated: 400; current=0
[8001]: 'r2' p=0; translated: 401; current=0
[8002]: 'r3' p=0; translated: 402; current=28000000
[8003]: 'r4' p=0; translated: 403; current=0
[8004]: 'r5' p=0; translated: 404; current=0

end
>

I just so happened to have done this with a DSP with only epilog loaded (in middle of DSP config - if it matters.. ?? (Id think it shouldn't)

Russ · Mar 6, 2007, 11:53 AM

Quote:

Originally Posted by Maddogg6

Sure - no problem...

Code:

engine "kX";
created "03/06/2007";
guid "b28873c4-0b2c-422a-88f5-2ef29375c4da";
; Registers
[8000]: 'r1' p=0; translated: 400; current=0
[8001]: 'r2' p=0; translated: 401; current=0
[8002]: 'r3' p=0; translated: 402; current=28000000
[8003]: 'r4' p=0; translated: 403; current=0
[8004]: 'r5' p=0; translated: 404; current=0

end
>

I just so happened to have done this with a DSP with only epilog loaded (in middle of DSP config - if it matters.. ?? (Id think it shouldn't)

Ok, so your A2 does not have the 'writing to zero' problem, so it seems that there is another issue that is causing the bleeding (although the 'writing to zero' thing is still an issue with 10k1 models (just not that issue)).

Thanks

Maddogg6 · Mar 6, 2007, 12:28 PM

Quote:

Originally Posted by Russ

Ok, so your A2 does not have the 'writing to zero' problem, so it seems that there is another issue that is causing the bleeding (although the 'writing to zero' thing is still an issue with 10k1 models (just not that issue)).

Thanks

Ok I tested the surrounder again to re-verify.. yes it DOES leak 'in_n' into 'sR'
with surrounder set to 4.1 - ON and VRearA>0 and VRearW>0 (both seem to affect sR out level)

Russ · Mar 6, 2007, 02:52 PM

Ok, I see the what is causing the second issue:

Code:

     macsn      lb,  in_L,  in_lfe,  0x40000000;
     macsn      rb,  in_R,  in_lfe,  0x40000000;
     acc3      LFE,  0x0,  0x0,  0x0;
     macs      0x0,  vWl,  wfzl,  wfb;
     macmv      wfzl,  vWl,  vWl,  wfy;
     macs      vWl,  accum,  in_L,  wfa;
     macs      0x0,  vWr,  wfzr,  wfb;
     macmv      wfzr,  vWr,  vWr,  wfy;
     macs      vWr,  accum,  in_R,  wfa;     
     macs      0x0,  0x0,  lb,  SK1;
     macsn      dwL,  accum,  rb,  SK2;     
     macs      lb,  lb,  in_n,  CK;     
     macs      fL,  in_nw,  lb,  0x7fffffff;
     macs      sL,  in_sw,  drL,  0x7fffffff;     
     macs      0x0,  0x0,  rb,  SK1;
     macsn      dwR,  accum,  lb,  SK2;
     macs      rb,  rb,  in_n,  CK;     
     macs      fR,  in_ne,  rb,  0x7fffffff;
     macs      sR,  in_se,  drR,  0x7fffffff;     
     macs      Center,  0x0,  0x0,  0x0;
     macs      0x0,  0x0,  0x0,  0x0;
     macs      0x0,  0x0,  0x0,  0x0;
     macs      0x0,  0x0,  0x0,  0x0;

The first (red) instruction, combined with the second (blue) instruction is the problem.

'lb' is modified and then written to TRAM, while 'rb' is modified after being written to TRAM (so you get different results in 'sL' and 'sR'.

The code would need to be modified such that 'lb' are 'rb' are used in the same way.

i.e. (something like this)

Code:

     macsn      lb,  in_L,  in_lfe,  0x40000000;
     macsn      rb,  in_R,  in_lfe,  0x40000000;
     acc3      LFE,  0x0,  0x0,  0x0;
     macs      0x0,  vWl,  wfzl,  wfb;
     macmv      wfzl,  vWl,  vWl,  wfy;
     macs      vWl,  accum,  in_L,  wfa;
     macs      0x0,  vWr,  wfzr,  wfb;
     macmv      wfzr,  vWr,  vWr,  wfy;
     macs      vWr,  accum,  in_R,  wfa;   
  
     macs      0x0,  0x0,  lb,  SK1;
     macsn      dwL,  accum,  rb,  SK2;  
     macs      0x0,  0x0,  rb,  SK1;
     macsn      dwR,  accum,  lb,  SK2;
     macs      lb,  lb,  in_n,  CK;     
     macs      rb,  rb,  in_n,  CK;     
     macs      fL,  in_nw,  lb,  0x7fffffff;
     macs      sL,  in_sw,  drL,  0x7fffffff;     
     macs      fR,  in_ne,  rb,  0x7fffffff;
     macs      sR,  in_se,  drR,  0x7fffffff;     

     macs      Center,  0x0,  0x0,  0x0;
     macs      0x0,  0x0,  0x0,  0x0;
     macs      0x0,  0x0,  0x0,  0x0;
     macs      0x0,  0x0,  0x0,  0x0;

Max M. · Mar 6, 2007, 04:52 PM

well, if it is about in_n - then i'm off - i'm not responsible for that 'surrounder+'
(it's a hack by someone - it is not my code, so i'm not sure i understand how it is supposed to work)...
but i'll look into...

Maddogg6 · Mar 6, 2007, 05:44 PM

Quote:

Originally Posted by Max M.

it's a hack by someone - it is not my code, so i'm not sure i understand how it is supposed to work)

No I know what you all must be thinking - but I SWEAR I had nothing to do with *that*...

Russ · Mar 6, 2007, 05:50 PM

I understand, I am also have a little difficulty trying to figure out the intention of the code in certain places.

I do not even know if fixing the above will fix all the problems.

i.e.
I noticed that with the 4.1 default settings (i.e. 4.1 speaker mode selected, without changing anything else), If a signal is sent into 'in_n' and 'in_lfe', both signals get cut out of the front channels (only goes to rear channels), which appears to be a third issue (edit: actually it only happens if vCenterA is 1.00, so maybe it is not so bad).

Russ · Mar 7, 2007, 10:11 AM

BTW: It appears that 'sCenter1' is never used with 10k1 models, but for some reason the output is still included in the code. This gives the possibilty of using sCenter1 instead of a temp, to fix the 'writing to zero' problem with 10k1 models (sCenter1 should just be cleared before the end of code, and there is room to this, since the last 3 instructions are NOP's). This would prevent the need for an extra GPR (for that matter any GPR that is used after those instructions (and is overwritten) can be used, so a temp is not needed).

Russ · Mar 7, 2007, 12:57 PM

In case Max decides he does not want to do it, I thought I would take a stab at correcting Surrounder+ (for the 'writing to 0' problem, and the bleeding problem).

I made the changes I mentioned previously (uses sCenter1 to prevent the 'writing to zero' problem (for 10k1 cards), and reordered the instructions to prevent the bleeding problem (for all models)), and recompiled Surrounder+. From what I can understand of the intended purpose of the code, the changes should not break anything (but hopefully makes it work better (3D sound positioning, and sound in general (with speaker modes > 2.1))).

BTW: This is Surrounder+ (not Surrounder).

If anyone would like to try it, I added it to my webpage (at the very bottom of the page (for kX version 3538m only)). It will not replace the original Surrounder+, and will be added to the effect menu under "Surrounder+ (Test)".

BTW: I removed the "A2" check so that I could test the 6.1 and 7.1 modes (test as much as I can with a 5.1 card anyway) as well, so it will use an extra GPR, and will have an extra output with 10k1 cards.

If anyone tries it, let me know if you think it works better than the bundled version, or if there are any problems (that are not a problem with the bundled version).

-Russ

Maddogg6 · Mar 7, 2007, 02:33 PM

Looks good so far here - 7.1 (in_w, in_e, in_top) sounds only come out in 7.1 modes. in_n no longer leaks...

Surrounder still changes its routing if selecting a headphone speaker mode after issuing the error message.
(leaks anything into LFE output - even tho - the Use Subwoofer Output switch is off)

Looks to me like a bugger to fix too - so maybe not worth that effort. No biggy anyway.

Nice work

Mark

Russ · Mar 7, 2007, 02:47 PM

Quote:

Originally Posted by Maddogg6

Surrounder still changes its routing if selecting a headphone speaker mode after issuing the error message.

The default behavior has it give the error and switch to 2.1 mode. That should be able to be changed easy enough.

Quote:

(leaks anything into LFE output - even tho - the Use Subwoofer Output switch is off)

I am not sure why it does that, since the 2.1 mode does not, I would have to look into it more.
<edit>
Actually I see the reason for this, and it should not be hard to fix either).
</edit>

In any case, since the HP modes are not functional, maybe it is not worth it anyway (would probably be better to just remove those modes until such time as they are functional).

Maddogg6 · Mar 7, 2007, 02:50 PM

Quote:

Originally Posted by Russ

In any case, since the HP presets are not functional, maybe it is not worth it anyway (would probably be better to just remove those presets/modes until such time as they are functional).

yeah - looks like they're partially implemented... but eh - what do I know...lol

Russ · Mar 7, 2007, 03:32 PM

Ok, I changed the behavior of the HP modes a little.
It still gives the message about not being supported, etc, but now it changes to 2.0 mode (2.1 mode, copy, no sub).

<edit>
Hold a sec, I forgot to hide the "Use subwoofer output" option for HP modes.
I will fix that in a sec.
</edit>

<edit2>
ok, done, it now hides the "Use subwoofer output" option with HP modes,
</edit2>

Maddogg6 · Mar 7, 2007, 04:50 PM

Hmm - I still see the switch... what file date/time should it be?
I have just got : 3/07/2007 3:26PM

??

But yes - no more LFE leaking...

*kudos to Russ*
*Mark green with jealousy*

Russ · Mar 7, 2007, 04:56 PM

Quote:

Originally Posted by Maddogg6

I have just got : 3/07/2007 3:26PM

I think you got a cached version or something.
Time should be 3:46.

Max M. · Mar 7, 2007, 05:01 PM

so i see Russ have done some fixes for it. Thank You. please let me know if you would need my assistance - unfortunately, i'm quite buzy these days so i cannot spend too much time for kX right now. Thanks.

Maddogg6 · Mar 7, 2007, 05:07 PM

Quote:

Originally Posted by Russ

I think you got a cached version or something.
Time should be 3:46.

Ok - its all good now... (I had before I posted, forced a page reload and still seen the 3:26 one.. ??)

Any - nice job.

Mark

Russ · Mar 26, 2007, 08:09 AM

@Max,

I have some more info regarding Surrounder+.

From what I can gather, the 10k1 version is supposed to remove 'in_s', 'in_top', 'sCenter1' and 'sCenter2' (since they are not used) and its corresponding code (the last 4 instructions), but currently it does not (only 'sCenter2' (register and code) is removed, and the corresponding code for the other registers are changed to NOP's).

This appears to be due to a bug in request_microcode();

Code:

int iSurrounder2Plugin::request_microcode()
{
    publish_microcode(surrounder2);

        if(!is_a2)
        {
         code_size-=4;
         info_size-=4;
        }

    return 0;
}

I am guessing that the above is intended to remove the last 4 registers and the last 4 instructions, but it seems that above should be:

Code:

int iSurrounder2Plugin::request_microcode()
{
    publish_microcode(surrounder2);

        if(!is_a2)
        {
         code_size-=4 * sizeof(dsp_code);
         info_size-=4 * sizeof(dsp_register_info);
        }

    return 0;
}

Additionally, 'in_s' and 'in_top' should be moved to the end (before 'sCenter1' and 'sCenter2') of the surrounder2_info structure (otherwise, if it worked like I think it was intended to, the wrong registers would be removed).

If the above is correct, then I guess it would be good if 'xrouting' were also modifed to remove these registers for 10k1 models (since again they are not used for anything).

What do you think about this?