Problem with FXBus1 ??

Holy Av · Mar 26, 2004, 09:09 PM

I don't know if this is a problem of the driver, the card, or maybe I'm doing something wrong...

When I verify what comes from the FXBus1 (from "FXBus" or from a "Src" with "FXBus 0/1" selected), I see that the sound is not correct. I mean that the frequency response is not flat as it should be. The other FXBus tested are correct, so it does not seem to be a problem in the way I'm recording.

Is there someone that know about this problem?

Max M. · Mar 27, 2004, 02:50 AM

please, post more details about "verification method"

Holy Av · Mar 27, 2004, 08:59 AM

Well, I must be crazy, everything is fine this morning

But anyway, here is the test I made...

I use a "Src" as the source, linked to a "b2b" to correct the rounding error, and linked to Out15/Out16 of a "k2lt" (for Rec L/R). I put the WAVE/PCM volume at 100% and the MIDI Synth on mute (just to be sure). By the way, where is that volume control made? I mean, there is no code in the DSP for that volume, the FXBus has its data already scaled...

I use one instance of Cool Edit to play white noise, and another to record, all at 48kHz stereo 16bit. If the sound is played through kX Wave 4/5, and I set the "Src" to "FXBus 4/5", then what is recorded is exactly what is played (the exact same numbers, except the first 9ms which uses a volume ramp). But when it was played through kX Wave 0/1, and "Src" set to "FXBus 0/1", then the right channel had a decreasing frequency response starting around 17kHz.

I suppose we should always wait the next morning to see if a problem disappear by itself...

Thanks anyway for the fast reply

Max M. · Mar 27, 2004, 11:12 AM

in fact, present version of "b2b" breaks the "don't access input register more then once" rule...
The code that breaks this rule may behave incorrectly when being directly connected to naked "i/o mapped registers" (such as "outputs" of "fxbus" module)...

The reason of the side effect is "decoupled execution" (e.g. the values of some registers ("i/o mapped" and "tram data") are updated in parallel with main microcode execution)...

Depending on "b2b" code location within microcode memory, the value of the "input" register may be changed (prev.cycle->next.cycle) right in between instructions which "read" from that input (if input is fxbus)...

present "b2b" code:

Code:

macs t, 0x4000, in, 1 
limit out, 0x4000, in, t

That's it, if "in" of first instruction contains the value of fxbus input for "previous" sample while "in" of the second instruction has the value for "current" sample cycle - we've got "mysterious filter" instead of "bit correction"...

(This side effect is rare to occur (for example load some module before "b2b" and the problem will disappear) but it should still be kept in mind - btw., there're too many "unsafe" plug-ins today)

To prevent all this, b2b may be modified for example like this:

Code:

input 	inl
output 	outl
input 	inr
output 	outr
temp 	t, s
    
macs	 s, inl, 0, 0			; "cache" input 
macs 	 t, 0x4000,  s,  1
limit 	 outl, 0x4000,  s,  t
macs	 s, inr, 0, 0
macs 	 t, 0x4000,  s,  1
limit 	 outr, 0x4000,  s,  t
     
end

Holy Av · Mar 27, 2004, 01:57 PM

Quote:

Originally posted by Max M.
in fact, present version of "b2b" breaks the "don't access input register more then once" rule...
The code that breaks this rule may behave incorrectly when being directly connected to naked "i/o mapped registers" (such as "outputs" of "fxbus" module)...

The reason of the side effect is "decoupled execution" (e.g. the values of some registers ("i/o mapped" and "tram data") are updated in parallel with main microcode execution)...

Depending on "b2b" code location within microcode memory, the value of the "input" register may be changed (prev.cycle->next.cycle) right in between instructions which "read" from that input (if input is fxbus)...
[...]

Do you mean that we do not know at which cycle the values are updated? Is that cycle a constant? Because if it's not constant, then it would produce a terrible jitter if read at the wrong place. And even if the update cycle is constant and we read the value only once, it would cause possible phase shift of one sample between multichannel data (which it a BIG phase shift for high frequencies). So we realy need to know when the values are updated (or make a prayer

) !

Max M. · Mar 27, 2004, 02:56 PM

this value is constant. so there's no "jittering" possible
as for phase-shift - yes, this problem is present and not only because of above side-effect but also because of other things (module interconnections and loading order (e.g. location ("offset") of module in microcode memory)... - there's interesting discussion about this in russian node of the forum... i doubt if one can translate it to eng.

getting back to "decoupled execution", it is relatively easy to find out the exact time (position) when each "i/o" register being updatesd....
for example if in configuration you described above you have only "FxBus", "b2b" and "k2lt" loaded and "b2b" is loaded before "k2lt", then we could say that update of "fxbus1" register takes place after 1st instruction execution (or - let's count it from zero - "instruction n0", in other words "between 0 and 1 instructions")
("b2b" is placed at the start of microcode memory (offset 0), "fxbus" have no code and its loading order doesn't matter)...
Then it is not to hard to guess that "fxbus0" register is updated before instruction n0, "fxbus1" before n1, "fxbus2" before n2 and so on...
(if side-effect occures when "b2b" is loaded after "k2lt" (16 instructions) (e.g. "b2b" code starts from n16) then it means that fxbus registers start to be updated from instruction 16... etc. - well, i hope you've got the idea)

^ [knowledgebase, dsp programming, low level]

-----

so in fact, it is possible to put nesessary "smart procedures" to the "dsp programs loader" so it could generate some "dummy/fixup" code (such as "input cache" in above example) on-the-fly when required... (although, as Eugene has already said, noone probably feels good to waste his time for this - actually there're too many similiar side-effects and therefor too many "smart procedures" (or "AI functions") are needed)
but i would say "fight and you will get it" ;)

(edited - some corrections)