Duke_srg

I implemented chorus-like plugin, but there is some hiss in the output. Can anyone say what is the problem, or this is a feature of such implementation?

p.s. I used sin generator code from the wavegen2

; Generated by kX DSP Editor - microcode dump
name "xChorus";
copyright "Duke";
engine "kX";
created "Aug 8 2003";
guid "437227c7-6f76-469d-b386-73fdc67434bb";
xtramsize 2048
; Registers
input in;
output out;
control Delay=0x0, Depth=0x0, Frequency=0x0;
control Feedback=0x0;
static offs=0x800, amp=0x1e0, y2=0x7fffffff;
static y1=0x7fffffff, maxdelay=0x400, prev=0x0;
static _AC1000=0x1000, _AC200=0x200;
temp tmpfreq, tmpdelay, sin;
; External TRAM delay line (2048 samples; ~0.042667 msec)
xdelay write wrt at 0x0;
xdelay read rd at 0x0;

; Code
macsn tmpfreq, 0x7fffffff, Frequency, _AC1000;
macs sin, 0x0, tmpfreq, y1;
macsn sin, sin, y2, 0x40000000;
macints sin, 0x0, sin, 0x2;
macs y2, y1, 0x0, 0x0;
macs y1, sin, 0x0, 0x0;
macs sin, 0x0, sin, 0x20000000;
macw tmpdelay, 0x0, Depth, sin;
macs tmpdelay, _AC200, tmpdelay, amp;
macs tmpdelay, tmpdelay, Delay, maxdelay;
macintw &rd, &wrt, tmpdelay, offs;
interp prev, prev, 0x40000000, rd;
macs out, prev, 0x0, 0x0;
macs wrt, in, rd, Feedback;

end

Lex Nahumury

Hi,

There are probably more then one reason this code doesn't work.

1. The sine code you used (well written by Eyagos) is meant for tone generation.
Therefore it's output range is not from 0...1 (wich you need for LFO purposes)

2. I see you try to use xtram instead of itram.
Any particular reason why?

3. Your code differs much from the standard 'chorus' approach.

Most working chorus/vibrato code I use, use itram.
If you are interested I can post a working version here.
To be honest, I have never seen this implemented in xtram.

I tried to code a chorus in xtram, but I guess the adressing 'trick'
to access xram is different from itram.
Besides that, to my knowledge, xtram uses 16 bit data.

Hmmm...interesting.

Max,...
Is it possible to make a lfo modulated delayline in xtram?
If so how does it differ vs the itram approach?


Regards,

/LeMury

Duke_srg

1. I corrected generated offset at line 9
2. I just tried
3. it's not actually a chorus, its a delay line with modulated delay - nothing more.

As i know, both trams is 16-bit.
I think itram trick should work fine with xtram too. But when i changed xtram to itram in my source, the clicks in the output disappears.
The trick MUST work, because there is no difference between itram and xtram access.
You can try my implementation in itram and xtram and see, that some noise clicks is only the difference between them. Maybe this is because xtram uses pci bus to access tank.

Lex Nahumury

>1. I corrected generated offset at line 9

Yep, sry, missed that one

>3. it's not actually a chorus, its a delay line with modulated delay - nothing more.

lol..I know that (read last section of my previous post).
What I meant is that it differs from the "standard vibrato/chorus/flanger whatever" code
as seen implemented in KX and APS effects wich goes more like this;

;--------------------------------------------------------
name "Basic Vibrato";
copyright "by LeMury 2003";
engine "KX";
created "08-12-2003";
comment "Basic vibrato";
guid "c09383e2-f7bb-44e8-b05f-3c16aa74b68c";

itramsize 962
input in
output out
control Freq=0.1
control Delay=0.3
static xsin, xcos=0.5
static t1, b
const maxtime=0x1df800

;delay line
idelay write d1 at 0
idelay read d11 at 961
idelay read d12 at 961
;------------------------------------
; freq control workaround
macs b, 0, freq, 0.001

; sine osc -0.5..0.5
macs xsin, xsin, b, xcos
macsn xcos, xcos, b, xsin
; range to 0..1
macs b, 0.5, xsin, 1
;-----------------------------------
; calc interpolation coef...
macintw t1, 0, t1, 0x00100000

; read tap points, interpolate (smoothing), output
interp out, d11, t1, d12
;-------------------------------
; set delay time
macs t1, 0, maxtime, Delay

; mod delay line (calc new read adresses and write them)
macs t1, &d1, t1, b
macints &d11, t1, 0x800, 0x1
macints &d12, t1, 0x800, 0x2

; feed delay line
macs d1, in, 0, 0
;----------------------------------
end;

This works in itram, but still not in xtram.

