What storage medium do "off the shelf" guitar looping pedals use?

[Kalcifer]

I'm looking into making my own guitar looping pedal; however, I'm slightly stumped (but mostly just curious) on what storage medium to use to store the audio that's being recorded.

Random DIY projects that I have seen online use an SD card to store the audio, but for some reason I have the feeling that a professional product like a looping pedal wouldn't use an SD card as a storage medium. I should note, however, that I am not against using an SD card, I'm just curious what is actually done in the industry. I would guess that they use a FLASH IC or something of the like, but I haven't found anything with any substantial capacity as of yet.

My other concern is with the endurance of the SD card, but I wouldn't imagine that you could run into the problem of the storage medium failing since it would take ages to perform millions of write cycles when it's just a looping pedal.

[james_s]

I don't know what the pedals use, but I've worked on samplers that use SRAM or DRAM for storage. If I were trying to design a looping pedal I'd look at SRAM since it's easy to work with and you probably don't need a huge capacity.

[Kalcifer]

I don't know what the pedals use, but I've worked on samplers that use SRAM or DRAM for storage. If I were trying to design a looping pedal I'd look at SRAM since it's easy to work with and you probably don't need a huge capacity.

With a 10bit ADC, and a sampling rate of 44.1kHz, you' be looking at 441kbps of data flowing to the storage device. For only 1 minute of audio that's ~26.5Mb of data. With those kinds of numbers I'd say that 1GB of storage would be a safe amount. Now with SRAM, I don't think numbers like 1GB even exist. There's gotta be a way to reduce the size of the recording though because 26.5Mb seems ridiculous to me.

[james_s]

1GB? For a guitar pedal? How long of a loop are you wanting to have? How many bits do you really need? I'd have thought a second or two at most. If you want to save a bunch of samples then SD would make sense but the actual active sample would almost have to be in RAM of some sort.

Obviously compression is an option, mp3 and other compression codecs have been around for a long time and there are hardware solutions to implement them with less powerful micros.

[Kalcifer]

1GB? For a guitar pedal? How long of a loop are you wanting to have? How many bits do you really need? I'd have thought a second or two at most. If you want to save a bunch of samples then SD would make sense but the actual active sample would almost have to be in RAM of some sort.

Obviously compression is an option, mp3 and other compression codecs have been around for a long time and there are hardware solutions to implement them with less powerful micros.

Well if you have say 6 loops each only 10 seconds long, that's a minute of uncompressed data. At the very least I would want 100Mb I'd say, and again that gets pricey or very difficult to find.
A loop could be a second, or it could be 10 seconds or 30 seconds or more. It just depends on what you're doing. 1 or two seconds for a loop wouldn't be very useful.
And you could transfer it in blocks. Record a chunk of audio into RAM, and then write it all to the storage device while you're recording the next chunk.

As for compression, can you use it on the fly? I feel like it would use up for too much resources to be used while recording and playing in real time.

[jbb]

Err, I’m not sure those numbers are right.  Assuming 16b samples * 44.1kSamples/s I get about 5.2MB/ min.

SRAM would be a bit expensive in this size but doable. DRAM would certainly be cheaper but you’d need to worry about refresh cycles and how long you could keep buying the chosen part.

For compression, I think latency could become an issue before you really ran out of processing power. No doubt it’s much worse if doing several loops simultaneously. I understand that timing problems in audio systems are pretty obvious and unpleasant.

[Siwastaja]

Choose SRAM if your samples are short enough so you don't need to rob a bank to buy the SRAM chips. The limit is somewhere around 1-4 megabytes, or a few seconds of audio, maybe 1 minute tops.

Else, use SDRAM. Use a microcontroller or similar that handles SDRAM access and refresh. Most "higher-end" $5 ARM MCUs do have a memory controller supporting SDRAM.

Only use flash if you need to store the samples between power cycles.

I would do it with some STM32 device, doesn't need to be the flagship model. If the samples are short (a few seconds max) or you can compromise on sound quality, even the internal SRAM (up to about 1megabyte in the flagship models, or maybe 256K in the cheaper options) could do the trick!

[dzseki]

Err, I’m not sure those numbers are right.  Assuming 16b samples * 44.1kSamples/s I get about 5.2MB/ min.

Also, with a guitar one would hardly notice if you lower the sampling rate to say 32kHz, and at that point you only need 3.8MB / min.

[MasterBuilder]

This sounds like its getting way over complicated. Why go digital.

Look up bucket brigade delay.

Old guitar pedals used parts such as MN3208.

It's datasheet says 102mS delay time.

There is some good parts here for both analog and digital delays.
https://electricdruid.net/?s=delay&x=0&y=0

[coppice]

This sounds like its getting way over complicated. Why go digital.

Look up bucket bridge delay.

Old guitar pedals used parts such as MN3208.

It's datasheet says 102mS delay time.

There is some good parts here for both analog and digital delays.
https://electricdruid.net/?s=delay&x=0&y=0

