Audio Digital Delay with DRAM and Arduino

Aka “ADDDA” or “AuDiDeDrAr” or “aww dee dee drawer” or “A3DA”

I’ve had this idea bouncing around in my head that you could use 1-bit wide DRAM as a delay line if you simply counted up through it’s addresses, reading and writing as you go. 1-bit wide DRAM like the M3764 have separate pins for Data In and Data Out which makes the read-and-write method easier.

The light bulb moment was coming across an old post on where one commenter provides a short snippet of code to do a Delta-Sigma analog to digital converter using the Arduino’s analog comparator pins. I had planned to do this purely in software by using the normal ADC pins and then calculating the Delta myself. But the built-in comparator makes this dead simple!

You can just see the OKI DRAM chip under all those wires.

So armed with an easy way to generate a one bit wide data stream from an analog signal, I went about hooking up the DRAM chip to a clone Arduino Pro Mini. There are quite a few “test a DRAM chip with an Arduino” projects out there, but the datasheet for the OKI chip has good timing diagrams that give the jist of what you need to do. DRAM has a shared set of address pins for the row and column you’re selecting, which you can think of as two halves of the full address. To get those halves in, you put the row on the address lines and strobe the /RAS pin. Then you put the column on the address lines and strobe the /CAS pin. Then your data is on the Data Out pin. Writing involves putting the data you want to write on the Data In pin and strobing the /WE pin after you strobe the /CAS pin. That’s really all there is to it. You’ll see that there are some short cuts you can take to speed up access, like only setting the row once for any number of columns you’d like to access. You can also read the Data Out pin right before writing new Data In. I do both of these in my implementation to increase the sample rate.

To start out, I did everything very simply, using the built-in Arduino functions to make it easy to read and understand. I then measured the performance of the main loop by looking at the Sigma-Delta signal’s minimum change period. This gave me a base line, and then I systematically went through the code swapping out the built-in functions for faster implementations one by one, measuring any increase in performance. If a change didn’t lead to any improvement, I wouldn’t commit it. Instead I’d commit a comment that I’d tried it. In retrospect, it’d have been better to use git revert so I had a better history of what I specifically tried.

Here I am demonstrating the delay at maximum delay length. I add some feedback to make it act like a reverb towards the end.

Doing this I was able to improve the performance of the DRAM access by a factor of about 16. The original version took 8 seconds to cycle through the entire memory and the final version took about 500ms. My commits show the improvements, although I realized later I was measuring the wrong signal! It was at least indicative of the improvements. All of the timing in this project has a lot of jitter due to the many different possible code paths with no attempt to balance them out.

In the end, the DRAM /WE pin is the best measure of how often you’re writing to the DRAM. It is at about 139 khz. I measured the actual audio delay produced by the system using my oscilloscope and it is about 480 ms at it’s longest. Those two numbers agree:

1 second      | 64*1024 samples           seconds
--------------|----------------- = 0.471 ---------
139 k samples | 1 buffer                  buffer

I’m new to working directly with delta-sigma converters, and after reading a few pages about it this morning, I’m not sure what I’ve built is exactly a delta-sigma converter at all!

My current understanding is that 139 khz sampling rate (F) means a Nyquist frequency (F/2) of 69.5 khz regardless of the type of converter used. I found a paper by Aziz, Sorensen, and Van der Spiegel from 1996 describing how delta-sigma converters work, and it gives some equations.

Letting the oversampling ratio, f_s / (2 * f_b) = 2^r …

[Therefore] every doubling of the oversampling ratio i.e., for every increment in r, the SNR improves by 9 dB, or equivalently, the resolution improves by 1.5 bits.

Aziz, P., Sorensen, H., & Vn Der Spiegel, J. (1996). An overview of sigma-delta converters. IEEE Signal Processing Magazine, 13(1), 61–84.
f_s -> sampling frequency
f_b -> signal bandwidth
r -> oversampling

f_s / ( 2 * f_b) = 2^r

f_s / 2^r = 2 * f_b
f_s / (2 * 2^r) = f_b
f_s / 2^(r+1) = f_b

