Russ

The appears to be a bug with Surrounder+ effecting the way LFE input is used under different settings.

Depending on the order in which certain options are selected, you get different results.

i.e.
Load Surrounder+.

Set the mode to 2.1 with Surround OFF ("Use Subwoofer Output" disabled).
- Note how LFE input is used in the microcode:
- - macsn fL, lb, in_lfe, 0x40000000;

Change the mode to 5.1 with Surround OFF ("Use Subwoofer Output" disabled).
Change the mode back to 2.1 with Surround OFF ("Use Subwoofer Output" disabled).
- Note how LFE input is used in the microcode now:
-- macsn fL, lb, in_lfe, 0x0;

This bug also effects other modes, so depending on the order in which certain settings are changed (when "Use Subwoofer Output" option is disabled), LFE input may be mixed in with other channels, or may not be used at all (i.e. same setting giving different results at different times).

BTW: This is not the only bug, there is also the bug(s) mentioned in the following thread:
Surrounder+ bug (with 10k1 models)

I will take a look at the code, and see if I can find the specific problem, etc (when I have a chance to do so).

-Russ

Max M.

surprisingly i can't reproduce this with my A2 (using kx39) for some reason.
In my case it is always 0x40000000;
but, yeah, i suppose it could be something wrong in C++ part

Russ

Hmmm, that is strange. Thanks for testing. I guess it would be helpful if other users (10k1 and 10k2) could check this as well (the line(s) in question is the first (2) instruction(s)).

BTW: I checked regular Surrounder as well and got the same result...

I will do some testing and see if I can find more info (and I guess I will use my test plugin as well, so I can disable 10k2 check to see if it is related to that).

<edit>
I got the same result with 10k2 check disabled so I am not sure why you cannot recreate the problem (it appears to happen every time for me).
</edit>

<edit2>
I checked with 3538h on WinME as well, and got same result (not surprising since Surrounder+ code has not changed in a while).
</edit2>

There only appears to be one place where that value is updated, so hopefully it will not be too difficult to figure out whats happening.

Russ

I found the problem...

The sub mode uses the surround mode as part of it's calculations, but the sub mode is not updated when the surround mode changes.

The code sets the value in question to 0, whenever the surround mode is set to OFF, so that value should be 0 in all speaker modes when surround is OFF (0.5 in all other surround modes). Because the sub mode is not updated when the surround mode changes, it's value remains at it's previous value instead of being recalculated (when the surround mode changes).

However, when changing the speaker mode, both the surround mode, and sub mode are recalculated (surround mode first), so depending on whether you change the speaker mode first, or the surround mode first, you will get different results.

(It also effects the other settings related to the sub mode for the same reasons.)

It should be an easy fix, but I will look over it some more (when I have more time), to try and make sure there are no other similar situations.

@Max M.
Given the above, I wonder why you could not recreate the problem?

Max M.

Yes. If i change "surround mode" first and then "speacker mode" it becomes 0.

Russ

Thanks again for the confirmation. I didn't send E. my previous fixes because I wasn't sure if I should remove the unused inputs/outputs for 10k1 cards (removing the inputs would be kind of pointless (since they do not use any resources) unless xrouting was updated as well). I think I will just remove the output (sCenter1) and leave the inputs (in_w, in_e, in_s, and in_top), and send E. the updated code.

Max M.

Thanks to you actually!