Strange chorus (code inside)

Duke_srg · Aug 10, 2003, 02:33 AM

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 · Aug 11, 2003, 10:32 AM

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 · Aug 11, 2003, 01:05 PM

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 · Aug 12, 2003, 07:32 AM

>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 · Aug 12, 2003, 12:29 PM

I just changed xtram declarations to itram.

**Eugene Gavrilov** · Aug 12, 2003, 07:03 PM

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 · Aug 12, 2003, 08:53 PM

>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** · Aug 13, 2003, 07:10 PM

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 · Aug 13, 2003, 08:07 PM

>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 · Aug 14, 2003, 11:16 AM

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** · Aug 14, 2003, 09:00 PM

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 · Aug 15, 2003, 08:14 AM

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** · Aug 15, 2003, 05:43 PM

>> 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 · Aug 16, 2003, 03:45 PM

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

Quote:

Originally posted by LeMury
macs b, 0, freq, 0.001
macs xsin, xsin, b, xcos
macsn xcos, xcos, b, xsin
/LeMury [/b]

Lex Nahumury · Aug 16, 2003, 07:06 PM

Quote:

Originally posted by Duke_srg
Tell me please, how does this works? I mean sin generation.

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

Lex Nahumury · Aug 16, 2003, 07:24 PM

Quote:

Originally posted by 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

I treid it all, but still no luck so far. It's probably a PCI issue like Duke_srg and you mentioned.
But it's ok Eugene. There is no hurry.
You go concentrate working on that 3D stuff.

Let's just wait what Max has to say on this matter.

Thanks,

/LeMury

Lex Nahumury · Aug 16, 2003, 11:14 PM

Quote:

Originally posted by Duke_srg
I just changed xtram declarations to itram.

One question:
Did you really get a total clean and noise free modulated delayline with your code in itram?

I ask this because there is no way I can get a noise/click free delay in itram with your code.
(I use sine signals to test moded delaylines for detecting modulation artifacts)

Please let me know.

/LeMury

Duke_srg · Aug 17, 2003, 01:40 AM

I understand all of above, but i just want to know what is a mathematics bacground of this section. It seems like function decomposition to the series of power, but in that case, this is for constant argument

Quote:

Originally posted by LeMury
; 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:
/LM

**Eugene Gavrilov** · Aug 18, 2003, 06:43 PM

>> But it's ok Eugene. There is no hurry.

btw, how's our 'headphones / virtual speakers effect'? have you got any progress with it? it would be nice to have one to help us in 3-D programming

(I have stereo speakers, not a 5.1 speaker-set

)

/E

Lex Nahumury · Aug 18, 2003, 11:33 PM

Quote:

Originally posted by Eugene Gavrilov
btw, how's our 'headphones / virtual speakers effect'? have you got any progress with it? it would be nice to have one to help us in 3-D programming (I have stereo speakers, not a 5.1 speaker-set )

/E

Well, it does what it suppose to do...

I will dig that stuff up as soon as I can and post it in:
crossfeed dsp plugin?

Right now I'm tired...was busy compiling dll, usually works fine but once in a while I mess with the upper/lower case of the plugins name declarations, ending the evening/night with a nice bunch of 'undeclared identifiers'...LMAO...

Then it's time to go to bed...

/LM