139e3 / 2^(r+1) = f_b
r = 0, 139e3 /  2 = 69.5 khz,  Nyquist sampling
r = 1, 139e3 /  4 = 34.7 khz, +1.5 bits
r = 2, 139e3 /  8 = 17.3 khz, +3.0 bits
r = 3, 139e3 / 16 =  8.6 khz, +4.5 bits
r = 4, 139e3 / 32 =  4.3 khz, +6.0 bits
r = 5, 139e3 / 64 =  2.2 khz, +7.5 bits

Those numbers would suggest a fairly lofi device. And certainly what I have running on my desktop is by no means producing quality audio. But it also doesn’t sound that bad? I’m losing a bit in my calculations because I should be counting the “single bit” of the comparator. If we take that bit and then work it backwards…

f_s / (2 * f_b) = 2^r
total_bits = 1.5 * r + 1
8 bits = 1.5 * r + 1
r = 7 / 1.5 = 4.667
139e3 / 2^4.667 = 139e3 / 25.398 = 5.47 khz

So the system is operating at 8 bits up to a bandwidth of 5.47 khz. That sounds about right. What happens if I add more features and reduce the sampling rate to 100 khz?

100e3 / 25.398 = 3.94 khz

What happens if I find some optimizations and increase the sampling rate to 200 khz?

200e3 / 25.398 = 7.87 khz

Someone check my math.

I vary the delay length from max to about minimum, then set it somewhere in the middle. The reverb feedback is still applied because that makes it easier to hear the changes in delay length.

National Semiconductor 4510 Mathematician

I have a small collection of vintage calculators that I stumbled into collecting. I found one at a garage sale, and then one was given to me, then I found a neat one on eBay for a good price… Before I knew it, I was a calculator collector.

I actually use most of them despite having a great calculator app on my phone because I prefer their physical interfaces. I have one on each desk and one in my bag so I don’t have to go searching. I don’t have that many bags and desks though so there is also a small stash in a drawer.

The brown and tan color scheme is very 70s. I think they’d have used wood grain print adhesive vinyl if they could have.

My latest addition is a National Semiconductor 4510 Mathematician from the mid 70s. It has an 8 digit red LED display and runs on a 9 volt battery. There is a jack on the top edge for connecting a wall supply if you’ve got a lot of math to do.

It is in great condition and the seller even included a brand new battery. It is one of the lesser RPN calculators of the 70s and not expensive. Like most of my collection, is not valuable but it is uncommon.

This model isn’t programmable although they made a version that was called the Mathematician PR. Those are a little bit more rare but their programmability is so limited that I didn’t want to deal with finding a nice one at a price I wanted to pay. I also know that personally I do not use the programmability of much nicer calculators I already have so it wasn’t something I’d use anyhow.

What makes this model stand out is its RPN entry method. If you’re not familiar with RPN, there are some great introductions online. I tried to explain it recently and was told that it sounded insane. You get used to it! It starts to make sense… eventually.

This model’s main downside is that it doesn’t do scientific notation, so the range is limited. Some of the math I do most often is around calculating values for circuit components. They are specified in orders of one thousand units. So for example, resistors are commonly available in units of ohms, kilo ohms, and mega ohms. This means you do a lot of math with numbers involving 10^3 and 10^6. Capacitors are similar but much smaller units. You often deal with pico farads – that’s 10^-12. So I’ll have to keep track of the exponents myself when doing those kinds of calculations.

The NatSemi Mathematician is delightfully slow for some operations. For example computing a logarithm of a number is slow enough that the calculator displays an animation of sorts to show that it is “thinking”.

Computing the natural logarithm of pi takes long enough for you to wonder when you’d ever want to know such a value.

I don’t know how much I’ll use this addition to my collection. If I leave it where I can see it, I’ll use it occasionally if only as a muse for an earlier time in computing history.

From the notebook: Tape Transports

Todays notebook sketch is some ideas for building a tape “transport” – the mechanical bits that move the tape around in the right way and at the right tension.

Three transport configurations and my current thinking on a capstan.

I have a weird fascination with magnetic storage media and tape in particular. It was a key technology in computing for decades and it has more or less completely disappeared.

All that time in home, commercial, and industrial use has left lots of bits and bobs to experiment with, although it is very very quickly disappearing.

Other than the playback and record heads and the media itself, the devices can be recreated from scratch. (And let me get back to you on making heads and media…)

Prototype Game of Life Synth Module

Conway’s Game of Life (CGoL)has always fascinated me. It is probably the most well known of all cellular automata and also probably the most intuitive. Yet even simple patterns can turn into complex sequences of shapes, patterns, and noise.

Years ago, when learning about the HTML5 WebAudio API, I came across a fun little demo called Blips of Life by Mike M. Fleming. Use your mouse to draw some dots and then click the triangle Play icon in the bottom left. Great, right? I’ll let you play around with that for a while. Leave it running while you read, perhaps?

This is in 1U Eurorack format.

When it came time to start prototyping new modules for my modular synth, I was inspired to recreate Mike’s work in hardware. I didn’t have exactly the parts to fully recreate his Blips of Life, but using the parts I had in hand I made a prototype.

My version has only an 8×8 grid and only has a major pentatonic scale. The small grid means that there are fewer possible patterns, although not so few it is monotonous. The major pentatonic scale is fine. The largest problem with the prototype is that I used CircuitPython to write it, which has no interrupt support. I love Adafruit – they’re a great company and they design terrific boards. But removing interrupts from their fork of MicroPython has cut several projects short.

The prototype works pretty well and exposed a new design challenge: how do you deal with “games” that end in loops? They’re a subset of steady state patterns in CGoL – a pattern can go “extinct”, “steady”, or loop in a finite sequence. The first case is easy to detect and deal with. If all the cells of the grid are off, repopulate the board. You can detect a steady state by comparing the next board with the previous. If they’re identical, repopulate.

But loops can be any arbitrary length, and can step through rather complex patterns. The only way I know to detect them is to have a list of boards known to be part of or lead to a loop. I’ve got some ideas how to do that either via live loop detection or with a precomputed list of boards. As yet, the performance limitations of CircuitPython really prevent tackling it. I’ll need to reimplement the code in C++ using Arduino. Hats off to Adafruit for supporting both Python and Arduino on their boards.

Ray Diagram: Now with Measurements

I’ve continued to work on the optical ray diagram tool prototype. I added a way to measure the effective focal length (EFL) of the lens system. It isn’t automatic, but by adjusting the parameters you can align an intersection at the optical axis and read off the EFL. Obviously this should be a one button click sort of thing, but it is kind of interesting to see how the various parameters affect EFL.

The UI is still very rough and the code is even worse. But I’ve actually been using it!

My main area of interest before going to automation is identifying and coding all the various measurements that you want of a lens. To identify these, I’ve been reading the excellent Applied Optics and Optical Engineering edited by Rudolf Kingslake. Chapter 3, Photographic Objectives, traces the history of the development of lenses from the development of photography to the book’s publication in the 1960s. I would recommend either starting there if you have some familiarity with optics already. If you’re new to optical design, start with Chapter 1, Lens Design. I got my copy from the public library but you can also borrow a digital copy from the Open Library on

I realized I should change the example lens configuration in my prototype to a Cooke Triplet after reading Chapter 3. As the book points out, a lot of modern lens designs can be traced to or analyzed as variants of the Cooke Triplet. It is also unique in being only three elements but having performance that is good enough to warrant doing the work of designing one yourself. It is also non-trivial enough that you want an automated tool to design one, so it makes a good example.

The next step will be to add proper measurements of the various aberrations and distortions. I’ll be using worked examples from Applied Optics and Optical Engineering to check the calculations of my tool. The current default configuration is from this student project in MIT OpenCourseWare by Choi, Cooper, Ong, and Smith. I think I’ve already found a discrepancy in my results so my work is cut out for me.

Another source for a worked example is Dennis Taylor’s original patent from 1985. While Taylor invented it, the design is named after the company he was working for at the time – T. Cooke & Sons of York.

Early 90s Camera Teardown

Over the weekend I tore down an old RCA Super8 camcorder. It came with a power supply but it had already been damaged in the past. The viewfinder showed text over static and the tape mechanism just made a horrible squealing sound.

