the most commonly questions about XITE-1

[garyb]

88.2 is NOT just half of 44.1k. all the problems with samplerate conversion still apply.....

we haven't seen whether 64bit drivers will be included(although i would expect them to be), but assuming the are, then 32 or 64bit, xp or vista will be working.

yes, pci-e will work 32bit.

i hope that there are updated gsif drivers, too.

[dawman]

If not, the ancient one is quite stable.

GSIF 2.0 will allow me to record into the app using the GigaPulse IR reverb, which is a great sounding convolution reverb.

Perhaps an upgrade can come later, and add 32 more stereo channels like the ASIO 2 64 module has.

That would be a blessing.


Happy Memorial Day Weekend.

[kylie]

Happy Memorial Day Weekend.

weekend is over, isn't it? any chance to get you stop spamming the forum with your veterans pics?

I'm fine with your screenshots from your DAWgs, though

-greetings, markus--

[katano]

88.2 is NOT just half of 44.1k.

You're right Gary, it's just double

[kylie]

88.2 is NOT just half of 44.1k.

You're right Gary, it's just double

I was quite tempted to say that, too

[garyb]

ok, smarty pantses, you're all correct.

what i was saying is that to go from 88.2k to 44.1k, it's not just a matter of throwing out half of the data. fthere's still interpolation(guessing) involved in the resampling process....

[Fede]

there's still interpolation(guessing) involved in the resampling process....

it depends mostly on how smart the algorithm is. However, often interpolation in such a particular case yields the same result of throwing half the data away, though processing time might not take advantage from that.

cheers
Fede

[astroman]

afaik it's a filtering process of 13th order I-dunno-what, way beyond processing by my own humble math capabilities...

Anyone thinking it's a simple bit shift operation, at best spiced with an add/divide by two adjecent samples is completely on the wrong track.
Consult the literature, please... I did with few success, tho...
but i've understood enough to know that the division by 2 with no remainder is completely meaningless in this context - it does not matter at all.

in reverse this does not exclude that some (self declared) smart *ss wouldn't actually try exactly that. Craig Anderton found such candidates in some of his (early) sound card reviews. The higher rate was nothing but doubling the available samples and play them back twice as fast....
but as long as people get along with iTunes quality - who cares anyway ?

cheers, Tom

[Fede]

afaik it's a filtering process of 13th order I-dunno-what, way beyond processing by my own humble math capabilities...

Hello Tom, correct me if I'm wrong, it should be "simply":

1) FFT
2) Zero padding / Throwing samples
3) FFT
or implemented in some more efficient way with some linear phase FIR.

The higher rate was nothing but doubling the available samples and play them back twice as fast....

that's perfectly correct... the only way to upsample is to complete the transformed buffers with zeroes, but doubling the samples will skip FFT steps and avoid also digit approximation, so it is the best solution.
...same thing of throwing one sample in two for 88->44 conversion

Cheers
Fede

[hifiboom]

88.2 is NOT just half of 44.1k.

You're right Gary, it's just double

no its right.

88,2 is halfing the sampling interval compared to 44,1

aside from that for sure every discrete sampling interval will be interpolated through the D/A conversion process.

but that just a different thing from internal interpolation.
I`ve still not yet found out a way how to upsample stuff inside the sdk, when using 44,1. I guess it can only be done via sharc assembler and special code, as all atoms work at the sampling rate which is setup currently.

thats also one thing i wish to see on a possible sdk update. make available the special stuff.
how cool would it be to have an upsampling and downsampling atom which could be used in the same manner as the poly out atom.

I think there is no need for working at sampling rates higher than 44,1 as long as we have access to a higher sampling rate internally.

If you work cmpletly at 88,2 you halfen the available dsp power.

With 44,1 and upsampling on critical tasks the used dsp power can be reduced compared to woking always at 88,2.

And although the xite-1 has loads of power, the power should not be thrown away for the ease of coding (the normal coding paradigm ).

[astroman]

you probably know this already, but here's some background about sample rate conversion algorithms
... not really my cup of tea

cheers, Tom

[siriusbliss]

Hey, while you guys are talking about samplerates, where's that dang link to the Xite video from AES (or whatever it was) that's up on youtube (or wherever)?

Just a little more lusty distraction while we wait for the hardware to arrive.

Thanks,

Greg