What storage medium do "off the shelf" guitar looping pedals use? - Page 1
Forum section: electronics / projects

author: Kalcifer
author_rank: Regular Contributor
timestamp: July 24, 2020, 04:15:20 am
content: 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.

author: james_s
author_rank: Super Contributor
timestamp: July 24, 2020, 04:27:54 am
content: 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.

author: Kalcifer
author_rank: Regular Contributor
timestamp: July 24, 2020, 05:01:36 am
content: Quote from: james_s on July 24, 2020, 04:27:54 amWith 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.

author: james_s
author_rank: Super Contributor
timestamp: July 24, 2020, 05:48:18 am
content: 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.

author: Kalcifer
author_rank: Regular Contributor
timestamp: July 24, 2020, 06:00:44 am
content: Quote from: james_s on July 24, 2020, 05:48:18 amWell 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.

author: jbb
author_rank: Super Contributor
timestamp: July 24, 2020, 09:40:54 am
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 24, 2020, 09:52:57 am
content: 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!

author: dzseki
author_rank: Frequent Contributor
timestamp: July 24, 2020, 09:59:56 am
content: Quote from: jbb on July 24, 2020, 09:40:54 amAlso, 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.

author: MasterBuilder
author_rank: Regular Contributor
timestamp: July 24, 2020, 10:31:05 am
content: 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

author: coppice
author_rank: Super Contributor
timestamp: July 24, 2020, 10:34:12 am
content: Quote from: MasterBuilder on July 24, 2020, 10:31:05 amThe OP wants a looping solution, not a delay. They need persistent storage (at least persistent until the power is switched off).

author: Siwastaja
author_rank: Super Contributor
timestamp: July 24, 2020, 10:48:00 am
content: Quote from: MasterBuilder on July 24, 2020, 10:31:05 amBecause 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.QuoteCompletely irrelevant.

author: MasterBuilder
author_rank: Regular Contributor
timestamp: July 24, 2020, 10:56:52 am
content: Quote from: coppice on July 24, 2020, 10:34:12 amFair enough, I read looping station and immediately thought Delay.

author: TheUnnamedNewbie
author_rank: Super Contributor
timestamp: July 24, 2020, 12:56:55 pm
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: July 24, 2020, 01:40:55 pm
content: 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.

author: mikerj
author_rank: Super Contributor
timestamp: July 24, 2020, 03:08:53 pm
content: Quote from: TheUnnamedNewbie on July 24, 2020, 12:56:55 pmAlso very noisy.

author: Marco
author_rank: Super Contributor
timestamp: July 24, 2020, 03:43:33 pm
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: July 24, 2020, 03:50:36 pm
content: Quote from: amyk on July 24, 2020, 01:40:55 pmWhy would you introduce such complexity for small lengths of recording when DRAM is so cheap?

author: Buriedcode
author_rank: Super Contributor
timestamp: July 24, 2020, 04:01:50 pm
content: 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.

author: langwadt
author_rank: Super Contributor
timestamp: July 24, 2020, 04:16:48 pm
content: Quote from: coppice on July 24, 2020, 03:50:36 pmcheap and readily available nonvolatile storage

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 24, 2020, 04:47:08 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 24, 2020, 04:56:57 pm
content: Quote from: langwadt on July 24, 2020, 04:16:48 pmWhereas 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.

author: Bassman59
author_rank: Super Contributor
timestamp: July 24, 2020, 05:18:01 pm
content: Quote from: Kalcifer on July 24, 2020, 04:15:20 amWith 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 24, 2020, 05:35:28 pm
content: 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.)

author: langwadt
author_rank: Super Contributor
timestamp: July 24, 2020, 05:36:00 pm
content: Quote from: SiliconWizard on July 24, 2020, 04:56:57 pmcd quality mono is 700kb/sec how slow can an SDcard be? and you could have a decent buffer in most mcusadvantage of nonvolatile storage is that you can have stuff prerecorded

author: jbb
author_rank: Super Contributor
timestamp: July 24, 2020, 09:35:51 pm
content: 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?

author: coppice
author_rank: Super Contributor
timestamp: July 24, 2020, 09:38:19 pm
content: Quote from: jbb on July 24, 2020, 09:35:51 pmRefresh cycle density is so low its not an issue. If you use an SD card, buffer in DRAM. SRAM is a rich man's plaything.