The OP wants a looping solution, not a delay. They need persistent storage (at least persistent until the power is switched off).

[Siwastaja]

This sounds like its getting way over complicated. Why go digital.

Because any analog solution would be massively expensive and complex.

There is a reason this complete product segment has born after digital audio processing emerged.

You could do that with tape, yes, but this would be a mechanical challenge, mainly because you would want to adjust the loop length, possibly have multiple loops and be able to dispatch them whenever you want.

Look up bucket bridge delay.

Completely irrelevant.

[MasterBuilder]

This sounds like its getting way over complicated. Why go digital.

Look up bucket bridge delay.

Old guitar pedals used parts such as MN3208.

It's datasheet says 102mS delay time.

There is some good parts here for both analog and digital delays.
https://electricdruid.net/?s=delay&x=0&y=0

The OP wants a looping solution, not a delay. They need persistent storage (at least persistent until the power is switched off).

Fair enough, I read looping station and immediately thought Delay.

[TheUnnamedNewbie]

Even for just delay, bucket brigade chips are an expensive and complex solution.

The delay pedals that still use them are generally way more expensive, because they require NOS chips. I seem to recall someone doing a re-tape of one of the old bucket-brigade delays, but don't know if that ever actually happened.

I think a lot of these kinds of pedals will be using low sample rate (no need to sample up to high frequencies, as others have said - 20-30 kSa/s is probably sufficient). Probably just need 8 or 10 bits to do it too. I suspect there might be some DSP SoCs or similar that contain sufficiently DRAM to pull it off in a single-chip solution. And you don't need to be able to store like 5 loops at the same time, I think the pedal will just store the additional loop on top of the existing ones.

[amyk]

I suspect they may use realtime compression/decompression, could be a proprietary or standard codec, but only one way to find out - buy one and RE it.

[mikerj]

Even for just delay, bucket brigade chips are an expensive and complex solution.

Also very noisy.

[Marco]

Googling, the RC-505 uses a simple sdcard ... so I assume the Boss looper pedal does too and probably all of them.

Fast enough, low latency enough, dirt cheap and massive capacity.

[coppice]

I suspect they may use realtime compression/decompression, could be a proprietary or standard codec, but only one way to find out - buy one and RE it.

Why would you introduce such complexity for small lengths of recording when DRAM is so cheap?

[Buriedcode]

I don't understand why people are talking about compression.  The cost of SDRAM and FPGA boards is so low these days it just isn't worth the hassle, and on top of that you have decoding latency (on playback) to deal with.

Yes, SRAM is much easier to worth with, but there are plenty of free SDRAM controllers available for common FPGAs, as well as I2S blocks, and whilst its a bit of a steep learning curve, it provides a lot of flexibility.

[langwadt]

I suspect they may use realtime compression/decompression, could be a proprietary or standard codec, but only one way to find out - buy one and RE it.

Why would you introduce such complexity for small lengths of recording when DRAM is so cheap?

cheap and readily available nonvolatile storage

[SiliconWizard]

Many recent "looping" pedals theses days use 48kHz, 24-bit sampling. 16-bit would be a minimum to get decent sound quality. 10- or 12-bit? Maybe just for a toy experiment, or if you're after weird lo-fi sound effects.

A common, yet already oldish reference is the venerable Boss RC-1. It's spec'ed at 16-bit, 44.1kHz, and 12 min max record time. Uncompressed audio would require thus over 60MBytes. I don't know whether they use compression on this pedal or not; if not, a 64MBytes SDRAM chip would be adequate. Cheap stuff these days.

For the more recent 24-bit pedals, some use some kind of compression, either lossless or lossy to some extent, to extend record time. I suspect the 64MBytes RAM figure is a minimum on a recent pedal - probably on the cheapest ones. The higher-end ones may contain as much as 1GBytes or so. As I said, using a small DSP or MPU with an embedded SDRAM/DDR controller would make a pretty low-cost solution for this these days. It's become dirt cheap. Just look at the price of a RPi 4 with 1GBytes of DDR RAM.

Flash would be an option only if you want your looper to have non-volatile storage. It would require fast enough Flash (as far as write times and max access times are concerned), and would be much more expensive than a RAM-based solution. Now if some DIYers go for this solution, that's because it may look simpler to use a small MCU and an SDCARD for the job.

And yes, forget about SRAM. The largest, yet still relatively affordable SRAM chips these days are 4MBytes or so, and they cost like 4 times or more the cost of a 1GB DDR RAM chip. With 4MBytes, at 16-bit, 44.1kHz, uncompressed, you'd get approx. 12s record time. Forget about fancy compression algorithms unless you're ready to use a powerful DSP. MP3 *encoding* is processing intensive.

At this point, you could implement a looper with an MCU supporting SDRAM - maybe something in the Cortex M7 range, an audio codec and an SDRAM chip. Some MCU eval boards give you this, so that could be where to start IMHO.