The good stuff – varifocal zoom mechanism and a teeny tiny CRT

I was interested in perhaps using the imager somehow but it seems to be damaged and not worth chasing down. The autofocus and motorized zoom work great though, so I’m hoping to use those paired with a Raspberry Pi camera. Even if I don’t ever use the motorized features, they’re manually adjustable so that will make for a nice setup.

Most of the parts that I didn’t use.

The other electronic parts of the camera are a bit too specific to be useful. I’m hoping to reuse some of the mechanics of the tape transport in my 1/4” audio tape experiments. 8mm is larger than 1/4” (6.35mm) so I think some of the various guides and rubber pinch rollers will come in handy.

Before I send all the extra parts to the electronics recycler, I need to plug it all back together and document the connector pin outs.

Prototype Eurorack Frequency Modulation Synth Module

I have a few prototype Eurorack modular synth modules in the works. I tend to get them working well enough to be musically interesting and then move to work on the next prototype. It’s not because I don’t plan on finishing them – it’s more that all the biggest questions are answered and I want to move on to the next prototype and answer whatever questions it is trying to answer.

The prototype laid out

This module is based around the Yamaha YM3812 chip, also known as the OPL2. You might know it as part of the capabilities of the AdLib and original Sound Blaster sound cards. Think of the classic sound of the Doom soundtrack – that’s coming out of a YM3812 (emulated or otherwise).

But you can do a lot more than what you hear on the Doom soundtrack – even though I’d be fine if that was the limit of it’s sonic capabilities. FM synthesis is “weird” in the way it can produce wild sounds that are very hard to produce with subtractive synthesis. As an added bonus, the YM3812 has multiple symmetrical channels and is this capable of impressive polyphony. One module isn’t just one voice – it’s 6. Also it has a drum synth mode… It makes sense that it is so capable if you think about all the great PC game soundtracks made with one, but it isn’t what you’d expect to be coming out of a single modular synth module.

The Problem

In the modular world, you tend to break apart and de-integrate as much of the synth chain as possible. This is so you have the freedom to reconfigure the synthesis signal path in wild and fun ways. So a module with not only a complete voice but six complete voices is swimming against the current in how you typically design these things.

How the front and back circuit boards attach together in the prototype

One outcome of such a non-modular module is the matter of the number of possible parameters available. Typically a module might have 1-4 inputs and 1-2 outputs. That’s a gross simplification but gives you an idea of the majority of signal complexity involved. A single channel of a YM3182 has about 16. And then you have 6-8 copies of those – each voice can be configured more or less independently. So we’re talking hundreds of possible inputs.

It has one output.

So on the face of it, this is a bad match. And therein lies the hypothesis of this design. “How can you adapt a YM3812 to the modular synth design norms?” How do you make it understandable to someone thinking in terms of fairly straightforward signal chains? How do you present the configuration of a YM3812 so it matches the mental model of someone used to something like the Behringer Neutron?

A Lone Voice

I can’t do anything about the output space. There is literally only a single pin for the output and there isn’t any access to the individual voices. So right off, I decided that this prototype would be a single voice. That might seem wasteful, but I can use the other voices to “mirror” the main voice to fill it out by slightly detuning them or by playing notes related by harmonics such as octaves or triad chords.

That also reduces the input space. We’re down from hundreds to a dozen or so inputs if we’re only treating this as a single voice. Some existing designs stop there, but I wanted to go further.

Time Variations

There are broadly two types of inputs to a voice: time varying and time invariant. The time varying inputs configure, for example, the way the amplitude of the sound changes over time. In a modular synth, input like this are controlled by other modules. So I decided to discard all time-varying parameters. Parameters like the amplitude of the voice would be modified externally using voltage controlled amplifiers (VCA) just like you would do with a standard modular signal path.

This reduces the input space by half. We’re looking at about 6 inputs. That isn’t bad – there are definitely synth modules with 6 inputs. But I wanted to go further.

Digital Zippers

