Foolou

I spend some time getting information about all this spatialized audio stuff, even wrote a small C-proggy some years ago that did spatializing with the KEMAR data.

When I installed the kxdrivers I saw there is a DSP-Effect included who does spatialized audio for Headphones already, although it doesn't say anything about the way the spatializing is done.

My thoughts now are ... would it be worth trying to setup just another 3D-positioning effect (would be pointless if the HPhSp-plugin works the same way), and is the processing power of the 10k-chips high enough to multiply every sample with like 50 values?

Lex Nahumury

Well, It has been a while, but IIRC, spatializing using HRTF data requires the input samples to be convoluted against the HRTF table(s).
This would take quite an amount of memory which unfortunately the emu10kx chips simply don't have.
Using external (system) Tank memory for this is also problematic because of the way emu10kx accesses/utilizes this memory. (see doc's on emu10kx architecture)

The HPhSp-microcode is originaly from Creative (audigy series) and is
undocumented. By studying the code and through "trial and error"
one can more or less reverse engineer what's happening.
(Maybe someone else here has already finished doing this)
As far as i could tell, it uses filter techniques based on 'fixed HRTF' freq responses.

/LeMury

Foolou

I just tried a bit around.

With extremly reduced Datasets for the convolution it's doing something.

Actually it seems like spatialized audio in a way although it sounds a bit strange, could be an effect of my manipulation of the kemardata (took the diffuse.zip package, resampled to 48KHz and normalized it to a reasonable value)

Do you maybe have an idea how to do a FIR-Filter better than this?



itramsize 34

; Registers
input in;

output outl, outr;

static l10=0x10a19c9, l11=0x906eb00, l12=0xfdec109f;
static l13=0xf69bc293, l14=0x6f6b741, l15=0x239cc14;
static l16=0xfa986f78, l17=0x5d16b17, l18=0xcf1ba97;
static l19=0x2af1dba, l20=0x242dcde, l21=0xa66132f;
static l22=0x10d4cef, l23=0xe030fea5, l24=0x31dc46;
static l25=0xfe7b8399, l26=0xfc25fca9, l27=0xfe251fdf;

static r22=0x2ac2edd, r23=0x3082c08, r24=0xfd141764;
static r25=0xfe7f8383, r26=0x1d546ae, r27=0xffd378e3;
static r28=0xffb379d5, r29=0x4b5fc7b, r30=0x770914d;
static r31=0x253a91f, r32=0x267a885;
; only significant DATA of the FIR-Filter stored .. wanted to keep it small


temp right, left;

idelay write putincue at 0x0;

idelay read w32 at 0x32;
idelay read w31 at 0x31;
idelay read w30 at 0x30;
idelay read w29 at 0x29;
idelay read w28 at 0x28;
idelay read w27 at 0x27;
idelay read w26 at 0x26;
idelay read w25 at 0x25;
idelay read w24 at 0x24;
idelay read w23 at 0x23;
idelay read w22 at 0x22;
idelay read w21 at 0x21;
idelay read w20 at 0x20;
idelay read w19 at 0x19;
idelay read w18 at 0x18;
idelay read w17 at 0x17;
idelay read w16 at 0x16;
idelay read w15 at 0x15;
idelay read w14 at 0x14;
idelay read w13 at 0x13;
idelay read w12 at 0x12;
idelay read w11 at 0x11;
idelay read w10 at 0x10;

; i need all those read-stuff to access the data in the cue


; Code

macs putincue, in, 0x0, 0x0;

; that's how i understood those itrams work: you put stuff in it at 0x0 and
; gets up by one position each run, so i had to store the new sample first


macs left, 0x0, w27, l27;
macs left, left, w26, l26;
macs left, left, w25, l25;
macs left, left, w24, l24;
macs left, left, w23, l23;
macs left, left, w22, l22;
macs left, left, w21, l21;
macs left, left, w20, l20;
macs left, left, w19, l19;
macs left, left, w18, l18;
macs left, left, w17, l17;
macs left, left, w16, l16;
macs left, left, w15, l15;
macs left, left, w14, l14;
macs left, left, w13, l13;
macs left, left, w12, l12;
macs left, left, w11, l11;
macs left, left, w10, l10;


macs right, 0x0, w32, r32;
macs right, right, w31, r31;
macs right, right, w30, r30;
macs right, right, w29, r29;
macs right, right, w28, r28;
macs right, right, w27, r27;
macs right, right, w26, r26;
macs right, right, w25, r25;
macs right, right, w24, r24;
macs right, right, w23, r23;
macs right, right, w22, r22;

macs outl, left, 0x0, 0x0;
macs outr, right, 0x0, 0x0;

end

This should be the back/left speaker (150°), getting the right one is just a mirrored version of this.

Well .. I'm not really sure that it does the desired convolution at all, but it's fun to see that it's not so damn complicated to get something running on the dsp.

Foolou

Well, I put a little Effect together now.

If you listen to it with headphones it should sound like the signal is coming from rearleft and rearright. Just route a normal stereo-signal through it.

I also included 2 controlers so you can listen to the rearleft and rearright source seperatly.

This is it: rearspeakers.rar

Think I'll go for a virtual-4point-surround-headphone-plugin, although I first need to get more into details about the dane-language and the interior of the dsp.

Lex Nahumury

Interesting!
I was looking for a less resource consuming way to provide 'positional clues'.
(btw; does rear position realy loose that much low freq content?)
Hmm,..Too bad I dropped this subject quite a while ago and currently don't have time to examine it.
(other priorities)

Anyway,..Keep up the good work!

/LeMury

Foolou

I'm done with the 4-speakerversion:

4speakervirtualsurround.rar

No perfect sound, but working with internal registers only.
Done the math with the accu and not in a normal register, didn't help much I fear.
With the right wiring it could be used as replacement for the more resource using hphsp-plugin.

Still needs a lot to be done, like balancing front and back-channels, probably a total change of the used filters.

For the technically interested:
This plugin should do 4 simultanous FIRs with 4 Mono-Inputstreams.
The streams are delayed by 34 samples to do the FIR filtering, and only the significant samples of the FIR are used.