Surrounder+ bug (with 10k1 models)

Russ · Mar 5, 2007, 07: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;
     [COLOR=Red]macs      0x0,  0x0,  lb,  SK1;[/COLOR]
     macsn      dwL,  accum,  rb,  SK2;
     macs      lb,  lb,  in_n,  CK;
     macs      fL,  in_nw,  lb,  0x7fffffff;
     macs      sL,  in_sw,  drL,  0x7fffffff;
     [COLOR=Red]macs      0x0,  0x0,  rb,  SK1;[/COLOR]
     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, 11: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, 01:52 PM

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, 03:20 PM

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, 04:07 PM

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, 04:21 PM

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, 04:45 PM

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, 04:53 PM

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, 05: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, 07: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;
     [COLOR=DeepSkyBlue]macsn      dwL,  accum,  rb,  SK2;[/COLOR]     
     [COLOR=Red]macs      lb,  lb,  in_n,  CK; [/COLOR]    
     macs      fL,  in_nw,  lb,  0x7fffffff;
     macs      sL,  in_sw,  drL,  0x7fffffff;     
     macs      0x0,  0x0,  rb,  SK1;
     [COLOR=DeepSkyBlue]macsn      dwR,  accum,  lb,  SK2;[/COLOR]
     [COLOR=Red]macs      rb,  rb,  in_n,  CK;[/COLOR]     
     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, 09: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, 10: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, 10: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, 03:11 PM

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, 05: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, 07: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, 07: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, 07: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, 08: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, 09: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, 09: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, 10:01 PM

[color=gray]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.[/color]

Maddogg6 · Mar 7, 2007, 10: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, 02:09 PM

@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)
        {
         [COLOR=DeepSkyBlue]code_size-=4;
         [/COLOR][COLOR=DeepSkyBlue]info_size-=4;[/COLOR]
        }

    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)
        {
         [COLOR=DeepSkyBlue]code_size-=4 * sizeof(dsp_code);
         info_size-=4 * sizeof(dsp_register_info);[/COLOR]
        }

    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?

Russ · Mar 26, 2007, 02:34 PM

If anyone is interested, I updated the test version with the above changes:

i.e.
I removed 'in_s', 'in_top', 'sCenter1' and 'sCenter2' and it's corresponding code for non-A2 cards (registers and code).

I re-did the previous microcode changes to use 'Center' instead of 'sCenter1' to prevent the 'writing to zero' problem (because 'sCenter1' was removed for non-A2 models).

BTW: The A2 check is re-enabled.

If anyone tries it out, let me know if there are any problems, etc.

-Russ

Max M. · Mar 26, 2007, 05:21 PM

Thanks Russ.

(just for the record - i'm not responsible for any surrounder+ hacks - only "surrounder w/o plus" is my authentic code (not including GUI part)

well, never mind )

So, anyway, when time comes, could you please send fixed sources to E.?

Russ · Mar 26, 2007, 06:35 PM

Quote:

Originally Posted by Max M.

(just for the record - i'm not responsible for any surrounder+ hacks - only "surrounder w/o plus" is my authentic code (not including GUI part)

well, never mind )

I understand, I just wanted to check to see if you had any knowledge of the Surrounder+ code (i.e. what was the original intention of some of these things, etc.), as I do not want to change anything that is the way it was intended to be, etc.

Also, Surrounder and Surrounder+ share some of the same code, and I have no way of knowing what parts are your original code ( Surrounder has the same 'writing to zero' issue, and the same issue with 'in_n' bleeding into 'sR', etc.).

Also, regarding the last info I posted, I always thought it was strange that 'sCenter1' was left in (with 10k1 models), but not connected to anything, but 'sCenter2' was not (i.e. if unused registers were to be removed, why not remove them all?), and from lookng at the code, it appears that the last 4 registers, and last 4 instructions were intended to be removed. I am thinking it is the 4 registers I mentioned previously, because they are not used with 10k1 models, but I cannot be sure about this. I was hoping for some confirmation on all this...

I really do not want to send Eugene anything unless I am sure it is right, as Surrounder+ is a main part of the default DSP config.

Russ · Mar 27, 2007, 12:07 AM

I added the source code to my download page (it only includes the files that are modified) if anyone wants to look over it.

All changes can be found in blocks like the following (so that they are easy to locate):

Code:

/* RG **********************************************/
     // code changes
/***************************************************/

Russ · Mar 29, 2007, 04:44 PM

Update:

I removed the 6.1 / 7.1 modes (i.e. no longer shows "(none)") and presets for non-A2 models.

I modified the behavior of the headphone modes/presets. Instead of changing to 2.1 mode, copy, no sub, it changes to 2.1 mode, off, no sub (because that is the values that the Hp presets are currently coded to use). Additionally, I made it so that the GUI shows this change (i.e. GUI changes to 2.0 Stereo Only after choosing a Hp mode or preset) instead of showing a blank page. This required less changes to the code (so it will be easier to undo if the Hp modes are ever implemented), and it will be more consistant as to what settings are being used after selecting one of these modes/presets (previously some of the settings where inherited from the previous setting, so when you selected a Hp mode/preset you could not be sure what settings it was using). So, now when you choose a Hp mode, it will be the same as choosing the 2.0 Stereo Only preset (again they were not implemented anyway, and previously just changed to some semi 2.0 state).

