Wow - interesting discussion.
I've implemented a real-time SDFT on an FPGA for use in carrier
acquisition of communications signals. It was surprisingly easy to do
and didn't require particularly massive resources, although FPGAs
naturally facilitate a degree of low-level parallelism that you can't
easily achieve in CPU-based systems.
Based on this it might be feasible to build the SPV on a modest FPGA
rather than resorting to GPUs or specialized parallel CPU systems. The
main stumbling block that I see was your use of double-precision
floating point. If that level of accuracy is really necessary then a
higher end FPGA would be needed as most mid-range devices are geared
more for fixed point or single-precision floating point.
I was a bit confused by the ICMC paper when it came to windowing. The
SDFT structure I'm used to seeing (as discussed in the Lyons/Jacobsen
article you referenced) involves a rectangular window applied prior to
the twiddle calculations using a comb-filter structure. Is this window
replaced by your frequency domain convolutions, or are the cosine-based
windows applied in addition to the rectangular one?
Eric
On 3/19/20 10:23 AM, Richard Dobson wrote:
In my original C programs it was all implemented in double precision
f/p, and the results were pretty clean (but we never assessed it
formally at the time), but as the computational burden was substantial
on a standard PC, there was no way to run them in real time to perform a
soak test.
However, we received some advanced (at the time) highly parallel
accelerator cards frm a Bristol company "Clearspeed" which did offer the
opportunity to perform real-time oscillator bank synthesis (by making a
rudimentary VST synth). For example, to generate band-limited square and
sawtooth waves. With single precision, and real-time generation it did
not take long at all (I ran it one time for 20mins, monitoring on an
oscilloscope) for phases to degrade and thus the waveform shape
degraded. Conversely, with double precision (which those cards fully
supported, most unusually for the time), I was able to leave it running
for some hours, with no visible degradation of the waveform or audible
increase in noise.
It doesn't fully answer your question, but I hope it offers some
indication of the potential of the process.
Later on, colleagues at Bath University got the SPV fully running in
real time on Nvidia GPU cards programmed using CUDA, fed with real-time
audio input, and this was presented (I think) at either ICMC or DaFX. If
John Fitch is following this, he will be able to give more details. GPUs
are definitely the way to go for SPV in real time. I estimated
(back-of-an-envelope-style) demands of the order of 50GFlops. Of course
there remain many unanswered questions!
Richard Dobson
On 19/03/2020 16:18, Ethan Duni wrote:
On Tue, Mar 10, 2020 at 1:05 PM Richard Dobson <rich...@rwdobson.com
<mailto:rich...@rwdobson.com>> wrote:
Our ICMC paper can be found here, along with a few beguiling sound
examples:
http://dream.cs.bath.ac.uk/SDFT/
So this is pretty cool stuff. I can't say I've digested the whole idea
yet, but I had a couple of obvious questions.
In particular, the analyzer is defined by a recursive formula, and I
gather that the synthesizer effectively becomes an oscillator bank.
So, are special numerical techniques required to implement this, in
order to avoid the build-up of round-off noise over time?
Ethan
_______________________________________________
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp
_______________________________________________
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp
_______________________________________________
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp
