Search results

Ha, yes, I was experimenting with how high I could clock the RP2350. I have two: a SEEED XIAO which seems stable at 300MHz, and a ThumbyColor that only runs at 250MHz. Not sure if that is sample-to-sample variation, or different QSPI flash used by each board? I certainly wouldn't deploy in a...

For a display, I'm using a 240x240 st7789v LCD. I'm able to hit 60 FPS by clocking SPI at 75MHz, with double-buffering and non-blocking DMA. There's a quirk in the Pico2 SDK where overclocking forces the SPI clock to 24MHz, but you can prevent this by defining...

Hello, Yes! I confirmed your latest version (with templated shiftC) restored the performance, while still preventing overflows in the interpolated shading. Thank you!! Here's my profile of the 3 versions, where "Draw:" column shows the rasterization (in MHz consumed). You can see it's fixed...

I've been using your library (the improved-drawing-primitives branch) for more than a year now. It is amazing! After updating, I noticed a substantial regression in performance (up to 50% slower) for the drawing mode I use -- drawing triangles using SHADER_GOURAUD to an RGB565 framebuffer, on...

You can quickly see what different compilers will do, using Godbolt compiler explorer. Just type in a non-inline function and ignore any function-call overhead, like the return at the end (bx lr). https://godbolt.org/z/vPLCD-

Good point, you can sum the harmonics up to Nyquist to accurately synthesize these waveforms. When using wavetable synthesis, this is a great way to generate the bandlimited wavetables. But it can be expensive to do this real-time. You can use an inverse-FFT as an efficient oscillator-bank, but...

Just curious, what would be the specs on the resampling you want to do? Years ago I wrote a very fast polyphase resampler for a previous Cortex-M4 project that I'm happy to contribute. It used 16-tap precomputed filters to convert standard rates (8k, 11025, 16k, 22050, 32k, 48k) to 44100Hz...

Hi Paul, The noise-shaping is actually correct, because the signed shift does truncation toward -inf. The quant error is guaranteed to be a positive fraction in [0,1]. If you round instead of truncate (to prevent the 0.5 ULP DC offset) then the error feedback becomes more complicated (and slow)...

The original poster is right in that if you generate a trivial square or sawtooth at the target sample rate, it has already aliased and is too late to filter it out. An obvious solution is to generate at an oversampled rate, then downsample to the target rate. The problem is the harmonics of...

To get good performance on older Teensy's, most of the audio code uses fixed-point instead of floating-point math. In this case, biquad coefs are converted to fixed-point with sign bit, one integer bit, and 30 fraction bits. This effectively represents [-2.0, +2.0] with enough fraction bits to...

That's what I did with my Newhaven OLED. In ssd1351.h, I changed it to #define SPICLOCK 16000000 and was able to run the Teensy 3.6 at full speed.

I think you're right, the theoretical operation-count for partitioned convolution seems to always be lower than unpartitioned. In practice, when FFTs get too small (32-point RFFT is only a 16-point FFT) the overhead and housekeeping really start to hurt. I'd consider these tunable parameters...

@WMXZ For a filter with L=129, I think the standard FFT convolution (N=128 and NFFT=256) is the way to go. With a minimum-phase filter, you'll have near-zero added latency and great efficiency. You can also use a real-FFT to almost double the efficiency of the FFT and complex-multiply. For long...

For partitioned convolution, the filter and the output are the same, only the machinery is different. The basic idea is to think of your long filter as the sum of shorter filters (where all but the first include some delay). This paper does a good job explaining it...

Nice work! If needed, there are several ways to reduce the latency further: 1) Instead of one big FFT, you can use uniform-partitioned FFT convolution to operate in blocks of 128. Slightly less efficient, but avoids the buffering latency and also distributes the computation. 2) You can reduce...

You forgot that the original code correctly saturates when the left-shift overflows. It's the same problem that Paul describes above with __SSAT(y<<n, 31). Bits are lost during the shift before saturation takes place. Here is an alternate method: int CLIP_2N_SHIFT(int x, int n) { int y =...