Electronics > Projects, Designs, and Technical Stuff

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

<< < (5/7) > >>

SiliconWizard:

--- Quote from: langwadt on July 24, 2020, 04:16:48 pm ---
--- Quote from: coppice on July 24, 2020, 03:50:36 pm ---
--- Quote from: amyk on July 24, 2020, 01:40:55 pm ---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.

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

--- End quote ---

cheap and readily available nonvolatile storage

--- End quote ---

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:

--- Quote from: Kalcifer on July 24, 2020, 04:15:20 am ---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.

--- End quote ---

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:

--- Quote from: SiliconWizard on July 24, 2020, 04:56:57 pm ---
--- Quote from: langwadt on July 24, 2020, 04:16:48 pm ---
--- Quote from: coppice on July 24, 2020, 03:50:36 pm ---
--- Quote from: amyk on July 24, 2020, 01:40:55 pm ---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.

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

--- End quote ---

cheap and readily available nonvolatile storage

--- End quote ---

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.

--- End quote ---

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?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod