r/DSP

Learning project that became my favourite: a chiptune synth written entirely in x86-64 assembly (Linux, NASM). No libc, no audio library — just computing raw 16-bit samples and writing a WAV header by hand.

The premise is that sound is just a list of numbers (44100/second) describing where a speaker sits. So the whole synth is: generate the numbers, write them out.

It does four oscillators (square/saw/triangle + LFSR noise), polyphony by mixing voices into one buffer, ADSR envelopes, and FM synthesis with a hand-built sine table. Working on effects next (vibrato, delay, reverb).

github.com/whispem/asm.fm

Feedback on the low-level details welcome — especially the fixed-point math in the FM operator.

When you hear an instrument, you can tell it's a piano, a violin, a drum — even if they're all playing the exact same pitch. We call that difference "timbre." But it made me wonder: can you actually explain what timbre is, physically?

In school you probably learned that pitch comes from frequency — how many times the air vibrates per second. But since the same pitch can have different timbres, frequency clearly isn't the answer.

If you've messed with synthesizers, you might guess it's waveform shape — sawtooth vs. square vs. pulse. That's closer, but still not quite right either: waveforms that look completely different can sound identical.

I dug into this and wrote it up (free, no signup) with interactive audio demos so you can test it on your own ears.
Link: https://sciencemusic.pages.dev/timbre/

This post was created using AI assistance (mainly translation).

I posted my chorus plugin here a couple weeks ago and someone told me allpass interpolation was the wrong tool for a modulated delay, since the recursive state goes stale while the delay length is moving under it, and that I should look at Lagrange. I was still on linear at that point. So I wrote a 4-tap cubic Lagrange interpolator by hand instead of pulling in a crate, mostly because I wanted to understand it rather than trust it.

What's actually in the thing now, so nobody has to guess from the post:

- 6 ms base delay with the LFO modulating around it, cubic Lagrange on the fractional read. Taps at -1, 0, 1, 2 off the integer index, each one wrapping the ring buffer separately.
- One-pole highpass at 160 Hz sitting inside the feedback loop so the low end doesn't stack up.
- One-pole lowpass on the wet path, cutoff swept by the LFO between 1k and 7k. Most of the character comes from that, not the delay.
- Separate voice struct per channel, LFOs offset 90 degrees. Collapses to mono without eating itself.
- Dry/wet is a plain linear crossfade. There's roughly a 3 dB dip at 50% and I'm fairly sure that's comb cancellation from summing a correlated wet signal with the dry, not bad crossfade math. If that reasoning is wrong I'd like to know.

One debugging note that saved me: check your coefficients at frac = 0.5. They should land on -0.0625, 0.5625, 0.5625, -0.0625. Mine didn't, and it was a typo in one of the products in the third coefficient.

At my defaults (1.6 Hz, about 4 ms depth) the improvement is small. A little less grit on held notes up top. I assume it opens up more if you push the rate.

Two things I still can't answer:

1. Any reason to go past cubic when the modulation is this slow, or is higher order mainly for pitch shifting and wide sweeps?
2. The HF droop moves with the fractional part, so slow modulation means a slow wobble on the top end. Does anyone correct for that in practice or is it under the floor at this depth?

It's free, GPLv3, VST3 and CLAP, mac/windows/linux. It's built for pitch-corrected vocals specifically, which is the only thing I use it on. If you'd rather hear it than read about it, it's at pyfessional.tech, the download button picks your OS for you and the source is linked from the same page. Would rather have someone install it and tell me it sounds wrong than get upvotes.

I have a small chat app with voice rooms. Started on LiveKit, but every time the audio broke I had no idea what was going on inside. Too much code for me to read. So I wrote my own SFU on top of Pion. It's been running my rooms since July, up to 25 people.

Just pulled it out into its own repo: https://github.com/Amesu-afk/tarnmedia

About 1800 lines with tests. No simulcast, no transcoding, no recording. It forwards audio and video, checks JWTs, and that's it. Every subscriber gets the publisher's single encoding, so one bad connection makes the room worse for everyone. I know. That's the next thing I want to fix.

That's also where I'm stuck. If you've added simulcast to something this small, how did you keep the packet path from turning into a mess? Right now the forwarding code is simple enough to read in one sitting and I'd like to keep it that way, but layer selection looks like it touches everything.

I am working with an AMD Xilinx Zynq-7000 SoC (XC7Z035) board and need to send a 500MHz signal through the board's SMA output. The problem is that we are using the GTX Transceiver Wizard to generate this signal, and it is proving to be extremely complex.

I could barely find any tutorials on YouTube about it, the Xilinx manual is also quite hard to follow on this point, and there are almost no articles or forums discussing this specific use case. This has left me wondering whether the GTX Transceiver is simply not the most common path for this kind of application, since the scarcity of material suggests that few people use this flow.

