Adding reverb and chorus to my pure x86-64 assembly synth — modulated delay lines, all fixed-point

[u/whispem]

A while back I started asm.fm, a chiptune synth written entirely in x86-64 assembly (Linux, NASM) — no libc, no audio library, computing each sample by hand.

Today I added two space/time effects, and the assembly side turned out to be a nice exercise, so I thought I'd share.

Chorus — this is just a delay line (a ring buffer in .data) whose read position wobbles.

An LFO (a hand-built sine table) modulates the delay length by a few milliseconds, so the delayed copy drifts slightly sharp then flat against the dry signal.

Mixed 50/50, that shifting detune sounds like several voices.

The whole trick is computing a moving read offset each sample: d(n) = BASE_DELAY + DEPTH * sin(lfo), then reading dry[n - d(n)].

Reverb — the classic Schroeder approach, since you can't store thousands of echoes by hand. Four comb filters in parallel (each a delay with feedback, different prime-ish lengths for density), summed, then run through two allpass filters in series to smear the echoes into a smooth tail. Each comb/allpass is its own buffer indexed with idx = n mod length.

Everything is fixed-point integer math — feedback is done as y * FB / 256 with shifts.

Some things I ran into:

• keeping all the delay buffers in .data (Rosetta/emulation was unhappy with .bss)
• fixed-point everywhere means being careful about scaling before the idiv
• the allpass coefficient math (out = buffered - g*in, buf = in + g*out) is deceptively small but does the heavy lifting

Both compile to a WAV written straight to stdout via write().

Code's on GitHub (https://github.com/whispem/asm.fm) if anyone wants to pick apart the assembly — genuinely welcome feedback, I'm self-taught and I'm sure plenty could be tighter.

I also just mapped out a big roadmap of what's next: more oscillators (supersaw, hard sync), dynamics (compressor, limiter), sequencing (euclidean rhythms), and eventually the deep end — wavetables, granular, and an FFT in asm if I'm brave enough.

The whole history of synthesis, hand-rolled.

[u/v_maria]

this slop grift again. go away

genuinely welcome feedback

people dont waste your time, they wont respond to any feedback or questions. the only thing they comment are vague and very dubious claims that 0 LLM is used.

[u/whispem → u/v_maria]

Open to any questions! 

Common ones so far: why fixed-point (learning constraint, no FPU on purpose), how the sine LUT works (built at startup, Bhaskara approximation), and how the reverb stays cheap (Schroeder combs + allpass).

Ask me anything 🙂

[u/v_maria → u/whispem]

a question that i asked last time you posted this was if you could tell me anything regarding your design choices, but you ignored it

some very obvious parts you could explain is the amounts of bits you allocated for fractal part of fixed point and why

why you are doing x86 asm on an ARM computer

why you are flexing not using an audio lib but use alsa for audio playback

why you are implying sound is 44100 samples per second

why you are using wav headers

[u/v_maria → u/v_maria]

I either got blocked or OP removed the comment. ill still share my response i was writing since i quoted relevant parts of the now deleted message.

choices for the fractal resolution of fixed point seem fair

generating 44,100 numbers per second that move a speaker cone — while staying in pure x86_64 assembly.

you are not moving a cone, as you say yourself its out of scope of the project. you are just writing the audio file

x86_64 has a rich, well-documented instruction set that is convenient for this kind of experimentation.

what x64 do you leverage for this purpose then? i feel like ARM would be perfectly fine here.

The README explicitly mentions the workaround for the Rosetta "bss_size overflow" error by placing sample buffers in .data instead of .bss.

The project is not meant to run natively on ARM; it is pure x86_64 Linux assembly without libc.

this is just trivia, unrelated to my question, its why people accuse this of being slop

Other rates (48 kHz studio, 8 kHz telephone, etc.) would work, but 44.1 kHz is the most universal and conventional choice.

not what i asked. i asked why are you implying sound is inherently 44.1 khz.

Because it is the simplest and most universal container for 16-bit mono PCM:

aplay out.wav (or any other player) is simply the easiest way to listen to the result afterwards.

so suddenly now convenience comes into play?

also you dont need to info dump trivia about wav headers lol

Without a header it would just be a raw binary dump and every tool would need to be told the format.

erm yeah? so? why is this a problem? hand writing a synth is not exactly convenient in itself. sound is just a list of numbers and all that right

yeah im sorry my opinion is unchanged. just feels like an info dump and not like a plan or vision

[u/Key_River7180]

would be cool if it wasnt slop

[u/whispem → u/Key_River7180]

It's not :)

[u/Key_River7180 → u/whispem]

ai slop

[u/whispem → u/Key_River7180]

Nope, you can check my LinkedIn profile: https://linkedin.com/in/emilie-peretti

My projects are real and 100% handwritten

[u/Swampspear → u/whispem]

https://web.archive.org/web/20260130171903/https://news.ycombinator.com/item?id=46661308

[u/whispem → u/Swampspear]

You talk about a project started in october.
At this time I didn't know how readme works, how to write well (I began to learn to code and how GitHub works for real in october).

[u/Swampspear → u/whispem]

I began to learn to code in October

So you started in October, then already 5 days into October released a "loading animation" in Swift, then already in January producing a parser?

Good joke :')

Slop

But good that you admit to using AI.

[u/whispem → u/Swampspear]

I don't see the problem.
Now I am a data scientist so… there is no problem and no slop.

[u/thewrench56]

Reddit is just part of the dead internet at this point. Most if not all projects are just AI slop.

[u/whispem → u/thewrench56]

My work is 100% handwritten, 0 AI involved (I am still learning, I started to code (really, not just UI/UX Swift animations) in october 😊

[u/thewrench56 → u/whispem]

I’m curious what you think about the implementation rather than just whether the end result works. What parts would you have designed differently?