-Russ

Micha80 · Mar 31, 2007, 04:45 PM

Hello,

since i used the surrounder i wonder about the "sub out" function.

My example configuration is a stereo source (in_L, in_R) witch "bass redirection" enable.
The splited frequenz of both channels were simply add to the LFE out. The result is a +6dB higher sub level.

http://img133.imageshack.us/img133/5719/kxdspsrs1.png

Bug or feature?

There should be a limiter or something similarly.

Best regards
Micha

Mar 5, 2007, 07:25 PM	#1
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	Surrounder+ bug (with 10k1 models) 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; [COLOR=Red]macs 0x0, 0x0, lb, SK1;[/COLOR] macsn dwL, accum, rb, SK2; macs lb, lb, in_n, CK; macs fL, in_nw, lb, 0x7fffffff; macs sL, in_sw, drL, 0x7fffffff; [COLOR=Red]macs 0x0, 0x0, rb, SK1;[/COLOR] 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

Mar 6, 2007, 03:20 PM	Thread Starter #4
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	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). Last edited by Russ; Mar 6, 2007 at 03:38 PM.

Mar 6, 2007, 10:50 PM	Thread Starter #13
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	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). Last edited by Russ; Mar 7, 2007 at 02:59 AM.

Mar 7, 2007, 05:57 PM	Thread Starter #15
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	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 Last edited by Russ; Mar 7, 2007 at 06:24 PM.

Mar 7, 2007, 08:32 PM	Thread Starter #19
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	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> Last edited by Russ; Mar 7, 2007 at 08:50 PM.

Mar 6, 2007, 11:02 AM	#2
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	>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" ?

Mar 6, 2007, 01:52 PM	Thread Starter #3
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	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.

Mar 6, 2007, 09:52 PM	#11
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	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...

Mar 7, 2007, 03:11 PM	Thread Starter #14
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	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).

Mar 7, 2007, 07:33 PM	#16
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	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

Mar 7, 2007, 09:50 PM	#20
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	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

Mar 7, 2007, 10:01 PM	#22
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	[color=gray]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.[/color]

Mar 26, 2007, 02:09 PM	Thread Starter #24
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	@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) { [COLOR=DeepSkyBlue]code_size-=4; [/COLOR][COLOR=DeepSkyBlue]info_size-=4;[/COLOR] } 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) { [COLOR=DeepSkyBlue]code_size-=4 * sizeof(dsp_code); info_size-=4 * sizeof(dsp_register_info);[/COLOR] } 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?

Mar 26, 2007, 02:34 PM	Thread Starter #25
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	If anyone is interested, I updated the test version with the above changes: i.e. I removed 'in_s', 'in_top', 'sCenter1' and 'sCenter2' and it's corresponding code for non-A2 cards (registers and code). I re-did the previous microcode changes to use 'Center' instead of 'sCenter1' to prevent the 'writing to zero' problem (because 'sCenter1' was removed for non-A2 models). BTW: The A2 check is re-enabled. If anyone tries it out, let me know if there are any problems, etc. -Russ

Mar 26, 2007, 05:21 PM	#26
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	Thanks Russ. (just for the record - i'm not responsible for any surrounder+ hacks - only "surrounder w/o plus" is my authentic code (not including GUI part) well, never mind ) So, anyway, when time comes, could you please send fixed sources to E.?

Mar 27, 2007, 12:07 AM	Thread Starter #28
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	I added the source code to my download page (it only includes the files that are modified) if anyone wants to look over it. All changes can be found in blocks like the following (so that they are easy to locate): Code: /* RG ********************************************/ // code changes /*************************************************/

Mar 29, 2007, 04:44 PM	Thread Starter #29
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,563 Rep Power: 62	Update: I removed the 6.1 / 7.1 modes (i.e. no longer shows "(none)") and presets for non-A2 models. I modified the behavior of the headphone modes/presets. Instead of changing to 2.1 mode, copy, no sub, it changes to 2.1 mode, off, no sub (because that is the values that the Hp presets are currently coded to use). Additionally, I made it so that the GUI shows this change (i.e. GUI changes to 2.0 Stereo Only after choosing a Hp mode or preset) instead of showing a blank page. This required less changes to the code (so it will be easier to undo if the Hp modes are ever implemented), and it will be more consistant as to what settings are being used after selecting one of these modes/presets (previously some of the settings where inherited from the previous setting, so when you selected a Hp mode/preset you could not be sure what settings it was using). So, now when you choose a Hp mode, it will be the same as choosing the 2.0 Stereo Only preset (again they were not implemented anyway, and previously just changed to some semi 2.0 state). -Russ Last edited by Russ; Mar 29, 2007 at 04:55 PM.

Mar 31, 2007, 04:45 PM	#30
Micha80 DriverHeaven Newbie Join Date: Dec 2004 Location: NDS, Germany Posts: 7 Rep Power: 0	Hello, since i used the surrounder i wonder about the "sub out" function. My example configuration is a stereo source (in_L, in_R) witch "bass redirection" enable. The splited frequenz of both channels were simply add to the LFE out. The result is a +6dB higher sub level. http://img133.imageshack.us/img133/5719/kxdspsrs1.png Bug or feature? There should be a limiter or something similarly. Best regards Micha __________________ SB Audigy 1 (SB0090)