posted 23 April 2002 06:47            

For example

posted 23 April 2002 13:25            

Sonically, I can't hear any difference between delay values of 525 and 526 samp.

posted 23 April 2002 15:35            

Once again, you describe a very interesting approach... But the sound you uploaded is not what you described. It is an older Sound that compares sines and square waves. Could you upload it again?

posted 23 April 2002 16:33            

You do have an interesting way of viewing the world... I obtained my phase plots using cross-correlation against pink noise. That shows that 525 samples is needed for flat phase response from DC to Nyquist. And that is the expected amount of delay needed for a FIR with 1051 taps.

But, it looks like you have uncovered an off-by-one error somewhere in the code that computes the filter tapweights. I am investigating further. Part of the difficulty comes from Smalltalk's wild insistence on numbering items from 1 instead of 0 (which as we all know is computer-speak for the first item...) This problem arises all the time in converting code between Fortran and C...

I even looked at the delay (non)effects of the attenuation on the output of the FIR filter. I put your 0.8993 factor inside the Smalltalk code and removed the attenuator just in case this causes a 1 sample delay (it doesn't). I also hard coded the 525 and 526 sample delays in your delay lines just in case there is some problem with round-off errors (there isn't). So all I can see now is that there must be something off by 1 in the Smalltalk code...

I do find it interesting that your Sound clearly demonstrates the error, while my cross-correlations do not. I wonder if I have an extra sample delay between my left and right channels on my soundcard SP/DIF inputs? I should try reversing the reference and test channels. If I do have an extra (unwanted) delay between left and right, that should produce twice the error you show with your sound.

posted 23 April 2002 16:47            

Is this a "feature" of S/PDIF, or is it just my peculiar sound-card? (I have an E-mu APS card).

- DM

[This also explains my prior confusion over the number of taps in the Kyma FIR Graphic EQ Sound. I can now state definitely that it uses 99-tap FIR filters. This also means that you probably shouldn't try to use this sound for serious filtering below about 1.5 KHz.

I know now that I need to insert a 1 sample delay on my left channel for any future measurements.]

posted 23 April 2002 17:34            

This is a tough discernment to make, but the Haas effect at 20 microsec can still lead one to hear sounds slightly to one side, whichever channel has the first appearance... If I choose the non-delayed left version then it sounds ever so slightly to my left side, compared to the delayed version. I realize this could also be due to an amplitude imbalance at some critical frequencies, as a result of my particular headphones and amplifiers.

But there is a smoking gun here, because prior experiments have shown that even in the presence of 10 dB amplitude imbalance, the Haas effect takes hold for delays as small as 20-40 microsec.

So my question to SSC is... Is there an inherent 1 sample delay in the right side output of your DAC's? and also on the S/PDIF. I have only ever used the Kyma->SoundCard connection on S/PDIF, and the delay is certainly present somewhere in that interface.

- DM

Another test shows that Capy is clean! I inverted the right channel output of that test Sound and then set the mixer board to center both channels. Without the delay, at high gain, I hear almost nothing. Putting in the 1 sample left channel delay produces a high hiss at that point. So it appears that Capy has very good time alignment on the analog outputs. I don't have any way to test the S/PDIF apart from my APS card.

Another test of mono pink noise into Capy from the S/PDIF shows that there is no delay L/R on S/PDIF input to Capy (and hence output from the APS). So it appears that my APS card during recording is to blame here...

posted 23 April 2002 19:20            

In all cases, when the filter size is 2*middle+1 the compensation delay must be middle+1 samples.

- DM

Running at a sample rate of 48 KHz here, I have been able to run the FIRFilter Soundblock with as many as 1281 taps. That's quite impressive! Somewhere between 1281 and 1437 taps the Capy runs out of gas. But that means that each tapweight is requiring somewhere between 14 and 16 nanosec to compute! Very impressive! (60-70 million taps/sec!)
That puts Capy at approx 1,000 times faster than my Pentium math models in SigLab and Mathematica!

BTW -- for all of you who wanted long convolutions, here it is! This FIRFilter Sound block offers more than twice the maximum length available with FFT processing. At 48 KHz this is equivalent to around 27 ms of convolution kernel. Perhaps by chaining several of these sounds together and scheduling on separate DSP's it would be possible to approach 3/4 sec of total convolution time! (for 28 DSP's)

posted 24 April 2002 12:48            

I did some more experiments last night and finally concluded the problem is in the software driver for the APS card (Win/95, Win/98). I can pipe sound into the APS card from the Capy over S/PDIF and mix and replay in realtime from the APS out to several other analog ports. When I do this, there is no delay between left and right channels.

The 1 sample delay is in the right channel and only shows up during recording -- in other words, only when data needs to be extracted from the APS card into the host computer. Direct routing on the APS card does not suffer this delay. There is also no delay in playback from computer memory to APS card. So I have to conclude that there is a quirk (bug!) in the APS device driver for Win95/98.

But I am grateful to your world view for finding a test that found my measurement bugs here. Now that I know about this problem it is easy to compensate in all further tests.

Cheers!

posted 25 April 2002 16:15            

phase-shift90.kym

The theoretical amplitude correction is 2/Pi. It also turns out that the window being used is a Hann window, not a Hamming window. The attached sound corrects the amplitude of the Hann window by removing the -3 dB backoff, and then multiplying every element of the FIR by 2/Pi. When this is done, the filter produces unity gain for all FIR lengths.