RecL doesn't record if connected...

eyagos

RecL doesn't record if connected directly to FXBus0 (with defaults routings). But RecR yes. And more, if I put an effect (anyone) between FX0 and RecL, it records perfectly.

eYgos.


----Hardware / Software configuration---------------
Driver Name:kX Audio Driver (Debug)
Driver Date: Oct 30 2003 01:31:32
Driver Version: 5.10.00.3536 - debug
DB Name:non
SB0240 10k2 [b400]
PCI Information:
Device: 41102 Subsys: 10021102 ChipRev: 4
Card is '10k2'
Card has MPU device
Card model is '5.1'
Card is Audigy2-compatible
Card HAS AC97 codec
Codec name: SigmaTel STAC9721/23
3D Extension: SigmaTel 3D Enhancement
Codec is 2.0 compliant
Capabilities[6940] :
DAC resolutions : -16-bit- -18-bit-
ADC resolutions : -16-bit- -18-bit-
Ext Capabilities [200]: -slot/DAC mappings-
Port: b400 Irq: 0xa(10)
Playback buffer: 20a0
Record buffer: 4000
Number of AC3 buffers: 4
Tank memory: 256 kb
GSIF buffer: 256 samples
OS version: [2 5 1 Service Pack 1; 2 5 1 Service Pack 1; 156 148]
----------------------------------------------------

Eugene Gavrilov

this is expected

sometimes you cannot use fx inputs/outputs connected to fxbusses (or any physical inputs/outputs) directly due to fx8010 hardware limitation

/E

Max M.

Yes, such issue is present. However this is more "dsp programming" issue then "bug".
As you remember there's some rule which sounds like "don't use more then one input register in one instruction, until you are sure that your plugin would not be connected directly to fxbus module"
This is related to the way dsp execution engine access regiters which are mapped to "phisical i/o" ports... If two or more such registers are accessed with single instruction the result of that instruction is undefined (unpredictable). This is not a big case since most of such " i/o mapped" registers are hidden with prolog and epilog... However FxBus module is exception. Its output pins are actually these naked i/o registers, so if some plugin with code that breaks above rule is connected to fxbus module some misbehaviour is possible (but not always)...
So finally, epilog accesses RecL/RecR inputs with (instructions 66/79):
macs tmpl, RecL, KX_IN(0), RecIn0;
macs tmpr, RecR, KX_IN(1), RecIn0;
where kx_in(x) is one of those "i/o mapped" registers.
And when you plug FxBus to RecL/R, the actual code in dsp becomes:
macs tmpl, fxbus0, KX_IN(0), RecIn0;
macs tmpr, fxbus1, KX_IN(1), RecIn0;
where fxbus0/1 are "i/o mapped" registers too...
Here we are - the rule is broken...
Well, again, this is not a big deal since Epilog is not meant to be used in that way (e.g. by default it is not connected to fxbus).

So, at last it can be treated as "Known Limitation":
"Do not connect RecR/L inputs of Epilog directly to FxBuses, that may not work" (e.g. result is undefined) ;)