You could look at using some kind of SBC instead, like the RPi. But the RPi doesn't have any decent audio codec on board AFAIK, so you'd need an external one. I guess an USB sound card should work, as it's likely to be supported by the common available Linux distributions. But then you'll need to figure out how to program audio on Linux (either using ALSA, JACK, etc...), and handle latency properly, as you'll get a pretty high latency with USB sound cards on Linux (I've managed to get low latency with these but only reliably with real-time patched Linux kernels, and there is none available for RPis that I know of.)

Note that a looper is not a sound effect, so latency itself is not an issue if you handle it properly - you just need to account for the latency when playing and recording audio, but that can be handled programmatically, as a looper only need to play back some already recorded audio, and record incoming audio at the same time, but doesn't need to process incoming audio in real time, so latency can always be compensated as long as it's known and fixed.

[SiliconWizard]

I suspect they may use realtime compression/decompression, could be a proprietary or standard codec, but only one way to find out - buy one and RE it.

Why would you introduce such complexity for small lengths of recording when DRAM is so cheap?

cheap and readily available nonvolatile storage

Whereas non-volatile (such as SD cards) would be an overall more expensive (and less reliable) solution in big volumes, I can see that it could be cheaper for amateur projects.

You'd still need to use decent and fast SD cards - so that write and access times are short enough, repeatable and BOUNDED. Certainly not all SDCARDs qualify here, and not the cheapest ones.
You'll also probably need to devise your own simplified filesystem, as existing libraries are likely to be either buggy, or not adapted performance-wise, etc. Not that simple to get something reliable.

[Bassman59]

I'm looking into making my own guitar looping pedal; however, I'm slightly stumped (but mostly just curious) on what storage medium to use to store the audio that's being recorded.

Random DIY projects that I have seen online use an SD card to store the audio, but for some reason I have the feeling that a professional product like a looping pedal wouldn't use an SD card as a storage medium. I should note, however, that I am not against using an SD card, I'm just curious what is actually done in the industry. I would guess that they use a FLASH IC or something of the like, but I haven't found anything with any substantial capacity as of yet.

My other concern is with the endurance of the SD card, but I wouldn't imagine that you could run into the problem of the storage medium failing since it would take ages to perform millions of write cycles when it's just a looping pedal.

With the caveat that I haven't taken any of these things apart --

Perhaps a clever way to work around the flash wear issue is to capture the loops in SDRAM and only on command write the loop to flash. For recall, the flash gets read back into the SDRAM.

You might need to be clever and have two delay banks, one for "live" and one for the recalled loop.

If you guys wanna have fun, look at how DeltaLab implemented delay in the famous Effectron units. They use a single-bit converter -- the delta/sigma modulator without the decimator -- and just run the single-bit result into a bank of old-school EDO DRAMs, as if it was just one long one-bit-wide shift register. Delay time range is set by choosing from which RAM bank to pull the output bit, and the delay time is set by changing the clock which drives the sampling and the memory-access state machine (all of which is implemented in 4000-series logic). Delay at the long end of the range has a lower sample rate than that of the short end.

Of course now delay is set by maintaining a difference between the read address and the write address and the buffer is just a big FIFO. It's a homework problem for kids learning FPGAs.

[Siwastaja]

Difference in complexity between SRAM and standard SDRAM is quite small, SRAM only makes sense when you need so little of it that the price difference is negligible. This would be < 1Mbytes.

As said, most things you would use to interface the RAM, such as cheap small microcontrollers, have SDRAM controllers built-in today. (Cheap small microcontroller not being an 8-bit AVR, but some Cortex M4 aimed for simple/small signal processing tasks, like audio.)

[langwadt]

I suspect they may use realtime compression/decompression, could be a proprietary or standard codec, but only one way to find out - buy one and RE it.

Why would you introduce such complexity for small lengths of recording when DRAM is so cheap?

cheap and readily available nonvolatile storage

Whereas non-volatile (such as SD cards) would be an overall more expensive (and less reliable) solution in big volumes, I can see that it could be cheaper for amateur projects.

You'd still need to use decent and fast SD cards - so that write and access times are short enough, repeatable and BOUNDED. Certainly not all SDCARDs qualify here, and not the cheapest ones.
You'll also probably need to devise your own simplified filesystem, as existing libraries are likely to be either buggy, or not adapted performance-wise, etc. Not that simple to get something reliable.

cd quality mono is 700kb/sec how slow can an SDcard be? and you could have a decent buffer in most mcus 

advantage of nonvolatile storage is that you can have stuff prerecorded

[jbb]

I did think of a wrinkle with DRAM: memory refresh. Normally it’s not a big deal, but for audio work you’d need to consider the inpact. It might be necessary to buffer some milliseconds of audio in microcontroller SRAM to avoid glitches.

For SD cards another issue would be flash wear out. Probably not a big deal. Audio bufffer in microcontroller SRAM would definitely be required.

I wonder whether DRAM or SD card would be lower power?