>You can try my implementation in itram and xtram and see, that some noise clicks is only
>the difference between them.

I have tried that, but it still makes the noise.
Please post your itram version so I can see if we are doing the same.

>Maybe this is because xtram uses pci bus to access tank.
>The trick MUST work, because there is no difference between itram and xtram access.

Maybe, but for some reason it does not work.

Well, I dropped the question to KX DSP engineers. I'm sure we will get an answer.
Keep me posted,

Regards,

/LeMury

Duke_srg

I just changed xtram declarations to itram.

Eugene Gavrilov

I tested both versions (itram/xtram)
it seems that the issue is really xtram-specific and currently cannot be avoided
probably, it is PCI-bus related (re-loading xTRAM addresses is a PCI-intensive operation...)

/Eugene

Lex Nahumury

>it seems that the issue is really xtram-specific and currently cannot be avoided.....

Hmm,.... I guess we will have to stick to itram then.
Thanks for clearing that up Eugene.

Regards,

/LeMury

Eugene Gavrilov

anyway, we can wait till Max investigates this case, too
there was a pseudo-issue with '0x800' constant (which has different meaning under 10k1 & 10k2)
moreover, the 0x800 is used as a shift value for TRAM access for certain cards
so, there are plenty of things to check

btw, if you change 0x800 to any other value (and modify the xtramsize accordingly) -- does it affect the issue in any way?
also, what is your card model?

/Eugene

Lex Nahumury

>anyway, we can wait till Max investigates this case, too

Good idea..

>there was a pseudo-issue with '0x800' constant (which has different meaning under 10k1 & 10k2)

On this machine I use a 10k1 based card. I have not yet tried it on my Audigy machine.

>moreover, the 0x800 is used as a shift value for TRAM access for certain cards

Yes, the 11 bits adress shift as mentioned in D. Bertands as10k1-manual.
So theoreticly it should work on the 10k1 card.

>btw, if you change 0x800 to any other value (and modify the xtramsize accordingly) -- does it affect the >issue in any way?

I will try that, but like you said;....plenty things to check...

/LeMury

Duke_srg

I have SB0092 (10k2), so maybe this it the problem?
BTW, where i can find 10k2 related docs, i can't find anything but asm10k1 manual. KX sdk header files helps, but a want full docs

Eugene Gavrilov

there are no 10k2 docs
the only source of information is our 8010.h file

from the DSP programmer point of view, there should be no differences between 10k1 & 10k2
(kX Driver uses logical registers when accesing inputs & outputs)
so, (theoretically) any program should run correctly under both 10k1 & 10k2 (provided there are free resources available)

/E

Lex Nahumury

Well, I have tried it on 3 machines now; 2 with 10k1 cards and 1 with 10k2 card.
Problem remains the same. So i think it's not card/chip related.

/LeMury

Eugene Gavrilov

>> So i think it's not card/chip related

if the distortion sounds the same on all the hardware without any change in the DSP code, then, hopefully, the problem is not related to the '0x800' bug. probably, a PCI timing issue...

btw, check the following: add a 'vol' effect before and after the xChorus (thus we will eliminate the usage of physical FXBUSes -- there's a known issue with the DSP dealing with multiple hardware inputs/outputs at the time)

also, try to rewrite the instruction "macintw &rd, &wrt, tmpdelay, offs;" to something like:

"temp a;
macintw a, &wrt, tmpdelay, offs
macs &rd, a, 0, 0",

thus, eliminating the simultaneous access to the xTRAM address registers

(I cannot test this myself because I'm currently working on EAX/DSound3-D and don't have kX drivers installed )

/Eugene

Duke_srg

Tell me please, how does this works? I mean sin generation.

Lex Nahumury

control Freq=0.1
static xsin=0, xcos=0.5
temp b

; Divide the freq control value to a usable runtime value in gpr b
;(This is a workaround. Normaly it should be done in dll extension)
; b = 0 + (freq*0.001)
macs b, 0, freq, 0.001

; b holds freq runtime value.
; Cosine starts at 0.5 after microcode is loaded.
; At each sample cycle:
; sin = sin +( b*cos)
; cos = cos -(b*sin)
; So it starts 'oscilating' and we get 2 sines with 90 degrees phase difference:
macs xsin, xsin, b, xcos
macsn xcos, xcos, b, xsin

; Output swing of osc is -0.5..0.5
; We need 0..1 range for moding purpose so we add offset:
; b = 0.5 + (sin*1)
macs b, 0.5, xsin, 1

;b holds final osc output

If you need -1..1 swing, just let cosine start at '1' instead of 0.5
It's a simple, crude but code efficient sine gen good enough for lfo stuff.

/LM