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