I am hoping to hear from anyone who has been through this. Is the GTX Transceiver really necessary to generate a 500MHz signal on this board, or is there a more direct path, for example through some clocking IP or an external DAC? Does anyone have a reference, tutorial, or example project showing this GTX Wizard configuration flow in practice? Is there an alternative connector or approach you would recommend for sending this signal to the oscilloscope without relying on the GTX?

Any pointer, link, or even a suggestion that I am overcomplicating this would help a lot. Thanks in advance.

Been heads-down on this for about a year and figured this crowd would appreciate the guts more than the marketing page.

BeatForge — drum machine, step sequencer and REX loop player. VST3/AU/AAX/Standalone, universal binary. JUCE 9 (migrated last month), everything below the framework is my own code.

Bits that might be interesting to people here:

REX SDK. Wrote a JUCE wrapper around Propellerhead REX SDK 1.9, including drag-and-drop of slices out to the host. Bitwig still has no REX support, which turned out to be a decent reason for the plugin to exist.

Synth engines. ~5k lines of 808/909/modelling done from schematics rather than sample playback — VCA topology, click transients, pitch sweeps, the 909 tom triple-VCO, that sort of rabbit hole.

Antialiasing. Started with blanket 8x oversampling and it was eating CPU for no good reason. Replaced it with ADAA on the memoryless waveshapers (exact tanh with the ln(cosh) antiderivative) and linear-phase minBLEP saws at 1x, then a per-engine oversampling map — most engines run 1x now, only FMKick and the 909 snare need 4x. Built an offline FFT alias-measurement harness to verify it; alias floor sits around -90 dB. Worth noting ADAA-2 blew up on me under heavy drive — catastrophic cancellation, auto-mute and crackle — so everything is bounded ADAA-1.

Realtime discipline. Lock-free atomic slot for deferred time-stretch, ScopedAudioSuspend guards on live mutators, steal-quietest voice allocation. Debug assertions went from ~3150 to 3. auval and pluginval at strictness 10 both clean.

Also. Full undo/redo, NAM master-bus saturation, and a WASM build of the synth engines for the site via Emscripten and a hand-rolled juce_shim.h.

Happy to go into detail on any of it — the ADAA and REX wrapper work especially, since there's not much written about either.

Site + demo: https://www.beatforge.nl

I have been working on AI Track Inspector 2.3, an experimental offline application that estimates whether a finished track contains acoustic patterns commonly associated with AI-generated music.

This is not intended to prove authorship or identify a generator with certainty. The output is a calibrated classifier estimate accompanied by temporal coverage, model agreement and reliability information.

How it works

The audio is converted to a normalized 16 kHz mono analysis signal and divided into overlapping four-second windows with a one-second hop.

Each window is evaluated by several branches:

• A spectral “fakeprint” branch looking at frequency-domain texture, high-frequency structure, spectral flatness, roll-off, transient behaviour and related statistics.
• A log-mel convolutional neural network trained on time-frequency representations.
• A rhythm branch measuring beat-grid consistency and local timing behaviour.
• A fusion stage combining the branches while accounting for disagreement and out-of-distribution input.

The application then produces:

• An AI-likeness classifier estimate.
• A separate timeline showing where AI-like acoustic patterns were detected.
• Temporal coverage across the track.
• Reliability and branch-agreement information.
• An ambiguous verdict when the analytical branches strongly disagree.
• PDF and JSON reports.

The training and evaluation material included Suno and Udio tracks, mastered and pitch-shifted AI examples, commercially produced real music, demos, semi-live recordings and difficult human-made negative examples.

One important change was removing absolute or unusual BPM as independent AI evidence. Speed-ups, half-time/double-time interpretations and unreliable tempo tracking produced too many misleading results. BPM is now hidden when the beat grid is uncertain and rhythm can only contribute when supported by the other branches.

Implementation

The macOS version is built with SwiftUI, AVFoundation, Accelerate/vDSP and Core ML. The Windows version uses a local Edge/Chromium audio runtime with the same model weights and fusion logic. All processing happens on the user’s computer; audio is not uploaded to a server.

The detector is designed for complete tracks and final mixes, not isolated stems. Stem-level results can be misleading because their spectral and temporal distributions differ substantially from full arrangements.

I am particularly interested in feedback about:

• Codec and resampling robustness.
• Cross-platform decoder differences.
• Better out-of-distribution detection.
• Hard-negative dataset design.
• How uncertainty should be presented without turning a model score into a false claim of certainty.

The current builds are available here: https://www.dropbox.com/scl/fo/bo5dd9t04f818jc8uos44/AOp5_gUP0L6uc63o0nNXcRs?rlkey=9i817ml9fh7mkk0y6ebxaoq8v&dl=0

It is a free experimental project, and I would appreciate technical criticism, difficult test cases and ideas for improving the validation methodology.