The YM3812 is a digital chip. All of the OPL series of synth chips are. This is what made them such a great product for Yamaha. It was easy to make a digital chip out of silicon so they could produce the entire sound path out of a handful of parts that would take thousands of separate analog components to replicate. And because it’s digital, it’s very easy to use in a PC sound card. The CPU just sets the input registers of the chip and away you go.

In a modular synth, all of the patch paths are analog: continuous time varying signals between about -10 to 10 volts. To adapt these kind of signals to the YM3812, I would need to digitize them using an analog to digital converter (ADC). But there’s a problem here too – what sort of digital resolution should I use? If I use too low a resolution, the continuous varying signals end up being converted to broad, stair step patterns. It means your smooth subtle varying input gets turned in to sudden chunky sound changes. People call this effect “zippering” because it can cause a sound similar sound when a parameter moves through those discrete stair step values. That isn’t intrinsically bad in the world of analog synths, but you’d like to at least have the option to avoid it.

Some of the input parameters of the YM3812 have a very limited range of possible input values. As an example, the strength of the feedback from one internal voice generator to itself is controlled by just three bits. That’s only 8 possible values! That does not map well to a 20v swing input.

So I took all the parameters that did not have enough bits of configuration available to be used with an analog input off the table. I would still have them accessible, but through manual switches and control knobs. They’d be more for setting the broad mode of the voice, not for use inside the time of a single note playing. That removes a handful more inputs from consideration. In fact, you’re down to only four. That is a completely respectable number of inputs for a synth module. But I wanted to go further.

A page from my notebook where I went through all the possible inputs to a voice

Getting Rational

One of the interesting things about FM synthesis is that a lot of the timbre results from the mathematical ratio between the different frequencies of the oscillators involved. In the YM3812, each oscillator has 12 possible frequency multipliers to aid in defining these ratios. So while there are only 12 values for a given oscillator, there are 144 combinations between the two oscillators of each voice. Twelve steps isn’t enough for an analog input but 144 is fine. So my final reduction was to combine the two ratio inputs into a single input.

I wanted to think about the ratios as actual ratios so I wrote this out by hand. This is the type of thing I think about to fall asleep sometimes.

And that leaves us with just three inputs: one that controls the frequency of the voice, one that controls the amount of mixing between the two internal oscillators, and one that controls the ratio between the oscillators. To put it another way: one controls the pitch and the other two control the timbre. That sounds like a perfectly understandable module. It is still more integrated than you would see in a traditional module where the timbre modification would occur in a separate module (or sets of modules), but it is much closer.

And there you have how I arrived at the final design of the prototype. All other design considerations stem from the decision of which inputs to use: the physical layout, the specifics of how signals map to sound changes, the size of the module, etc.

There are a lot of details I’m glossing over here, and I’ll talk about them more in future articles.

More ray diagrams

I’ve dug into this ray diagram sketch on CodePen because it’s pretty satisfying to twiddle the properties of the simulation and see how things change. I’ve added some sliders, but beware of the code – it isn’t pretty. I’d say it’s about reached the point of unmaintainability.

Screenshot as of this post

The UI is a total wreck, but you can currently alter all the major parameters. There aren’t any measurements yet, which is probably the next most important feature. It’s fine and dandy to move these virtual lenses around and see how the rays refract, but without the proper measurements it’s not actually a useful tool. Also there isn’t a way to change the lens type or order, and once you can do that, you’ll really want to be able to save and load a given configuration.

And this hasn’t even gotten into the optimization part! That’s the whole purpose!

WIP: Ray diagram in Javascript

During lunch I whipped up a software sketch based on that notebook entry I posted earlier. I thought I’d start with actually drawing the shapes required for a ray diagram, and then make it more data-driven over time. I should be able to then make a clean seam in the code where the diagram is controlled either by a human or a robot – maybe both at once!

Screen shot of where the ray diagram software sketch is so far.

Also I obviously need to write the actual solver, but that’s “just” a bunch of geometry and shouldn’t be too hard. I think I’m okay to assume that each ray will hit each boundary in order. If a ray doesn’t hit it’s next boundary, it gets dropped from the list.

This is pretty software-oriented compared to what I’ve been working on lately, but it’s the easiest thing to write up and very recent work.