author: Bassman59
author_rank: Super Contributor
timestamp: July 25, 2020, 02:31:42 am
content: Quote from: jbb on July 24, 2020, 09:35:51 pmIf you set it up properly, all of the memory will be accessed during the course of storing and reading the samples, so you don't need to do the refresh.Also, even older SDR DRAM is faster than necessary for audio looping access. For memory writes, then, your samples get stored in a FIFO first before being burst written to the DRAM. So if there's a refresh cycle, you can hold off the burst write until the refresh cycle ends. Reads are similarly bursty, so you'll read a whole buffer's worth and there's dead time between those bursts during which you can refresh. DMA access to the SDRAM from/to an ARM's on-chip SRAM should hide all of that from you.Think about it -- at 48 kHz sampling you have to present new samples to the DAC every 20.8 us, and you read new samples from the ADC every 20.8 us. How many bytes can you write or read from your DRAM in that one sample time? Lots!

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 25, 2020, 03:23:14 pm
content: Regarding the buffering, keep in mind that a double-buffer scheme is a necessity in order not to generate audio glitches. Since a typical looper use will be playback + recording at the same time, that's at least 4 times a single audio buffer that's required here. If you use SDRAM for your main storage, only relatively small buffers will be necessary - typically a couple ms worth of audio should be more than enough. If you're using Flash/SD cards, you'll need much larger buffers - you may find that you don't have enough RAM on a given MCU to do this.Just a couple figures: at 16-bit, 44.1 kHz: 1 ms of audio => ~88 bytes. So any SDRAM-based solution can be implemented even on an MCU with pretty limited internal SRAM. If you're using an MCU that can directly stream data from SDRAM to an I2S peripheral, you may even not need any intermediate SRAM buffer.100 ms => 8820 bytes. Times 4 => 35280 bytes. Consider MCUs with at least 48 or 64 KBytes of SRAM. I think 100 ms of buffering would be a good starting point if you're using SD cards - of course using a good, class 10 card should get you lower max latencies so you may be able to use smaller buffers.Regarding SD cards, as I said before, even though they may look like a simple and cheap (at least for an amateur design) solution, you may encounter more problems than you think trying to use them. You'll need proper "drivers" and at least a minimal filesystem. Thing is, IME, most available and free ready-made libraries for that are crap one way or another: very lousy performance, bugs, sometimes hard to figure out... In the same vein, many free filesystem libraries you'll find will also have poor performance. Writing that all from scratch is of course possible, but is definitely not trivial. SO getting it right and robust may not be as easy as you think.Anyway IMHO, as I suggested earlier, I think starting with a small dev board with some Cortex M4 or M7 MCU, SDRAM and audio codec should be relatively straightforward. You could also consider an FPGA-based solution as some have suggested, but unless you're experienced with FPGAs, I wouldn't recommend it. Besides, a looper will required some UI to be useful, and implementing a decent UI is always much easier on a MCU IMO.As to what existing pedals typically use - I have never torn one down, but I'd be pretty sure most of them use some kind of MCU or DSP, along with SDRAM. Depending on the features and the manufacturer, I wouldn't be surprised also if some pedals from the big players, such as the Boss one I mentioned, used some ASIC instead of an off-the-shelf MCU/DSP to further cut costs down.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 25, 2020, 03:39:55 pm
content: Quote from: langwadt on July 24, 2020, 05:36:00 pmSince a typical use case is playback + recording at the same time, double that. If you want to support stereo, double that further. If you ever want to implement your looper such that it can read several "tracks" simultaneously and mix them in real-time while still recording (some loopers can do this), that can be yet a lot more.Now sure even a very lousy SD card these days will have read and write throughputs of several MBytes/s - on average, so average throughput shouldn't be a concern, but access times can be lousy and non-predictable on some cards, which have very lousy controllers, especially when you're constantly *reading and writing* alternately (as I mentioned, going for a class 10 card would likely be a smart move as it would give much more predictable acess times). I really suggest experimenting and see for yourself - between that and what I mentioned above about SD card libraries and filesystems, I'm not saying it's impossible whatsoever, but I'm pretty positive it's not going the picnic some appear to be thinking, at least if you want something reliable and 100% glitch-free.Of course I'm talking about something decent - commercial material. Now if all you target is a toy project based on an Arduino, and SDCard and maybe even internal ADC/DAC, being OK with occasional crackling sounds and low-fi audio, that's another matter entirely.Quote from: langwadt on July 24, 2020, 05:36:00 pmTypical use for "pedal" loopers is live use, or studio use but then you're usually fine as long as the pedal is powered on. But of course if it's a requirement, add non-volatile memory. Really depends on what you want to use that for. My two small cents - just don't underestimate the kind of headaches it could give you.

author: wizard69
author_rank: Super Contributor
timestamp: July 29, 2020, 01:32:41 am
content: In this case looking at what was done in the past doesn't make any sense to me. Instead evaluate contemporary tech that gets you the results you want. there are all sorts of storage technologies out there. Bubble Memory is a thing of the past, but there are modern things like MRAM that come in 16Mb packages, and FRAM. Not exactly high density solutions but very capable.In any event if you want cheap & high capacity the only answer is some form of EEPROM / Flash technologies.

author: duckduck
author_rank: Frequent Contributor
timestamp: July 30, 2020, 02:51:05 pm
content: Quote from: TheUnnamedNewbie on July 24, 2020, 12:56:55 pmBucket brigade chips are currently being made. Here's one for 5 pounds:https://electricdruid.net/product/v3208-2048-stage-delay-line/

author: avogadro
author_rank: Contributor
timestamp: August 01, 2020, 09:02:41 pm
content: Quote from: coppice on July 24, 2020, 03:50:36 pmSmack an FPGA in it and implement a turbo encoder. Easy